[games_access] GAIM 0.02 updated

[Eelke Folmer]

Hey Thomas,

On 14/12/2007, Thomas Westin <thomas at pininteractive.com> wrote:

> if you have a guideline saying that all you must provide audio cues to
> visual information, it says nothing about how hard it is doing that in
> practice, i.e with code, which is the dark horse in planning resources
> (time and money) for a game. That's in my mind the biggest obstacle
> for convincing publishers about implementing game accessibility.

I think we need to distinguish two things here:

Usually a lead designer or an interaction designer does the high level
game design, either by a rudimentary prototype or even on paper. For
him a requirement such as " provide audio cues" might be useful as a
requirement, i.e. something that is specified in the  game design
document. What usually happens then is that this document is tossed
over the wall to a software engineer who then has is to figure out how
to implement this a requirement. Software engineers are not
interaction designers so they may not understand why or how this
requirement works.

What thomas and - I  also to some extent- try to do is translate such
a requirement into something that software engineers can understand;
either using UML or some class diagram, which can provide some hands
on advice on how to implement this requirement.

Though accessibility requirements can serve as requirements I do think
they have some serious shortcomings which limit their usability and
usefulness.

1) some of the requirements assume absolute validity but are actually
only applicable in very specific contexts; take the "provide audio
cues to visual information". A requirement as such does not make any
game accessible to the blind automatically. In our guitar hero
modification we were not able to use sound since music was already
playing and had to revert to haptic feedback. There is still a lot of
guesswork involved in tailoring this requirement to a specific game.
What usually happens is then that more requirements are specified that
deal with specific contexts. e.g. one could specify "for music games
use haptic feedback". Which usually results in a large number of
requirements for each exception.
2) There are too many; take for example a look at all the web
usability requirements there are out there. I found more than 200
different different usability heuristics for web design in the work of
my thesis. This makes it very hard for a developer to select the right
one including the danger that some of the requirements obviously
conflict. Nielsen  (a famous usability guru) specifies for example:
provide feedback but also keep things at a minimum. These two
statements do conflict. E.g. too much messages may overwhelm a user
and no messages may frustrate a user.
3) Another thing that I think is lacking with guidelines is that is
does not specify what problem it actually solves, why it works or how
it can be implemented. Provide audio feedback for visual information.
What problem does this solve? who benefits from this? Why does it
work? why does it have to be visual and not haptic? etc etc.
Guidelines are too prescriptive do this do that but they're not
constructive.

In order to make guidelines more usable as design tools i suggest they
should be used in conjunction with a richer description format;
interaction design patterns.
</shameless_self_promotion>  ;-)

Cheers Eelke






> With UML you can communicate many things about a system, one of them
> are logic with a state diagram, another is the structure of a system
> with a class diagram, a third are use cases and so on.
>
> So with the UML based model I'm designing developers can see all the
> necessary things to implement, without being langauge specific. I.e
> UML can be applied to any programming language; in fact many UML
> editors directly support Java, C/C++, Python and more.
>
> Hope that helps
>
> Kind regards
> Thomas
>
>
>
>
> 11 dec 2007 kl. 18.02 skrev Robert Florio:
>
> >
> > You might want to give an example of what this in-between stage it is
> > because I'm confused.  What else is there in between I think the
> > actual act
> > of doing it is the implementation I don't know what is in-between.
>
> _______________________________________________
> games_access mailing list
> games_access at igda.org
> http://seven.pairlist.net/mailman/listinfo/games_access
>


-- 
----------------------------------------------------------------------------
Eelke Folmer                           Assistant Professor
Department of CS&E/171
University of Nevada              Reno, Nevada 89557
Game interaction design        www.helpyouplay.com
----------------------------------------------------------------------------