From: Paul Louden <paulthenerd_at_gmail.com>
Date: Sun, 28 Aug 2011 08:22:45 -0500

On Sun, Aug 28, 2011 at 5:41 AM, Jonathan Gordon <jdgordy_at_gmail.com> wrote:
> My view regarding debug is that there is nothing there that is
> actually useful once a port is up and running *or during development*

Every now and then I've seen debug needed to check things in the past.
Personally, I'd disable it for release builds but leave it enabled for
current builds rather than requiring the user to do anything manually
to enable it.

> Equally, why are the settings given such high priority in the main
> menu? Sure they are useful, but after the initial player setup how
> many settings does one need access to? and given how poor the setting
> layout is it is likely regularly used configs are saved in .cfg anyway
> (and put on the quickscreen).

I don't really think your speculation on what the most likely way
users use the settings is means much. The honest truth is, we don't
know. People have asked for a quickscreen that can hold more settings,
meaning that there's at least 5 settings they want to change
regularly. There are many people who didn't even know you could save
custom .cfg files. We have no real way of knowing how the typical user
experiences Rockbox. Even a poll would give a decidedly skewed result.
We should be making our decisions based on something else. Perhaps
"what will help a new user most easily find what they need." I'm not
saying that explicitly, but rather, forward-looking ideas rather than
"I think this is how users already use our software" guesses.


> I think it makes sense to group items based on what they give the
> user. Files and Database are "Find music to play" and should be
> grouped. WPS, radio, recording are "listen to music" and should be
> grouped. System and Plugins are "misc" and should be grouped. Playlist
> catalog and bookmarks are "find previously saved playlists" and should
> be grouped.

I don't see how grouping is beneficial. Is the idea that they need to
be in groups to make it easier for users to spot them? Are users even
going to recognize that "playlist catalog" and "bookmarks" are the
same group? I certainly don't see bookmarks as a playlisting function,
at least. "Recording" isn't related to listening to music at all, and
is arguably the exact opposite. The groups seem a little arbitrary in
the first place, but I don't see a reason "grouping" is the approach
we should take with this list.

To me, rather, two things should be taken into account. What's visible
on the screen on our smallest screen targets with the default theme,
and what individual items are most likely to be sought. The screen
visibility seems important because when a user first turns on our
player, especially during the period they're unfamiliar, they're going
to want to glance at the screen and see useful options. Not remember
whether they need to go up or down to get to the ones they want. I
think it's convenient for the most used options to be the least
presses away, but "visibility on boot" is a little more important.

That being said, the below list isn't bad. On the Clip+ though, the
menu is six items I believe. This means "Recording, FM and System" are
visible on boot where Bookmarks and Playlist Catalogue are not. I'd
actually recommend moving FM below WPS, and squeezing those two
between FM and Recording. I don't mean to belittle the value of
recording, as such, but many of these devices don't even have the
feature, and even those that do are mostly sold as music players.
Features like Bookmarks and Playlists should be made more
visible/accessible. Someone who's bought a unit primarily for
recording purposes probably checked that Rockbox can still record
before installing it, and will scroll down to look for it..

>
> The order I'd like to see is then:
> Files
> Database
> WPS
> Recording
> FM
> System
> Plugins
> Playlist Catalogue
> Bookmarks
>
Received on 2011-08-28