KeyboardSpoke improvements
 

These patches include improvements of the KeyboardSpoke based on your comments and some other ideas.
A video presenting these changes can be found at: http://vpodzime.fedorapeople.org/add_layouts.ogg and as well
as the previous one it doesn't contain the mouse pointer and the dialog may seem a bit slow and unresponsive
because it was recorded on a virtual machine and the list of layouts was loaded from a file.

--
Vratislav Podzimek

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

KeyboardSpoke improvements
 

On Thu, 2012-01-19 at 13:44 +0100, Vratislav Podzimek wrote:
> These patches include improvements of the KeyboardSpoke based on your comments and some other ideas.
> A video presenting these changes can be found at: http://vpodzime.fedorapeople.org/add_layouts.ogg and as well
> as the previous one it doesn't contain the mouse pointer and the dialog may seem a bit slow and unresponsive
> because it was recorded on a virtual machine and the list of layouts was loaded from a file.
One more thing:
I want to block the "Back to install summary" button when the list of
added layouts is empty (we should allow this for convenience if the user
wants to replace the predefined layout by some other), but since it is
integrated to the AnacondaSpokeWindow widget it cannot be simply loaded
by builder.get_object(). Chris, could you please add a function
returning this object to the widget? I think it could be useful in some
other cases too. Or am I wrong?

--
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

KeyboardSpoke improvements
 

Hey Vratislav,

On Thu, 2012-01-19 at 13:51 +0100, Vratislav Podzimek wrote:
> I want to block the "Back to install summary" button when the list of
> added layouts is empty (we should allow this for convenience if the user
> wants to replace the predefined layout by some other), but since it is
> integrated to the AnacondaSpokeWindow widget it cannot be simply loaded
> by builder.get_object(). Chris, could you please add a function
> returning this object to the widget? I think it could be useful in some
> other cases too. Or am I wrong?

So, I think that you don't need to grey out the back to install summary.
The only place you need to grey out is the next button on hub #1. If the
user goes back to the hub, there should be a little (!) icon next to
keyboard layout with a message saying, 'No layout selected' or something
like that.

(Make sense?)

That's the general model we were going for with greying stuff out.

~m



_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

KeyboardSpoke improvements
 

Hehe, one more thing -

On Thu, 2012-01-19 at 10:22 -0500, Máirín Duffy wrote:
> So, I think that you don't need to grey out the back to install summary.
> The only place you need to grey out is the next button on hub #1. If the
> user goes back to the hub, there should be a little (!) icon next to
> keyboard layout with a message saying, 'No layout selected' or something
> like that.
>
> (Make sense?)
>
> That's the general model we were going for with greying stuff out.

With the widget we have for the keyboard layout selector, even better is
if you could grey out the '-' button for the last layout. So it wouldn't
be possible to have no layouts.

I think that would make it easier for the user because then they won't
have the opportunity to get into that error state in the first place.

~m


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

KeyboardSpoke improvements
 

----- Original Message -----
> Hehe, one more thing -
>
> On Thu, 2012-01-19 at 10:22 -0500, Máirín Duffy wrote:
> > So, I think that you don't need to grey out the back to install
> > summary.
> > The only place you need to grey out is the next button on hub #1.
> > If the
> > user goes back to the hub, there should be a little (!) icon next
> > to
> > keyboard layout with a message saying, 'No layout selected' or
> > something
> > like that.
> >
> > (Make sense?)
> >
> > That's the general model we were going for with greying stuff out.
>
> With the widget we have for the keyboard layout selector, even better
> is
> if you could grey out the '-' button for the last layout. So it
> wouldn't
> be possible to have no layouts.

I don't think this is a good idea. If the default keyboard is something what I don't want at all, I would first remove it, and then go and add the ones I want. Not add the ones I want, and then look and find the one that was there before to remove it.

Do you know what I mean?

>
> I think that would make it easier for the user because then they
> won't
> have the opportunity to get into that error state in the first place.
>
> ~m
>
>
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

KeyboardSpoke improvements
 

On Thu, 2012-01-19 at 12:14 -0500, Martin Gracik wrote:
> I don't think this is a good idea. If the default keyboard is something
> what I don't want at all, I would first remove it, and then go and add
> the ones I want. Not add the ones I want, and then look and find the
> one that was there before to remove it.
>
> Do you know what I mean?

I know what you mean, but I do think that's a narrow use case. I mean,
if you go to do that and see the button is grey, you add the one layout
you want, hit enter, then delete the original one. It's an
inconvenience, sure, but how inconvenient is it compared to putting the
dialog in an error state and necessarily having to have some kind of
text (which would need to be translated) to explain you can't move
forward until you pick a layout?

How are we setting the default layout now? Is the default layout going
to be the default one associated with the language the user selected on
the very first screen (language selection) or is it going to be US
English?

It might be a very common case to always want US English available as a
layout, in which case if it's always there you wouldn't want to remove
it?

~m

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

KeyboardSpoke improvements
 

----- Original Message -----
> On Thu, 2012-01-19 at 12:14 -0500, Martin Gracik wrote:
> > I don't think this is a good idea. If the default keyboard is
> > something
> > what I don't want at all, I would first remove it, and then go and
> > add
> > the ones I want. Not add the ones I want, and then look and find
> > the
> > one that was there before to remove it.
> >
> > Do you know what I mean?
>
> I know what you mean, but I do think that's a narrow use case. I
> mean,
> if you go to do that and see the button is grey, you add the one
> layout
> you want, hit enter, then delete the original one. It's an
> inconvenience, sure, but how inconvenient is it compared to putting
> the
> dialog in an error state and necessarily having to have some kind of
> text (which would need to be translated) to explain you can't move
> forward until you pick a layout?
>
> How are we setting the default layout now? Is the default layout
> going
> to be the default one associated with the language the user selected
> on
> the very first screen (language selection) or is it going to be US
> English?

I would say it should be based on the language you select.

>
> It might be a very common case to always want US English available as
> a
> layout, in which case if it's always there you wouldn't want to
> remove
> it?

Then we can automatically use English US layout if the user removes all layouts from the list.

>
> ~m
>
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

KeyboardSpoke improvements
 

A little bit of rationale for these issues&solutions:

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).

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.

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.
Still, if the list is empty, we have to have some layout set for the
AddLayout dialog's filtering functionality -- English (US).

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. 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.

--
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

KeyboardSpoke improvements
 

> These patches include improvements of the KeyboardSpoke based on your comments and some other ideas.
> A video presenting these changes can be found at: http://vpodzime.fedorapeople.org/add_layouts.ogg and as well
> as the previous one it doesn't contain the mouse pointer and the dialog may seem a bit slow and unresponsive
> because it was recorded on a virtual machine and the list of layouts was loaded from a file.

Thanks for making the changes. They look fine, except for one comment I
made on the last patch. We'll continue the other subthread separately
and arrive on a decision for that stuff there.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

KeyboardSpoke improvements
 

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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list