Created attachment 152236 [details] Download page (Windows) Summary: It needs extra steps to download LO in non-English languages and the language selection page doesn't help the user to find their language quickly. Context: Around 15 years ago I worked with OpenOffice, but its bad use interface impeded and annoyed me, which made me switch to Microsoft Office. Now I tried to download LO to test whether LO is matured enough to replace MS Office in my private and in a German governmental environment. Therefore, yesterday I went to www.libreoffice.org and clicked the big “DOWNLOAD NOW” button in the middle of the landing page. This brought me to the Download page. I expected to get a German LO version to start quickly and explore LO’s current maturity state. As UX and Design Thinking are not very common in governmental environment yet (with all the drawbacks unhappy users and UX designers know) I do care a lot for good UX to overcome this unhealthy state. I tested with Firefox on macOS High Sierra, Windows 7 and Ubuntu 18.04. Current solution: 1. The download page is in English. 2. By default LO in English is downloaded, but the download page does not inform about it. Users of macOS (and Linux) have to download their preferred language pack separately. 3. There are download links for non-English languages at the end of each box and at the right hand side of the page. 4. The language selection page is long and requires scrolling. It lists and sorts the languages by their English names. It shows native language names only as supplementary information after the English name. I attached some screenshots (made on Windows, macOS and Linux) with these points marked. Drawbacks - Non-English speakers need extra steps to download LO in their preferred language. I easily overlooked the link “Need another language?” after answering the question to download supplementary packages in their language with “No”. While focusing on the gaudy yellow download button I also overlooked the link “Choose other language” at the right side of the page. - For non-English speakers the sort order of the language selection page is unnatural. Therefore, the language list is slow to scan. The need for scrolling adds to the handicap. I was not able to find German language quickly. - Summary: it is cumbersome to get LO in languages other than English. - At the end my conclusion was like: “Oh, things have not become much better yet, now even from the beginning. Another missed chance for FOSS to convince me.” At least I know now that this FOSS project has an infrastructure that gives me the chance to improve things and my feedback is hopefully not lost behind the walls of a closed enterprise. Proposed solution: 1. Detect the user’s preferred language automatically, e. g. from the browser’s preferences or the user’s IP geolocation. This seems to be already done. 2. If existing, show a translated download page. 3. By default, provide the localized version of LO for download. 4. In the language list, do list and sort the languages in their native language name. Optionally: supplement the language by their name in the detected language from step 1 or English. Jakob Nielsen, a UX expert, suggests to list non-Latin languages twice: once in Latin characters in the proper alphabetical order and once in the true character set at the end of the list. Use visual symbols to describe languages. This would make it easier for non-English speakers to get LO in their native language: either by one single click on the Download button or by finding their preferred language quicker in the language selection list. I’m open if your UX and web designers find a better solution and am willing to work with them. You find more information on language selections: - Nielsen, International Web Usability, https://www.nngroup.com/articles/international-web-usability/ - Offer, Best practices for presenting languages, http://www.flagsarenotlanguages.com/blog/best-practice-for-presenting-languages/ - Szilvai, My take on language selections, https://uxdesign.cc/my-take-on-language-selections-945caceb58f7
Created attachment 152237 [details] Download page (Linux)
Created attachment 152238 [details] Download page (macOS)
Created attachment 152239 [details] Language selection page
We talked about the localization topic these days in the team. And besides the requested improvements to our infra structure there are more aspects worth to consider. I would like if we decouple the l10n effort from the release cycle and don't compile localization into the application but have an easy way to add. At least on Linux, the list of localizations spams the repository. And default combinations such as western, ctl, cjk are sometimes also not helpful, eg. when I want to just switch between Hebrew and English. So my take here is to have the localizations as extensions and provide a selection dialog after the first installation. Admitted that such a change wont change the download issue.
Thank you for caring about the issue. What do you mean by decoupling the l10n effort from the release cycle exactly? Where and when do discussions about bugs and/or UX take place? IMHO the outlined approach adds an extra barrier for end users before they can use LibO which they should not be forced to. For security and administration reasons plain end users (not administrators) usually don’t have permissions to install software. So they will have to enter administration credentials as an extra step. In governmental or enterprise environments where they don’t have them they will fail. Therefore either they would not have LibO in their native language or the organisation’s IT department has to build its own LibO software package including the language pack. I looked how the OpenOffice people handles this, see attachment. On their download site they detect the operating system and language. The user can change both. They offer a full installation package and a separate language pack.
Thank you for caring about the issue. What do you mean by decoupling the l10n effort from the release cycle exactly? Where and when do discussions about bugs and/or UX take place? IMHO the outlined approach adds an extra barrier for end users before they can use LibO which they should not be forced to. For security and administration reasons plain end users (not administrators) usually don’t have permissions to install software. So they will have to enter administration credentials as an extra step. In governmental or enterprise environments where they don’t have them they will fail. Therefore either they would not have LibO in their native language or the organisation’s IT department has to build its own LibO software package including the language pack. I looked how the OpenOffice people handle this, see attachment. On their download site they detect the operating system and language. The user can change both. They offer a full installation package and a separate language pack.
Created attachment 152630 [details] OpenOffice download site
Don't think the AOO way is better. If you click on "need another language?" (that admittedly could become more emphasized) you come to a nice page with all the localizations where the language is available in English and original. Also, keep in mind that it heavily depend on the OS/distribution how installation works.
This is work in progress.
Website issues are not tracked here