Releases and website behaviour...

[Angyman]

So first thing to mention: this is just for proposal.. i dont want to argue or something...

I follow the rockbox progress now over three years or so. I am that kind of guy more related to project management than programming itself. In fact i work together with lots of programmers and now a little bit about the problems which are connected to a project in the size and in the manner of rockbox.

But without trying to appear as a "i know everything guy"  i think it harms the project that:
1. The website is too much developer orientated on the first sight
2. And i think it would help the project to focus back on stable releases

Really, right now you never now what happens to your player if you update to a newer build. Always some problems can be expected. There is now overview for a customer which essential progress really has been done without following the rockbox project frequently and reading through the forums and/or following and understanding the subversion commits. An unexperienced user who enters the rockbox site is definetly scared about all the geek stuff in here and it will be possibly end more in the result that he or she wont tryout rockbox on their player. A little bit of more explanation what rockbox is and how easily it can be installed on a device would be helpfull especially on the front page. I really think that the focus on a stable build and short release cycles by concentrating on an iterative step by step cycle, reagarding the most developer and customer needs, would help. The marketing part of rockbox is really nearly down to zero. Thats definety true. I know that there was a request for a website redesign which vanished in the depths of the forums and i really would love to make an proposal but up to the next two months i am really out of time ressources. I'll make one if nothinghappens until then. But i really think that marketing is an urgent problem of rockbox...

Over an out...

[Llorean]

Exactly why is marketing a problem? Who are we selling to?

The people we want to attract are the geeky ones. We get more from one new developer than we do a hundred or a thousand new users, unless those users happen to refer a developer.

But really, what I see here is simply "you guys should do all this, but I can't help, I'm just saying what you should do."

[bluebrother]

There are no customers. There is no product. Period.

Rockbox is simply an(other) open source project, and while it's nice to have users we don't need them to continue with the project. Arguing about loosing or not gaining users is simply ... pointless. Besides, getting more users means more support questions, and this means less time to work on the project. So depending on your point of view it also could be *better* to have less users.

[AlexP]

If you would like to work on some sort of "marketing" campaign, then by all means make some proposals etc.  But as the others have said, Rockbox isn't trying to sell anything.  It is of course great that so many people use and enjoy Rockbox, but ultimately developers do it for themselves, and the fact that so many others use it is a happy side effect.

[Bagder]

Some numbers from real-life that I think indicates that Rockbox is already a rather successful project:

* More than one million downloaded zips per year from build.rockbox.org alone. Add custom builds and downloads servers to that and I suspect we are at two million or more.

* www.rockbox.org site has some 12000 "visits" per day

* we are recognized by ohloh.net to be one of the largest open source teams in the world (counted by the number of committers the last 12 months)

I'm all for figuring out new ways to make us seen more and appear more favourable to the general public, but I don't see any particular need to.

[shotofadds]

Those are all valid points, but I do think the homepage could be a little more informative, e.g. it addresses the basic "what" and "why" questions, but doesn't give any information about "how" (which could potentially be solved with a couple of links to rbUtil and the manual).

The question about recent changes is a valid point. The page which would best answer the "what's changed recently" question (MajorChanges) isn't linked from the homepage, and isn't easy to find unless you happen to know that it's in the wiki. The split between what goes in News and what goes in MajorChanges seems rather arbitrary (eg. iPod 1/2G as a supported target made the News list, but the m:Robe 100 and iAudio M3 did not).

I'm probably in the minority here, but I don't see the point of having the developer information on the front page at all - there's a perfectly good Recent Activity page which gives a much more complete picture.

[GodEater]

I'm not even going to get into the "developer stuff on the front page" discussion - I've been involved in it before, and (I agree with you) got shot down. Apparently not having it there presents Rockbox as being some sort of "finished" product which might attract the wrong sort of people.

However, I'll address at least one of your other points : The manual *is* linked on the front page.

We've also had length discussions about having alternative ways to access the "How", and we've always decided that the manual is the way we want people to get to it.

[pondlife]

All of this is IMHO...

A what-why-how format for the top would be sensible.

The MajorChanges link should be re-instated to the home page (it was there until quite recently, IIRC).

I'd certainly agree that RBUtil should be more prominent; RBUtil and the manual should be all a user needs to get started.  Add the support channels and you have all of the user requirements covered, I think.

The project news section should be merged into the MajorChanges link - maybe with a rename.

I don't like the Recent Activity page as it is, would much prefer if it was ordered SVN - wiki - mail, but that's probably an opinion thing.  I wouldn't then mind if they were then removed from the frontpage.

pondlife

[Llorean]

RBUtil is pretty prominent: If they read the manual, they find it. If we make it any more prominent, they'd find it before the manual, which is not ideal. The current method funnels them from "Front Page -> Manual -> RBUtil" which I think is the ideal order of events. The only thing missing, I think, is an "installation" link in the documentation section that simply leads to a page saying "All installation instructions can be found in the manual, linked to in the bar on the left." People look for "installation" before they look for "manual" often enough just because usually a manual tells how to use something, not always how to install it. Many softwares have a separate install guide.

[Zardoz]

I'm not a developer needless to remark (in fact I might be Lloreans nemesis.) I'm more than willing to contribute to a reworking of the manual (I've spotted many grammatical and spelling mistakes, and I think I could be clearer in more basic English.

[GodEater]

Many softwares have a separate install guide.

Is there anything stopping us turning the Installation chapter in the manual into a seperate guide we could offer as well?

I'd still leave that section in the normal manual too - but it might be nice to have a "quick start" method for people ?

I'm not a developer needless to remark (in fact I might be Lloreans nemesis.) I'm more than willing to contribute to a reworking of the manual (I've spotted many grammatical and spelling mistakes, and I think I could be clearer in more basic English.

Start submitting patches then.

[bluebrother]

Many softwares have a separate install guide.

Is there anything stopping us turning the Installation chapter in the manual into a seperate guide we could offer as well?

I'd still leave that section in the normal manual too - but it might be nice to have a "quick start" method for people ?

In that case we should rework the current installation section first. Setting up a new build rule that builds only a segment of the manual (maybe create a new front page for that and leave out everything else but the installation section?) should be fairly easy then.

[shotofadds]

RBUtil is pretty prominent: If they read the manual, they find it. If we make it any more prominent, they'd find it before the manual, which is not ideal. The current method funnels them from "Front Page -> Manual -> RBUtil" which I think is the ideal order of events.

..which is fine, except the current front page text doesn't explicitly ferry people anywhere at all. I think an equally likely scenario (if not more so) is "Front Page -> Releases -> "oh..." -> Current Build -> Click the pretty picture of my player -> "oh.. what do I do with this .zip?"

If we expect people to read the manual first, we should at least say clearly "We'd really appreciate it if you read the manual before doing anything, thanks".

[Llorean]

I find myself wondering, then, what you thought of these sentences from the same post:

The only thing missing, I think, is an "installation" link in the documentation section that simply leads to a page saying "All installation instructions can be found in the manual, linked to in the bar on the left." People look for "installation" before they look for "manual" often enough just because usually a manual tells how to use something, not always how to install it. Many softwares have a separate install guide.

Note the use of the word "missing" suggesting I think that it is in fact a flaw that it isn't there...

[shotofadds]

Of course, but I was trying to say that the link needs to be somewhere way more obvious than "in the documentation section".