From: fredc@fredc.ibmpcug.co.uk (Fred Curtis)
Newsgroups: comp.windows.x.motif,comp.software-eng
Subject: Re: User Interface Design Techniques and Documentation Guidelines
Date: Wed, 6 Jan 93 02:53:43 GMT
Organization: CONNECT Mail Feed via ibmpcug.co.uk in the UK [+44 (0)81-863 6646]

In <VRM.93Jan4164644@hawksnest.cerc.wvu.wvnet.edu> vrm@hawksnest.cerc.wvu.wvnet.edu (Vasile R. Montan) writes:
>   I am looking for specific references for User Interface Design
>using Object Oriented techniques and the Model-View-Controller
>paradigm.  However, I would also be interested in any user interface
>design strategies or examples of good design documents.

 [...]

>   I have done design before, but this is my first user interface
>design and I feel that it should somehow be different.  I also feel
>the previous designs that I have participated in were inadequate
>because much of it seemed forced to fit in the document and we were
>making many design decisions well into implementation.  However, I do
>not know how they could have been improved and have never studied a
>good design.

>-- Vasile

I would be extremely interested in any responses to this posting.  I've
just developed a set of widgets (my first task in a windows environment)
and have had a similar experience, though probably on a smaller scale
given my company's contempt for SE practices in general and my ignorance
of (the existence of) things like M-V-C paradigm.

My view of what a design is has changed radically.  Having grown up on
normal, boring, large applications which had a single, easily traceable
execution path, it was a real culture shock to write event-driven code.
After dismissing several 3rd-party widgets because their behaviour
could not be modified to meet the specs, I wanted to ensure that what was
developed was easily customisable and divided up so that components could
be reused elsewhere.  The desire for reusability and the attempt to cope
with concurrency (events can now be inititated either within the application
(model?) or within the user interface (control?)) forced me to think in
terms of abstract interfaces between co-operating objects.  This contrasted
with my OO experience in more traditional applications where the concern
was an abstract interface between an object and the outside world.

I now see the design document as an _architectural_ description; it's not
surprising to make design decisions during implementation if you're fine-
tuning/inventing an architecture.  I've also come to appreciate the role
of design documents in maintenance; the traditional apps I've been involved
with could be understood, eventually, by tracing through the single thread
of execution.  In contrast, the windows code I've developed, though very
well commented, is almost impossible to appreciate without an overview of
the architecture.

What I would love now is a decent machine representation of a design (text
is such a pain) and a way of providing soft links to the implementation.
And while we're at it, a framework for design reuse.  But then, this
presupposes a formal description of a design :-P.


-- 
fredc@ibmpcug.co.uk | Ambividexterous - To be unsure of which hand to use, as
                    | of a parent with unruly children, or of a cyclist about
                    | about to indicate a turn.
Newsgroups: comp.windows.x.motif