The Anaconda of Today
Here is what the Anaconda of today has to offer us in terms of selecting the language for the installer UI and the keyboard layout:
There’s (of course) a number of issues with these current screens:
- It’s not translated. If I don’t speak English and/or if I don’t know the name of my native tongue in English, it may require varying degrees of cleverness for me to locate my language here.
- It unnecessarily limits the OS language. This list only makes available the languages that Anaconda’s UI itself is available in. The Fedora UI has available translations in more languages than that set. (GNOME has Lithuanian, Irish, and Belarusian available, for example. KDE has Uzbek, Kurdish, and Kashubian.) However, this is the only language selection dialog in Anaconda, so even if a Fedora translation for your language exists, if it doesn’t have an Anaconda translation, you’re not installing it here!
- It could offer better filtering. While Anaconda’s manually-maintained lang table ties together some useful information across the languages (a default locale, keyboard layout, etc.), at least for keyboard layout selection, it could be a bit smarter providing not only a sane default, but also ‘adjacent’ alternatives that are more likely than most of the others. These are long lists where only a fraction of the data in the list is relevant to the user. If I choose English as my installation language, and I’m (for example) in the U.K., there’s an annoying amount of difference between the two keyboards, yet as you can see in the screenshots above, the Ukranian layout is between the default and the (likely) more relevant U.K. layout. That the U.K. layout is near the U.S. one is sadly a coincidence based on the first few letters of each country’s name (thankfully we’re both united!) Maybe these kinds of smarts are infeasible / difficult-to-maintain, but even a less-intelligent simple list filter widget could go a long way here.
Here’s what it looks like, kind of…. at least my understanding of it, which may be as flawed as believing frankfurters are spiritual beings:
Today’s Discussion: Keyboard Layout
Today in #anaconda, Chris mentioned that users have requested the ability to test out the keyboard layout for a long time. The current ‘Layouts’ tab in the GNOME 3 control center’s ‘Region and Languages’ screen does functionality in it that will light up the keys on a diagram of your chosen layout as you type on the keyboard physically in front of you:
I do see a couple of issues with using it to solve the user goal of testing out their keyboard layout in Anaconda:
- Questionable real estate availability: Keyboard layouts are large and complex. Anaconda may likely be running in a reduced-quality / low resolution graphics mode (depending), within a virtual machine window on a larger desktop, within a live desktop, or otherwise in an environment where the screen real estate available isn’t all that great for the likes of a complex diagram. On my 1400×1050 laptop, it’s pretty difficult to read the key labels on the diagrams at the default window size GNOME’s control center uses for it.
- Too ninja-like: It’s not a very obvious kind of widget. Apparently I’d encountered this widget a number of times (it existed pre-GNOME 3 or so I have been told) without realizing that it responded to keyboard input. It looks like a diagram that you might see in PDF files, which aren’t typically interactive. I feel it doesn’t really compel you to type and try it out.
Both Chris and Elad liked the idea of having a box users could use to take their chosen layout for a road test, so here’s an idea for that:
This is mostly stolen wholesale from the GNOME control center UI. It is whittled down somewhat. Here’s how the screen would work with the original GNOME control center design:
So as you might notice comparing them side-by-side:
- The keyboard layout option to have layouts apply either across the desktop or to individual windows have been removed. The thinking here is that they don’t really apply in Anaconda, and bcl (rightly so, IMHO) keeps pushing the idea Anaconda should be for installing the OS, and not really get out-of-scope. So if folks want to change details about how layouts apply to windows, they can do that post-install. Plus, respective to the other options that I think are more common, the option takes up an awful lot of real estate.
- We added a layout-testing text dialog that users can use to type a bunch of text to see if their keyboard layout is selected properly.
- We added a visible indicator of what the current key command to switch between layouts is. We’ve been talking about keeping Anaconda panel-less, so you’d need to know the key combo to be able to switch within Anaconda’s UI.
- I removed the ‘Reset to Defaults’ button. Maybe it really belongs there. I took it out because I didn’t really understand how it was useful: to me it seems a large target that in one poorly-aimed click could create more work, and I am not sure how such a functionality is particularly useful to this screen but not necessary for other such configuration screens. Maybe that was stupid of me. I’m sure you’ll let me know!
Some more screens for this section of the UI; these are the various dialogs that pop up depending on what you click on screen 6 above:
Keyboard options dialog
Add a layout dialog
Layout preview dialog
Stuff you might notice here:
- We removed the vast majority of the options in the keyboard options dialog (screen 6-1.) The way our discussion on this went was that the current options popup in GNOME 3 shows all of the options available in /usr/share/X11/xkb/rules/evdev.xml – way too many options than are really needed for the bare essentials of getting through the installer successfully in the correct language. We decided that layout switching *is* important to keep though, since again, non-live installs have no panel so there’s no layout chooser otherwise. So that’s all that’s left.
- The ‘preview’ button in the add layout dialog (screen 6-2) is gone. I would like very much for Anaconda not to have more than one level of dialog on top of the main screen. The window stacking that happens in Anaconda today is pretty bad. The keyboard layout preview may still be accessed via the gears icon on the bottom of the layouts list in screen 6.
- The layout dialog (screen 6-3) says what you can do with it. Just a brief line saying how you can use it to see where your physical keyboard maps up to the diagram.
Today’s Discussion: Language
So after taking a look at the above, and after we talked about potentially adding more smarts to how things are selected as defaults, we took a look at the language-related screens in the new Anaconda UI layout.
First, the “Welcome to Fedora” language selection screen that introduces users to the install process received some updates:
What you’ll notice:
- Languages are listed both in their native name and in their name with respect to Anaconda’s currently-displayed language.
- There is a filter box for them (a great idea from the GNOME control center.)
Next, the OS language selection screen. This is a departure from what Anaconda currently allows; as mentioned earlier, Anaconda today collapses the installer UI language selection and the OS language selection into one selection, so you miss out on being able to select some languages that are actually available.
Now, I admit I don’t quite understand yet how this will work under the hood. For example, should this list change based on my desktop environment selection? If I don’t install a desktop and only use the system from a terminal, how does my language choice here affect that? I’m not sure right now, but here it is anyway:
There are some ideas here that might be kooky / stupid. Regardless, here they are:
- There’s a flag to indicate if a translation is very incomplete. A random idea is to show a ‘Limited translation’ flag next to translations that are less than 30% complete. At build time, we could talk to Transifex and get the completion percentages for each language, and set the flags that way. “Why would you even show those in the first place?” you might ask. Well, there’s a tension to be balanced here, as Chris pointed out. Is it going to save a user from the frustration of seeing their language only in 30% or less of the UI and English everywhere else? (Well, English or whatever it may fall back to, according to the C locale – whatever language the programmer wrote it in originally as I understand it.) Or, is it going to be demoralizing to not see your language in the list, and every little bit helps and might inspire a contribution to further complete it? We’re not sure. We’re both Americans. You may not be and this may be an issue that deeply affects you. What do you think?
- There’s a filtered list of probable languages displayed at the top of the list. Again, I am American, a sad monoglot (well, I probably know enough Japanese to make a native speaker cover their ears in pain) so this may be a completely stupid idea—I’m relying on you to school me in a non-inflammatory manner! The idea is we could check the list of languages to see if there are any other versions of the same language. So if I chose to view Anaconda in English, any languages whose code is en_* would be displayed in the filtered list. (Dvorak fans, rejoice in the 15 seconds this may save you!) Maybe there is some way we could display languages with the same country code next to each other as well (I am thinking of India, a country of many languages, here.) What do you think?
Implications
If we went with this design, then, the language selection flow in Anaconda might look something like this:
A probably non-exhaustive list of how this would change Anaconda is as follows:
- Folks who don’t speak English would be able to more easily pick out their language in the initial set of ~60 or so languages Anaconda supports since they’d be available in their native name.
- You’d be able to install the OS in a language beyond the limited set that the Anaconda UI itself is available in.
- You’d be able to choose between a preferred language with limited coverage or a less-preferred language with fuller coverage since limited coverage languages would be flagged.
- You’d be able to use more than one keyboard layout, which was not possible before. Multi-lingual users would not have this extra step post-install.
- The keyboard command for switching between keyboard layouts would be more visible, and you’d be able to switch between them in the installer itself (useful for an American with accent marks in her name. *cough*)
- You’d be able to modify the keyboard command for switching between keyboard layouts, and not need to configure it post-install.
- You’d be able to filter in both the keyboard layout and language lists.
- You’d be able to take a selected keyboard layout for a test drive before committing to it.
So, what do you think? Cool? Crazy? Somewhere in-between?
Wait, whoah, what are you doing with my precious Anaconda?
Wait, whoah, you consider Anaconda precious?
We’re doing a UX redesign of Anaconda. All the details are in that post. You’d like to help? AWESOME. Check out the UX redesign of Anaconda post, please!
Unrelated Public Service Message
I’ve heard that those reminder signs you sometimes see on napkin dispensers at restaurants about how ‘paper comes from trees,’ and ‘please don’t hurt the environment’ are effective at curbing folks wasting napkins by throwing out the ones they didn’t need or use. I’d like to test a similar mechanism with respect to blog comments. In the past, I’ve taken to leaving the nastier ones unapproved in the queue, but I’ve decided I’d rather not ever see them in the first place!
So, before you post an annoyed or angry comment, please realize we’re doing the best we can and that mean comments make panda cry. LOOK HOW HAPPY HE IS! DO YOU WANT TO MAKE PANDA CRY?
Okay, I’ve gone and said it. There. Thanks for indulging me.
Left this on Facebook but I think this is a more appropiate place to leave my comment:
I really love the Anaconda redesign. I like the keyboard and language redesign, and the only thing that I can ask is that the Filter Box is placed ABOVE the list, not below it.
Thanks for working on this Mairin (And the entire Anaconda Team!), I'm looking foward to installing Fedora 16!
Assuming the user downloaded the Fedora installation media from some existing OS that has the right language set, you might consider helping the user default to that when using an installation mechanism that bootstraps from that existing OS. As for keyboard layout, what about the "please type this word" approach, where you look at the keycodes you receive when the user types known text?
Oooooh I love the 'please type this word' approach… I don't think I've ever seen that before. Do you know of any examples I could look at? (I'm guessing there's specific words you need them to type to get at this.) Although that wouldn't work for say Dvorak folks who use Qwerty, but hey, can't please everyone… 🙂
Oh, also! Owen also had the idea of having some way of passing the language set used to download the ISO into the installer, he was looking into how we might be able to grab that and embed it into our ISOs somehow… I forgot to mention that in the blog post, so thanks for the reminder!
The most effective way that I know of to identify keyboard layouts without being annoying works something like this:
1. Press the key to the left of the Shift key on the right side of the keyboard.
2. Press the key to the right of the Shift key on the left side of the keyboard.
This is typically sufficient to narrow it down to a list of human-consumable size. An ANSI keyboard, for instance, narrows it down to ANSI/JIS/ISO. Since you know the language already you can just display the list and preselect your best guess based on the language.
3. Your keyboard has been identified with the ANSI layout. Test your keyboard below, then click Next to proceed. If this is not the correct type for your keyboard, choose the type and click Next.
This is much simpler for the user than entering “please type this word” cheat codes. It also prunes layouts from the list based on facts about hardware rather than assumptions based on the language.
There's a bug in that first screenshot — the entire idea with the language list is that it includes both the native language version of the language name as well as the one in the current language (so English by default) much like your later mockup 🙂
Hehe I figured as much because of the doubling. Although, the list in GNOME 3 isn't doubled and is only in English. :-/
Looks like "make lang-names" isn't generating the right thing anymore. I probably screwed this up.
Note that you might actually be able to reuse the Gnome 3 control center widgets that you want instead of reimplementing them.
For example, the map widget for timezone selection should be pulled out of control center into a library so it can be reused for the GDM initial setup: http://mail.gnome.org/archives/gnomecc-list/2011-…
Yep, we're actually acutely aware of that, but have been running into some issues:
* The control center widgets aren't super-easy to reuse, apparently they are not in libraries and there aren't plans to do so at the moment 🙁
* They're really not always appropriate for Anaconda's env and need modification (Networking is a good example here)
The problem with the keyboard layout viewer is that it shows alle possible symbols for every key. (Ie, 4).
The OSX one does it a bit differently
. Simply show the main key function, and if a modifier is pressed, show a new set of possible actions for all the other keys.
It does make it look much more friendly, and allows a much smaller window.
Nice to see that the Fedora installer is finally being redesigned. The current installer is ugly and confusing.
The new installer should have a option to download and install support/codecs for mp3 and other common proprietary stuff.
"The new installer should have a option to download and install support/codecs for mp3 and other common proprietary stuff. "
Heh. Not going to happen, my friend. You know why it doesn't today, right?
anaconda will allow you to add your own repos, and we will merge the comps from those third-party repos so you can select the groups in the UI as well. So you can already add whatever proprietary stuff you want if you know where you can get it from. But we won't be adding it into the default repo list for you.
As someone else who does a lot of drawing and colouring in with Fedora 15, only thing that bothers me about the keyboard is the way X gobbles up the Alt key so that "Alt-left click"-ing moves windows instead of text kerning (Inkscape) or scaling (Synfig Studio) or whatever. Probably a quick win to add to the next Fedora for artists would be to reinstate the GNOME2 "Window Movement" setting to the Keyboard Preferences in GNOME3. BTW: I've found those keyboard layout previews are invaluable for Hungarian users as there are so many different Hungarian keyboard layouts. Great blog, lovely Panda and I do hope Panda isn't upset with me!
Oh yeh, the alt left click grab is also problematic with Inkscape, as you need that combo to grab objects behind other objects but it can't work. It would be lovely to get around that. I'll need to look into the 'Window Movement' setting to see how that is configured and what its backstory is… to me it feels like we should just configure it in a more artist-friendly way by default, but there may be (and there usually is in these types of things) a good reason why the X.org/GNOME folks made the change, in which case providing a way to opt-out of it could be a good fallback.
Someone else here mentioned Hungarian layouts. I was completely unaware that there are so many so thank you for schooling me. 🙂 We'll try to figure out a more convenient way to interact with the layout previews, then.
Panda is quite pleased with the tone of all of the blog comments, and is very happy at how many great ideas and useful information you all took the time to share. Thank you so much 🙂
Is there any particular reason why you can't just have the user choose one language during the install, and then have good configuration UI in the operating system so they can add more later? It's not like Windows where you have to download language packs, it's just a setting that turns languages on or off that are installed anyway, right?
By the way, if you make it semi-required that the user uses the keyboard to select in lists (because there are a million choices and they need to filter) you do need to make sure the keyboard is setup correctly as early as possible. But again, why not have a default choice for the key to switch layouts, and UI in the operating system to change it later?
On the keyboard layout example, you could show just the default key output and show the others as the user presses or clicks on the modifier keys. Do not include strings like 'XF86…' and perhaps use "space" instead of "nonbreaking space". If the left control key does the same thing as the right one (while typing), make it say 'Control' instead of 'Control L'. Then again, making it easy to select a reasonable layout (that will get you through the install) and then having good UI in the operating system to fix it is better in my opinion.
One thing to watch out for is passwords typed with weird layouts though.
I read that you removed most of the options, I ask : please don't remove the compose option.
I cannot live without compose, and I really don't want to go edit file to activate it.
Can you explain to me a bit how you use it?
It's simple, you check the key you want to perform a compose operation (for example right control) in the gnome keyboard options, and then when you type, for instance, compose+o+/, you get ø. It's a killer feature of X for me, and it deserves a better place, maybe even an adv for new users and an UI for the user to add it's own composing sequences.
So why would you use compose to type ø if your keyboard supports it? E.g., wouldn't you set your keyboard to Danish or whatnot that would have support for that character? Or do you have a specific reason to not use the layout that includes that character?
When Fedora 15 came out, I installed Fedora for the first time and was VERY disappointed about its installer, knowing the latest Ubuntu installer. It really needs some Panda love. 🙂
I like your mockups very much.
+1 for the filter at the top.
Also, because the language selection comes after the keyboard layout selection, it should already have a sane default selected based on the chosen keyboard layout. (If I choose a German layout chances are high I will choose German as the language)
The "type this word" approach seems circumstantial to me. I think even scrolling through the whole list might be faster than typing numerous words (that most probably would be in a foreign language).
Hi Michael, I do believe Anaconda has this behavior today, but it definitely would in these mockups – see how the United States keyboard is at the top of the layout list on the layout selection screen? I think that whichever language you chose up-front, the appropriate layout would already be in that list.
Also you might always keep the US layout as a second choice, just below the preferred ones. It is somewhat common for programmers to use a US layout rather than the local layout. Related to that, I don't think having the preview in a separate step is a good idea. It's the typical choice that would be okay for 95% of the locales but would piss off others (from reading the comment, Hungarians seem to fall in this category).
Regarding your request for opinions from non-Americans, I would certainly prefer a "limited translation" warning to not seeing the language at all. If it's possible to add fallbacks as kamil said below, that would be nice. And related to that mockup, please note that "Chinese (Simplified)" and "Chinese (Traditional)" are a tricky differentiation with political aspects too. It shall suffice to say that traditional Chinese is mostly used in Taiwan.
Another somewhat niche setting is the distinction between language and locale settings (for example there's no intuitive way to use English and have the euro as the default currency symbol! And at some point I wanted Italian date/time, English messages and Czech currency…). Perhaps an "advanced" button can be added.
"Related to that, I don't think having the preview in a separate step is a good idea. It's the typical choice that would be okay for 95% of the locales but would piss off others (from reading the comment, Hungarians seem to fall in this category). "
What do you mean about the preview in a separate step? The diagram popping up? Why is this an issue specific to Hungarians? Do they use a lot of similar-but-different layouts?
"Another somewhat niche setting is the distinction between language and locale settings"
But you don't need the euro sign for filling out anaconda, right? So this is a post-install config you could do? Or would you really really rather configure it during install? We definitely don't want anaconda duplicating too much of the post-install config that's available, since the post-install config environment is much richer for these types of things than anaconda could be, and we don't want anaconda's scope to creep too much.
Re. preview, you wrote “The ‘preview’ button in the add layout dialog (screen 6-2) is gone. I would like very much for Anaconda not to have more than one level of dialog on top of the main screen. The window stacking that happens in Anaconda today is pretty bad. The keyboard layout preview may still be accessed via the gears icon on the bottom of the layouts list in screen 6.”
At the time I thought it would be nice to have the preview available in screen 6-2. However, it is not clear to me now what the text box in 6-2 is for. The magnifying glass on the right makes it look like a search box, but perhaps it is for testing the layout you selected?
In any case, perhaps the solution is not to add a preview, but rather to add a text box for testing.
Regarding the distinction between language and locale settings, you’re right that it can be deferred to firstboot or later. Windows does it during installation. 🙂 BTW they’re incredibly difficult to find—at least in GNOME 3 they are gone completely, it seems—so there’s already a problem there anyway.
Hi, really nice redesign.
Would it be possible to add more keyboard layout?
For Example, il French there are several different options (even some deprecated) but we don't have the choice for the "bépo" (which is coming from the dvorak-fr).
There are some bug reports about that…
https://bugzilla.redhat.com/show_bug.cgi?id=70075… https://bugzilla.redhat.com/show_bug.cgi?id=55615…
Any actions to take, from the anaconda team or from other contributors?
Your work is wonderful, like every time. 😉
I would like to propose a new feature that is very helpful for non-english speakers, but I haven't seen it nowhere yet. There are certain sets of languages that are very close to each other and a speaker of one such language can easily understand the other language. For example, take Czech and Slovak languages. The Czechs understand Slovak almost flawlessly and the Slovaks understand Czech almost flawlessly (first hand experience, I am Czech). If you look at GNOME translations, Czech has almost full coverage, but Slovak has only about 60% coverage. It means that it would be extremely beneficial for a Slovak speaker to use following language fallback mode: Slovak -> Czech -> English (instead of current Slovak -> English). This is easily configurable even today (using LANG environmental variable), but no configuration tool like that is neither pre-installed nor part of the installer.
The proposal is that you wouldn't allow to select just one preferred language and then forcefully fallback to English, but you would allow the user to select more of them and order them according to his/her priority. Even better solution would automatically suggest best/recommended option (like Slovak -> Czech -> English) – I am sure Fedora community can create these language dependencies pretty quickly for most world languages. These relations can be easily hardcoded because they don't change in time (maybe in tens of years).
It seems to me that the best place for the configuration would be in the very language selection dialog in the system installer (of course it would be nice to have some GUI to change it later, but I think Anaconda is a good fit for the initial configuration). It would also apply for Anaconda itself.
With my proposal, I don't need to solve the hard questions of using "limited translation" language (I may not have a clear idea what that really means). Even though my native language has limited translation, I can choose a good secondary (or tertiary) language before falling back to English.
I love this idea of smart fallbacks! I'm not sure where it would need to be implemented though. E.g., Anaconda might support it for its UI, but how would it configure things in a such a way that post-install the desktop UI / etc fall back correctly?
AFAIK it's a matter of configuring just one environment variable (similarly to locale variables like LC_ALL, etc). That can be written out to files like /etc/environment or /etc/bashrc. Anaconda surely touches files like this when setting the default system language. Every application that uses gettext for translations should then pick it up correctly. I don't have deep development knowledge in this, I just know it's possible (I used it personally some time ago) and it would be very beneficial for many users. So I would like to propose this idea, I am sure Anaconda developers will know more about it.
It would be great if this option was already available in Gnome language preferences, so that it can be configured easily post-install and you could take your inspiration out of it. But that's probably another RFE bugreport to file.
Cool, thanks for the great idea and for this background information. I'll see what we can do!
Juste some suggestions:
On the Welcome window:
It would be cool to ask the country with the language. If Anaconda know the language _and_ the country, it can guess the true keyboard layout and the true time zone.
Another cool point: Auto-suggestion in big lists.
Exemple: If you have selected the language, place countries where peoples speake this language on top of the country list and keyboard layouts most used for this language on top of the keyboard layout list. And vice versa. specially in the welcome window of Anaconda.
Okay cool, I'll see what we can do there. We've been talking about using GeoIP too if there is an active network connection, so that might help as well. I agree that narrowing things down as much as we can so the user has to go through less effort in most cases is a good approach!
It would be very useful if this redesign could take care of Anaconda in live medias.
As of now, there is no easy way to use non-english language in Anaconda when running from KDE Spin. See this bug I reported two years ago: https://bugzilla.redhat.com/show_bug.cgi?id=54105…
Thanks for bringing this bug to my attention! I'll take a look and see what we could do.
“Language” and “Keyboard Layout” should be managed at grub stage (actually it’s english-only!) right after booting an installation disk and made default for root (who installed the machine).
User settings must be part of upstream gnomeOs effort https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup
good F16!
How come?