The week in Palapeli: User research, or: Is that the opportunity?

What opportunity?!?

“Never miss an opportunity to throw away code.” — Guillaume Laurent

Ah.. that opportunity. But first things first: I have a patch in my working copy which throws the old Palapeli interface out, and only shows the new one. On Wednesday, I made some user research with this adapted version of Palapeli: I took three visitors of our local Linux User Group meeting, and presented them with a survey of 19 questions (essentially a UI walkthrough). During this survey, I saw that many terms used in the interface were ambigous or hidden too well (“Is saving to some internal storage, or to the hard drive, and what is this export all about?” or “If New starts a puzzle from the library, where is the function to create a puzzle from a custom image?”).

I had some thoughts about the results of this test today, and read some usability papers that Celeste linked in her last blog entry. My conclusions are:

• The user should not have to create savegames. The progress should be saved in the puzzle directly. That’s easier to manage, and looks more persistent. (Think of it like you take a box of jigsaw pieces, begin to assemble pieces, then put everything back into the box to continue later. It’s still the same box, not some magic copy of the box that’s being put in a special room.) If you want it, you should always be free to reset the puzzle, of course.
• The user should not have to save at all. The only real change is when a piece is moved, and the amount of changed data is so small that it these changes can be saved instantly. That removes these annoying “Do you want to save before closing?” dialogs.
• If you reopen your box of puzzle pieces, the pieces do not necessarily have to stay in the same order. We might reorder the pieces randomly when loading. (The persistence of piece positions should however be configurable.)
• On a side note unrelated to the above points, dockwidgets have been found to be unoptimal for the minimap and image preview as they produce large whitespace.

Now, what does these changes mean technically? (Attention, brain dump following.)

• On the interface side, these changes would effectively mean to throw out the new interface completely. The new code can however be reused to display the minimap and the image preview as (moveable) on-screen widgets.
• Inside the application, most of the code handling with loading and saving games has to be refactored. (That’s about 40% or 2000 LOC. The rest is 50% interface and 10% for the actual game engine. Remember the 80-20 rule?)
• On the library side, out with the GameStorage code. It has served its purpose very well in the last months, but I think it is overkill to use it anymore. The new storage could adapt the format currently used for the puzzle library, and extend on it for games being played currently.

If you have stood this brain dump, here comes my question: What do you think about this vision? The key is to view the puzzle as a single object with a persistent state (no more manual saving); where the only load/save is what is called import/export now: packaging the puzzles into files to share them with your peers.

About these ads