UI failures in 0.4.3

[Nepster]

Here a list of UI fails. I only looked at the options, then browsed the level folder a bit and started one level. I will add more points to this list, once I encounter them.

• Setting the option to windowed mode takes only effect after restarting Lix. Either let it take effect at once or notify the player, that a restart is required.
• In the options menu, there is always an empty box at the bottom: I have no clue what this does?
• If you put a skill hotkey onto "<", it is displayed as "KEY.", which is not informative at all.
• There are hotkeys, that I will never need. But I have no clue how to set the respective hotkey to "no hotkey". Currently I put all these functions on the key that is farthest away from all other hotkeys, but this is more a hack than a proper solution.
• In the menu options you have a "Delete/no" hotkey. Usually I want "Escape" as a hotkey for "no", but I certainly don't want to delete levels by pressing "Escape". Moreover I have actually no clue in which situations this hotkey is used for "no" compared to the hotkey for "Back/cancel"?
• Menu options - "Export": I have no clue what this hotkey does? Levels and replays already exist as files, so they don't need to be exported. Can Lix now save images of levels and is "Export" used for this?
• Menu options  - "Replays": Save replays? Load replays? Delete all replays? What does this do?
• The default setting has two functions for the right mouse button: "Priority invert" and "Hold to Scroll". Do people really want to use both functions at the same time? I certainly prefer to have different hotkeys for them.
• Set the "Hold to Scroll" to an actual key (e.g. ctrl). Then it is super easy to move out of the game window while playing the level and pressing this button. This is pretty annoying. I don't know if it is any better when using the default setting - haven't tried this yet. And perhaps I just have to get used to this...
• When selecting a new directory with levels in it, no level is selected at first. Given the large empty space for the preview image, this looks now rather weird. Perhaps automatically select the first level when going in a new directory with levels?
• The scrollbar misses two features: Firstly, the button cannot be dragged. Secondly clicking onto the scrollbar background (where no button is) doesn't jump to the corresponding location.
• I have usually two folders "Nepster Test" and "Nepster Lix". If I go to subfolders of them, both of them are called "Nepster ." at the top of the level browser, so cannot be distinguished.
• tba.

[Proxima]

When selecting a new directory with levels in it, no level is selected at first. Given the large empty space for the preview image, this looks now rather weird. Perhaps automatically select the first level when going in a new directory with levels?

The problem with that is that when you want to create a new level, the easiest way is to navigate to the directory and click "Edit". This doesn't work if a level is already selected -- it will then edit the selected level instead. Perhaps there should be a separate "New Level" button.

[Nepster]

And here a list of problems with the editor:

• If you select several pieces, their rectangles "pulse". While the idea is nice, the frequency and brightness amplitude of the pulsing is far too high, especially if you select lots of pieces.
• Word "Constants" overwrites the hotkey. And I am not sure, "Constants" is the best description for the basic level properties. With constants I associated more stuff like level width/height and background color, because these tend to get changed far less often than level name, number of lemmings, ... and so are far more constant.
• "Looks" doesn't describe the menu either.
• menu "Constants": Swap level name and author.
• menu "Constants": The numbers are not consistently aligned. They should be either all centered or all right-aligned.
• menu "Constants": Number of players is less important (or rather: will be changed less often) than number of Lix, ..., so should be between Spawn Interval and Overtime.
• menu "Constants": Overtime should only appear when the number of players is at least two, i.e. when the level is a multiplayer level. Otherwise people will think, D-Lix continues to support time limits in single player mode.
• menu "Topology": Do you really think, that hex-values for width/height help people? My guess is, that they will confuse non-programmers to no end, especially as they will not know what the 0x in front signifies.
• menu "Topology": If you add space at the borders it should say "+128" instead of "128". Currently there is a big chance that new players will take these values as totals and not as relative changes to the current values. The additional "+" at least signifies a bit, that there is still some mathematical operation going on.
  You might even consider changing the description to "Add Left", "Add Right", ...
• The icon "Mirror tile horizontally" has a vertical arrow, leadig people to believe that it mirrors the tile vertically, i.e. interchanges top and bottom.
• While browsing through the tile folders, the buttons at the bottom are still visible. But they cannot be clicked! When I decide that I need a steel piece instead of a normal terrain piece, I have first to click on "Cancel" and then open the steel selection menu, instead of being able to click directly on the steel selection menu, despite it being visible.
• Even when adding a hatch, trap, ... it says at the top "Add terrain".
• The description for adding traps is "Hazard: Add a trap, water or fire". This is slightly misleading, because one can add other gadgets like springs or streams as well. Perhaps just add "or an interactive gadget" to the description?

[Simon]

Awesome lists! Thanks for such thorough weeding.

I blew my router at home. I'm catching up with the last 1-2 days from IRC and forum.

1. change resolution needs restart

Planned feature to explain every option. but change-resolution-needs-restart is so important that it needs a kludge until the feature.

2. In the options menu, there is always an empty box at the bottom: I have no clue what this does?

For the planned feature in #1 above. >_>

3. If you put a skill hotkey onto "<", it is displayed as "KEY.", which is not informative at all.

What key is "<"? German layout and the key between left-shift and Z? I query Allegro 5 for key names, and maybe it has crappy key names for some. What integer ID is that key in your user save file?

Or do you mean "<" as arrow-left? Want to replace arrow-left with unicode arrow left.

4. There are hotkeys, that I will never need. But I have no clue how to set the respective hotkey to "no hotkey". Currently I put all these functions on the key that is farthest away from all other hotkeys, but this is more a hack than a proper solution.

Agree that we need delete-hotkey, even while only 1 key assigned.

5. In the menu options you have a "Delete/no" hotkey. Usually I want "Escape" as a hotkey for "no", but I certainly don't want to delete levels by pressing "Escape". Moreover I have actually no clue in which situations this hotkey is used for "no" compared to the hotkey for "Back/cancel"?

Never thought much about it. Open for input. Make many more hotkeys?

Menu options - "Export": I have no clue what this hotkey does? Levels and replays already exist as files, so they don't need to be exported. Can Lix now save images of levels and is "Export" used for this?

Unimplemented feature. The key saves images of levels in C++ Lix.

Menu options  - "Replays": Save replays? Load replays? Delete all replays? What does this do?
The default setting has two functions for the right mouse button: "Priority invert" and "Hold to Scroll". Do people really want to use both functions at the same time? I certainly prefer to have different hotkeys for them.

geoo and I want it on same button. Open for alternative suggestions. Default hotkey layout is not holy, hack it apart if needed.

Need visualization of priority invert.

Set the "Hold to Scroll" to an actual key (e.g. ctrl). Then it is super easy to move out of the game window while playing the level and pressing this button. This is pretty annoying. I don't know if it is any better when using the default setting - haven't tried this yet. And perhaps I just have to get used to this...

Ease of mouse-leaves-window shouldn't depend on where hold-to-scroll is bound. Does it depend?

How difficult is moving the mouse out of the window?

Meet me in IRC #lix to discuss technical crap associated with the mouse -- when I have a working router in a week >_>

When selecting a new directory with levels in it, no level is selected at first. Given the large empty space for the preview image, this looks now rather weird. Perhaps automatically select the first level when going in a new directory with levels?

Hard, but probably better to show 1st level than to not show anything.

I have planned "play next level" and "play next unsolved level" in the you-win dialog at end of level. Such functionality is good too for select level in chosen folder.

Bitter aftertaste: Computer wants to be smarter than the user and shows a level, even though it may take long to render. This is an architectural problem, maybe I should cache preview images. Maybe the browser should show preview images of many levels right in the level list.

Proxima's button for new level: Good suggestion no matter what we do here. My normal method is to edit any level and click new-level during editor. Can't inflict this longcut on newbies either.

The scrollbar misses two features: Firstly, the button cannot be dragged. Secondly clicking onto the scrollbar background (where no button is) doesn't jump to the corresponding location.

Known bug. Even though it's on the bug tracker, it's good to bring it up again, because it's important.

I have usually two folders "Nepster Test" and "Nepster Lix". If I go to subfolders of them, both of them are called "Nepster ." at the top of the level browser, so cannot be distinguished.

Design debris. I rushed the breadcrumb navigation and made stuff fixed-with. Now it bites.

-- Simon

[Nepster]

3. If you put a skill hotkey onto "<", it is displayed as "KEY.", which is not informative at all.

What key is "<"? German layout and the key between left-shift and Z? I query Allegro 5 for key names, and maybe it has crappy key names for some. What integer ID is that key in your user save file?

Or do you mean "<" as arrow-left? Want to replace arrow-left with unicode arrow left.

The key between left-shift and Y (in the German layout). In the user file it is number 71 and NeoLemmix calles it 0xE2.

5. In the menu options you have a "Delete/no" hotkey. Usually I want "Escape" as a hotkey for "no", but I certainly don't want to delete levels by pressing "Escape". Moreover I have actually no clue in which situations this hotkey is used for "no" compared to the hotkey for "Back/cancel"?

Never thought much about it. Open for input. Make many more hotkeys?

I looked a bit around where this hotkey is used. Apart from deleting levels, the only other place I found is when quitting the editor without saving.
But this dialog has other problems as well: To exit the editor I press Escape. But then I have to change the hotkey to confirm it, because pressing Escape again means cancelling exiting the editor. Lovely double-negation here .

So I propose changing the buttons in the "Save changes of this file" dialog to:
- "Discard" - using hotkey Back/Cancel (Escape)
- "Save" - using hotkey OK/Yes (Space bar)
- "Return to editor" - using hotkey Edit (F)

[Nepster]

Lix just crashed: D-Lix doesn't automatically create a "replays" folder if it doesn't exist yet, but instead produces an error.

[Simon]

Reply to Nepster's reply #4:

Esc-Esc to exit the editor: Tricky.
A: If we have (exit editor) and (confirm to lose data during exit of editor) on same key, then we lose data by mashing Esc.
B: t's good design to eventually come back to main menu, and then exit the program, with Esc-Esc-Esc-...

Do you feel that B weighs more than A? And that most users are OK with losing data when mashing Esc like a madman?

Replies for editor UI:

If you select several pieces, their rectangles "pulse". While the idea is nice, the frequency and brightness amplitude of the pulsing is far too high, especially if you select lots of pieces.

Thanks. Hovered pieces must be brutally visible, because the next mouse click depends on what's hovered. Selected pieces may be less brutal indeed.

Word "Constants" overwrites the hotkey. And I am not sure, "Constants" is the best description for the basic level properties. With constants I associated more stuff like level width/height and background color, because these tend to get changed far less often than level name, number of lemmings, ... and so are far more constant.

Overwrite of hotkey: Bug, I want the hotkey to go in front.

Bad name: Agree. "Properties" sounds too inclusive, good naming is exclusive. "Properties" is better than "Constants" still.

"Looks" doesn't describe the menu either.

The menu sets bg color and starting position. Suggestions for alternative names?

menu "Constants": Swap level name and author.

Okay.

menu "Constants": The numbers are not consistently aligned. They should be either all centered or all right-aligned.

Right. Thanks.

menu "Constants": Number of players is less important (or rather: will be changed less often) than number of Lix, ..., so should be between Spawn Interval and Overtime.

Agree how the existing layout isn't optimal.

Problem: I want to show different widgets depending on (player number == 1) or (player number > 1). The overtime is only a multiplayer setting. The save requirement is only a singleplayer setting. When B's availability depends on A, then A should come before B.

Maybe the entire dialog must look differently for this.

menu "Constants": Overtime should only appear when the number of players is at least two, i.e. when the level is a multiplayer level. Otherwise people will think, D-Lix continues to support time limits in single player mode.

Yeah.

menu "Topology": Do you really think, that hex-values for width/height help people? My guess is, that they will confuse non-programmers to no end, especially as they will not know what the 0x in front signifies.

I use only the hex numbers, because all the terrain blocks come in base-16. >_>

C++ Lix hid them behind a checkmark, so you weren't confused until you explicitly asked for hex. For D Lix, I felt that hiding 1 or 2 lines of text doesn't justify the checkmark. I may be wrong.

I want to keep hex at least somehow, and I don't want to scare people. Thus: Need user testing.

menu "Topology": If you add space at the borders it should say "+128" instead of "128". Currently there is a big chance that new players will take these values as totals and not as relative changes to the current values. The additional "+" at least signifies a bit, that there is still some mathematical operation going on.
You might even consider changing the description to "Add Left", "Add Right", ...

Awesome, agree with the "+".

The icon "Mirror tile horizontally" has a vertical arrow, leadig people to believe that it mirrors the tile vertically, i.e. interchanges top and bottom.

I want to mirror horizontally, much more useful than vertical mirroring.

Needs new icon. The tree was excellent because it meant terrain. But the tree is invariant under horz mirroring, so need different icon.

While browsing through the tile folders, the buttons at the bottom are still visible. But they cannot be clicked! When I decide that I need a steel piece instead of a normal terrain piece, I have first to click on "Cancel" and then open the steel selection menu, instead of being able to click directly on the steel selection menu, despite it being visible.

Smart. Needs a powerful solution, will think about it.

Even when adding a hatch, trap, ... it says at the top "Add terrain".

Oversight, good find.

The description for adding traps is "Hazard: Add a trap, water or fire". This is slightly misleading, because one can add other gadgets like springs or streams as well. Perhaps just add "or an interactive gadget" to the description?

Smart. Yeah.

-- Simon

[Nepster]

Esc-Esc to exit the editor: Tricky.
A: If we have (exit editor) and (confirm to lose data during exit of editor) on same key, then we lose data by mashing Esc.
B: t's good design to eventually come back to main menu, and then exit the program, with Esc-Esc-Esc-...

Do you feel that B weighs more than A? And that most users are OK with losing data when mashing Esc like a madman?

It is good to have this safeguard, but if I want to save a level, I usually do so before hitting Esc. So I want "exit without save" much more often than "save and then exit" and prefer an easy way to exit the editor.
Whether this can be generalized to the average user, I don't know at all.

If you select several pieces, their rectangles "pulse". While the idea is nice, the frequency and brightness amplitude of the pulsing is far too high, especially if you select lots of pieces.

Thanks. Hovered pieces must be brutally visible, because the next mouse click depends on what's hovered. Selected pieces may be less brutal indeed.

Once selected, the slight pulsing is fine. But the brutal hovering stuff annoys me! The current situation is fine, if you only select a few pieces and they are properly aligned so that some of the pulsing lines coincide. But once I use more tiles in a small region that do not properly align, this starts to get terribly annoying.
Let's make a test: Load the attached level with only 35 pieces and try to select all pieces of one of the colors.
And now imagine how this looks if you have three (or more) times as many pieces there. (And yes, this happens in my levels.)

menu "Constants": Number of players is less important (or rather: will be changed less often) than number of Lix, ..., so should be between Spawn Interval and Overtime.

Agree how the existing layout isn't optimal.

Problem: I want to show different widgets depending on (player number == 1) or (player number > 1). The overtime is only a multiplayer setting. The save requirement is only a singleplayer setting. When B's availability depends on A, then A should come before B.

Maybe the entire dialog must look differently for this.

Perhaps add a switch-button at the top, selecting between single-player and multi-player?


And another bunch of stuff that doesn't work as expected:

• When shrinking the level, the screen position in the editor does not get moved accordingly into the level area. So until you move the screen manually, a part outside the level is visible (and sometimes displays weird graphical glitches).
• Go to the terrain selection geoo/construct: The pieces precisely fit in one screen of the selection menu, but the scrollbar still appears. Moving the scrollbar does have no effect at all on the displayed terrain pieces.
• The editor needs a hotkey for saving the level and zooming.
• Zooming in the editor: Currently it cycles always 1x -> 2x -> 4x -> 1x. But when I have worked zoomed in for some time, I usually want to return to the normal view and not zoom in further.
  If you plan to include zooming out as well (which would sometimes by useful too) some time in the future, then a completely different solution might be necessary. Not sure about the best soltution though.
• By default, "B" moves tiles to the Top, while "T" moves tiles to the Bottom. Logical, right?
• When selecting various terrain pieces by drawing a rectangle in the editor, the mouse can move outside the level area onto the buttons. This happens actually fequently when I want to select a large part of a level, because I draw a rather large rectangle very fast. So in addition of the (wanted) selection of the tiles, I modify them as well or open the skill menu (unwanted).
  I am not sure whether restricting the mouse to the level area or simply ignoring the pressing of the button (or something completely different) is the better solution to this.
  
• Levels without hatch have no preview image displayed at all.
• Options -> General menu: Most of it is ordered vertically, only "auto-save level solutions" and "sound volume" are in one line. But certainly one does not only set the volume of the auto-save sound ?

[Nepster]

Time for another addition to the buggy editor-UI list:

• The X- and Y-coordinates of tiles in the editor are not displayed anywhere. How can I find out, what the mysterious group is that sits at 1544/256?
• If you save a level as "Level:V2" (because of a typo), Lix does not complain about invalid characters, but saves an empty file "Level" (without any extension).
• Moving several tiles to the backgrund/foreground does not preserve the internal order of tiles, if the selection contains both normal pieces and black pieces.
• If I come back with the mouse from outside Lix, the displayed cursor does not always coincide with the actual cursor position. I have yet to find a consistent way to reproduce this.
• There is no way to undo a tile grouping. This is especially annoying when the group contains tiles, where the rotational 1-pixel shift messed up the carefully arranged terrain.
• Topology menu: If you add/remove space at the top/bottom, changes to the width of the level (instead of the height) are displayed below. The actual changes to the level are done correctly - just the displayed change in the topology menu is wrong.

Edit: Added another point to the list.

[Simon]

Thanks for the continued bug hunt!

0.4.4 fixes:
* crash on nonexistant browser base directory
* draw button hotkeys on top of button captions
* when changing z-order, preserve relative z-order of selection

30 or 40 bugs is too much to fix before asking people to migrate. Especially UI fails are okay to postpone: We ask Lix level designers to migrate who have used C++ Lix and know its quirks. I suggest to fix these issues before migration:

#86: Colon in filename -> save empty level (because it threatens data)
#82: Grouped steel becomes earth (affects physics)
#87: Implement ungroup (huge annoyance)
#88: Show coordinates of hovered tile (huge annoyance)

You can file bugs directly on github. I've filed issues for these 4 bugs. They get a globally unique ID, and we can close them straight from git commit messages.

Pixel-perfect noow algorithm: This would generate the same physics as my impl, but group fewer tiles. You (Nepster) have made the tile-heaviest, no-overwrite-heaviest levels so far. Can you wait with the most problematic levels, or redesign them by hand? Then we can wait with the pixel-perfect noow detection.

-- Simon

[Nepster]

You (Nepster) have made the tile-heaviest, no-overwrite-heaviest levels so far. Can you wait with the most problematic levels, or redesign them by hand? Then we can wait with the pixel-perfect noow detection.

No problem, pixes-perfect detection would be convenient, but isn't necessary strictly speaking.

But I just found one more issue, that I would fix before migrating: Display the (constant) SI while playing a level.