Rockbox Technical Forums
Rockbox General => Rockbox General Discussion => Topic started by: arodier on September 18, 2007, 07:56:29 AM
-
In first, Il have to recognize that your work is really huge, and the project has made a big step from the beginning. Thanks for all.
But for the moment, I have the feeling that Rockbox is a project by geeks, for geeks.
I dont know if you want became a more ambitious project :
- Included by default in some players, based or untouched.
- Receive donations or being employed by players manufacturers.
- Improve user acceptations of open source codecs.
What do you think about starting another branch of rockbox, with an easy to use interface as goal.
Reorganize GUI with less menu depth and more logic for users.
- Create a wiki for users, where they can propose user interface ideas,
- Start with a reduced number of menu entries and depth.
- Reorganize menu entries by most used entries, for example last played music at top level, etc...
Less options :
Separate normal, advanced, and ( normaly ) never used options.
- Show normal options,
- Hide advanced options by default, but left a button advanced.
- For power users, let the ability to set normaly never used options, for instance with a register editable in an advanced section. Like the about:config from mozilla products.
- Create a default options set for each model.
- Hide unusable options : Why display FM radio when my sansa e200 doesn't have one ?
- etc...
Create new GUI widgets
For instance, why use another page to set the play speed. A single percentage number that raise or below when is focused may be fairly better, and use less space on screen.
Games and applications
- Remove geek applications and games.
- Harmonize settings, translations, and loog'n'feel.
Default theme
- Create a default theme for each model.
- Example : after installation on my sansa e200, the default theme was poor in regards of this device capabilities.
Sorry for this comment if I have upset somebody. It's just suggestions because I believed that this project dont receive the support is deserves normally.
-
What do you think about starting another branch of rockbox, with an easy to use interface as goal.
Why branch? However, if you want to, feel free - it is GPL after all
- Create a wiki for users, where they can propose user interface ideas,
We have a wiki
- Start with a reduced number of menu entries and depth.
I quite like being able to get to the options
- Reorganize menu entries by most used entries, for example last played music at top level, etc...
This depends on the person. What I use most is probably not the same as you
Separate normal, advanced, and ( normaly ) never used options.
- Show normal options,
- Hide advanced options by default, but left a button advanced.
This would just be more confusing. You might consider advanced what I consider normal, and vice versa
- For power users, let the ability to set normaly never used options, for instance with a register editable in an advanced section. Like the about:config from mozilla products.
That would be a nightmare to edit on a dap, and I don't want to have to connect my dap to a computer to change the settings
- Hide unusable options : Why display FM radio when my sansa e200 doesn't have one ?
They are. You are seeing a current bug in the Sansa radio detect code.
Create new GUI widgets
For instance, why use another page to set the play speed. A single percentage number that raise or below when is focused may be fairly better, and use less space on screen.
I don't quite know what a GUI widget is for a dap, but feel free to code us up some examples
Games and applications
- Remove geek applications and games.
Different people like different plugins. Who are you to decide that they can't have them because they are geeky?
- Harmonize settings, translations, and loog'n'feel.
Please feel free to help us do this. Rockbox is open source.
Default theme
- Create a default theme for each model.
- Example : after installation on my sansa e200, the default theme was poor in regards of this device capabilities.
We are aware that the default theme is not nice, and everyone would like a new one. However, no-one has yet designed and written one that will work on all players (we want the same look across all units) that can be agreed on. Perhaps you are that person?
We know there are areas that can be improved in look and feel, but it is a lot of work even once a design is agreed on (and there are problems with what you suggest as I have pointed out above). It has been said before, but I will say it again:
Rockbox is open source by volunteers. Of course we want it to be as good as possible, but people only work on what they want to. Most core devs would prefer e.g. the music playback to be stable before adding eyecandy.
Please do feel free to work on a design (and implementation would be nice), but just pointing out problems isn't so helpful.
-
I have the feeling that Rockbox is a project by geeks, for geeks.
Yes, I also think this is true. For me this is the open source philosophy: geeks make a program that is useful to them and decide to share it with the world.
I dont know if you want became a more ambitious project :
- Included by default in some players, based or untouched.
- Receive donations or being employed by players manufacturers.
- Improve user acceptations of open source codecs.
I personally don't share any of these goals (for me it's more about having fun and more control over my player), but it might be good for the project.
What do you think about starting another branch of rockbox, with an easy to use interface as goal.
I know nothing about interface design. If people think they can design a better system I'm all for it. Perhaps it would be better to include it with the official rockbox instead of forking, but that's up to you. I hope you find some people who will help you out (with the design and programming)
Good luck!
-
And just to respond to those very few line items that BigBambi did not touch upon...
I dont know if you want became a more ambitious project :
- Included by default in some players, based or untouched.
- Receive donations or being employed by players manufacturers.
- Improve user acceptations of open source codecs.
- I think you'll find very, very few manufacturers who wish to include an Open Source OS for their devices, because it makes it much more difficult (or impossible) for them to include DRM measures.
- Rockbox is 100% volunteer work and I suspect (without speaking for all the many contributors) that they wish it to remain that way. Rockbox is happy being by geeks users for geeks users
Ref: http://forums.rockbox.org/index.php?topic=7237.0, http://forums.rockbox.org/index.php?topic=3926.0, http://forums.rockbox.org/index.php?topic=12220.0
- I'm not even sure that increasing RB exposure would significantly increase Open Source codec take-up. As RB currently supports MP3, AAC and WMA (between them, a vast majority of the market), there is less incentive for RB users to switch to anything else if they are not forced to.
-
And just to respond to those very few line items that BigBambi did not touch upon...
Heh, sorry :)
I just want to say that I don't mean to sound like I'm dismissing the OP out of hand, I'm not. It is just that we hear similar posts not infrequently, yet the people who put forward the 'ideas' rarely do anything else. I would love it (as I'm sure would many others) if a proper design with ideas of how to implement were to be made. I'm just trying to point out that quite a lot of the ideas mentioned (such as hiding menu items, removing plugins) are very unlikely to happen.
-
Rather than suggesting "You guys should do all these abstract ideas", the best way to see something like this happen is to accomplish these abstract ideas, and post a patch, showing that they're worthwhile.
For example your menu reorganization idea: Why not create a patch with the new menu structure and show that it's more usable and useful? We've discussed it many times and decided there was benefit to repositioning menu items, but never a benefit to hide them (even advanced users are unlikely to spot all advanced options if they're hidden, and as most options are only changed rarely anyway depth is not a large concern except for options that are regularly changed). So offer up a reorganized menu structure that perhaps meets usability ideals.
-
I have the feeling that Rockbox is a project by geeks, for geeks.
Yes, I also think this is true. For me this is the open source philosophy: geeks make a program that is useful to them and decide to share it with the world.
I agree with this and I'm perfectly fine with it. The people working on this project do this for *their* fun, not for others. So while it's nice to have non-geek users I don't think many (if some at all) would consider it a requirement of any way to gain more users. As I said several times in other places: Rockbox is *not* a product.
(And honestly: If I should consider myself geeky I prefer the software I'm using being more geeky ;) )
-
ok, rockbox is definitely not geeky and i am very offended by you even saying that. i have used rockbox for almost 6 months now with almost no problems on my ipod nano. i got it installed for the first time in under 5 minutes. rockbox is high on the list of open source projects along with superb programs like firefox. it has excellent documentation and personally, i woundn't change anything with rockbox, it's perfect the way it is.
-
Let's not carried away, whilst rockbox is awesome there are things that could be better. However, it needs someone to do it. Just saying this that and the other aren't very good doesn't help is all.
-
I think the long and short of this is that the project is GPL, so you're free to do as you please and make your own 'version' of Rockbox.
I'm sure there is a large user base out there who would prefer a firmware which is as simple to use as the one you are suggesting, however Apple have pretty much cornered the market on that one.
Lastly, I applaud your efforts - you're clearly thinking of the best for Rockbox. That said, I would point out that your idea of progression/evolution is not necessarily the same as the developers' (collective) idea - in fact, I'm quite sure of it ;).
MU4L
P.S. On a personal note, I love Rockbox the way it is, to such an extent that I now only consider players that are Rockbox-able (for purchase). That is to my own detriment, seeing as the largest (non-modified) capacity available on a Rockbox target is 80GB whilst my collection tops 120GB.
-
That is to my own detriment, seeing as the largest (non-modified) capacity available on a Rockbox target is 80GB whilst my collection tops 120GB.
The Archos hard disk players take 2.5" disks :)
-
Reorganize GUI with less menu depth and more logic for users.
the title of that is a valid point and has been brought up a few times. the thing is, with over 180 settings, trying to organise them in a logical and simple way isnt very easy... but if a patch came which did it well it wouldnt be ignored.
removing settings is a no-no though (unfortunatly)
-
If someone wants to try and rework the interface/menus/etc, please submit a patch. No need to fork, we could work on it from the tracker, or if its really that complicated, could commit it as a compile time option.
-
Shouldn't an interface/menu system be designed on paper first? Going straight to coding it seems a bit silly.
If someone can think of a 'better' design they should put a design document on the wiki so it can be discussed. Wouldn't that be a good starting point?
-
Shouldn't an interface/menu system be designed on paper first? Going straight to coding it seems a bit silly.
If someone can think of a 'better' design they should put a design document on the wiki so it can be discussed. Wouldn't that be a good starting point?
Absolutely. Personally I would love to see some designs, bearing in mind things like access to all settings, no removing settings, easy to navigate for blind users (i.e. voicable) etc etc.
-
If someone can think of a 'better' design they should put a design document on the wiki so it can be discussed. Wouldn't that be a good starting point?
There is a previous attempt at http://www.rockbox.org/twiki/bin/view/Main/MenuLayoutDiscussion
-
I have been looking at the current menu structure (thinking about writing the missing manual section) and mostly I think it is pretty good.
From using it, the only thing I wished was higher up was the LCD brightness, but I got round that using .cfg files for the two settings I need (day and night).
BTW here's the picture of the whole* menu system (http://www.burbleland.com/tmp/rockbox_menus.html) I have so far (eventually it will be latex, but html/js is easier for now!).
(*actually there are a couple of missing menus that I'm not sure where to fit yet)
-
Are there any statistics that show the settings most changed by users? You could use that data to tell you what settings should be at the top etc.
-
No there are no such statistics and I am pretty sure it varies a _lot_ between users so making a new layout that is good for everyone is far from easy...
-
Of course it varies a lot. If any trends are evident though, it will aid the design. I thought user metrics were a fundamental part of this process (at least, that's what I was taught).
-
There's also the risk that one or several settings just won't be changed because they're buried too deep down so people don't find it or won't bother...
So the changed settings doesn't display what people want to change, but only what they have in fact changed.
-
Yes, you'd certainly want to delve deeper than that.
-
Regarding the menu layout, wasn't it the plan that after the introduction of the (no longer not so) new menu/settings handling code (or was it the root menu?), there would be some layout changes, in particular regarding the settings menus, which were moved down in a bit? Not much of that happened... (And no, I don't know what the plan was.)
-
I agree that laying it out on paper first is important, but a very large part of a good menuing system is "how does it feel when using it?"
New users should be able to find things quickly by categories (and in this case all current Rockbox users who didn't have a hand in creating the layout are "new"), so really to see whether a menu system is an improvement, it needs to be testable on-target (in my opinion). Lots of things look good in theory, bad in use.
-
I'd certainly go with iterative development (not really much choice with open source is there? x) ).
-
I agree that laying it out on paper first is important, but a very large part of a good menuing system is "how does it feel when using it?"
Llorean, quick and dirty menu testing could be accomplished using a variation of your "directory tree and .cfg files" joke of an idea.
-
Indeed. Do that in a UI sim, and you have a quick and dirty, drag 'n drop, on-the-fly menu tester.
-
Regarding the menu layout, wasn't it the plan that after the introduction of the (no longer not so) new menu/settings handling code (or was it the root menu?), there would be some layout changes, in particular regarding the settings menus, which were moved down in a bit? Not much of that happened... (And no, I don't know what the plan was.)
that recode makes rearranging the menu extremely simple (code wise).
-
Sorry if I have upset somebody.
Two remarks.
For the moment, I don't think to have sufficient free time to study the rockbox code core and produce patches. Actually, I keep my free time is for another open source project from myself. Please, don't believe I just came here to post free critics.
I will be very happy to view this project more adopted, and not only by geeks. If interfaces like KDE or Gnome, (or others) have never been created, I'm not sure that Linux adoption would be so important today.
May be a large adoption of rockbox by no powerful users, with help from friends of course, sensibilise them to open source, and open source formats.
-
And, as expected, someone else with great ideas for Rockbox has come back to us and said "actually I don't have time to do any of this."
Well, that pretty much means it won't get done then. Nothing more to see here. Move along :)
-
For the moment, I don't think to have sufficient free time to study the rockbox code core and produce patches.
And this is why it doesn't change. If you don't want to spend your free time on something you want, why should someone else spend their free time on it for you.
and not only by geeks.
Please stop calling us all geeks. I know some people revel in it, but I don't.
May be a large adoption of rockbox by no powerful users, with help from friends of course, sensibilise them to open source, and open source formats.
I'm afraid I don't understand this sentance.
Seriously, I don't think anyone is properly upset! We would all (nearly) like a nicer interface (personally I'm fine with the current one, but were someone to improve it I wouldn't complain), but if the people who think the interface is rubbish aren't willing to spend the time to help improve it, nothing is going to happen.
-
is it really necessary to change the menu layout? for me it is 99% perfect (-1 since i dont use the recording function).
-
That is to my own detriment, seeing as the largest (non-modified) capacity available on a Rockbox target is 80GB whilst my collection tops 120GB.
The Archos hard disk players take 2.5" disks :)
Correct me if I'm wrong, but AFAIK the Archos' don't have Parametric Equalisers, do they ??? ?
-
is it really necessary to change the menu layout? for me it is 99% perfect (-1 since i dont use the recording function).
Same here. I don't use my iPod for recording; that's what my Archos is for. I'm perfectly fine with the menu layout Rockbox has right now; everything's laid out very logically, and nothing is inaccessible.
So why reinvent fire and the wheel when others have done it already, and got it right the first time?
MU4L: I see Super Bass and various settings for MDB on my Jukebox Recorder, but no equalizer settings. So I guess the answer's no.
-
Bummer. I was living in hope that there may've been a (relatively) cheap alternative to the Classic.
Oh well. Chopping and changing (my music) it remains :) ...
-
I have a little idea how the settings menu could be rearanged which reduces at least one level of depth.
A problem right now is finding good and short names for my new categories and balancing everything. My main goal is having an evenly distributed tree.
I don't think that a redesign on paper convinces anyone to code it up, that's why i want to do it in the (sim)code before presenting it. JdGordon pointed it out, it is not very hard to rearange the menu entries in the code to play with it.