iHP140 Built-in Themes Overhaul

[Llorean]

I use Rockbox default, though I usually remove the peakmeters.

I really don't need much more than that. Some people like their themes to just be purely informational, rather than shiny.

[Paul Slocum]

cool, fair enough, but I think that the actual default theme should be one that looks a little more polished.  Rockbox firmware should be competitive with commercial firmware in every way, including aesthetics.

[Llorean]

That requires someone submitting a theme that works on all of our players, and is also good looking, and agreed to be good by the devs. A tall order, to say the least.

For example, how much, or how little should a default theme show? How different is it allowed to be on different targets?

One day there will be a nicer default, and there has been discussion on the matter for a while, but it hasn't, yet, been changed to something.

[Mikerman]

Simply as a point of discussion, I wonder if a default for each player can be set to "on" for each build, something that best shows Rockbox for the player.

Of course, this is a small issue, as one simply can switch to a WPS of one's choosing after installing Rockbox.  So not sure if this merits any time or effort.  And, of course, it would involve value choices over what's deemed "best" on each player.

And having the "basic" default does have an advantage--it's like a clean slate, to compare to/build off of.

[Paul Slocum]

When people first boot up Rockbox they should be wowed.  As devs I think you're too familiar with the project and you know where to go change themes, know that it's an amazing project and worth sticking to, etc.

Users who are immediately impressed when they boot up Rockbox for the first time are more likely to go immediately post on their blog and spread the word about Rockbox, and users on the fence are more likely to stick with Rockbox through any learning curve frustrations or bugs.  First impressions are important, and I'm sure you know that a strong, enthusiastic user base is the best fuel for open source projects.

I just love this project and have seen it reach a new level of maturity recently.  I want to see it do the best it possibly can.

[bluebrother]

When people first boot up Rockbox they should be wowed.

Why? We're not selling a product, we're just doing a firmware for personal fun. I really don't see a reason why to try like commercial products do. I really prefer focussing on functionality. Users coming only because of the look of Rockbox ... I think they missed the point, and if they don't use it because it's not fancy I don't consider them as a loss.

[jaybeee]

^^ I think that's a little short-sighted tbh.

You never know what is going to happen in the future. Bet you didn't think this would happen.

Sure, I came to Rockbox for functionality, and my god it gives me it.

I do think that "tidying up" the supplied themes/wps's (supplying better ones etc) is a very good thing. Sure, the authors need to help out here and I don't see why they wouldn't; after all they helped out to create a theme/wps in the first place. Equally the default theme needs to be improved. Whilst I'm sure there are a few people (Llorean for example) that leave the default on, I willing to bet most people change to something a little more polished (that I believe is good term to intimate what we're getting at here).

In the same way the functionality is "polished" so should the gui. Ok, a tenuous analogy, but you get my point.

Once again, I know this is a spare-time project and anything and everything that has been done and is still being done is amazing; it truly is. I've donated and I'd hope that all Rockbox users have too. However, such discussions need to take place to allow progression to be made; we're not having at go at anyone. Ok it may not be a high priority for the Devs for example, but to highlight what some/many(?) users feel is important helps those amazing Devs to keep in touch with the non-Dev community. Mind you this forum does that.

This isn't a rant (honest) and I'm not having a go at anyone. Far from it. Just helping (I think) to clarify what I think Paul was getting at.

[Llorean]

You have to remember: The devs want to keep in touch with the DEV community.

Rockbox grows by getting more interested developers, who then contribute more. Most of the developer sorts are interested in functionality.

While it's true many people feel it would be nice for the devs to work on UI shinyness ando ther such things, to be honest there's not a compelling reason to do so. Most or all of the developers agree Rockbox could look prettier. But if you're a developer, and you look at Rockbox, and you see audio freeze bugs, voice interface problems that prevent blind people from being able to even use it, battery life issues, tons of not yet implemented hardware, and then you loook in the other direction and you see people saying "You guys should make it prettier" it's somewhat frustrating.

There are so many tasks on the table, and making it prettier doesn't actually _benefit_ the project, on a grander scale. Making it work better means more people can use it who just couldn't before. More audio related functions that appeal to technical users helps to bring in developer interest, which in turn helps the project grow further. More shiny helps to bring in non-technical users, who flood the tracker with feature requests for things that the software can't already do, ask questions that are answered in the manual, and otherwise increase the support load.

I know it's a very, very, very cynical standpoint, and I'm exaggerating it, because surely there are nontechnical users that certain features appeal to, as well as technical users that like shiny, but overall shiny is just going to tend to having a very low priority because there's a large list of things that need "Fixed", and those should always take priority over things which need "Polished."

You have to remember, as long this project is not being sold, all non-contributing (and by contributing I mean developing) users add to the project is a number (how many we're installed on), word of mouth to spread it (a good thing) and increased support time (not necessarily a good thing, those of us running support are also volunteers, and our tempers do have limits, I'm sure many of you have occasionally seen me chew out a forum member who's pushed it just a little too far).

So while I'm not saying "More shiny" is a bad thing, it really doesn't have a lot of advantages to speak for it.


Just as a note, I would never want to suggest that we don't _want_ more users. We certainly do, every project does. I'm just stating that from a cold, mathematical standpoing there's a cost involved with attracting more people, and that cost is significantly worse if the software itself is not in a solid position (which to me means "At least a release candidate, if not a release") because you're introducing users to work-in-progress code.

[jaybeee]

^^ good point well made. Makes sense. And I thought my post was a long one!  

If anything, then perhaps this thread will prompt those peeps that created some themes to add them to the tracker so they can be included in the standard builds.

Cheers

[bascule]

I was going to chip in with a similar stance to jaybeee (Unique Selling Point, attract users, professional image, etc.) but Llorean, as usual, has successfully demolished those arguments:

...there's a cost involved with attracting more people, and that cost is significantly worse if the software itself is not in a solid position (which to me means "At least a release candidate, if not a release") because you're introducing users to work-in-progress code.

We see this so clearly with, in particular, with the iPod arrivistas...

* bascule goes off to think about porting my TextBox WPS to all targets and adding to the tracker...

* bascule wishes the time fairy would come along and grant me a whole day to myself every week

[Dwyloc]

While it's true many people feel it would be nice for the devs to work on UI shinyness ando ther such things, to be honest there's not a compelling reason to do so. Most or all of the developers agree Rockbox could look prettier. But if you're a developer, and you look at Rockbox, and you see audio freeze bugs, voice interface problems that prevent blind people from being able to even use it, battery life issues, tons of not yet implemented hardware, and then you loook in the other direction and you see people saying "You guys should make it prettier" it's somewhat frustrating.

I quite agree that this is not really something that the core developers really need to be spending their time addressing as I am sure they feel that their free time spent working on Rockbox is better spent working on improvements to functionality and fixing more serious issues.

I am also of the opinion that there are at least as many people who use rockbox who do not have the programming skills to work fixing technical issues with Rockbox, but do have the skills to help improve the look and UI of Rockbox.

More shiny helps to bring in non-technical users, who flood the tracker with feature requests for things that the software can't already do, ask questions that are answered in the manual, and otherwise increase the support load.

I also agree to a certain extent that this is also true but as the default look and UI of Rockbox improves new users should have less questions feel they need to ask before they can start making full use of Rockbox.

For example if the default rockbox wps was changed for less CPU demanding wps without peak bars less people would start their rockbox experience with audio playback issues and making support requests on the forms and IRC.

[Llorean]

There's a very high probability that when the default WPS changes, it won't have peakmeters for that very reason.

And people who can improve the UI are freely welcome to submit patches. Nobody's going to stop them. So these users who lack the technical skill for more in depth work but can do UI work are fully welcome to submit patches.

I don't see how most of that conflicts with what I said, since most of my statement was regarding the core developers.

[Paul Slocum]

But this isn't something developers need to spend time on.  Non-developers could create a uniform, nice looking default WPS for all targets.  It's just a matter of switching the default choice once it's done.

And in any open source project, some users inevitably become developers.  More users translates to more developers, which means a stronger project.  That was my point in talking about gaining users.

I'm a embedded systems programmer and I would jump in if I didn't already have way too many side projects.  And actually, I'm more likely to become an active developer on an open source project that looks professional and doesn't skimp on UI design (like a lot of open source projects do).

[Llorean]

So, to attract people interested in UI design, like you, we should have an already good looking UI?

Anyway, the WPS isn't the UI, it's just a single screen. I assumed by "UI" you meant the full user interface including the interaction with the menus, etc. Those certainly require a programmer.

We're already considering multiple themes as possible default ones, and if I'd know this conversation was solely and entirely about the default theme, I'd have had a lot less to say. When you started mentioning "UI" though, I thought we'd passed into the "Programming time is necessary" category.

[Dwyloc]

So, to attract people interested in UI design, like you, we should have an already good looking UI?

No the project just need to continue being open to new idea's and patches (like it is today).

Anyway, the WPS isn't the UI, it's just a single screen. I assumed by "UI" you meant the full user interface including the interaction with the menus, etc. Those certainly require a programmer.

Yes I quite agree, but reprogramming menu's is not quite as changing as fixing audio playback bugs.

I would also like to say at this point what I am really impressed with the new menu system and its small icons and the new root menu.  Both of which I was not expecting to like that much.

As normally I use the always use the file view as bookmarking is not supported in database mode and I listen to a lot of audio books with my DAPs. But I find my self using the database view alot now on my h120 and I previously never used it as its that easy to bookmark my audio book in file view then search for some music in the database view with the new interface.

I am also impressed with just how good the icons look in the new menu system with both my h120 and ipod nano and would love to have the option of customising them at some point in the future.

We're already considering multiple themes as possible default ones, and if I'd know this conversation was solely and entirely about the default theme, I'd have had a lot less to say. When you started mentioning "UI" though, I thought we'd passed into the "Programming time is necessary" category.

Sorry I started out this discussion just looking to come up with some idea's for renaming the existing wps to name them in more consistent way (like renaming engineer2 to engineer or add an engineer1) and making sure that they all also had matching rwps for the LCD remote.   But I seem to have got side tracked again  

I am happy to say I think we are now looking for the same type of future changes / improvements but are just fraising it in a different way.