User Experience and Rockbox- A rethink required?

[adityabhandari]

Interesting discussions going on.

As concerns the issue of simulator firmware and my DAP firmware mismatch, the simulator version is as shown in the image

and my DAP firmware is 3.3(which is the latest I guess?)

Also, regardless of the FW, I've been facing the problem since I first moved to rockbox.



Didn't get much time to update today. But I did prepare some more material over the weekend. Would share soon

[[Saint]]

Ouch....burn.

Should've checked that one first.....absolutely nothing is displayed in the image except a message informing us that you can't perform this function using Imagebarn.

and my DAP firmware is 3.3(which is the latest I guess?)

Rockbox 3.4 was released on September 24, 2009 and is the current *release* build.

[St.]

[adityabhandari]

oops! i shall update this tomorrow morning, i don't have the simulator as of now...

edit:
Simulator version-r24039-091217
DAP version-3.3

[psycho_maniac]

i think its cool that there is discussion about this again. keep up the good work!

[torne]

oops! i shall update this tomorrow morning, i don't have the simulator as of now...

edit:
Simulator version-r24039-091217
DAP version-3.3

The appropriate version to install on your device to compare to that simulator is, unsurprisingly, r24039-091217, not 3.3 or 3.4. You won't be able to find that version, though, as current builds are not kept for that long.

Generally if you are testing things you should be using the latest current build on your player, not the release version.

[adityabhandari]

Check out thIs lInk.
http://docs.google.com/fileview?id=0B6bduX-uMpdUZTllZjFjNWUtYTk2My00ZjA0LTg0OWQtMjFkYTY4ZDM5MTY1&hl=en

[GodEater]

"Sorry, the page (or document) you have requested is not available."

Nice link

[saratoga]

It works for me now. 

Most of those changes look sensible to me, and some have been on various todo lists for a while (the EQ menu for instance). 

[adityabhandari]

I guess nobody read the first page on the pdf

ROCKBOX USER INTERFACE
Rockbox as a product has matured. So has its user-interface. The current UI is quite functional, if not beautiful. A few minor tweaks would make it even better. Rockbox as a DAP has matured. It supports a variety of players and a variety of codecs. It plays your music, radio, even acts as a recorder. It performs these functions more or less flawlessly. No doubt this is a huge achievement, however, we need to ask ourselves a few important questions.

Is there room for improvement?
Hell yeah!
A few points:
#Navigation to secondary menu's should have the similar intuitive way back instead of returning to the root menu
#RBX doesnt remember states. It should remember and tell the user about currently selected things. This includes all the settings as well as the database.
#Transitions in menu, help add a sense of direction to the menu layout and helps the user form a mental map of the menu more easily. transitions
#Advanced equalizer should be accompanied by a graphcal representation of the equalizer showing resultant of the changes being made. The equalizer can give information regarding lows, mids and highs according to corresponding frequencies
/-/The database should be made more reliable. It currently crashes a lot if too many buttons are pressed? Also, if load to RAM is enabled, it should be loaded to RAM at boot itself. Currently, it takes a while before the database is available to the user, especially if it is huge!
?Bookmarking should be more simplified and easier to understand
/-/It doesn’t sleep, it powers off, atleast in case of ipod video 5g
?Increase font size in headers
?Header information to be reviewed- Players of all screen sizes have the same header! Atleast in players with slightly bigger screens, the header could look better?s

What can we look forward to in rockbox?
Because of a relatively low prominence given to applications, rockbox doesn't really have many applications which people would use on a daily basis. Rockbox is primarily a music player and most ironically, neither of the applications put under the plugins>applications nodes is related to music! A lot of work can be done in this regard. Applications specific to music could be the next big thing for rockbox. A driving factor that can never lose charm since it's open ended. So many music based applications can be built! We have just the right platform for it, it's open-source and it's free. The potential is unimaginable. Rockbox could become a playfield of innovation through collaboration of individuals such as ourselves! Look at the way mozilla has flourished. Today, one can safely say that mozilla has become so widely adopted because of its support for extensions/addons. No wonder, it's a developers favourite browser as also of the everyday users.
To sum it all, I would look forward to the following things in Rockbox:
*Development of an API that simplifies the development of applications
*A simple way to apply ‘patches’ by non-developers as well, ie, without having to compile anything. E.g., there’s a patch out there that displays the metadata of songs instead of the filename in thet playlist view. And users like me want it, but can’t have it!




#UI Proposal provided
?UI Proposal can be worked out
/-/Conceptual suggestions, no UI proposal required

Edit
Also check out this file for the transitions in UI
http://www.box.net/shared/bpb4grc5i1

[Llorean]

#Navigation to secondary menu's should have the similar intuitive way back instead of returning to the root menu

Doesn't it work in almost all cases except the few, which we're already discussing action for on the list?

#Transitions in menu, help add a sense of direction to the menu layout and helps the user form a mental map of the menu more easily. transitions

Transitions slow down the user interface, and waste battery. This isn't a particularly good improvement. There is no "direction." You could be going down, or left, or up. Currently whichever menu map best fits your mind is what you'll imagine, rather than having a perspective forced upon you with a set transition effect.

/-/The database should be made more reliable. It currently crashes a lot if too many buttons are pressed?

"Please fix bugs" isn't something that should be brought up here, at all. If there are bugs, file proper bug reports, one report per bug.

Also, if load to RAM is enabled, it should be loaded to RAM at boot itself. Currently, it takes a while before the database is available to the user, especially if it is huge!

Do you mean that boot should be delayed until the database is ready? This seems like it would be very frustrating, as it's just means that it still takes just as long for users to get to the database, but if they didn't need it immediately this time they have to wait for no reason.

?Bookmarking should be more simplified and easier to understand

This isn't helpful at all. As we said earlier, please make specific suggestions, because "easier to understand" doesn't mean anything useful.

/-/It doesn’t sleep, it powers off, atleast in case of ipod video 5g

Why is powering off bad?

?Increase font size in headers

Do you mean the status bar? Please, try to use the same terms as the manual, or this discussion could become very complicated. The status bar is now user configurable.

?Header information to be reviewed- Players of all screen sizes have the same header! Atleast in players with slightly bigger screens, the header could look better?s

The status bar is user configurable - the user can now choose a theme which displays what they want.

What can we look forward to in rockbox?
Because of a relatively low prominence given to applications, rockbox doesn't really have many applications which people would use on a daily basis. Rockbox is primarily a music player and most ironically, neither of the applications put under the plugins>applications nodes is related to music! A lot of work can be done in this regard. Applications specific to music could be the next big thing for rockbox. A driving factor that can never lose charm since it's open ended. So many music based applications can be built! We have just the right platform for it, it's open-source and it's free. The potential is unimaginable. Rockbox could become a playfield of innovation through collaboration of individuals such as ourselves! Look at the way mozilla has flourished. Today, one can safely say that mozilla has become so widely adopted because of its support for extensions/addons. No wonder, it's a developers favourite browser as also of the everyday users.

Please, try to write specific suggestions. This isn't a press release, you're not pitching something to a sales department or trying to get venture capital. You're more or less wasting space with "just imagine all the great things you can do" segments.

*Development of an API that simplifies the development of applications

Being a non-programmer, are you deciding the current API is not simple simply because there are few apps, or what?

*A simple way to apply ‘patches’ by non-developers as well, ie, without having to compile anything. E.g., there’s a patch out there that displays the metadata of songs instead of the filename in thet playlist view. And users like me want it, but can’t have it!

This will never realistically happen. If you can create a binary patch, you've already got a build you could simply distribute instead. Patches are not for non-developers.

[adityabhandari]

Transitions slow down the user interface, and waste battery.

Then how come ipod comes with transitions and manages to last for upto 10hours before dying?

Do you mean that boot should be delayed until the database is ready? This seems like it would be very frustrating, as it's just means that it still takes just as long for users to get to the database, but if they didn't need it immediately this time they have to wait for no reason.

No, what I meant is that it should be loaded to RAM as soon as rockbox has booted, ie, the user is shown the root menu. This way, there'd be no waiting time for the user when he/she wants to use the database.

?Bookmarking should be more simplified and easier to understand
This isn't helpful at all. As we said earlier, please make specific suggestions, because "easier to understand" doesn't mean anything useful.

Please read the whole post, the legend is mentioned at the bottom.

?UI Proposal can be worked out

Why is powering off bad?

Because a lot of battery life is wasted in booting the player. Atleast this is what happens to my ipod 5g video, am assuming that similar battery wastage would be happening in case of other players as well.

?Increase font size in headers
Do you mean the status bar? Please, try to use the same terms as the manual, or this discussion could become very complicated. The status bar is now user configurable.

No, I mean the menu headers, e.g., the text 'Rockbox' that appears on the root menu. And speaking of terms, what is the correct term for these? Also, you spoke of customizable status bars, I believe the user can't choose at the moment the items he wants to see. If such a UI existed, can this be implemented?

Please, try to write specific suggestions. This isn't a press release, you're not pitching something to a sales department or trying to get venture capital. You're more or less wasting space with "just imagine all the great things you can do" segments.

So you're saying that you'd jump right in with me without knowing what the bigger picture is? What I've written can be seen as more of a strategy statement. Also, if agreed upon, it can be detailed out as well.

Being a non-programmer, are you deciding the current API is not simple simply because there are few apps, or what?

Yes, that's exactly what I am saying. Otherwise, why haven't there been no new applications added to the default set in the past year? I maybe wrong, but I am only working on the facts.

This will never realistically happen. If you can create a binary patch, you've already got a build you could simply distribute instead. Patches are not for non-developers.

Fine, but couldn't there be a way to model a few of these patches as 'addons' or apps?

[Llorean]

Then how come ipod comes with transitions and manages to last for upto 10hours before dying?

You do realize Rockbox gets better battery life than the original software right? I'm not saying menu transitions are a part of this, but is your point simply "I think 10 hours is good enough?"

No, what I meant is that it should be loaded to RAM as soon as rockbox has booted, ie, the user is shown the root menu. This way, there'd be no waiting time for the user when he/she wants to use the database.

Describe this more clearly. "Load to RAM" just means the database is loaded to RAM. This is exactly what happens if you have load to RAM enabled, and you boot the player (having already previously initialized the database). Clearly you mean something other than that, but I can't figure out what.

Please read the whole post, the legend is mentioned at the bottom.

This doesn't answer my question. I did read the whole post, and found nothing useful about bookmarking. Telling me to read it again is just insulting - instead of assuming I didn't read it and insulting me, why don't you assume I did read it and simply didn't understand and attempt to explain things better? This way I'm not offended, and you can clarify it for anyone else who might encounter the same difficulty I did.

We told you early on to give whole proposals. Saying "it can be improved" means nothing - you've neither stated what's wrong with it nor how to fix it. PLEASE stop making comments like that. If you aren't going to take the time to actually offer ideas for improvement, you're just wasting the time of anyone who reads this. Nobody can know if they agree with you if you don't even say what you think is wrong, or how you'd fix it. "It could be better" is true of every aspect of Rockbox. All of them. Re-stating it serves no purpose whatsoever.

Because a lot of battery life is wasted in booting the player. Atleast this is what happens to my ipod 5g video, am assuming that similar battery wastage would be happening in case of other players as well.

This is not the case. Sleeping wastes battery because the battery is slowly being drained even when the player isn't in use. Sleeping only saves power if you're going to be turning the player on and off frequently throughout the day. There are situation where sleeping is better, and situations where powering down fully is better.

The fact that your player only gets 10 hours in the original firmware suggests something is quite wrong with its battery already.

No, I mean the menu headers, e.g., the text 'Rockbox' that appears on the root menu. And speaking of terms, what is the correct term for these? Also, you spoke of customizable status bars, I believe the user can't choose at the moment the items he wants to see. If such a UI existed, can this be implemented?

Please, take some time to really learn about the features in the most current version of Rockbox. The status bar is customizable in themes.

As for menu headers, making them larger is wholly impossible until someone implements the ability to use multiple fonts. You'll find much discussion of this - it's not a design issue but an implementation issue.

So you're saying that you'd jump right in with me without knowing what the bigger picture is? What I've written can be seen as more of a strategy statement. Also, if agreed upon, it can be detailed out as well.

"make things better" is not a strategy. "make things better" also isn't a bigger picture issue. There isn't a strategy, and can't be. There is no consistent developer pool, nobody assigning tasks. The strategy is, and always will be, "people will work on what interests them." This needs to be a discussion of ways to improve things, so that people interested in improvement can have ideas. Not just a statement "things could get better."

Yes, that's exactly what I am saying. Otherwise, why haven't there been no new applications added to the default set in the past year? I maybe wrong, but I am only working on the facts.

No, you're not working on "facts" but "assumptions". There's a famous statement "correlation does not imply causation." There's not a lot of plugins because people don't often want to write plugins. The fact of the matter is that a digital audio player is a very limited environment. No magic API will change that fact.

People typically don't write plugins because the people who want plugins often aren't programmers, and the programmers often want to spend their time on making their device a better music player, rather than adding another toy to it that their phone can already do better.

Fine, but couldn't there be a way to model a few of these patches as 'addons' or apps?

They're called plugins...



One thing you're clearly missing is that you seem to have a concept that something can be "agreed upon." People, individuals, work on what they like.

You need to propose individual ideas that individuals can implement, not try to create some grand project scope.

[adityabhandari]

Wow, you're still up...nice

Describe this more clearly. "Load to RAM" just means the database is loaded to RAM. This is exactly what happens if you have load to RAM enabled, and you boot the player (having already previously initialized the database). Clearly you mean something other than that, but I can't figure out what.

That's exactly what I meant. If that's what is already happening, then I guess it takes a hell lot of time to load up since it's impossible to navigate the database right after booting.

This doesn't answer my question. I did read the whole post, and found nothing useful about bookmarking. Telling me to read it again is just insulting

I didn't mean to insult you and even pointed to the legend in the last post! The points with a '?' appended to them are the ones for which the UI proposal has not yet been provided but will be, in the future.

. There are situation where sleeping is better, and situations where powering down fully is better.
The fact that your player only gets 10 hours in the original firmware suggests something is quite wrong with its battery already.

In that case, isn't it better if we let the user decide what he wants to do with his player? This should be made configurable. Can we do this?
And yes, there's probably something wrong with the battery already considering that it is already 2.5 years old.

The status bar is customizable in themes.

The user should be able to customize it, using a UI, not the person making the theme. That's the whole point of 'customizing', I guess?  And please don't tell me that this can readily achieved by editing a text file, it probably does work that way but how about actually allowing the user to modify on the fly, while using the player?

"make things better" is not a strategy. "make things better" also isn't a bigger picture issue.

Below is what I had written in that particular para...please care to point me to the bit that you have "quoted" so much,ie, "make things better"?

This very much looks like a strategy.

Applications specific to music could be the next big thing for rockbox. A driving factor that can never lose charm since it's open ended. So many music based applications can be built! We have just the right platform for it, it's open-source and it's free. The potential is unimaginable. Rockbox could become a playfield of innovation through collaboration of individuals such as ourselves!

There is no consistent developer pool, nobody assigning tasks. The strategy is, and always will be, "people will work on what interests them." This needs to be a discussion of ways to improve things, so that people interested in improvement can have ideas.

So how is streamlining things a bit and focusing on building applications instead of looking to improve an almost well built product not helping to the improvement bit? Agreed that "people will work on what interests them". But, is it such a big crime to show them a potential playfield which is being consistently overlooked by them? And how could developing new applications not be interesting to developers, especially if the lead is taken by rockbox-heavyweights like yourself?

They're called plugins...

Again, at the cost of sounding redundant. These 'plugins' don't really offer any useful music-related functionality. And nor do they work in tandem with the main rockbox player!

[Llorean]

That's exactly what I meant. If that's what is already happening, then I guess it takes a hell lot of time to load up since it's impossible to navigate the database right after booting.

As I said, the only way it'd be possible to navigate the database immediately upon booting is if booting waited for the database to be ready before completing.

I didn't mean to insult you and even pointed to the legend in the last post! The points with a '?' appended to them are the ones for which the UI proposal has not yet been provided but will be, in the future.

As I also said, you need to offer actual suggestions. Not "this could be better, but I'm not going to say how." statements. Everything in Rockbox could be better. If you don't have a suggestion for it now, don't bother bringing it up until you have one.

In that case, isn't it better if we let the user decide what he wants to do with his player? This should be made configurable. Can we do this?

Again this is an implementation issue, not a design issue - there's no code to make it sleep.

The user should be able to customize it, using a UI, not the person making the theme. That's the whole point of 'customizing', I guess?  And please don't tell me that this can readily achieved by editing a text file, it probably does work that way but how about actually allowing the user to modify on the fly, while using the player?

Do you really expect the user to design bitmaps and position text on the player? Editing a text file on the player is actually more practical than a GUI implementation on the player for editing the status bar. You'll notice there's not even a GUI application for editing themes on the PC either.

This very much looks like a strategy.

Applications specific to music could be the next big thing for rockbox. A driving factor that can never lose charm since it's open ended. So many music based applications can be built! We have just the right platform for it, it's open-source and it's free. The potential is unimaginable. Rockbox could become a playfield of innovation through collaboration of individuals such as ourselves!

That's not a strategy. That's a statement of potential. You ramble about all the things that could be done. Yes, there are a nearly infinite number of things that can be done with open source. What is gained by saying "this could be done?" It causes nothing to happen, and you've provided no specifics. You've not given ideas for applications that could be developed, or improvements for existing ones.

This is the point I've been trying to make time and time again - stop with the sweeping general statements. They serve no purpose in this environment. Instead provide some focus. Details on where lack is found, and how it could be improved.

So how is streamlining things a bit and focusing on building applications instead of looking to improve an almost well built product not helping to the improvement bit? Agreed that "people will work on what interests them". But, is it such a big crime to show them a potential playfield which is being consistently overlooked by them? And how could developing new applications not be interesting to developers, especially if the lead is taken by rockbox-heavyweights like yourself?

With hundreds of reported bugs, and plenty of core functionality to be implemented, new targets to port to, etc, you really expect "applications", a secondary feature of the software at best, to be considered the best path of improvement? Surely fixing the bugs is the best path. Followed by making Rockbox available on modern hardware so that people can use it. Improving the audio quality and basic playback functionality must rank up there as well. Leaving applications at best in fourth place.

As to how people could not be interested? Ask yourself that. You yourself could be interested enough to spend some time learning to program and do exactly what you're suggesting. Instead, you are not doing so. Tell me, how can you not be interested enough? The same answer applies to everyone else - there's something they'd rather spend that time on. Just because someone might already know how to program doesn't mean they are more willing to do it.

Again, at the cost of sounding redundant. These 'plugins' don't really offer any useful music-related functionality. And nor do they work in tandem with the main rockbox player!

You said

Fine, but couldn't there be a way to model a few of these patches as 'addons' or apps?

You explicitly mentioned them being apps and addons. I can't read minds, so when you say something like "apps" I can't know that instead of meaning an external app, you mean integrated playback functionality.

There's no realistic way for patches to be non-developer. Due to the nature of the hardware it's almost entirely impractical for binary data to be shared between them (and in some cases wholly impossible) so even were they available one would have to be made available for every single player.

The closest to cross-platform compatibility would be, potentially, a plugin written in LUA.

[torne]

Regarding sleep vs power off: we don't know how to sleep on iPods. It would take someone considerable effort to discover how to do it by reverse engineering the original firmware. This is the first reason why such an option doesn't exist. If we knew how to do it then we could consider providing it as an option. Deep sleep (suspend to disk) on iPod Video would be better, as this uses the same amount of power as being powered off but would boot faster (db already in ram, etc), but that would be even more difficult to do

You state that powering on wastes a lot of battery life; while obviously booting does use some power (all those disk accesses, especially if you load the DB to ram), I am guessing you haven't actually measured this and are going by the battery life estimate displayed in Rockbox? This is an estimate, based on an assumption about average consumption and the reading from the battery ADC - this reading will have fluctuated between powering off and powering on again even if the battery level didn't change, because it's not an entirely stable measurement