Description of problem: In KEYBOARD pane of the new anaconda installer, the user almost always just wants to select one keyboard layout. This is complicated. The user must: * Realize that the button with a plus on it adds a keyboard layout. * Select the keyboard layout from the list in the dialog that pops up. * Now faced with two layouts, select the one that's not desired. * Find out that the button with a dash on it removes the selected keyboard layout. I would expect to simply choose a keyboard layout from a list. In fact one actually only needs to select the one that one will be using to log in and complete the installer. It seems that you could leave the configuration of multiple keyboards later through a configuration program such as gnome-control-center. Version-Release number of selected component (if applicable): Fedora 18-Alpha INSTALLATION
(In reply to comment #0) > Description of problem: > > In KEYBOARD pane of the new anaconda installer, the user almost always just > wants to select one keyboard layout. This is complicated. The user must: > > * Realize that the button with a plus on it adds a keyboard layout. > * Select the keyboard layout from the list in the dialog that pops up. > * Now faced with two layouts, select the one that's not desired. > * Find out that the button with a dash on it removes the selected keyboard > layout. Sorry but non of these seems to me as a big issue and anything surprising. > > I would expect to simply choose a keyboard layout from a list. > > In fact one actually only needs to select the one that one will be using to > log in and complete the installer. It seems that you could leave the > configuration of multiple keyboards later through a configuration program > such as gnome-control-center. mizmo, any comments here?
And just one tip: You can use the "minus-button" to replace the only layout you have in the list.
Hi Stef, depending on the language, there may be many (look at English, for example, there's more than 30 I think) potential keyboard layouts. We emulate the GNOME control panel keyboard layout selection dialog. If we had some text saying to click on the [+], would it help? (The GNOME dialog does not have this text.)
(In reply to comment #2) > And just one tip: > You can use the "minus-button" to replace the only layout you have in the > list. Thank you. I did figure that out. Obviously though, I didn't file this bug because I was annoyed and not able to accomplish my personal objective. Rather with the aim of helping to make the new installer better. (In reply to comment #3) > Hi Stef, depending on the language, there may be many (look at English, for > example, there's more than 30 I think) potential keyboard layouts. I imagine you've seen how Ubuntu or Windows accomplish that: http://howtoubuntu.org/wp-content/uploads/2012/04/6-How.png http://tekwik.com/wp-content/uploads/2012/06/Screen-Shot-2012-06-08-at-11.30.59-PM.png Maybe you've considered the use cases ... But are you sure you want to have all the options for setting up multiple keyboard layouts in anaconda, their order, including compose keys, and so on? Can all of this even be manifested in the installed OS for users who are not installing a desktop environment? I would have assumed the main use case for configuring a keyboard in an installer is so that you can type during the installer. Seems like the rest can be configured later, if necessary. This has the nice side effect of not overwhelming a user while installing the OS. > We emulate the GNOME control panel keyboard layout selection dialog. I think that the work on making the two have commonality and present a similar interface to the user is really great. Kudos. That said, there's a difference between a UI you have to step through just once (like anaconda) and a UI that's more of a tool, which you can explore and grow to know better over time (like GNOME Control Center). Both should be intuitive, but in some cases different UI decisions have to be made. In addition, the keyboard selection in GNOME control center isn't very helpful either. That is: Often the user is selecting a keyboard layout because they cannot type with the default keyboard layout. But the user has to type in order to filter the keyboard layouts in the very long list :S There's some discussion about that, but waiting on design input for the keyboard selection use case: https://bugzilla.gnome.org/show_bug.cgi?id=684565
(In reply to comment #4) > Maybe you've considered the use cases ... But are you sure you want to have > all the options for setting up multiple keyboard layouts in anaconda, their > order, including compose keys, and so on? Can all of this even be manifested > in the installed OS for users who are not installing a desktop environment? > > I would have assumed the main use case for configuring a keyboard in an > installer is so that you can type during the installer. Seems like the rest > can be configured later, if necessary. > > This has the nice side effect of not overwhelming a user while installing > the OS. Well, there is an expected use case that would be problematic if we allowed only one keyboard layout during installation: If user wants to enter his/her name with all (possibly national) characters and on the other hand wants to enter the password that contains special characters that can be typed only using English layout.
(In reply to comment #5) > Well, there is an expected use case that would be problematic if we allowed > only one keyboard layout during installation: > If user wants to enter his/her name with all (possibly national) characters > and on the other hand wants to enter the password that contains special > characters that can be typed only using English layout. Interesting use case. Is it a use case you want to support in the new anaconda UI? It wasn't supported before, right? In this use case the user would need to think ahead and realize that they should select their keyboard layouts appropriately in anaconda, so that later on in firstboot (at which point I don't think they have a way to change keyboard layout) they can create a user account with a name and password with differing keyboard layouts. In this use case, does firstboot indicate the current keyboard layout, and offer a way to switch between multiple layouts? Or is the user expected to guess which keyboard layout is active and remember the key combination to switch between them?
(In reply to comment #6) > (In reply to comment #5) > > Well, there is an expected use case that would be problematic if we allowed > > only one keyboard layout during installation: > > If user wants to enter his/her name with all (possibly national) characters > > and on the other hand wants to enter the password that contains special > > characters that can be typed only using English layout. > > Interesting use case. Is it a use case you want to support in the new > anaconda UI? It wasn't supported before, right? > > In this use case the user would need to think ahead and realize that they > should select their keyboard layouts appropriately in anaconda, so that > later on in firstboot (at which point I don't think they have a way to > change keyboard layout) they can create a user account with a name and > password with differing keyboard layouts. > > In this use case, does firstboot indicate the current keyboard layout, and > offer a way to switch between multiple layouts? Or is the user expected to > guess which keyboard layout is active and remember the key combination to > switch between them? This is expected to happen in the "installation progress" screen in anaconda, not in firstboot. I don't know if this will be implemented in F18, but it is a plan for the future.
(In reply to comment #7) > This is expected to happen in the "installation progress" screen in > anaconda, not in firstboot. I don't know if this will be implemented in F18, > but it is a plan for the future. That'll be a nice touch.
Stef, can you think of a less overwhelming way to allow for multiple keyboard layout usage in the installer? We do have users who asked for this, particularly with inputting the system hostname, root password, and wifi access point and passwords. Part of the goal of emulating desktop configuration was to make it less necessary past install since setting up keyboard twice via two very different dialogs is annoying (again, why we're striving for consistency.)
/me thinking, we could have a simplified ui by default and have an 'additional layouts' button somewhere in the corner where you could add more? It might be okay to support only two, so the additional layouts button could have a nrowseable tree view (as suggested in gnome bug 684565) and let you select one. it totally kills the consistency, but i guess if the 'upstream' dialog is busted we don't want to emulate it. :-/
(In reply to comment #10) > /me thinking, we could have a simplified ui by default and have an > 'additional layouts' button somewhere in the corner where you could add > more? It might be okay to support only two, so the additional layouts button > could have a nrowseable tree view (as suggested in gnome bug 684565) and let > you select one. That sounds like a good plan. > it totally kills the consistency, but i guess if the 'upstream' dialog is > busted we don't want to emulate it. :-/ Yes, true. I do agree with you that it would be nice to have some consistency between the two. Perhaps the 'additional layouts' dialog would be consistent (where possible) with the gnome-control-center dialog ... although it may be a bit of a moving target.
Created attachment 621031 [details] idea for simplified keyboard layout selection here's a super simple mockup with no multi-layout functionality...
Created attachment 621033 [details] idea for simplified kb layout selection (last mockup export was kind of wonky, this should look better)
Created attachment 621060 [details] idea for simplified kb layout with secondary layout option here's an idea how we could allow for a second kb layout to be selected but still maintain a simplified primary kb layout ui.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I'm moving this bug to F20 because I think it still applies. Hope that's okay!
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.