[Usability] Re: [Fwd: Re: Your final comments on gswitchit in 2.4...]



tis 2003-06-24 klockan 16.01 skrev Andrew W. Nosenko:
> OK.  I try to show simple example: east Ukraine.  There need 3 languages:
> 1. English (for comunicating with computer, or you know another name for
>    cat(1) command? ;-)
> 2. Russian for communicating with peoples
> 3. [very rare, but unavoidably] Ukrainian itelf for filling official papers.
> 
> No possibility exist for place all required symbols on keyboard into two
> layouts without losing functionality.  At least 3 layouts required.
> 
> But because 3th layout (Ukrainian) is used wery rare, then cyclic
> switching "Eng -> Rus -> Ukr -> Eng -> ..." is uncomfortable.  Need fast
> switching "Eng -> Rus -> Eng -> ...".  Solution: "Eng <-> Rus" switching
> do from keyboard and make Ukr accessible only over mouse by clicking on
> the applet.  GswitchIt allows this (remember secondary layouts?)  The
> dot.  All are happy.

It seems to me from your description that it's the cyclic switching
that's the real problem here, i.e. you need three available layouts but
will typically only use two of them very often, and so when you cycle
you need to cycle an extra step to get past that not-so-frequently-used
one.

Perhaps a better idea would be to just having different shortcuts for
the different layouts, and not use cycling at all. Or have cycling, but
allowing the different layouts to be directly accessed by other
shortcuts at the same time. Perhaps this is already possible (I haven't
used gswitchit) but if so then I really don't see the problem.


> Yet another example.  About need/unneeded discussion.  How many
> "latin-based" users writes from right to left?  But, for some "strange",
> reason I don't see any who say that r-t-l support is unneeded, too
> complicated and unused.  But I see discussion when some amount of
> peoples says that support of cyrrilic keyboard layouts in GNOME is
> unneeded, too complicated and should be reduced to state of unusability.
> Yes, excluding/don't including GSwitchIt from/into GNOME means
> no-more/no-less that support/unsupport of cyrrylic under GNOME without
> hacks.  At least in my opinion.  Yes, these hacks are exists.  But
> reason to use its if exists right way?  Or you think what GKB is usable in
> cyrrilic environment?
> 
> PS.  Excuse me is I affront someone -- nothing personal was there.  But
>      it has been worrying one for so long.

I don't see how anyone is or has been trying to discriminate Cyrillic
users the way you describe, at least not on these lists. It's just that
most of the core people seem to not use this type of functionality, at
least not very often, and hence don't know much about the problems
involved and what's really needed. So we need to learn these issues.
This is not an uncommon scenario; it used to be that way with for
example accessibility too, until accessibility experts came along and
contributed code and gave advise on how to write accessible
applications. :) It's just the way free software works.

In the case of gswitchit, we need to find out what's really needed
functionality and how to best expose that, in order to integrate it
cleanly into GNOME. GNOME needs a keyboard switcher, not just a GKB
frontend, so UI details that are just a result of the underlying
implementation should be avoided where possible.
Likewise with functionality that's just a hack or workaround for other
problems, where we should be looking at solving the real problem
instead[1]. The flag customization and the secondary layout feature you
describe very much sounds like such workaround functionality to me.

So we need to understand the problems involved, not just what
functionality is currently present in gswitchit. We can't start by
assuming everything in there needs to be there for good reasons, so
please don't feel offended. Your problem description above was really
helpful, please keep it that way. 


Christian



[1] http://www106.pair.com/rhp/free-software-ui.html




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]