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

[Luis Villa <louie ximian com>]

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.

On Wed, 2002-08-28 at 13:28, Bill Haneman wrote:
> Yes, please log plenty of bugs, so they can be tracked down, etc... I
> think it's time.

Great.

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

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

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

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

Luis