Hi Vratislav! Great write-up of the issue here (more below) On Fri, 2012-01-20 at 15:32 +0100, Vratislav Podzimek wrote: > 1. There must be some layout set on the Welcome/Language screen -- > English (US). And when user selects his/her language we could add the > corresponding layout to the list. But we shouldn't remove the English > (US) layout and switch to the new layout (at least without letting the > user know with some "warning", so we simply shouldn't). > Summed up when we get to the Keyboard spoke for the first time, we > should have two layouts there -- English (US) and the one based on the > language choice (if it is different from the English (US), of course). 100% ecstatically agreeing here. > 2. There must be some layout set all the time because otherwise the user > wouldn't be able to use keyboard (How to interpret pressed keys?). So > leaving the Keyboard spoke with no layout in the list and greying out > the 'Continue' button on the hub doesn't make sense. Well, I agree here, but I think if no layout is active in the list, you still fall back to 'en us' as being the active layout so it's not the end of the world. (The user won't be running around naked, they'll be clothed with the comfort of en_us :-p) I do think this scenario is confusing for users because *they* don't know that with the empty list they are using 'en us:' Since the list is empty, there is no visual indication to tell them that. Users shouldn't be able to move forward with the install in this scenario unless they explicitly select one so if we went that way, we would grey out the continue button on hub #1. I do not think this option is great, but I don't think its necessarily unworkable either. > > 3. On the other hand, I completely agree with Martin that it would be > confusing/annoying if the '-' button was greyed out with only one layout > in the list. When I get to the screen having only the 'English (US)' > layout which I don't want to be there, the first think I will do is > trying to remove it (natural reaction on something like "Hey, there's > something I don't want/need"). I would consider it stupid if it forced > me to add another layout first. After some thought I agree that is pretty stupid and annoying too. :( > Still, if the list is empty, we have to have some layout set for the > AddLayout dialog's filtering functionality -- English (US). I agree 100% > > Altogether I think we should a) put both English (US) and language-based > layout to the list; b) let the user remove everything first and then add > something else. I agree, but b) is hard :( > Obviously, when we have to have some layout set, we > shouldn't let the user to return from the Keyboard spoke with an empty > list, i.e. we should grey out the 'Back to install summary' button or > always add the English (US) if the list is empty when leaving the spoke > (that might seem confusing, so +1 for the previous one). > > These are my opinions, please let me know about yours, so that we can > get to some final resolution and adapt the code to it. > So here's my thoughts: - Blocking the user from leaving the screen is very annoying, I think. "I will lock you in this jail cell until you do what I want! MUAHAHAH!" (It's a little different when we lock hub #1, because it's a 'point-of-no-return.') - Blocking the user from removing the last / only layout from the keyboard layout list is very annoying. "No, I really really don't like English (US). Why won't you let me get rid of it?? Don't force it on me!" PROPOSAL (let's call it the 'replace' proposal): If there is one language in the layout dialog (let's say en_us), '-' is not greyed out. If I select '-' with that language selected, I will get the 'Add keyboard layouts' pop-up dialog. I can select whatever layouts I want in that dialog. - If I press 'add', the add dialog goes away, en_us is gone from the layout list, and whatever layouts I selected in the add dialog all appear in the list. - If I press 'remove', the add dialog goes away, en_us is the only one in the layout list (as if I had never pressed '-' in the first place) So effectively we're having the '-' button behave as a 'replace' button if there is only one layout in the list. And we're avoiding locking anybody into the screen or locking the '-' button. What do you think? A couple more thoughts on the layout dialog: - I redesigned the keyboard layout addition dialog slightly so the user could add multiple layouts at the same time rather than having to go through and add them one-by-one. So that would make it less likely for a user juggling multiple layouts to reach the point that they only have one in the list. You can see this here: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Live% 20Prototypes/index.svg#screen-keyboard-layouts - Do we have any notion of supported layouts, at least in RHEL? Or are they all supported? (Or is there an official list of supported languages, and only layouts that correspond to those are supported?) I'm just thinking some indicator of supported or not might be helpful. ~m _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
