Rockbox Technical Forums

Rockbox Development => Feature Ideas => Topic started by: adityabhandari on December 17, 2009, 07:45:33 AM

Title: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 17, 2009, 07:45:33 AM
Rockbox is an amazing and powerful achievement. I own an iPod video 5g and for me, rockbox was a godsend that allowed me to break free from itunes and its tyrannies.

As much as I love rockbox, I have to say that while a great amount has been accomplished in terms of functionality, the user experience has not been paid due attention. The user interface is very, well, developer like :].

If we want rockbox to be truly embraced, even by the non-technical users, we need to give the user-experience a rethink, and not just a facelift.

As a trained usability engineer, I am very interested in collaborating with people interested in taking forward the UX cause.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: GodEater on December 17, 2009, 07:51:02 AM
Can you give us your design then for how you'd do it please?

We often get people coming in here saying they don't like the user interface - but no-one ever offers any actual improvements.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 17, 2009, 07:56:57 AM
One thing worth remembering - a lot of the usability hindrances (such as crowded button maps or the basic list-based user interface) are also strengths in other ways.

The user interface is very developer-ey because it was designed by developers who actually use these players, and want powerful access to many features. While this leads to a UI that requires some learning, I'm sure it would be frowned upon if replacement ideas simplified things at the cost of some of the power advanced users expect to be at their fingertips.

The relatively simple text-based view also allows the UI to easily be driven blindly with the addition of voice prompts, and any future UI ideas should remember that a not-insignificant user group is sightless or visually impaired.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: AlexP on December 17, 2009, 07:58:27 AM
And we don't want to remove or hide options (unless the same functionality can be achieved in another way).

However, as GodEater said - we are open to improvements, but nobody who says the interface is bad ever actually gives any workable solutions (other than silly things like remove half the options, or make it like an ipod etc.)
Title: Re: User Experience and Rockbox- A rethink required?
Post by: linuxstb on December 17, 2009, 08:01:06 AM
I too would be interested to know more specifically what you don't like about Rockbox's current UI, and how you think it can be improved.

You need to consider Rockbox's limitations though - it runs on many different devices, each with different LCD types and (more importantly) different numbers of buttons, and buttons with different names printed on them.

In order to make Rockbox development (and support) more manageable, we want Rockbox to behave as consistently as possible across all these different devices.  We wouldn't want to have to maintain 20 different UIs, each optimised to work perfectly on one particular device.

For an idea of the range of devices Rockbox needs to run on, see here:

http://www.rockbox.org/wiki/DeviceChart

Don't be put of by the slightly negative replies you've been receiving - it's simply because you're not the first person to say what you're saying, but no concrete proposals have ever been made.  I wish you luck!
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 17, 2009, 08:53:50 AM
What a response! Thanks for all the info. Here are a few of my doubts/comments based on what has been mentioned so far. Please bear with me if you find them to be childish or uninformed. I ask them with the intention of encouraging more discussion :-

@linuxstb "it runs on many different devices"- I feel final optimizations still need to be in place. However, we can bring some sense of consistency across all platforms by adopting common UI patterns. Can someone give me information regarding the display options available on B/W players, e.g., for color screen players we can use jpgs, what do we use in case of B/W players? Also, do we support .svg/ .png graphic files? If not, would we, in the future?

@AlexP:"we don't want to remove or hide options"- By default, nothing should be hidden, but I guess, we can atleast give the user the choice to decide what he wants to see/hide? E.g.: my ipod 5 g doesn't support recording and hence I have no use for it, I want to hide it.

@Llorean: "lot of the usability hindrances (such as crowded button maps or the basic list-based user interface) are also strengths in other ways"- crowded button maps?? Also, I am not against the list-based UI, it's nice. I just feel that we can work to enhance the already existing UI.

@Llorean: "powerful access to many features..."-The access needs to be in place, for sure, that's what Rockbox is all about! :) However, these UIs can look and work better. E.g. Text Entry in ipod 5G is certainly not very convenient, to put it mildly. Also, the "graphical equalizer" does offer advanced control over the sound but isn't very easy to use. It doesn't do much in terms of informing the user(especially a novice user) about the meaning of say, "LS" or "PK1".

@GodEater: I intend to provide UI mock ups of my suggestions.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: torne on December 17, 2009, 08:59:14 AM
Features such as recording *do* only appear on players which support them. The iPod 5G is perfectly capable of recording, the line-in pins are on the dock connector.

Is the manual's description of the graphical equaliser not sufficient? There really isn't room to go into a detailed discussion of what the EQ settings mean on the device, especially on devices with small screens...
Title: Re: User Experience and Rockbox- A rethink required?
Post by: AlexP on December 17, 2009, 09:02:40 AM
@linuxstb "it runs on many different devices"- I feel final optimizations still need to be in place. However, we can bring some sense of consistency across all platforms by adopting common UI patterns. Can someone give me information regarding the display options available on B/W players, e.g., for color screen players we can use jpgs, what do we use in case of B/W players? Also, do we support .svg/ .png graphic files? If not, would we, in the future?

The UI is already consistent across devices, and things like bmp backdrops, jpeg album art etc are supported where possible.  Other formats are unlikely, these are limited resource devices.  I strongly suggest that you try out other players using the simulator before making any suggestions.

@AlexP:"we don't want to remove or hide options"- By default, nothing should be hidden, but I guess, we can atleast give the user the choice to decide what he wants to see/hide? E.g.: my ipod 5 g doesn't support recording and hence I have no use for it, I want to hide it.

Configurable menus are a huge bag of worms.  Search for previous discussions on this on the forums, IRC and the mailing list.

Normally features that are not supported are not offered, torne beat me to why.


We need actual idea here, not just that something isn't nice.  And please read the manuals/check the sims first, so you don't suggest things that already exist/are done.  It'll also help you to get an idea of what is possible across targets.

All that being said, we do want improvements (we have just got rather cynical that anyone will actually do anything other than list what they don't like :))
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 17, 2009, 09:06:05 AM
Can someone give me information regarding the display options available on B/W players, e.g., for color screen players we can use jpgs, what do we use in case of B/W players? Also, do we support .svg/ .png graphic files?
We use bitmaps, not jpgs. See the themeing options, no graphics should really be incorporated into Rockbox itself. .svg and .png are somewhat unlikely. You shouldn't be thinking of UI improvements in terms of graphics - themeing options exist for graphics. You should be thinking in terms of usability.

Quote
E.g.: my ipod 5 g doesn't support recording and hence I have no use for it, I want to hide it.
Actually, your player does support recording. Features that are useless aren't included to save RAM.

Quote
crowded button maps??
Many people complain about the fact that there are sometimes different features on a tap of a button compared to holding it down, or that some features are activated by pressing multiple buttons simultaneously.

Quote
It doesn't do much in terms of informing the user(especially a novice user) about the meaning of say, "LS" or "PK1".
These are terms someone familiar with equalizers would know, and it's not really possible for the UI to explain technical details, just like it doesn't explain "bitrate" or "sample rate" for recording users. If these need explaining they should be in the manual. It's not really the place of the UI to educate users.

Remember that it's also bad to waste RAM. You can't just include everything everyone might want in the UI. These players have limited processors and limited available memory and there's generally a benefit to using as few total resources as possible (with RAM being, generally, more freely available than CPU time).
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 17, 2009, 09:33:28 AM
Quote
These are terms someone familiar with equalizers would know, and it's not really possible for the UI to explain technical details, just like it doesn't explain "bitrate" or "sample rate" for recording users.

Actually, I was wondering about how much of a performance issue would it be if can display a kind of a tooltip which would inform the user about the intended usage/description of the item. Also, I think that space would not be an issue in most players, there's plenty of it available in mine below the equaliser UI. On a side note, a reason why the equaliser is hard to understand could be that it doesn't look anything like a real equaliser would look like! Most of them are vertical as opposed to the horizontal layout in Rockbox.

The Tooltip feature could be used in several places, but not ALL, it could prove to be a valuable enhancement, but only if used judiciously.

Quote
Is the manual's description of the graphical equaliser not sufficient?
Good design helps us to understand a product- the user should not have to rely on the manual.

Quote
crowded button maps??
Oh! I am totally sold on the versatility of these babies. They give the user so much more power, especially at their fingertips :P. They need not go away. However, we could look into reasons why people face problems while using them and take a call if we indeed need to change this feature or not.

Quote
I strongly suggest that you try out other players using the simulator before making any suggestions.
thanks alex, I will. I hope they're all as easy to get up and running as the one for ipod 5g video.


Title: Re: User Experience and Rockbox- A rethink required?
Post by: Multiplex on December 17, 2009, 09:35:15 AM
I always struggle with the idea that something we use frequently should be intuitive - actually I think that the opposite is true - you're going to use it frequently so it is worth your while getting to learn how to use it and be able to use the thing to its greatest capability.

Driving a car is hardly intuitive but we almost all take the effort to spend weeks or months to master the user interface, same for the keyboard in front of you now.

I don't want a dumbed down useless Rockbox - there's the Original Firmware with its pretty, but useless, pretend GUI for folk that like that.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: AlexP on December 17, 2009, 09:37:29 AM
Tool tips are horrible, they really slow you down and get very annoying.

Your ipod video has one of the biggest screens (in fact the biggest of the standard targets) - most do not have plenty of room at all.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 17, 2009, 09:40:16 AM
I always struggle with the idea that something we use frequently should be intuitive - actually I think that the opposite is true - you're going to use it frequently so it is worth your while getting to learn how to use it and be able to use the thing to its greatest capability.

Driving a car is hardly intuitive but we almost all take the effort to spend weeks or months to master the user interface, same for the keyboard in front of you now.

I don't want a dumbed down useless Rockbox - there's the Original Firmware with its pretty, but useless, pretend GUI for folk that like that.

Agreed, I am also not aiming to propose designs that dumb-down the beast that we have.
Products that are designed for first time use, ie, to accommodate even the dumbest of the users, get used only once. :D  And we're aiming to streamline rockbox for the fairly advanced users only.

Tool tips are horrible, they really slow you down and get very annoying.

Your ipod video has one of the biggest screens (in fact the biggest of the standard targets) - most do not have plenty of room at all.
Probably the reason why it's UI looks as if it's been designed to cover only half the screen :P
Nevermind, it was just a suggestion, my recommendations would not come in before I've been through all the simulators :)
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 17, 2009, 09:41:32 AM
Actually, I was wondering about how much of a performance issue would it be if can display a kind of a tooltip which would inform the user about the intended usage/description of the item. Also, I think that space would not be an issue in most players, there's plenty of it available in mine below the equaliser UI. On a side note, a reason why the equaliser is hard to understand could be that it doesn't look anything like a real equaliser would look like! Most of them are vertical as opposed to the horizontal layout in Rockbox.
Tooltips then require another button to pop them up, screen real-estate (the iPod you use has one of the largest screens, most players have far less), either RAM use or disk accesses when they're loaded. And those are just the obvious drawbacks.

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?


Quote
Good design helps us to understand a product- the user should not have to rely on the manual.
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?
Title: Re: User Experience and Rockbox- A rethink required?
Post by: AlexP on December 17, 2009, 09:44:43 AM
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. 

I keep trying to counter my negative points with positive ones, so here goes again - we do want it to be as good and easy to use as possible, but the primary focus is the developers.  I think we can expect people who decide to replace the firmware on their players to read a little if needed.  They absolutely have to for the install at the very least.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 17, 2009, 09:52:59 AM
Quote
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?

Quote
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.

Quote
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! :)
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 17, 2009, 09:57:35 AM
Quote
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?
Title: Re: User Experience and Rockbox- A rethink required?
Post by: ew on December 17, 2009, 10:33:27 AM
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?
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 18, 2009, 09:04:23 AM
Quote
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.

Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 18, 2009, 09:35:42 AM
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.


Quote
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.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: GodEater on December 18, 2009, 09:48:50 AM
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.

Quote
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.



Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 18, 2009, 09:50:44 AM
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.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: nls on December 18, 2009, 10:54:38 AM
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.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Biont on December 19, 2009, 09:53:47 PM
- 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!
Title: Re: User Experience and Rockbox- A rethink required?
Post by: tdb on December 20, 2009, 04:51:10 AM
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.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: AlexP on December 20, 2009, 07:14:04 AM
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).
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 21, 2009, 03:12:56 AM
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 :)

Quote
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).
Quote
thanks for the information. i didn't know this before.

Quote
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.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: [Saint] on December 21, 2009, 09:54:26 AM
Quote
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.]
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 22, 2009, 09:33:50 AM
Quote
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?

Quote
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!


Quote
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. :\
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 22, 2009, 12:30:10 PM
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.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: cpu98 on December 22, 2009, 06:31:06 PM
Here goes some my thoughts. :)
I don't need them, but they would be nice.
Rather than tooltip that pops up, tooltip bar would be better.(For small screen or anything)
Of course that bar should be disableable.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: GodEater on December 23, 2009, 09:34:57 AM
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.

Ditto. XBMC is shiny. That doesn't mean it has a good UI at all. In fact, I was only swearing at it the other day because there's no consistent way to turn off subtitles in it.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 26, 2009, 09:52:38 AM
Improving user feedback in Rockbox UI

I hope you all can see this link?
https://docs.google.com/fileview?id=0B6bduX-uMpdUZjRmMmRiNzEtYjQ5OC00MjAxLWFiMDEtNGNlZjE1YTlkMGUz&hl=en
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 26, 2009, 01:11:07 PM
The idea of showing the setting value in the list has actually been discussed before. I don't know what the results were, but some searching should help you find it.

The issue in the context menu sounds like a bug that should've been reported. The same with "it remembers which font I selected in the simulator but not on the player." Are you sure that the version on your player and the version of your simulator match?

Please, when writing these up, don't write "Rockbox must do this" but perhaps "Rockbox should do this." It sounds very aggressive the way you've written it.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: AlexP on December 26, 2009, 07:35:21 PM
The idea of showing the setting value in the list has actually been discussed before. I don't know what the results were, but some searching should help you find it.

From memory the major objections were something like it looks bad/doesn't work on smaller screens/with bigger fonts.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: psycho_maniac on December 26, 2009, 08:40:57 PM
The idea of showing the setting value in the list has actually been discussed before. I don't know what the results were

this what your talking about?
http://forums.rockbox.org/index.php?topic=5881.0
also i like the Rockbox UI_Feedback.pdf link. looks nice, but i want the back button to act as it does now currently when at the main menu.
edit: i think that if we go hit the back button when we are in a context menu we should be taken back to where we were. the only one i know of is when your in the wps and you hold select and when you hit back you are taken back to where you were, which is the wps.

edit: wow i have been a member here for 5 years and i just busted the 800 post mark YAY me!
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 26, 2009, 09:00:23 PM
I think you misunderstood what he's saying - he's not proposing changing the back button (as far as I can tell) but rather fixing a bug where pressing "back" doesn't take you to the previous level of the menu, but rather kicks you out of the menu and back to the WPS.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: JdGordon on December 26, 2009, 09:06:17 PM
the thing with the context menu is not a bug.. its actually by design (and by that I mean thats the way its worked for the last 4 years and wont likly be changed any time soon... in fact, there is actually bandaid code in there to make it work :/ )

My preferred method for showing the setting value in the list is to make the current item 2 lines high with the name of the setting on the top line and the value right aligned on the second line. This is actually fairly fiddly and might not really be doable. There are also problems with showing setting values in the lists, some settings look like settings to the user, but are actually handled differently so either special handling needs to be added for them (not good), or they are displayed differently (also not great).

help text of any type is not really ideal because it wastes alot of space, or it involves alot of disk access (or is done in a plugin which only allows english).

from the pdf...
1) displaying "nothing to resume" in the main menu is possible, just needs someone to do it
2) There was already a discussion about remembering the current theme, I am hugely against this because there is no way to enforce it (unlike remembering the font or wps), search the forums and irc if you want more explanation
3) there is no rule three!
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 26, 2009, 09:18:14 PM
It's by design that you can tap "right" to go into Sound Settings, then "Left" to leave it back to the context menu but tapping "Right" to go into Playlist followed by "Left" doesn't take you back to the context menu, but rather to the WPS?


I do agree with JdGordon that the two-line proposal for the settings looked best if it can ever be achieved (and is probably most compatible with larger fonts, etc, and almost certainly would work better on charcell displays than the shared-line version).
Title: Re: User Experience and Rockbox- A rethink required?
Post by: BdN3504 on December 26, 2009, 11:00:08 PM
One thing I found a bit irritating when switching to rockbox was that after you changed the "view file type" setting, you sometimes ended up with an empty filebrowser. For people who don't RTFM this causes panic, because they think all their files have automagically gone and rockbox is an evil disk formatting virus infected OS some jerk put on their beloved DAP. This of course is the consequence of entering the quickscreen and changing that setting without knowing what it does.
These useres couldn't undo this change because they didn't know what they had done. This was mainly because the "display file type" setting wasn't displayed anywhere but in that setting. Now that there is the wonderful feature of customisable satusbars, this is a problem of the past.
On any account, I suggest we include the view file type setting in the default sbs (e.g. with the letter A, P, M, S) and create a manual entry for that.

As for popups, this could easily be done using conditional viewports in combination with the %mv tag. of course the %mv tag would have to adapt to the current screen and represent changes taking place respectively. Am I right in assuming that every screen in rockbox is currently shown in a viewport? If that's really the case and we are in favor of popups (which i understand we're not), I'd suggest we work on an XML interpreter. People could provide XML files in which every menu item is listed including a description which serves as the pop up text. i don't know about the difficulty of implementing a XML reader, so this suggestion might also very well be complete nonsense.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: JdGordon on December 26, 2009, 11:04:15 PM
is the "fiew file type" option still on the default QS?
Title: Re: User Experience and Rockbox- A rethink required?
Post by: torne on December 27, 2009, 05:03:49 AM
Yes, it's still there. Is there something better to replace it with? :)
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on December 27, 2009, 01:01:16 PM
Anything really. If the up/down directions are correct for it, maybe simply "volume." If it would be inversed, something else. Things with less confusing behavior than "show files" would be great.

It's caused no end of confusion for users over the years.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: BdN3504 on December 27, 2009, 03:48:31 PM
i find the sort files setting very useful in the quickscreen, because when you transferred music to your player recently and know the name of the folder/file you transferred and it's not easy to find in the alphabetical view, then using the "sort by newest date" setting is helping a lot.
you all suggested removing the show filetype item from the quickscreen but didn't comment on my suggestion of including this setting in the default sbs. removing this setting is the "cheap" way of addressing this problem, so what do you think of the inclusion?
Title: Re: User Experience and Rockbox- A rethink required?
Post by: [Saint] on December 27, 2009, 10:40:25 PM
Since this is still "User Experience and Rockbox- A rethink required?"

How the f**k did you get:

So you're saying that technically illiterate people could possibly never want to use an open source product?

From:

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?



The point I was trying to make at the time was (and this had been explained to you before but you conveniently ignored it) that Rockbox is in no way a "streamlined product", nor is it intended for the "general population"....if the general public can use it and get a kick out of it....great....all the better.
But it's designed by Devs FOR Devs and with continued development in mind, which is the reason (I presume) that there are quite a few things that "don't look nice".

I was trying to point out that every single user has the option of either sticking with Rockbox or reverting back to their OFW, and by "Have you read the forums?" I was trying to convey the fact that it's apparent that even with the fact that Rockbox " 'aint pretty ", it just plain does more than the OFW so despite it's apparent "downsides" for inexperienced users...it's an informed choice that they've made to continue using it.

Requests for support in the forums/irc support the fact that even as a "work in progress" users would still rather work out the kinks they have with Rockbox than revert back to the OFW (a "streamlined" "product")...so is refinement at this stage really necessary?

Without a clear view of the end stage "product" is it even possible to achieve?

What's the point in "streamlining" (which lets face it, often doesn't actually involve streamlining anything, but rather simply removing features/information from the user) a "product" that could well change drastically in the forseeable future?


[St.]
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 28, 2009, 09:44:30 AM
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(http://26.imagebam.com/dl.php?ID=61488545&sec=8353daee0c1003e5fbee56e5dd9e12e3)

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 :)
Title: Re: User Experience and Rockbox- A rethink required?
Post by: [Saint] on December 28, 2009, 10:05:52 AM
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.]
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on December 28, 2009, 11:23:58 AM
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
Title: Re: User Experience and Rockbox- A rethink required?
Post by: psycho_maniac on January 02, 2010, 12:49:26 AM
i think its cool that there is discussion about this again. keep up the good work!
Title: Re: User Experience and Rockbox- A rethink required?
Post by: torne on January 02, 2010, 07:53:36 AM
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.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on January 02, 2010, 08:24:10 AM
Check out thIs lInk.
http://docs.google.com/fileview?id=0B6bduX-uMpdUZTllZjFjNWUtYTk2My00ZjA0LTg0OWQtMjFkYTY4ZDM5MTY1&hl=en
Title: Re: User Experience and Rockbox- A rethink required?
Post by: GodEater on January 02, 2010, 11:47:44 AM
"Sorry, the page (or document) you have requested is not available."

Nice link :(
Title: Re: User Experience and Rockbox- A rethink required?
Post by: saratoga on January 02, 2010, 12:01:41 PM
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). 
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on January 04, 2010, 02:34:28 AM
I guess nobody read the first page on the pdf :P ???

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
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on January 04, 2010, 02:52:58 AM
#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?
Quote
#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.

Quote
/-/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.

Quote
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.

Quote
?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.

Quote
/-/It doesn’t sleep, it powers off, atleast in case of ipod video 5g
Why is powering off bad?
Quote
?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.

Quote
?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.

Quote
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.

Quote
*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?

Quote
*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.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on January 04, 2010, 04:47:50 AM
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.
Quote
?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?
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on January 04, 2010, 04:58:35 AM
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?"

Quote
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.

Quote
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.

Quote
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.
Quote
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.


Quote
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."

Quote
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.


Quote
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.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on January 04, 2010, 05:23:47 AM
Wow, you're still up...nice :)

Quote
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.

Quote
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. :)

Quote
. 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. :(

Quote
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?

Quote
"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!

Quote
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?

Quote
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!
Title: Re: User Experience and Rockbox- A rethink required?
Post by: Llorean on January 04, 2010, 05:37:31 AM
Quote
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.

Quote
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.


Quote
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.

Quote
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.


Quote
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.


Quote
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.

Quote
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
Quote
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.

Title: Re: User Experience and Rockbox- A rethink required?
Post by: torne on January 04, 2010, 07:25:13 AM
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 :)
Title: Re: User Experience and Rockbox- A rethink required?
Post by: mcuelenaere on January 04, 2010, 07:42:45 AM
*Development of an API that simplifies the development of applications
The API is already there, the documentation not (or is incomplete). This is something I've wanted to work on, but haven't gotten to due to lack of time.

*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 should be possible with Lua, at least if you're talking about plugins; not core modifications.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: adityabhandari on January 04, 2010, 07:47:09 AM
Quote
This should be possible with Lua, at least if you're talking about plugins; not core modifications.
I think I am talking about plugins only? Here's the kind of thing I have in mind. Rockbox db to read custom tags like mood, occasion etc. from the mp3 file(the addon bit) and probably a front end UI could visualize the same and could perhaps be incorporated with the rockbox player(the application bit).
Title: Re: User Experience and Rockbox- A rethink required?
Post by: mcuelenaere on January 04, 2010, 08:02:26 AM
Quote
This should be possible with Lua, at least if you're talking about plugins; not core modifications.
I think I am talking about plugins only? Here's the kind of thing I have in mind. Rockbox db to read custom tags like mood, occasion etc. from the mp3 file(the addon bit) and probably a front end UI could visualize the same and could perhaps be incorporated with the rockbox player(the application bit).
That requires modifications to the database (which is in Rockbox core). This is currently not possible in Lua.

What you could do however, is write a MP3 metadata parsing plugin with your front end UI all in Lua, which you could launch from the plugins menu.
Title: Re: User Experience and Rockbox- A rethink required?
Post by: saanaito on January 06, 2010, 04:47:30 PM
Again this is an implementation issue, not a design issue - there's no code to make it sleep.

Does any need to be written? Rockbox's power draw when idle on many targets appears to be astoundingly low - comparable to a sleep mode.

If one stops playback, returns to the main menu, and engages the hold switch (with the setting to turn off the backlight on Hold enabled), one has almost done exactly the same thing as putting the DAP into a Sleep mode.

The exceptions are targets for which power management needs a fair bit of work. The iPods come to mind, as their screens do not turn off when the backlight does, among other nits.