Re: FYI: UsabilityGuidelines handbill - supplement: Usage Designdocument

[Henning Sprang <henning_sprang gmx de>]

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

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?!


Another idea i have when reading this is: o.k., we have the gnome HIG, 
we have our own little page with a quick overview about those, that's 
fine, it helps to decide how to get along with some small but important 
design decision on how the application has to behave in some situations, 
concernung GUI behaviour in general.

But i would go a step further (or is it a step before?) and propose to 
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.

I feel it is a very important aspect to harvest use cases from 
prospective users and try to design the application in a manner to help 
users getting those done as easy as possible - as there are guidelines 
in web design saying, a web user should get to the needed information or 
function in as much as 3 clicks, one could state something similar about 
GUI applications.
Intuitiveness plays a big role there, too, as it doesn't help if there 
are only three clicks but nobody manages to find out _where_ to click at 
without reading lots of documentation (that is at least partly a topic 
of the HIG if i get it right). I think this is pretty possibly a main 
area where beast needs develoment and improvement when one compares it 
with "professional", "commercial" applications like reason, just to name 
one.

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

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

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

Henning