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
> 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
- 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
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:
- 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.
Anaconda-devel-list mailing list