Bug 1025286

Adding/changing keyboard layouts is a further step. The LayoutIndicator widget cannot tell you everything in its tooltip, that would make it confusing and not useable anywhere else. Moreover, you typically don't need special keyboard layouts configured on the Welcome screen.

(In reply to Vratislav Podzimek from comment #2)
> Adding/changing keyboard layouts is a further step. The LayoutIndicator
> widget cannot tell you everything in its tooltip, that would make it
> confusing and not useable anywhere else.

sorry, but I do not get the logic behind this

it is confusing already, and you say you don't want to make it confusing?

could you explain further?

> Moreover, you typically don't need special keyboard layouts configured
> on the Welcome screen.

once upon a time, there was a bug that you couldn't search for your language because you have no option how to enter the language name

AFAIK this has been fixed by allowing some characters substitutions in the search, but still I consider it a very bad UX design not to allow to change the keyboard layout _before_ the keyboard is to be used to enter text

(In reply to Karel Volný from comment #3)
> (In reply to Vratislav Podzimek from comment #2)
> > Adding/changing keyboard layouts is a further step. The LayoutIndicator
> > widget cannot tell you everything in its tooltip, that would make it
> > confusing and not useable anywhere else.
> 
> sorry, but I do not get the logic behind this
> 
> it is confusing already, and you say you don't want to make it confusing?
> 
> could you explain further?
I'm sorry, but I have no idea what more should I explain. I can only quote my own words again -- the LayoutIndicator widget cannot describe in details, how to add/configure more keyboard layouts.

> 
> > Moreover, you typically don't need special keyboard layouts configured
> > on the Welcome screen.
> 
> once upon a time, there was a bug that you couldn't search for your language
> because you have no option how to enter the language name
> 
> AFAIK this has been fixed by allowing some characters substitutions in the
> search, but still I consider it a very bad UX design not to allow to change
> the keyboard layout _before_ the keyboard is to be used to enter text
Yeah, do you have any solution for the famous chicken-egg dilemma? If we put keyboard configuration before language selection, people would complain about keyboard configuration being not translated (which is even worse UX design). That's why language selection is step #1 and the other steps follow later. The only solution here would be removing the filtering box from the language selection screen which, and I believe you will agree with me here, wouldn't bring any good.

(In reply to Vratislav Podzimek from comment #4)
> (In reply to Karel Volný from comment #3)
> > (In reply to Vratislav Podzimek from comment #2)
> > > Adding/changing keyboard layouts is a further step. The LayoutIndicator
> > > widget cannot tell you everything in its tooltip, that would make it
> > > confusing and not useable anywhere else.
> > 
> > sorry, but I do not get the logic behind this
> > 
> > it is confusing already, and you say you don't want to make it confusing?
> > 
> > could you explain further?
> I'm sorry, but I have no idea what more should I explain.

1) you said "cannot tell you everything" - what do you mean by "everything"?

I am not asking for the ultimate answer about life and universe and ... but rather just a way to change the keyboard layout, it cannot tell even such a simple thing?

2) you said "that would make it confusing" - and I ask how could you "make" confusing something which already _is_ confusing?

"make something" is a status change, to the best of my knowledge of English

from "confusing" to "confusing" is NOT a status change

but that's just word play ... the point is, how could fixing the tooltip/adding more information be confusing? what would "make it confusing"?

why don't you care about the fact that it _already is_ confusing, as layouts cannot be added at the moment it says you should add layouts?

3) you said "not useable anywhere else" - where else is that used? what are the lowest and greatest common denominators of the widget usage?

> I can only quote my own words again -- the LayoutIndicator widget cannot
> describe in details, how to add/configure more keyboard layouts.

why?

> > > Moreover, you typically don't need special keyboard layouts configured
> > > on the Welcome screen.
> > 
> > once upon a time, there was a bug that you couldn't search for your language
> > because you have no option how to enter the language name
> > 
> > AFAIK this has been fixed by allowing some characters substitutions in the
> > search, but still I consider it a very bad UX design not to allow to change
> > the keyboard layout _before_ the keyboard is to be used to enter text
> Yeah, do you have any solution for the famous chicken-egg dilemma? If we put
> keyboard configuration before language selection, people would complain
> about keyboard configuration being not translated (which is even worse UX
> design). That's why language selection is step #1 and the other steps follow
> later. The only solution here would be removing the filtering box from the
> language selection screen which, and I believe you will agree with me here,
> wouldn't bring any good.

and this is false dilemma, there exist far more solutions than the one that you present

for example the text could be "Add more layouts to enable switching. (Rightclick to open layout configuration.)" and the action obvious - jump to the keyboard configuration screen on rightclick

the fact that the keyboard config dialogue won't be translated until language is chosen is a red herring, because even the language selection screen _is untranslated_ before you select the language, so if you'd act on premise that you have to get it translated before _any_ user action, then even the language itself could not be configured (unless the installer has a crystall ball ...)

"the fact that the keyboard config dialogue won't be translated until language is chosen is a red herring, because even the language selection screen _is untranslated_ before you select the language, so if you'd act on premise that you have to get it translated before _any_ user action, then even the language itself could not be configured (unless the installer has a crystall ball ...)"

Hm, just a quick remark - this isn't fair to say. The languages are presented in their native names / characterset by default. So if you could not read the UI you could at least scroll until you recognize the native name of your language.

We have thoroughly hashed out this design with various UX experts, end users, and product management.  Given that RHEL 7.0 Beta has shipped and we have received basically no negative feedback on the language and keyboard selection from HTB users, we need to spend our remaining 7.0 development time on blocker bugs.