Editor, Giga's rant

[GigaLem]

And finally I have made the first Review, split off from my Blog thread.

Why the Lix Editor is not so good

I hope I explained everything. Had to use Google doc since Microsoft word was a no go.
If there's anything I missed I'll see If i can explain it. so without further ado, give it a read

[Simon]

Congrats on finishing this, thanks for the excellent read. It's hard to gain insight into people's workflows otherwise without watching them live.

The biggest issue of the Lix editor is that I re-use a graphical user interface designed for a game -- with large, oversized buttons and mostly icons instead of text -- instead of a GUI toolkit that produces a look and feel appropriate to the operating system. My high-level answer is that I should consider a standalone editor application. But that would be a massive project for the long term.

The finer points, I should reply to them them separately over time. Behind the map-size menu alone, there are enough stories to fill an entire post.

Some points aren't editor-specific; e.g., lack of custom background is a design choice of the entire game, even the background color is already a stretch because the tilesets don't need it. Or the clunky overall feel; I accept this feedback but can't act on it because it's so general.

-- Simon

[GigaLem]

Thanks for giving it read. I Do have habits with going off topic but when my mind springs an Idea. I don't want to forget an idea.
If you wish we can probably talk about a improved lix editor in another topic.

[namida]

It is worth keeping in mind that a very significant difference between Lix's philosophy and NeoLemmix's is that Lix focuses on functionality, with aesthetics as a much less significant concern; whereas NeoLemmix tries to accomodate for both. This explains the lack of eg. background image options. There are also very significant differences in the behind-the-scenes handling of physics (even if the physics themself may ultimately be similar) that may also make it trickier to add backgrounds and whatnot, although this is just a possibility (I don't know in full detail how Lix's rendering and physics work).

[Dullstar]

Congrats on finishing this, thanks for the excellent read. It's hard to gain insight into people's workflows otherwise without watching them live.

The biggest issue of the Lix editor is that I re-use a graphical user interface designed for a game -- with large, oversized buttons and mostly icons instead of text -- instead of a GUI toolkit that produces a look and feel appropriate to the operating system. My high-level answer is that I should consider a standalone editor application. But that would be a massive project for the long term.

The finer points, I should reply to them them separately over time. Behind the map-size menu alone, there are enough stories to fill an entire post.

Some points aren't editor-specific; e.g., lack of custom background is a design choice of the entire game, even the background color is already a stretch because the tilesets don't need it. Or the clunky overall feel; I accept this feedback but can't act on it because it's so general.

-- Simon

When I tried Lix compared to NeoLemmix, the clunky feel of the entire program was immediately obvious. Some of that comes from having become familiar with NeoLemmix first, but awareness that there is a large amount of overlap in the potential audience of the two programs can be something you could use to make transitioning between the two less jarring. Probably the simplest place to start would be a preset for NeoLemmix-like hotkeys.

The problems are a lot deeper than just negative transfer, however, but for that I'll need to find time to write up a rant on clunky UIs in general. There are a lot of them, and I think Lix's editor can benefit from a discussion of the large variety of editors of various types with bad interfaces.

[Simon]

Buttons bunched at bottom. They are in groups, but the grouping is not apparent at all. Yeah, looks like an uncoordinated cluster.

Hard to remember because they don't have a label, hmm, are you sure? Which of the icons are obstuse? Do you really suggest 30 words instead of 30 icons? If words plus icons on all 30 buttons, how to align?

Do you want to hide most of the buttons? These buttons aren't context-sensitive. The mirror button is there, and does nothing, when the tile selection is empty. That's bad, but buttons rolling in and out is also disorienting. This dovetails into a fundamental design choice:

Lack of context menu is good and bad. Right mouse button (RMB) doesn't access a context menu. Reason: Everything that would go into such a context menu instead gets a hotkeyed button. If you want speed, learn the hotkey, or even remap (some default bindings suck).

Lack of context menu costs discoverability and is hard to justify; it's geared towards the stronger users. Context menus are far slower than hotkeys. Context menus are only slightly faster than buttons at the side because they're local (no need to move mouse by large distance) but their buttons/entries roll in and out. Pie menus instead?

Instead of accessing a context menu, holding RMB scrolls. This, again, is the fastest and most precise way to scroll, far preferable to edge scrolling and, on small-to-medium maps, obsoleting minimap scrolling. The scrolling on RMB is extremely convenient and is the biggest argument against pie menus. Still, everybody and their cat understand that RMB opens context menus.

Disorienting because no border is shown. Yes, excellent criticism. The default zoom leaves you floating in the void. I'm planning the most straightforward fix for now, to always show more of the map when the editor starts.

Lack of new-map dialog is a feature. My goal is to remove dialog boxes wherever possible. Why do you want a dialog at start of map? You select the tileset when you insert the first tile. You select the map size once you're unhappy with the one-screen default.

Map dialog sucks. It's true and I would love to ditch this dialog. User should be able to drag the edges of the map, or at least click on the edges to do something with them.

No number entry widget. I rolled the UI toolkit myself and it doesn't have a number widget that has both up/down buttons and allows for entry of a number. You want direct number entry for the map dialog and the skills dialog. The map dialog should be abolished entirely, but the skills dialog should ideally get direct number entry, yes.

Background. Lack of background images is a feature. I'd love to cut even the background color. Haven't decided yet. Maybe introduce a gradient instead of one solid color. The background color is OK if it's subtle and dark. Backgrounds with more structure risk being mistaken for foreground; levels should be decorated with terrain instead.

Sonic sound test digit things are the standard presentation for colors, decimal digits would be weird. If the background is settable in a dialog, it should preview immediately when a value changes. Then the exact representation (hex or decimal) isn't even important.

This covers 1/3 of the rant and I'm happy to discuss this part in more detail.

Dullstar, have you gotten into UX professionally? Would love very much to see the more detailed rant on bad editor UIs.

The negative transfer from NL, yes, it exists, but I believe this belongs purely on NL's plate. For a long time, it forced its egregious unremappable hotkey layout on every NL user; it was impossible to rest the non-mouse hand in any place for long. Even offering such an archaic layout in Lix feels like a regression. If one is used to old NL keys and doesn't wish to improve, one is certainly free to remap even though it pains to see livestreams with mappins spread across the entire keyboard.

-- Simon

[Simon]

"Without a proper "Level start window" it can be a hassle trying to put the level together and figuring out where the level starts."

Lack of new-map dialog is a feature.

I misinterpreted (Level start window) as (dialog that appears when user creates a new map in the editor). More likely, you mean a rectangle drawn onto the editor canvas that marks the initially-visible region during play.

Initially-visible region depends on player's resolution. Normally, the game fits the map's height to the screen. When very large maps would need a zoom smaller than 1x to show entirely, the zoom is 1x instead and the screen centers on the average position of player's own hatches.

To develop a feel for big and small tiles, best advice is probably to learn how some common tiles relate to the lix's height and splat distance.

-- Simon

[Proxima]

My thoughts after reading the rant and Simon's feedback:

I know I took a while to get used to the icons on the Lix editor buttons and what each one means. The "group" button, for instance, requires you to interpret the three blobs as ungrouped terrain and the large blob as a group, so that the arrow means going from ungrouped to grouped. It's clear enough, but it doesn't have the immediacy that NL's button with the word "group" has.

Of course, the main point in favour of the icon is that it doesn't depend on a particular language; it's more universally accessible. It's up for debate whether Lix or NL is really accessible to non-English speakers, given that tooltips and menus are only in English (and German, for Lix). But at least I can appreciate that it's making an effort towards inclusivity.

I agree that in some situations, changing the level size with the mouse would be an excellent feature (particularly when you have placed terrain and want to shrink the level to just touch the terrain). But there are other situations where being able to enter a number is an indispensible effort-saver; the main one is when you have made a multiplayer level and want to make versions for other numbers of players, by changing the level size to exact multiples of its current size.

I'd be okay with culling the background colour feature. Lix never really needed it.

[GigaLem]

Background. Lack of background images is a feature. I'd love to cut even the background color. Haven't decided yet. Maybe introduce a gradient instead of one solid color. The background color is OK if it's subtle and dark. Backgrounds with more structure risk being mistaken for foreground; levels should be decorated with terrain instead.

Sonic sound test digit things are the standard presentation for colors, decimal digits would be weird. If the background is settable in a dialog, it should preview immediately when a value changes. Then the exact representation (hex or decimal) isn't even important.

This covers 1/3 of the rant and I'm happy to discuss this part in more detail.

Personally I would like to keep the BG color feature, and have it be improved on like, give some set colors you can choose or just choose your own. I found this to be a nifty feature and IMHO I want this feature in neolemmix as well

[Dullstar]

Dullstar, have you gotten into UX professionally? Would love very much to see the more detailed rant on bad editor UIs.

I'm no professional by any means. I've just used a lot of editors for various things, some of which were nice and intuitive, and some of which were quite terrible. It would very much be a user's perspective and focus primarily on which features make editors nice to use, and which ones feel super clunky. I want to get more experience with Lix's editor before I really write this, but I can already tell you that the new formats NL editor is easier to get started with, which is a pretty major advantage held by NL. Hotkeys are a great feature for power users, but you don't want an editor design that relies on them too much - it quickly becomes convoluted for people just starting out. Ideally, you should have a layout that still feels intuitive to mouse-users, as well as solid hotkey support. Typically, when using a new editor for the first time, I'm going to almost exclusively use the mouse to navigate, except for common keyboard functions that tend to be fairly consistent across similar programs. As I grow more accustomed to using the program, that's when I start learning the hotkeys, starting with the functions I use the most.

That said, based on the experimentation I've done with Lix so far, your UI is at least functional. I've used much worse. I can figure out how to do most things with a little clicking around, while I've definitely used editors in the past that were completely unusable without constantly referring to the help file.

On a separate note, I would say that lack of background images isn't really related to UI, though I don't think BG color is a good choice of cull - sometimes changing the BG color is a good idea to improve the contrast between the background and foreground. Otherwise, all graphics must be designed to have good contrast with whatever the default background color is, which is rather restrictive.

I will make it a goal to have the UI rant (it will focus on what makes an editor feel good and what makes it feel clunky, but I'll devote a section at the end to comprehensively review the Lix editor based on what I discuss in earlier sections) done by the end of May. I need more time to really mess with Lix to get a better understanding of the editor. I will write up a first impressions piece in the meantime. I've used it for a little bit, but not enough to really get used to its functionality.

[Dullstar]

Lix Editor First Impressions

First thing I immediately noticed - having music on the Lix menu isn't a bad idea, but it really shouldn't continue when I launch the editor. Second, it's good that the hotkeys are printed in the corners - that makes them discoverable. I would write out "Tab" instead of using the symbol simply because it may not be immediately obvious what key the picture refers to. It's not that the symbol is wrong - it's just not used often enough to be immediately recognizable. (EDIT: Enter is similar here. Symbol is probably fine for arrow keys, and the enter symbol is at least more recognizable than the tab symbol) Third, there's no obvious way to access the options (e.g. to change a hotkey) from within the editor.

The default hotkeys seem very strange to me, especially with regards to copy/pasting.

The weakest UI portion currently, in my opinion, is adding pieces. By default, the directory structure is convoluted. I don't know if the file organization makes sense from a programming perspective, but it's by far the worst part of using the editor. Probably the best solution here would be some way to choose to also show files in subfolders - that way, you don't have to keep opening and closing subfolders until you find the piece you're looking for. I agree with Giga that having steel as a separate category is unnecessary and makes things a bit clunkier. One of my biggest complaints about the piece selector is that you can't quickly switch between different types of objects. If you click Terrain, and realize you meant to click Steel, you have to close the Terrain window, then open the Steel window. Having a way to seamlessly switch between the windows would be helpful. Additionally, so much of the editor is keyboard navigatable that I'm actually quite surprised the piece selector isn't (if it is, the hotkeys aren't displayed and the obvious ones don't do anything). It's one of only a few things you actually need to use the mouse for. Arrow key navigation for it would be a great addition and would fit nicely with the way the rest of the editor is designed.

My favorite part of the Lix editor is definitely the interface for placing pieces once you've already selected them. It works as well (maybe even a little better) than NL. I'm not sure I'd use A as the default copy hotkey, but other than that it works pretty well.

When adjusting skills, number of Lix, etc. (basically anything involving choosing a number), I think using a number entry field would work better than the arrow options currently. I would suggest making infinity a button rather than putting it between 0 and 999.

The tooltips when hovering over buttons are a great usability feature.

Finally, NL allows the level to be tested a bit more easily than Lix.

Since the editor is integrated with the game, it's not a huge issue, but I found it odd that there wasn't a load button within the editor. Quit/new functions give a dialogue box when there is unsaved work and don't otherwise, which is good.

Given the choice, I'd prefer if duplicated pieces were placed directly on top of the originals, as in most cases it will reduce the number of button presses to get the piece where I want it, although the offset does make the fact that a new piece is present visually obvious.

Conclusion:
- Overall, your UI is nice and simple. Everything is easily discoverable, and other than the clunky piece selector, it's very easy to build a level quickly. If it weren't for clunky aspects I've mentioned, I would like it better than the NL editor. I did not find the buttons to be a problem.
- Improve the piece selector. It's where 90% of the clunkiness is happening. The remaining 10% is the number input UI. When it works smoothly, it is as good as or better than NL's editor. However, the overall experience of NL's editor is a little smoother because NL's editor lacks particularly clunky aspects.
- The options menu needs to be accessible from inside the editor - if it is currently, it's non-obvious how to access it.
- I do not think this editor needs context menus. I don't think they would add anything.
- I did not check resizing the level or screen wrapping.

Fix these, and I actually won't have any more negative to say about it. I actually probably won't say much more about Lix when I get around to writing the UI rant.

As for my preset suggestion earlier, I'd suggest an import/export hotkeys feature. This would let users make their own presets and share them easily. It looks like you CAN do this, but it requires editing the user data, which some people might not be comfortable with.

I've attached the test level I made. Don't expect much of a puzzle from it, though. It's just a simple 20-of-all-classic-skills level.

[Simon]

Thanks! I'll eventually write a detailed answer. Especially about adding tiles; adding tiles is the #2 editor task (#1 is move existing tile) and there are some reasons behind the design, but they clash with expectations.

Hotkey export: I'd like to ditch data/config.txt and data/user/yourname.txt and instead write either to game's root dir or a clearer-named subdir. I'm happy with writing 3 separate files for hotkeys, level progress, and other settings.

The hotkey A for copying is unusual; I should implement a copy buffer and then reconsider keys. The reason behind A was that it's the easiest to hit when ESDF moves tiles. Ctrl isn't bound to anything and should be bound to hold-to-add-tile-to-selection because that is universal.

-- Simon

[Proxima]

I agree with Giga that having steel as a separate category is unnecessary and makes things a bit clunkier.

NL has steel in every graphics set, and most levels use the same graphics set for terrain and steel. But in Lix, only a few of the more recent and rarely used graphics sets, such as raymanni's, have individual steel. The vast majority of levels use geoo/steel for their steel folder. The editor remembering the last visited folder for terrain and steel separately ends up being a huge convenience.

[Dullstar]

I agree with Giga that having steel as a separate category is unnecessary and makes things a bit clunkier.

NL has steel in every graphics set, and most levels use the same graphics set for terrain and steel. But in Lix, only a few of the more recent and rarely used graphics sets, such as raymanni's, have individual steel. The vast majority of levels use geoo/steel for their steel folder. The editor remembering the last visited folder for terrain and steel separately ends up being a huge convenience.

The folder structure itself strikes me as part of the problem (feeling quite clunky to navigate) but I'm not sure I have a good suggestion on how to fix it. It seems that Lix's tilesets don't really exist as distinct entities and are really just a collection of pieces in folders that happen to correspond to tilesets. Whatever the case, something about the interface needs to change.

Just messing with it a bit and brainstorming some possible changes, I noticed that part of the reason switching between different object types is so clunky is that the row of buttons at the bottom is nonresponsive while the object selector is open - meaning that if you mindlessly select the wrong object type (I do this way more often than I really should), it is necessary to completely close the object selector and then open the desired one - an extra click that serves seemingly no purpose. If I am currently in the terrain selector, then realize I need the steel selector, clicking the steel button should replace the terrain selector with the steel selector, rather than doing nothing like it does now. It probably wouldn't completely fix the clunky feel, but it would be a simple place to start that would offer at least some tangible benefit.

[Simon]

#208 Editor: re-click window-opening button closes modal window
#319 Terrain/steel browser: flatten dirs to one depth is in 0.9.17.
#325 Steel browser, start on geoo's steel is in 0.9.15.

Thanks for the ideas. It's worth to try these and get feedback.

Yeah, Lix tiles live in a tree, the game doesn't abstract into tilesets. It feels alien to force every tileset to make its own steel, steam, flingers, etc. Most tiles are at depth 2, some at depth 3.

Remember-last-dir separately for terrain and steel, along with the universal steel pieces; this is the main reason that steel is in a separate browser.



Still haven't replied to final 2/3 of Giga's rant and some of longer Dullstar post.

-- Simon