User Experience and Rockbox- A rethink required?

[adityabhandari]

As for how it looks, most of the players have screens wider than they are tall so the equalizer more readily fits rotated as it is. Are you really saying that it's confusing to users that something has simply been rotated?

That's exactly what I am suggesting! Would you be used to a rotated number-dial on your cell phone?

It is physically impossible to design something above a certain degree of complexity without requiring reading. Including tooltips in the product is just a way of disguising the manual as the software - for something you use regularly and want to keep lean isn't it better to keep them separate and individually efficient?

I understand what you're saying and that's why I mentioned earlier that we should use the tooltips very judiciously and only where they are deemed absolutely necessary. Also, I forgot to mention. The tooltips need not be permanent. The user should have the option of turning them off after he/she feels that they are not needed.

Also, keep in mind that Rockbox isn't a product.  Sure, we would like people to use and enjoy it, but we don't have to go for the lowest common denominator in order to chase sales.

Again, I just want it to get more efficient at what it already does The bottom line is that no user, and I am assuming all users to be fairly technical, should have their 'WTF' moment with Rockbox. I've had my fair share of those and that's why I am here


Also, I am leaving for the day! It's 8.30PM and I am still in office. I should be home.

Will take the conversation forward tomorrow!

[Llorean]

As for how it looks, most of the players have screens wider than they are tall so the equalizer more readily fits rotated as it is. Are you really saying that it's confusing to users that something has simply been rotated?

That's exactly what I am suggesting! Would you be used to a rotated number-dial on your cell phone?

That's a very different situation. A cellphone keypad is used frequently and subject to muscle memory. An equalizer is adjusted rarely, and the visual display of the equalizer does not affect the physical inputs necessary to adjust it in any way.


On the subject of images that you brought up earlier - what sort of redesign do you have in mind? Rather than listing problems that exist, why not start out with a rough description of what your ideal Rockbox would be like in terms of UI?

[ew]

Please forgive me if my ideas are off base, or impractical, but a variation of tool tips may be something workable.

Now that there are themes (with the sbs file), perhaps a way to implement a tooltip would be to have the tip display in a special area (say at the bottom of the screen) using a token in the sbs.

To elaborate:
- The tool tip would be some additional text that would be displayed along with a menu item.
- The tool tip text would be displayed as defined in some new wps token.
- Tool tip placement and use would be up to the theme developers
- Perhaps tool tip text could be added as an element to language files, thus allowing languages and customizations as desired (I am sure there could be some humorous ones as well)

Does this make sense?

Is this doable?

Is it beneficial?

[adityabhandari]

That's a very different situation. A cellphone keypad is used frequently and subject to muscle memory. An equalizer is adjusted rarely, and the visual display of the equalizer does not affect the physical inputs necessary to adjust it in any way.

They're not, not really. If you go one level deeper, they have much to do with the user's mental model of a certain product.


From now on, I will not propose any fixes/ideas here until I have UI proposals for them. However, I will keep you all updated about the latest in the form of daily reports and if I have any doubts.

Summary report for today
I have not had much time to post here today but I have downloaded all the simulators today. I saw some of them and I have a definitely-positive feeling that we can pull off universal usability fixes.

Last night, I sat down and thought about what UI design is all about. It's about users of course and how they interact with a product. In this context, I'd like to ask if we have any specific data/ statistics about rockbox usage? E.g.: Number of total downloads so far, and which ones are the highly used players? What is the level of technical expertise of rockbox users?Etc..
How it could possibly help?
It's always better to know what segment we are designing for. It will also put to rest claims that it is mostly developers who download and use rockbox. Or that all rockbox users have advanced needs.
It may not be the case, OR it just might. In the end, we'd have the truth, cold hard facts, and not opinions.
And based on facts, we can create a sort of persona for the 'average' rockbox user whom we can further design the product for.

I have a feeling that such data does not exist. So, my proposal is that we conduct this data collection exercise in the form of a questionnaire. The questionnaire can be featured in a section which is frequented by most users. How about that?

Regarding Images-A case for moving forward to .png and .jpg
Bitmap files(.bmp) are uncompressed and huge, in comparison to .jpg which are used universally across the web but do not offer transparency. The best case would be to support .png which is a very lightweight image format that also supports transparency.

[Llorean]

I think you missed a few specific points: It's not necessarily desired to design for the "average" Rockbox user.

This isn't a "product." It's not sold. It does not need to increase its market share. It needs to increase its developer count - people interested in contributing code and time to improving it.

Therefor while the majority of users may not be technical or advanced users, the target audience is not the same as the majority user base.

Any usability "improvements" need to not be considered regressions by the people actually working on the software - they need to make it better for the developers first.

Regarding Images-A case for moving forward to .png and .jpg
Bitmap files(.bmp) are uncompressed and huge, in comparison to .jpg which are used universally across the web but do not offer transparency. The best case would be to support .png which is a very lightweight image format that also supports transparency.

Even on software that uses PNG/JPG at some point the image is decompressed to BMP before display. BMP has the advantage of requiring little to no processing for use (remember, these are very limited devices) whereas PNG would either need to be decompressed on load (in which case it's less efficient than BMP - processing on loads and still uses the same RAM) or decompressed on display (could use less RAM, but quite a bit more CPU time).

As well, the core Rockbox UI is not image based. With a few key exceptions (the sliders in the equalizer, for example) all images in the Rockbox UI are part of themes, and are completely customizable by the user. So again, you really shouldn't be thinking much about images - the UI you're designing shouldn't incorporate any of its own, nor require any, if possible.

[GodEater]

It's always better to know what segment we are designing for. It will also put to rest claims that it is mostly developers who download and use rockbox.

I don't think I saw anyone claim that we thought it's mostly developers who download and use Rockbox. The issue is though that the developers design Rockbox for themselves, not for users. We welcome users to come and use our toy - but it's our toy, designed by us, for us.

And based on facts, we can create a sort of persona for the 'average' rockbox user whom we can further design the product for.

We don't design for the average rockbox user though - we design it for us. If the 'average' rockbox user finds it useful, great. If they don't, well - no-one's making them use it.

Now, we're still not claiming that the UI is perfect, but too many people have arrived at www.rockbox.org, tried it out, and liked it's features, but not the UI. In most cases this is because they got used to the original firmware of their player before they came here. Many of the "old hands" here disagree with people who claim the original iPod firmware is "intuitive" or "easy to use". It's not. It's just that more people are used to it. The assumption by those people is though that we'd want to change our interface to be more like player X's original firmware, but with all the features that Rockbox offers. This is simply not the case.

[Llorean]

Just to tack on to Godeater's post. I think many of the developers agree that the UI could be improved, possibly significantly. The key point is that the target audience is always going to be the people making the software, so improvements for other audiences need to not take away from what the developers are getting out of the software.

So there's no objection to improvement ideas. Just bear in mind that it seems like developers designed the UI because they did design it, and a lot of choices were made to suit the target audience - themselves.

[nls]

Many of the "old hands" here disagree with people who claim the original iPod firmware is "intuitive" or "easy to use". It's not. It's just that more people are used to it.

This is so true!
I have recently started using my firs ipod after years of only rockbox players and the interface often leaves me guessing which button to press and trying at random.

I think a better and less intrusive way to have hlp tesxts is a menu itme in the context menu, that shows a "help screen" with relevant help text, will require that users know about the co text menu but it's such an important feature of our UI that they will eventually, I hope.

[Biont]

- The tool tip would be some additional text that would be displayed along with a menu item.
- The tool tip text would be displayed as defined in some new wps token.
- Tool tip placement and use would be up to the theme developers
- Perhaps tool tip text could be added as an element to language files, thus allowing languages and customizations as desired (I am sure there could be some humorous ones as well)

I am no developer and I am lacking an artist badge, but I must say that I really like this idea. This could well be implemented in sbs-supporting themes - maybe (optionally) after a timeout. If we leave it to the themers, there are no problems with the plain default menu.

It would be hard to implement this feature on devices like the sansa clip, but I already used a rockboxed clip and I think its interface is a lot better that the current Cowon D2 interface (YMMV)

The D2 and the iPod Video however would allow for much more on-screen information that could even be displayed in a separate "window". And there sure are more devices that would be capable of this

So if you really need to stress people to RTFM: Leave it to the devices that can't suport the tag because of the screen size.

Usability!

[tdb]

I am not a dev and very pleased with Rockbox. UI could be more intuitive for the novice user , but there are so much settings you can adjust in Rockbox I doubt it will ever be possible to make it easy for everybody.

What I would like to see though, is a method to adjust the UI myself. I have given away on of my rockboxed Clips to my mother and she is not very technically savvy.
By hiding the menus and settings she will never use it will become easier to navigate.

She will not need playing lists, adjust settings, radio, plugins, system etc.
The only thing she needs is bookmarks, files, resume playback and the sleep timer. The rest of the menu is bloat and more confusing for her.

If it would be possible to change a configfile or mark/unmark the menu entries in rockbox that would be a very nice option. People could configure their own UI then.

[AlexP]

Everyone should search the forums for for previous discussions on menu customisation - it is a controversial subject.  Personally I'm not in favour, but I wouldn't argue against it given some provisos such as must be easily resettable, maybe some items cannot be hidden, people reset to standard menus before asking for support, etc. (i.e. I'm not too bothered).

[adityabhandari]

This isn't a "product." It's not sold.

I don't mean 'product' in that sense. Coming from a design background, I refer to anything that is used by people as 'product' and therefore rockbox is a product in my view

Even on software that uses PNG/JPG at some point the image is decompressed to BMP before display. BMP has the advantage of requiring little to no processing for use (remember, these are very limited devices) whereas PNG would either need to be decompressed on load (in which case it's less efficient than BMP - processing on loads and still uses the same RAM) or decompressed on display (could use less RAM, but quite a bit more CPU time).

thanks for the information. i didn't know this before.

I have given away on of my rockboxed Clips to my mother and she is not very technically savvy.

Can we still have that user survey? There may be other such users too! On a side note, we SHOULD have data about rockbox usage wrt the devices it's being run on.




I will post more, may be today or tomorrow. I thought up a few things over the weekend.

[[Saint]]

I have given away on of my rockboxed Clips to my mother and she is not very technically savvy.

Can we still have that user survey? There may be other such users too!

Have you read the forums.....?

Just a *weeeee* bit of an underestimate saying there "may" be other such users out there, in my opinion it seems pretty obvious that there's a rather large percentage of the "technically illiterate" that use rockbox and even after having gui/feature related requests shot down continue to do so, because of the simple fact that it may not be pretty, but it just plain does more...

I'd rather an "ugly" player that did a shit-load of stuff than a "pretty" one that just does the basics that all the other DAP's do....otherwise, what's the need to switch to RockBox?

If you want a "pretty", and "streamlined" "product" for your DAP, what's wrong with what it had in the first place?


As for ToolTips:

1: Annoying
2: I can personally read a manual, and don't find it too much effort to do so.
3: Think of DAP's like the iPod Nano....where the hell would you possibly put a tooltip on a 176X132 screen?

And in general:

There are HEAPS of niggles that I have with RockBox personally, and I myself have had feature ideas shot down (in a big way), so I took the initiative to learn to edit and compile my own build, without the "bloat" (which is always subject to personal opinion).
If I can do it with my knowledge, then I'm sure if you're THAT passionate about the changes you propose, you'll follow suit and do the same.

It was a big step for me to realise that just because I, and even others, think something is a good idea...RockBox is built as it is for a reason, and there's probably a VERY good reason (backed up by a myriad of passionate developers) why it is indeed the way it is.

Which I'm sure you've noticed by now.

I'm sure it would be easier to find the information you need and apply the changes yourself (in fact I'm positive of it) than it would be to get the changes you want included in the official build.


Just a thought or two....

[St.]

[adityabhandari]

Have you read the forums.....?

Just a *weeeee* bit of an underestimate saying there "may" be other such users out there, in my opinion it seems pretty obvious that there's a rather large percentage of the "technically illiterate" that use rockbox and even after having gui/feature related requests shot down continue to do so, because of the simple fact that it may not be pretty, but it just plain does more...

I'd rather an "ugly" player that did a shit-load of stuff than a "pretty" one that just does the basics that all the other DAP's do....otherwise, what's the need to switch to RockBox?

So you're saying that technically illiterate people could possibly never want to use an open source product? It leads me to wonder then possibly why or how Firefox 3.5 recently became the most popular browser on the earth! Or you could probably go and see xbmc and tell me why it looks so good?

As for ToolTips:

1: Annoying
2: I can personally read a manual, and don't find it too much effort to do so.
3: Think of DAP's like the iPod Nano....where the hell would you possibly put a tooltip on a 176X132 screen?

I am confused, really. Do you keep a printout of the manual handy when you're using rockbox on your 'portable' mp3 player? Also, HAVE YOU READ THIS POST? I am pretty sure that I quelled any doubts about making the entire rockbox UI tooltipped!

I'm sure it would be easier to find the information you need and apply the changes yourself (in fact I'm positive of it) than it would be to get the changes you want included in the official build.

Again, do you even know what this post is about? HAVE YOU READ THIS POST, at all?? I am a usability engineer , not a developer. I maybe familiar with some of the development platforms/jargon, but definitely cannot write code to change rockbox.


I will present a strategy shift as well as some more thoughts on UI changes tomorrow . This is all I had time for today. :\

[Llorean]

So you're saying that technically illiterate people could possibly never want to use an open source product? It leads me to wonder then possibly why or how Firefox 3.5 recently became the most popular browser on the earth! Or you could probably go and see xbmc and tell me why it looks so good?

I'd say Firefox 3.5 has a direct goal of competing with IE. This means presenting the user interface in a way somewhat familiar to users of the software. You'll notice there are plenty of other browsers (Chrome, Lynx, etc) that have chosen instead to redesign their UIs to fit their (and their features) needs instead of attempting to compete head on with IE. So using Firefox as an example is misleading - their project goals relative to the software they're trying to supplant are vastly different than Rockbox which seeks a UI designed to meet its own needs rather than the needs of some public it seeks to woo.

As for XBMC, sure it's pretty. It also has a very inconsistent interface where many options are only available during playback, or during playback of a certain type of media. Different buttons have different functions on different screens. And it doesn't have useful tooltips to help you navigate either.

If XBMC is a "good design" in your book, I'm becoming less interested in what you have to say. Learning to use XBMC requires learning many screens individually, whereas learning Rockbox requires learning list navigation and the existence of the context menu. Other than that, almost every option available is actually in the settings where a user would look for it.

The fact that XBMC "looks good" doesn't make it a good UI. Please, when you present your ideas focus on functionality issues rather than appearance issues.