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

[Luis Villa <louie ximian com>]

On Wed, 2002-08-28 at 21:18, David Bolter wrote:
> 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.

That's great to hear. We do want GNOME to be something exciting to be a
part of, and it seems like all of the projects I've approached this week
have had the same enthusiastic response, which I think means we must be
doing something right :) 

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

That's OK. Particularly with a11y, 'outside' projects often don't know a
lot about our release process. It is as much GNOME's fault as the fault
of the projects involved- we haven't been good about documenting this
type of thing in the past. We'll make sure that it is better documented
and all of that in plenty of time. It's pretty minimal overhead. 

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

Great.

> >>>*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)?

No clue on that- probably something the UI team might have some better
ideas on. I'm just a humble QA nerd ;) 

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

Not sure- it's definitely a tougher issue than I'd understood at first.
Like I said, the usability team probably has better ideas on this than I
do. Once we make the list of New Apps official (it's pretty short, gok
should be honored ;) I'm sure the UI team will talk to you a bit, and
hopefully this can be one of the issues raised.

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

Oh, that's great. I'm sure the doc team
(http://developer.gnome.org/projects/gdp/contact.html) would be very
happy to answer any questions that they have.

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

Yeah, Bill explained that issue to me in IRC this afternoon. I guess
we'll have to forgo some of these standards- even more so than I'd
thought. Ah, well. My most basic concern is that able users at least get
some clue what the tool does and how to use it. Past that, obviously the
first priority must be to work for the intended audience, not to serve
as a 'nifty' toy for people like me.

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

'tis my job ;) 

>  (BTW please don't pay any attention to late responses this week... I
>  am on holiday).

Ah, well, stop responding to me and enjoy it, then :) 

Luis