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. > > Marcus > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
