Hi, vpodzime and I had a discussion about the keyboard layout UI and made a couple of decisions about it, so I wanted to post a summary of that so later on we'll be able to look up why we decided to do what we did. (Before & after mockups attached!) So the background of the before mockup is that it is a direct copy of the GNOME control center keyboard layout dialog. For a lot of the screens in the UI redo, there's a lot of copying of the GNOME control center dialogs because we have a theory that having consistent pre- and post-install configuration will make it more usable, rather than having users learn a different interface for pre- and post-install. (Of course there's no reason why we can't tweak or modify the post-install dialogs to suit our users' needs or constraints we have in the install environment, but starting with the same design is a good starting point I think.) The before mockup shows a search filter along the bottom of the list, which will only show layouts whose metadata match the given search term, and hides those layouts that don't. It is not limited to filtering by layout name only: if you search for 'US', for example, the 'Spanish (Latin American) layout pops up, because 'US' is in the metadata even though it's not in the name of the keyboard layout. So vpodzime had a couple of data points about the keyboard layouts: - We have about 500 possible keyboard layouts. As mocked up in the 'before', then, the list has 500 items total to browse through. - We have about 100-150 supported languages with the keyboard layouts. We also have some non-country based layouts (e.g., Dvorak, Macintosh / Sun, etc.) vpodzime's main concern was that we have a list of 500 items, and it's huge. He suggested that we follow a model similar to XFCE, using a treeview, where the parent nodes are the languages, and the child nodes are the layouts under that language. I noted that treeviews generally are less desirable than a flat list because a lot of UIs have only the 16x16 px '+' and '-' icons as a click target, which is physically difficult and frustrating for a lot of users. Vpodzime confirmed that we could implement the treeview such that clicking on the entire parent row would expand or collapse the subtree, however. We came up with a couple of use cases: - An English-speaking American who needs to add an international layout to access accent marks / Euro symbols / whatnot. - This case worked fine. I typed 'English' in the search box, and it filtered down to ~30 English layouts that were completely relevant to English input. If I typed 'English international' in the search filter, it narrowed down to 8 highly relevant results, all international US layouts. Down to 30 and down to 8 from 500 is great. - A French-speaking Swiss who needs a Switzerland-specific French layout. - This case also worked fine. I searched for 'French' in the filter box and got about 30 relevant layouts, including Belgian even though French isn't in the name of the layout. If I typed 'French swi' immediately the list shows all four Swiss French layouts and I don't need to finish typing 'Switzerland.' Down to 30 and 4 from 500 is also great. So it seems the filter box is pretty sufficient to bringing down the 500 entries down to a workable 30 or less. However, if you can only browse the list and cannot use the keyboard (perhaps the input layout is misconfigured and you're in this dialog to fix it, so it is difficult to type your filter terms), you'll have to browse a list of 500 items. Ouch. What to do? So vpodzime asked, well, if we added the tree view, would that help users who can't use the keyboard? Adding the tree view would take us down from a flat list of 500 layouts to a list of 100-150 parent nodes in a tree list. We decided it's pretty difficult to manually browse through 150 items and not much easier than 500, so adding the tree would only marginally improve the experience. (If the tree view cut the list down to 10-20 items, this would be a different story.) So we decided going with a treeview wouldn't really solve the problem for non-keyboard users. So another thing we considered is putting up front the layouts that go along with the language the user selected on the very first screen of Anaconda. E.g., we could pre-fill the filter field with the name of the language they chose, so by default if they spoke English, they'd see only the ~30 layouts relevant to English, and they would have to erase the search filter to see all 500 layouts. We decided that would be inconvenient for a lot of users, e.g., a lot of folks outside of the US like to add English as a keyboard layout, but this would then add an extra few clicks for those folks. Also, multilingual folks who can say speak Spanish, Chinese, and German (hey they exist) and would want input layouts for all three languages, and this would make it difficult for them. It seems more common that someone would speak multiple languages they'd want to input than they'd want more than one layout for a single language, so we decided to not pre-fill the field. However, what about folks who can't use the keyboard at this point? We had an idea to put some GeoIP smarts into place, if we could. So if, for example, the American wants to add US international layout... we know their main language is English from earlier screens. With GeoIP, we could detect they are within the United States. So we could highlight those keyboard layouts in the list that are most relevant to a United States location, so when the user scrolls through the list, a little icon next to the location-relevant layouts would catch their attention, making it a little bit easier for them to find the layouts they are looking for. If the user doesn't have GeoIP, no big deal - it's just a small value add, and not essential. So the 'after' mockups, attached, show how this GeoIP-based layout highlighting might work. So that's what we talked about. The decisions were: - no tree view - the search box works - don't pre-fill the search box with the user's selected language - add highlights to layouts relevant to the user's location via GeoIP if available ~m
Attachment:
06-keyboard-layouts_before.png
Description: PNG image
Attachment:
06-keyboard-layouts_after.png
Description: PNG image
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
