Better singleplayer browser

[Simon]

Hi,

we had a little discussion on IRC about how the singleplayer browser should behave. I'm not content with the small preview, and Proxima is not content with the small area for level authors' names.



Here's a first sketch. Criticize, and dump more ideas here.

-- Simon

[Nepster]

What will you do if there are both levels and subdirectories in the current directory?

Why do we need larger preview images? What are they useful for, except as an additional reminder for players how a level looked like, if they have already played it before?

Isn't there enough space in the current design to use two lines for level authors if needed?

[ccexplore]

What will you do if there are both levels and subdirectories in the current directory?

First, my understanding is that while the underlying file system allows you to have a mix of files and subdirectories, in Lix the expectation (ie. convention) is that at each location you either have all subdirectories or all files [edit: at least as far as levels are concerned; I'm less sure about replays browsing].  At least, I haven't seen a compelling case where you'd want to mix subdirectories and files at the same location?

That being said, it seems the natural behavior with mixed content would be to show the "file view" (ie. the sketch on the right) whenever a level is selected, otherwise show the directory view (the sketch on the left).  Alternatively, Lix can enforce the (presumed) convention by always using the file view as long as there's at least one file, which makes it useless to mix subdirectories and files in the same location.

=====================

Why do we need larger preview images? What are they useful for, except as an additional reminder for players how a level looked like, if they have already played it before?

I'd think the preview is more for people who haven't played the level yet.  It may also be more useful in the multiplayer case which admittedly I don't have much experience with.

[Simon]

What will you do if there are both levels and subdirectories in the current directory?

This is important, and I have only loose ideas so far.

ccx is right about the tree convention: In the main download, each directory contains only subdirs or only levels.

We complicate matters by allowing to save new files from within the application. Levels are saved by editor or replay-level-extractor. I would like to allow saving everywhere, and have a mkdir button, within the save browser. I don't plan to offer file moving.

geoo would like to navigate subdirs with the up/down keys that navigate levels. Merging the level list and the dir list can be interesting. At the very least, that's fodder for object-oriented design with Simon.

Why do we need larger preview images? What are they useful for, except as an additional reminder for players how a level looked like, if they have already played it before?

Screen space should be filled with interesting stuff. Status quo: I waste screen estate with a mostly-empty directory listing. Enlarging the preview doesn't add information, but looks lovely.

Enlarging the preview is only one possibility to improve screen usage.

Isn't there enough space in the current design to use two lines for level authors if needed?

I agree that long author information is the weakest reason to redesign the browser.

Yes, there would be space. Multiple authors, or long names, could be linebroken automatically.

Having the author info in one line is preferable, because that part of the screen tables different statistics, each stat in its own line.

-- Simon

[Nepster]

First, my understanding is that while the underlying file system allows you to have a mix of files and subdirectories, in Lix the expectation (ie. convention) is that at each location you either have all subdirectories or all files [edit: at least as far as levels are concerned; I'm less sure about replays browsing].  At least, I haven't seen a compelling case where you'd want to mix subdirectories and files at the same location?

My current structure both for Lix and NeoLemmix is: One main directory where I save all the levels I am currently working on or temporary test levels. Then I have two subdirectories: One for the latest versions of finished levels and one for old versions of finished levels.
Of course one could put the non-finished/test levels in a separate subdirectory, but they need to be easily accessible, so I don't want to hide them in a subsubsubdirectory.

geoo would like to navigate subdirs with the up/down keys that navigate levels. Merging the level list and the dir list can be interesting.

This is an interesting idea. But then I would like to have a button/hotkey "Jump to top of the list = Jump to subdirs" without having to scroll through the list of all levels/replays in that directory.

Screen space should be filled with interesting stuff. Status quo: I waste screen estate with a mostly-empty directory listing. Enlarging the preview doesn't add information, but looks lovely.

Enlarging the preview is only one possibility to improve screen usage.

If you have too much space that needs filling, then I would suggest adding a scroll-bar in the level/replay list for fast movement within the list. Not as lovely as larger previews, but much more useful .

[Simon]

My current structure both for Lix and NeoLemmix is:
two subdirectories:

Yeah, I'd like to support that workflow. I bet many people do it similarly. And allowing that imposes the fewest restrictions on the level tree.

geoo and I continue to recommend git instead of manual subdirs for version control.

button/hotkey "Jump to top of the list = Jump to subdirs" without having to scroll through the list of all levels/replays in that directory.

Sensible, I'll be on the lookout for this. Or the dirs could remain visible at all times. If there is hotkey navigation for subdirs, an extra key seems required.

adding a scroll-bar in the level/replay list for fast movement

Yes!

-- Simon

[Clam]

Why do we need larger preview images? What are they useful for, except as an additional reminder for players how a level looked like, if they have already played it before?

I'd think the preview is more for people who haven't played the level yet.  It may also be more useful in the multiplayer case which admittedly I don't have much experience with.

If the preview is big enough (and the level itself isn't too big), you can use the preview to strategise before you even play the level. It's definitely more useful in multiplayer (better preview has been repeatedly, albeit not recently, requested for multiplayer), but for singleplayer I can imagine it being useful in deciding whether or not to play the level. In the best case, you can plot your solution from the preview and then go solve it straight away

In fullscreen, you might even be able to fit the level at full scale in that preview space

[Simon]

UI fail in D and C++ Lix: Iff we're not in the file-browser-specific root dir, "../" is at the top of the directory list. Now we mash "../" repeatedly with the mouse. We end up toggling between the root dir, and the first dir inside the root dir.

Mass-clicking "../" should not be dependent on how many dirs we have to traverse.

Inspired by 2012 blog post about UI abuse on Ipods. The blog site itself violates a design principle, WTF the UI clicks for you.

-- Simon

[NaOH]

-- Simon

For the first image (with subdirs), I feel like a grid format might be better suited than the linear format, just from an aesthetic perspective. Also, my gut tells me the ../ button should go at the top-right, not the middle-side at the top-left, not the middle-right. (Thanks, ccx.)

The title or path of the current directory might be nice to go at the top of the browser.

However, I think the main issue with the Lix browser is not the single-player browser but the multiplayer browser. Even if you don't have plans to implement multiplayer in D for a while, it still makes sense to think about what will be desired in the multiplayer browser. With enough foresight, you'll (hopefully) be able to use the same browser for both multiplayer and singleplayer.

Some issues with the existing multiplayer browser are:

• No interrupt signal when another player has chosen a level
• No signal that another player is currently choosing a level
• Preview does not display where exits and goals are and of what relative colours, which is essential for strategising (and strategising in advance is even more important in multiplayer than singleplayer because there will be no time to pause and think once the game has started)

And there are plenty others we've discussed before.

tl;dr: this discussion cannot just be about the singleplayer browser.

[ccexplore]

Also, my gut tells me the ../ button should go at the top-right, not the middle-side.

Actually, I think in most file browsers out in the real world, you'll find that the functionality for "up a directory" is typically near the top left.  If you decide to show the current path, then usually the up button is somewhere to the left of it (and in many file browsers you can also click the path components of the displayed path as buttons to go to the corresponding directory, but I digress).

It is good point though that with the given sketch, it is not even clear whether the ../ button will remain in the same location between the subdir and levels layout.  It would not be very desirable to have the button relocate between the two layouts.

Having brought up the ../ button, I'm actually wondering whether it's really desired to have that button located so separated from the list of subdirs/levels.  I kinda feel like maybe it's better for it to live as the first entry of the subdir/levels list.  Simon's issue about mass-clicking ../ can easily be solved by keeping the button shown even at root level but disabled.

[Proxima]

Also, could it be named something more indicative of its function than "../" ?

[NaOH]

Also, my gut tells me the ../ button should go at the top-right, not the middle-side.

Actually, I think in most file browsers out in the real world, you'll find that the functionality for "up a directory" is typically near the top left.

Whoops, that's what I meant! Fixed above.

Also, could it be named something more indicative of its function than "../" ?

'../' is the standard on UNIX, and this is probably why Simon is fond of it. I'm guessing most lix users probably won't be aware of the meaning of '../', though. Plus, '..' reminds me too much of terrible 90s filebrowsers like the one in QBASIC. Maybe something like an up-arrow or a left-arrow would be more helpful?

[ccexplore]

I've assumed that "../" (or ".." which isn't all that different) is not meant to be the final text, just something understandable for programmers to indicate the functionality in the sketch, eventually to be substituted by text more widely understandable by non-programmers.  It is indeed the case that an up arrow (or sometimes "<"*) is typically used in file browsers.  Slightly less common, some may use a left arrow to call out an (imperfect but close) analogy to the web browser's "back" button.

*It's a "left turned up" arrow.  I can't find a way to encode it here in a universal fashion except through using the Wingdings 3 font in Windows, in which it is assigned to the "<" character.

[Simon]

Agree with "../" not descriptive enough. In the root dir's blah-blah text, I've told people to play the tutorial, then click ".." when they're done. Instead of telling people what a button does, we should try to improve the button first.

I have never allotted vertical space to anything but the file list. With the file list's paging button, there are 20 files per dir shown at once. The lemforum pack has 40 levels per dir, a multiple of 20, probably because of this restriction. With a scroll bar, there is no advantage anymore in sticking to a multiple of max. visible entries. We can shorten the file list vertically.

I like ccx's breadcrumb navigation with buttons per nesting level, [levels] -> [single] -> [lemforum] -> Simple. Either in addition to an improved "../" in the top left, or instead of it. I haven't yet pondered how much screen space we should invest on the tree navigation.

-- Simon

[Simon]

Merged the dir list with the file list, and gave it a scrollbar.

Screenshots (click to show/hide)

I've left many bugs behind, and the exact placement isn't final either. But the big picture is coming through already.

Location of ".." is odd. Maybe shorten the list and put it above, as ccx said.

NaOH's points about the multiplayer browser are good.

-- Simon

[ccexplore]

Hmm, you never brought up how this would also affect the terrain(etc.) browser in the level editor, until now.  Having those big buttons for subdirectories there look a little odd on first impression, but I guess I can get used to it?   The breadcrumb bar might actually work best for that browser, though it's possible it may be a less familiar UI control for some people.