Am 07/30/2013 12:25 AM, schrieb Kay Schenk:
On Mon, Jul 29, 2013 at 3:21 PM, janI<j...@apache.org>  wrote:

On 30 July 2013 00:16, Marcus (OOo)<marcus.m...@wtnet.de>  wrote:

Am 07/29/2013 10:39 PM, schrieb sebb:

On 29 July 2013 21:12, Marcus (OOo)<marcus.m...@wtnet.de>   wrote:

Am 07/29/2013 09:45 PM, schrieb sebb:

  On 29 July 2013 19:27, Marcus (OOo)<marcus.m...@wtnet.de>    wrote:


Am 07/26/2013 11:10 PM, schrieb Marcus (OOo):



Am 07/26/2013 10:44 PM, schrieb Andrea Pescetti:



On 25/07/2013 Marcus (OOo) wrote:



I've created a new webpage to offer all possible download links
for
a
release version:
http://ooo-site.staging.**apache.org/download/test/**
other_tables.html<
http://ooo-site.staging.apache.org/download/test/other_tables.html>




This is really nice, looking forward to seeing it online!




see below

  It's especially important to have a link to checksums for those who
want
a "static" reference to it or want to verify a package on a
different
system than the one used for downloading.




That was one intension, yes.

  - all possible downloads for a respective language and OS in a
single
place




I foresee another interesting way to use that page, i.e., getting
more
localization volunteers. Let's get this version online first, but
maybe
we could then add another table with something like "The following
languages are released only as source code:", and then a list of
each
of
the 90+ remaining languages with the link to help us release it (in
most
cases, it will be a link to http://openoffice.apache.org/**
translate.html<http://openoffice.apache.org/translate.html>
but in some cases it might be different).




Good idea. However, I think I've to add more additions than one can
thought. But this is no obstacle.

  @Andrea:
I've already considered your smaller font size wish for the
checksum
links.




Thanks, looks great.




Thanks. :-)

Even when I've missed to state it from the beginning but I expect to
use
lazy consensus here. If there are no objections I plan to make it
Live
at ~Sunday evening Hamburg time.




As I haven't seen any objections I'll create the new "other.html" in
a
the
next time.



Sorry, but I find the page hard to use.

Most people will not need any language packs, so why clutter the table
with them?

Also if a user does want to add multiple language packs, it's hard
work finding them amongst all the full installations.

I think it would be a lot clearer for the page to be laid out
something like the following:



This was the old system and the goal was to integrate all files that
belong
to a specific language and platform.


I'm not sure that goal is particularly useful to the end-user.

  If it's hard to read due to a small font size, this could be changed.


It's not the font size.

  Otherwise I don't thing that it's too confusing.


Well, you are a developer working on OOo.


Only for the website, not for the source code. But maybe this is no
longer
relevant as I do this already for years.

  I am trying to look at it as a non-developer who wants to download the
software.

  ---------------- [ cut here ] ---------------


...

---------------- [ cut here ] ---------------


If it is possible to provide a dynamic page, then it might be nice to
determine the platform first (user selected; perhaps with
auto-detected default), and then use the platform to display only the
installation sets and language packs for that platform.



The dynamic thing is not to continue the data guessing from the main
download webpage but to simplify the modification for new releases.

The "other.html" is a kind of fallback when:

a) the user is not able to use the green box on the previous main
download
webpage.

b) or when he is searching for a build different from the browser's
language
/ platform.


AFAICT it's also used when the user wants to add a new language, in
which case they already have the base installation.


Yes, and there are maybe some more possibilities.

  As we don't know the reason(s) for a) there shouldn't be any limitations
to
give the user the full control to find what he needs.


Yes, but that's not relevant to the issue of the page design.

  And if b) it will help him as well.


Which is where the page design is very important.

  The difference of full installations and language packs is described
directly above the table by your suggestion.


Yes, but I'm afraid I don't find it easy to read.
There's quite a lot of information there which is not particularly
relevant to the end user.

Also the most common use case - downloading a single base installation
and no languag packs - is not actually described.


If you think that the text can be better, then please tell me. Based on
Apache's famous slogan: Patches are welcome. :-)

  That would avoid problems with people downloading the language pack
for the wrong platform.



Sorry, but this can also happen in the current "other.html".


Of course; I was just making a suggestion to improve the page further.


Yes, that's great. However, I'm missing arguments that the new layout is
more confusing than the current one. Maybe you can help here to give us
some use cases?

  I think it would make for a better end-user experience.



I would say: Let the users decide. :-) If we get a reasonable amount of
complains then we can go back to different tables.


Anything against this? We can change back to the old one at any time.

@marcus; I for one like the way its done, not need to change back. But I
assume the old version is kept in svn ?

So lets see if there are compains (which you seem to solve quickly and
quietly something I really favour).

rgds
jan I.



I think we should just go live with these new changes. There is more to
this one but I don't think it's more confusing.

And...we can always go back.

Thanks to all for your opinions. I've done the commits and the new webpage is live:

http://www.openoffice.org/download/other.html

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to