Re: [g-a-devel]gnopernicus robustness and a11y tools in the GNOME2.2 release

[David Bolter <david bolter utoronto ca>]

Luis Villa wrote:

> Thanks for the feedback, Bill. Like you say, the final call has to come
> from the folks at utoronto and baum; I hope they'll see the benefits for
> all of us if they can achieve these goals.
I think I can speak for the GOK team that we are definitely on board 
here -- with enthusiasm.

> > > I built it out of CVS yesterday and couldn't get
> > > anything to work, and I'd be happy to track down and file specific
> > > issues wrt warnings, failures, and such. It may just be a
> > > documentation/usability problem, to be honest- I have no idea if my
> > > gnome-speech is set up correctly, for example, and no idea how to test
> > > that. Ditto for gnome-mag- it built and did 'make install' fine, but I
> > > have no idea if it actually works/is installed correctly. 
> > >
> > > FWIW, gok built and ran well. It's pretty nifty, especially the word
Your compliments are appreciated.

> > > prediction stuff. It doesn't at all look and feel like a GNOME app,
> > > though :/
> > It *can't*, it's an onscreen virtual keyboard ;-)
> >
> > (see below)
>
> Sure. :) 
>
> > Yes, I think this would be a fantastic thing.  Certainly without
> > client-side programs like gnopernicus and GOK, the accessibility
> > framework won't get the needed exercise and attention, and of course it
> > won't do anything for end-users until assistive technologies are
> > available.  Bundling them would also be a great step towards "universal
> > access" for GNOME.
>
> Sounds like we're on the same page. Good to hear. 
Agreed, there has clearly been great work done with the a11y services. 
and not to expose this (through 'nifty' clients) would be tragic.

> > > But... that will require a lot of work.
> > >
> > > Among other things[1]:
> > >
> > > *neither project, to the best of my knowledge, has done an actual
> > > release yet. To be included in the Desktop release there must be tarball
> > > releases on a fairly regular basis, so that people can build and test
> > > the programs.[2] There also has to be a committment to UI and feature
> > > freezes in the stable branch- which may or may not be acceptable.
> > I think it's too soon to freeze UI or strings in these projects. 
> > Perhaps something can be done for STABLE in the 2.2 timeframe, I don't
> > know.
>
> Strings and UI wouldn't have to be frozen until (according to the
> schedule) Oct. 31st. I don't know if they can be by that date. They
> certainly don't have to be frozen by the first tarball release in a few
> weeks- those early releases are definitely understood to be early
> releases and not supposed to be finished, UI-wise. This would be doubly
> true for things like gok and gnopernicus that have never been 'really'
> released before.
We can certainly build tarballs without too much effort, but we are new 
to the tarball submission process (do we just put it on the gok website 
and make an announcement?), and I apologize here -- we have had a bit of 
tunnel vision lately trying to get GOK features in and haven't paid any 
attention to any of the calendar dates involved with 2.2 and 2.4... 
We're working hard towards GOK 1.0 on a 'very soon' deadline.  We have 
been doing both Solaris and Linux testing this month and it is going 
quite well.

> > > *Neither application /looks/ like a GNOME app. Obviously, because they
> > > are intended primarily for a different audience than the typical GNOME
> > > user, a certain amount of deviation from the GNOME look and feel is
> > > probably acceptable and possibly even very necessary. But we do intend
> > > to look like an integrated desktop, and so minimal steps that shouldn't
> > > interfere with a11y (like using GNOME toolbars, using standard spacing,
> > > and having help and close buttons when appropriate) should be
> > > considered. [GOK, for example, should probably look at the very minimal
> > > toolbar that gnome-calculator has.]
> > The GOK "onscreen keyboard" windows are a special case; it doesn't make
> > sense for these to have ordinary toolbars, etc.  It's debatable whether
> > they should even have decorations.  However the GOK "Settings" dialog
> > clearly should follow GNOME conventions.
>
> I'd think the Settings dialog, and also ideally the first window that
> comes up. Obviously the keyboard itself is probably a special case. [As
> a total aside, I found it amusing that GOK does not follow the GNOME
> theme by default- given how much time the a11y team has put into making
> other apps do that.]
>
> Obviously, if having a menu bar would interfere with that first screen,
> that's fine, but to someone completely naive about a11y like myself it
> seems like it wouldn't actually interfere with anything, and having
> default close and _especially_ help buttons might make things much more
> clear for the able-bodied who are trying to understand these things for
> the first time. If necessary, make the toolbar an option that can be
> turned off- but it's hard to justify shipping something with the main
> Desktop that's completely unintuitive for the unexperienced and has no
> standard help stuff. This is doubly so when half the point of shipping
> it is to educate the unexperienced.
Bill's response earlier gels with me, but you do raise an interesting 
problem -- that of the learning curve for these atypical 'applications' 
to the uninitiated.  Generally, the typical user of one of these tools 
just wants to use it to drive other 'real' applications.  The tool 
itself can be thought of in the same vein as monitors, keyboards, 
speakers, mouse (all the bits that allow primary HCI).  But you probably 
know that, and I don't want to ignore your important point that there 
are able-bodied users that we would really like to enlighten -- and I am 
not sure of the best solution here.  If there was an initial screen 
would it just be the first time you launched the tool (wizard-like), or 
would it be every time you launched the tool(annoying-like)?

I agree there should and will be a help button.  Currently the button is 
in the GOK settings dialog and not yet implemented, but we should 
probably also make it available directly from the GOK window.  The GOK 
window real estate is a premium, what is the best place to put this help 
button?  As a key on the keyboard?  Is that too non-standard?  At least 
it is directly accessible to gok users that way...

We have a technical writer on the GOK team currently creating content 
for documentation, and we intend for it to end up in gnome-docbook format.

> > As for gnopernicus, it does use gtk+ and GNOME, but again it's
> > questionable as to whether it should follow all the UI conventions since
> > it is actually a sort of meta-app.  Again I think it makes sense for
> > things like settings dialogs, etc. to pay attention to GNOME conventions
> > though.
>
> My thought was that at least the first window that comes up should make
> at least minor efforts to look GNOME-like. Yes, it's a meta-app and it
> is a special case, but if it lacks help or even basic keynav like ctl+Q,
> it's not going to be of much value in educating anyone [And,again, maybe
> I'm missing something, but I don't see how that would interfere with the
> basic purpose of the app.]
The GOK should never have input focus, so the ctrl-q thing is kind of a 
funny issue for us.  Users would use the GOK to send a CTRL-Q to other 
'real' apps...  We could add an at-spi registered key listener for a gok 
closure key combination, but that seems a bit wasteful and non-standard.

> Anyway, glad to hear from you, Bill. Hope we'll get some more feedback
> from the people doing the bulk of the work on these apps soon. :)
;-)

Thanks Luis for starting this important thread.  (BTW please don't pay 
any attention to late responses this week... I am on holiday).

cheers,

~~David

> Luis
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel