Re: FYI: UsabilityGuidelines handbill - supplement: Usage Designdocument

[Tim Janik <timj gtk org>]

On Sat, 7 Feb 2004, Henning Sprang wrote:

> Hello,
> Sorry, i am not sure if this here belongs into the Mailing List or into
> the wiki discussion, as it's now exactly a comment to the wiki page, but
> more a proposal for a design document i post it here. (anyway, this
> leads to the question: which discussion should be done in the wiki,
> which one here?)

at this length, i think email was the right medium ;)

> Tim Janik wrote:
> > [...]
> > for improvements and better HIG intergration, it may
> > make sense to:
> > - add HIG section links to the individual items in UsabilityGuidelines
> > - use this as a starting point for an official HIG handbill which is easier
> >   to digest than the whole document and allowes quick lookups.
>
> finally i read this after i already thought "erm, why start an own
> document for thsi and not try to get this content integrated into the
> gnome HIG document as it is an addition to this one." This seems to mean
> you're having this goal?!

yes and no. to some extend i wanted the hig people to be motivated
to provide their own handbill and even provide start material for them.
also, i wanted beast to have its own spot for usability issues,
so there exists a place where we can outline usability issues differing
from the hig due to whatever reason (might be we're of different opinions,
or things haven't been back folded into the hig yet, etc...)

but most of all, i wanted to have this handbill to outline all the simple
issues in a brief and memorizable manner that one happens to forget all
too easily in every day coding.

> But i would go a step further (or is it a step before?) and propose to

"a step further" is the correct term.

> create a document which documents and helps planning for the development
> of the behaviour of Beast in real usage, when a user tries to get some
> specific job accomplished - I borrow the term "use case" which i
> previously only heard in OO-Design, but it seems a pretty descriptive
> word for what i mean.

heh, beast is subject to OO-design or modern user-interface-design.
so the term "use case" is more than appropriate here.
the problem with that is that i'm like completely overloaded already,
so you're pretty unlikely to see me produce usage cases inthe near
furutere. i'd however much apprechiate if someone else started out on
creating some, and i'd certainly comment on them / discuss them.

if in succession of that user interface improvements are being developed,
i can also provide technical guidance to get those implemented in beast.

> But that's no rant, I am just seeing that the facilities to create
> sounds in a nearly unlimited manner(which can easily extended by
> plugins) by software synthesis, sample playback, running both through
> filters and driving all that from a buitlin note editor (which could,
> for drums, be optically represented by a drum sequence editor, there is
> also a rudimentary sequencer for that) are all there, beast even has the
> plus of being able to script and automate all that with the scheme
> language, which i am not shure if commercial tools have something like this.

s/shure/sure/

> But there is no really quick and easy access to all that, like for
> example to get a job done like "i wanna get some drum loops together by
> starting a programm, choosing some drums, and clicking a drum pattern
> from the different drum samples together, and underly some drum tracks
> with some effects" which is a pretty simple basic reason task one can
> get done in reason within minutes even as a first time user - and beast
> isn't lacking anything to be able to do it, in it's actual state one
> would only need about 2 hours when already having some knowledge of
> beast, and maybe 2 days or weeks without knowing beast.

well, make a suggestion to improve beasts GUI, what should change for it
to provide easy access in the way you outlined?

> And as far as i can see there's no planning document to get things like
> that documentented and do the design of this aspect of the application
> so development can do steps into this direction (Please correct me if i
> am wrong an don't kill me if i am to blind to see it!).

nope, you're right. it just takes someone to step up and start working
on use cases, story boards and general interface design planning ;)

> It's something like the "before you start" chapter of the Gnome HIG
> http://developer.gnome.org/projects/gup/hig/1.0/reality-checks.html#id2858222
> but a bit more detailed...

it's pretty much a use case description / written story board what they are
describing there.

> In German i heard the word "Benutzerkonzept"
> for it, or "Fachkonzept" in more bussines oriented development teams,
> right now i am missing the right english word - maybe as in the topic
> something like "usage design document"?
>
> I would volunteer to help getting such a collection of "Use Cases" together.
>
> What do you think?

you should start out right away ;) just do it in public as much as you can
(e.g. post about updates to the mailing list), so you can collect and
fold back feedback.

>
> Henning
>

---
ciaoTJ