On 31 July 2013 01:41, Dave Fisher <dave2w...@comcast.net> wrote: > > On Jul 30, 2013, at 3:43 PM, Marcus (OOo) wrote: > >> 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 > > I think that while sebb has some good points let's not forget that these are > the pages we send users to when the javascript detection of their environment > does not give them what they want.
They may also navigate there if they want to add another language (in that case, autodetect may well have worked OK). > If we want to improve the experience then we would do something really > dynamic and ask some questions which would narrow the selection. That's much what I suggested already. The user should be asked what their platform is (default set by autodetect if they were not redirected because autodetect has failed). The page could then show them only the appropriate installations and language packs. They could then be asked whether they want a new installation, and if so, what language. They could then be asked what additional language(s) they want. What would be really nice would be if they could select the base installation and the language packs and have them all downloaded automatically, but that might not be possible. I still think it's a mistake to combine the installations with the additional language packs. They serve two different purposes. e.g. if the user already has an installation, and they want to download extra language packs, they should not have to wade through all the full installations. At the moment the main download page is quite awkward to use if the user just wants a new language pack. And if they don't have an installation, they have to look through a table which is twice as long as it need be. I think there should be a multi-step process which helps the user choose what they need. - first get the correct base installation - then get any optional extras that they may want (language packs, templates, etc). For users who already have a suitable base installation, they should be able to skip directly to the optional extras. > Regards, > Dave > > >> >> Marcus >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
