Usability: What to test with newbies?

[ccexplore]

It is an interesting question where to draw the line when it comes to level management and distribution features, how much to support in-game versus having the user use tools outside of the game.  Right now, one can argue that even just to play a custom level set, the user would need to have sufficient computer literacy to handle un-archiving a zip file or similar (as it likely comes in that form when downloading over the Internet via a web browser), and make sure it goes into the right directory within Lix so it shows up in the right place in the game.  If that's the expected baseline for the user's computer literacy to get involved with custom levels at the most basic level, it seems somewhat reasonable to expect that they probably also know how to manage files through the file manager of their choice (or at least whatever's bundled with the OS/distro).  So it becomes more just a matter of convenience to duplicate some of that in the game itself.  Creating new directories for example, Simon provided a fairly compelling argument to support in-game.  A poll or usability study amongst people who are new to Lix level editing could shed some light on which such features are ranked most desired to include in-game.

Interesting that the comment about the Edit button, which I started off with the result that some people apparently ended up interacting with buttons in a state where nothing happens, now becomes a discussion of protecting the user from accidentally overwriting "official" levels.  I do feel that it should be possible to open even official levels in the editor so that at least they can be examined in that setting.  Overwrite protection can be done at the point of the actual save attempt, rather than all the way out at the button that opens the editor.  I don't have any solid ideas yet in terms of how to designate which levels to protect, although in addition to the ideas proposed so far, I wonder if mybe a simple heuristic like the level's author != the user's name may work well enough 90% of the time?  And yes, there should be an option to disable such protection.

Alternatively, maybe the approach here should be to just keep some number of automatic backup of older versions each time user saves a level?  Of course this can also be a configurable feature in terms of enabling/disabling and how far to keep history.

[NaOH]

I do feel that it should be possible to open even official levels in the editor so that at least they can be examined in that setting.  Overwrite protection can be done at the point of the actual save attempt, rather than all the way out at the button that opens the editor.  I don't have any solid ideas yet in terms of how to designate which levels to protect [...]

How about 'write-protect' is a flag in the level. The rule is, a 'write-protect' level cannot be saved over except by a level without the 'write-protect' flag. (Edit: this is the same as "a 'write-protect' level cannot be saved over by another 'write-protect' level")

This means the user most open the level and un-check 'write-protect' in order to save it.

Seems much simpler than having a lock.x.txt file and I think it would be fairly intuitive.

[Nepster]

I agree with every point in ccexplore's first paragraph.

But I see a few problems with the rest:

I wonder if mybe a simple heuristic like the level's author != the user's name may work well enough 90% of the time?

What happens if someone fills in their forum name as the level author, but uses the real-life name as the user name?

Alternatively, maybe the approach here should be to just keep some number of automatic backup of older versions each time user saves a level?  Of course this can also be a configurable feature in terms of enabling/disabling and how far to keep history.

I usually keep several backups of my levels, which is currently difficult to keep track of. The reason is, that there is no in-game possibility to view the file name or file creation date. So one has to keep track of version numbers using the level's title (especially if versions differ only by minor backroutes-fixes), or always exit the game to move earlier versions to subfolders. Having automatic backups makes this problem only worse.

NaOH's suggestion of a 'write-protect' flag seems a cleaner solution to me.