Oh haha thank you! Summaries are nice :)
The thing that has changed in the past year is that is the GTK list widget is now available and in use in a lot more places. But I should read through the summary more to see what I was thinking... will reply more thoroughly later today.
~m
-------- Original message --------
From: Vratislav Podzimek
Date:01/27/2014 7:25 AM (GMT-05:00)
To: Discussion of Development and Customization of the Red Hat Linux Installer
Subject: Re: Reworking the Keyboard spoke
On Thu, 2014-01-23 at 20:50 -0500, Máirín Duffy wrote:
> Hey Vratislav!
>
> I wanted to point out we did have a mockup that would enable two layout
> selections, here:
>
> https://bugzilla.redhat.com/attachment.cgi?id=621060
>
> (from https://bugzilla.redhat.com/show_bug.cgi?id=859465)
>
> The mechanism for determining whether or not a layout is default or not
> is whether you use the main ui to set it up or a lightbox to add it and
> it appears in the secondary bucket below.
I know about that mockup, but:
* we should allow users changing the order of the added layouts
* the AddLayout dialog as a reaction on clicking the Secondary Layout
icon is problematic (the same issues we have with the current one)
* more things answered below applies to this mockup
>
> I'm not saying we need to do that now, just that it might be interesting
> to look at now and maybe provide some ideas.
>
> There's also the gnome-control-panel way of doing it which is also
> interesting (although it doesn't seem to have as many layouts?)
>
> On 01/23/2014 09:07 AM, Vratislav Podzimek wrote:
> > in the lifetime of Fedora 18, 19 and 20 there have been some serious
> > issues identified in our Keyboard spoke. The main issue is that with a
> > one-level layout selection, it is not possible to list keyboard layouts
> > for multiple languages (thus e.g. Belgian layout was not listed as
> > Belgian, but as Dutch, because those two languages both use the layout).
>
> > The other issue is that it's not obvious which of the layouts will be
> > used by default (as the VConsole keymap) and last but not least it is
> > not possible to preview the layout before adding it.
>
> Okay. I'm not sure if I understand the first problem - can one layout
> only be listed under one language/locale? And the Belgian layout was
> only shown under Dutch instead of Belgian?
The problem now is that the AddLayout dialog lists layouts prefixed with
languages they are related to (and there are many layouts for which this
is really useful). But since some layouts have multiple related
languages, listing some of the layouts multiple times would result in a
really, really long list (even without duplicates there are IIRC over
600 items in it) bringing performance, clarity and generally UX
problems. However, the result is that e.g. the Belgian layout is listed
as Dutch, because that's the first language we iterate over when getting
all layouts. And people then struggle finding it in the list because
they search for the Belgian layout, not 'Dutch (Belgian)'.
Thus we should do the listing two-level: language --> layout
>
> > For those reason, I've started thinking and working on the new version
> > of the Keyboard spoke. The following link shows what I have right now:
> > http://vpodzime.fedorapeople.org/reworked_keyboard_spoke.png
> >
> > Issues I'm aware of (and didn't make implementing them today):
> > * there should be descriptive labels visually splitting the screen into
> > two parts (something like "Available layouts:" and "Keyboard
> > configuration:")
>
> Yeh, I think right now there's too many panes; there's two for drilling
> down to the layout, then a third for specifying the order of the layouts.
>
> I think maybe we could get that down to two if you could make one
> drilldown pane using an inlay (see
> http://designinginterfaces.com/patterns/list-inlay/ ) which you could do
> with a treeview disclosure triangle, then the second would be organizing
> the selected layouts?
Well, I'm for a treeview and this expanding since January 2012 when the
first discussion about these things happened. Have a look at your
summary of our discussion from that time:
http://www.redhat.com/archives/anaconda-devel-list/2012-January/msg00036.html
Has something changed? Based on this I thought a two-pane selection
would be better from the accessibility and clarity perspectives and also
it would fit in the Anaconda's patter of using two-pane selection for
languages/locales.
>
> > * the default layout should be bold
>
> That's a good idea.
>
> > * layout switching label should be more visible (italics?)
>
> I think it's lost just because the screen is a bit cluttered. I think it
> will be helped if we can de-clutter a little bit.
>
> > * the + and - buttons are probably not so catching as they should be
>
> Yeh, I'd use that little bar that's anchored to the bottom of listviews
> in a lot of the gtk3 panels; we have one on the bottom of the left-hand
> pane in custom partitioning, for example.
That's the same bar (widget) that is used in my mockup, just with a
different size and position (left in custom partitioning, center in my
mockup).
>
> > - Should the testing area and treeview with added layouts be swapped
> > and the +/- buttons replaced with the up/down arrows?
>
> Hmm. Well there's two tasks here: finding potential layouts, and then
> ordering the ones you chose. Kind of like, picking out products you like
> on the shelf at the grocery vs sorting / putting away the groceries you
> chose when you get home.
>
> I think the testing area is maybe more related to choosing which layouts
> you want - e.g., "Does this layout have the '@' under '2' or is it a '"'
> under '2' ?" So it might make more sense to group the testing area with
> the layout selection area.
>
> The options for setting up layout switching seems like it should be
> grouped with the final selections.
>
> > - or should they be marked as important and thus have the blue colour?
>
> I wouldn't do the blue color on the buttons; I think it's only meant to
> be used on one button per screen and it'll already be on the Done button.
>
> Here's a (tiny, weird font) mockup that uses the newish Gtk Listbox a
> *lot* -
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Keyboard/keyboard-2.png
>
> Let me walk through it, tell me if it's nuts:
>
> - You start with the left pane. You scroll to and hover over a language
> of interest. When you hover, an 'expand' link appears.
That would mean Gtk will likely resize and reorder half of the GUI
because there would be a new "column" in the ListBox. We could hack this
around, however, by setting some size request for the ListBox.
> - Click on 'expand' and the full list box comes into view with the list
> of layouts that apply to the language. Hover over a specific layout and
> you'll see an add button and an arrow button.
Same issue here, I'm really not sure Gtk is prepared for this "hover to
reveal" things. As a practical example -- I had to make column headers
visible with the name of the column with the right arrow set to ""
because otherwise the arrow didn't show.
> - You click on the arrow button and you get a dropdown that lets you
> test the layout or view it.
Not sure hitting quite a tiny arrow would be usable for all users.
> - Select test it, and the test area below lights up and comes into
> focus, you start typing, and the text shows up in the test area. When
> you are done testing you can hit tab to change keyboard focus or mouse
> somewhere else.
To allow such testing we would have to replace the X server's runtime
configuration with the currently selected layout, let user test the
layout and then, when they leave the testing box, restore the X server's
runtime configuration to the original state. That would be confusing for
users, I'd say, and it would cause 3-5 seconds long UI hangs (changing X
server's runtime configuration is not a cheap action). That's why I'd
like to provide testing of the current configuration, i.e. added layouts
and layout switching.
> - Select 'view layout' and you get a lightbox with a diagram of the
> layout, which you can click on to dismiss.
> - Press the 'add' button and the layout is added to the list on the right.
> - Then let's go to the right pane. The default layout it marked with the
> 'default' icon on the left.
Don't know if icon on the left is better then icon on the right. But
when I tried using our "selected" icon from the disk selection, it was
so tiny that it was hard to recognize. That could be solved, but still I
think radio buttons are more common and better understandable.
> - Hover over a non-default layout, and buttons will appear: set default,
> or remove.
> - Click set default, the default icon will disappear from the current
> default and move to the one you just set as default.
> - Click remove, and the layout will be removed from the right pane list.
Same issues with these appearing buttons as above.
Another problematic thing is that when the spoke appears, there will be
two lists without a single button. Don't know about other users but I'd
struggle guessing what is expected from me as a user if somebody just
gives me two lists. Should I drag&drop layouts or what?
I'd suggest following:
* have two lists -- one with languages expanding to layouts and one with
added layouts
* arrow buttons for moving layouts "between" those lists (i.e.
adding/removing layouts)
* preview buttons under both lists
* arrow buttons for changing order of the added layouts
* layout switching configuration below the list of added layouts
* testing area at the bottom of the spoke
* "is default" icon or radio button either on the left or on the right
of the the default layout
* double-clicking a non-added layout adds it
* double-clickign an added layout makes it the default one
* drag&drop working? (RFE)
* tooltips over the "Default" column, icon/radio button and layout
explaining that it will be the only VConsole keymap configured
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
