Hi all,
as promized I've created a first draft . Please have a look:
http://download.openoffice.org/test/index.html
http://download.openoffice.org/test/other.html
Please do not take the website content too serious, it's just a test. ;-)
Some notes for the layout:
- even when it should happen that we have 4 different Dev Builds / RCs,
IMHO it's OK with the space and we shouldn't scroll that much, mostly we
will have Dev Builds from 2 different codelines and here and then a new RC
- the white space between the "Get more platforms and languages" links
will be removed, so still some CSS work necessary
- the explanation for RC, Dev Build, Beta Release is in the right bar, I
don't know if this looks fine
- the colors do not really fit (green should be for stable builds only),
my suggestion:
yellow = 3.x.y RCs
orange = OOO310 Dev Builds (should be coming soon)
red = DEV300 Dev Builds
Some notes for the technical:
- the Bouncer links may work or not already, we still have to do some
work to enable a one-click solution for all builds, platforms and languages
So, that's it for the first draft. What do you think?
Thanks
Marcus
Marcus Lange wrote:
currently we have the pleasure to manage 2 release more or less in
parallel: 3.0.1 and 3.1. Currently 3.0.1 RC1 is out and the next 3.1 Dev
Build is coming soon.
On "download.openoffice.org" we have a colored box as link for
downloading both, RC and Dev Builds. Of course this cannot work when
handling 2 releases in parallel.
Due to this I think about a few requirements:
1. Avoid version numbers and strings in links
Example:
bad = http://download.openoffice.org/3.0.1rc1/index.html
Because we have to create new directories and files for new builds.
good = http://download.openoffice.org/next/index.html
We can reuse the existing things again and again.
2. Keep it simple in the layout
Example:
good = http://download.openoffice.org/index.html
maybe bad = http://download.openoffice.org/other.html
But maybe here it depends on the people we want to reach. It's not the
normal users but the developers, and these are more experienced and can
handle/understand a complex table structure better.
3. Keep it simple to maintain.
Example:
When we have a new stable release only one version string has to be
adjusted in the "http://download.openoffice.org/index.html";. I could
think about the same for RC and Dev Builds.
Possible solution:
When clicking on the "Get Release candidates and Snapshot builds" link,
a new "index.html" will open with 2 columns that offers a) the current
RC (if still available and needed) and b) the next Dev Build.
I'll plan a first HTML file as draft how I think about a possible
solution and will post a link to the file.
Please tell me about your opinions. Am I the only one who sees this as a
problem? Maybe someone has already a solution and maybe a better one?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
