Rockbox Development > Feature Ideas
User Experience and Rockbox- A rethink required?
adityabhandari:
--- Quote from: Llorean on January 04, 2010, 02:52:58 AM ---Transitions slow down the user interface, and waste battery.
--- End quote ---
Then how come ipod comes with transitions and manages to last for upto 10hours before dying?
--- Quote from: Llorean on January 04, 2010, 02:52:58 AM ---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.
--- End 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.
--- Quote from: Llorean on January 04, 2010, 02:52:58 AM ---?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.
--- End quote ---
Please read the whole post, the legend is mentioned at the bottom.
--- Quote ---?UI Proposal can be worked out
--- End quote ---
--- Quote from: Llorean on January 04, 2010, 02:52:58 AM ---Why is powering off bad?
--- End 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.
--- Quote from: Llorean on January 04, 2010, 02:52:58 AM ---?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.
--- End 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?
--- Quote from: Llorean on January 04, 2010, 02:52:58 AM ---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.
--- End 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.
--- Quote from: Llorean on January 04, 2010, 02:52:58 AM ---Being a non-programmer, are you deciding the current API is not simple simply because there are few apps, or what?
--- End 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.
--- Quote from: Llorean on January 04, 2010, 02:52:58 AM ---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.
--- End quote ---
Fine, but couldn't there be a way to model a few of these patches as 'addons' or apps?
Llorean:
--- Quote from: adityabhandari on January 04, 2010, 04:47:50 AM ---Then how come ipod comes with transitions and manages to last for upto 10hours before dying?
--- End quote ---
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.
--- End 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.
--- Quote ---Please read the whole post, the legend is mentioned at the bottom.
--- End 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 - 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.
--- End quote ---
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?
--- End quote ---
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.
--- End quote ---
"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.
--- End quote ---
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?
--- End quote ---
They're called plugins...
One thing you're clearly missing is that you seem to have a concept that something can be "agreed upon." People, individuals, work on what they like.
You need to propose individual ideas that individuals can implement, not try to create some grand project scope.
adityabhandari:
Wow, you're still up...nice :)
--- 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.
--- End 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.
--- 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
--- End 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. :)
--- 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.
--- End 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?
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.
--- End 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?
--- Quote ---"make things better" is not a strategy. "make things better" also isn't a bigger picture issue.
--- End quote ---
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.
--- End 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?
--- Quote ---They're called plugins...
--- End 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!
Llorean:
--- 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.
--- End quote ---
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. :)
--- End quote ---
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?
--- End quote ---
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?
--- End quote ---
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!
--- End quote ---
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?
--- End quote ---
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!
--- End quote ---
You said
--- Quote ---Fine, but couldn't there be a way to model a few of these patches as 'addons' or apps?
--- End quote ---
You explicitly mentioned them being apps and addons. I can't read minds, so when you say something like "apps" I can't know that instead of meaning an external app, you mean integrated playback functionality.
There's no realistic way for patches to be non-developer. Due to the nature of the hardware it's almost entirely impractical for binary data to be shared between them (and in some cases wholly impossible) so even were they available one would have to be made available for every single player.
The closest to cross-platform compatibility would be, potentially, a plugin written in LUA.
torne:
Regarding sleep vs power off: we don't know how to sleep on iPods. It would take someone considerable effort to discover how to do it by reverse engineering the original firmware. This is the first reason why such an option doesn't exist. If we knew how to do it then we could consider providing it as an option. Deep sleep (suspend to disk) on iPod Video would be better, as this uses the same amount of power as being powered off but would boot faster (db already in ram, etc), but that would be even more difficult to do :)
You state that powering on wastes a lot of battery life; while obviously booting does use some power (all those disk accesses, especially if you load the DB to ram), I am guessing you haven't actually measured this and are going by the battery life estimate displayed in Rockbox? This is an estimate, based on an assumption about average consumption and the reading from the battery ADC - this reading will have fluctuated between powering off and powering on again even if the battery level didn't change, because it's not an entirely stable measurement :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version