I also really like this demonstration. I was thinking about something
similar earlier today but this is way more thought through and is a great
basis for discussion
> Jochen Schulz :
> First I want to thank you for your work. I agree that the Rockbox menu
> structure needs some work and your mockups help as a basis for further
> discussion. Secondly I think that discussing the structure is currently
> more important than deciding upon the style of presentation (icons and
> stuff, which may be configurable at runtime or per target device
> What I like about your proposal is the focus on usage scenarios. This
> cleans up the root menu and helps the user find what he is looking for.
> I am using Rockbox on my Iriver H120 for almost half a year now and I
> still have to search for some settings now and then. And there are some
> menus that I would like to reorder or move somewhere else entirely.
Totally agree. Different users use their devices in different ways. In
particular, the habits for "ex iRiver users" are different from the habits
for "ex iPod users", "ex Archos users", etc. Some way of accommodating the
different behaviours (flexibly and reconfigurably) would be ideal. Not
sure that 'reconfigurably' is a word, however.
> What we still have to keep in mind is the different usage habits which
> all of us have. Saving a few keystrokes and "blind" usability (even for
> sighted users) may be preferable to reordering things strictly .
> Another topic which I think should be at least thought about in the
> same process is the mapping of keys. I cannot come up with
> irregularities that are annoying me at the moment, but I guess if I
> go searching for them, I will find some. ;-)
There's definitely two camps of thought already: some argue that Stop or
Left (on an iRiver device) should always "back out" of any menu and
eventually return you to the WPS. some argue that Stop in a menu should
stop playback and that Play should always back out of any menu and return
you to the WPS. But I think the current behaviour is somewhere in between -
Play sometimes operates like "select" and sometimes like "go to WPS", and
Stop sometimes operates like "back" and sometimes like "stop the music".
> Ok, to finally respond to your proposals, here are some random thoughts:
> - The purpose of the "play music" item is still unclear to me. I think
> the only reasonable action for it would be to just "Resume" from
> where I left. The other possibilities you list could be done via the
> - I like the idea of a "System" menu. The three "settings" items plus
> "Browse Themes" plus "Playlist options" Rockbox currently has in its
> root menu are a mess
Again, as a fellow ex iRiver user, I would agree
> - "Radio" and "Recorder" are just fine, IMHO. "Plugins" is ok, too,
> although I ask myself whether someone may think it may be a good idea
> to seperate "Games" from the rest of the plugins.
That would be neat (not necessary, but some users could find that useful,
and so it would be nice to make such a behavioural option available)
> - "View Pictures" may make sense on devices with large color screens.
> But: I guess this would just open a browser with a certain display
> filter (we don't want to generate thumbnails, do we?) which could be
> incorporated into the quick menu thingy (A-B in browser mode).
> - I am unsure about putting the bookmark settings into the playback
> settings menu.
> - AFAICS, you forgot to put "Recent Bookmarks" somewhere and I have no
> idea where to put it into the new structure.
> - I like the idea of making the bootup action user-configurable.
Me too - as I mentioned, I was thinking about this earlier today and
realised that some users like to boot into the file menu, some into the WPS,
and presumably some would like to boot into the main menu too.
Received on Tue Mar 7 23:37:14 2006
- application/x-pkcs7-signature attachment: smime.p7s