home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / windows / x / motif / 8323 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  2.5 KB
  1. Xref: sparky comp.windows.x.motif:8323 comp.software-eng:5201
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!wvnvms.wvnet.edu!cerc.wvu.wvnet.edu!babcock.cerc.wvu.wvnet.edu!vrm
  3. Newsgroups: comp.windows.x.motif,comp.software-eng
  4. Subject: User Interface Design Techniques and Documentation Guidelines
  5. Message-ID: <VRM.93Jan4164644@hawksnest.cerc.wvu.wvnet.edu>
  6. From: vrm@hawksnest.cerc.wvu.wvnet.edu (Vasile R. Montan)
  7. Date: Mon, 4 Jan 1993 21:46:44 GMT
  8. Sender: news@cerc.wvu.wvnet.edu (USENET News System)
  9. Organization: Concurrent Engineering Research Center
  10. Nntp-Posting-Host: hawksnest.cerc.wvu.wvnet.edu
  11. Lines: 42
  12.  
  13.    I am looking for specific references for User Interface Design
  14. using Object Oriented techniques and the Model-View-Controller
  15. paradigm.  However, I would also be interested in any user interface
  16. design strategies or examples of good design documents.
  17.  
  18.    Most of the user interface design books that I have seen
  19. concentrate on the aesthetics of design, which widgets to use under
  20. various conditions, how to organize the various widgets on the screen,
  21. and other hardware mapping details.  What I am looking for is what
  22. comes before that.  I realize that there are no "cookie cutters" for
  23. design, but there must be some guidelines out there.  We are also
  24. planning to use C++, so I would appreciate the design to be object
  25. oriented.
  26.  
  27.    What I have in mind are guidelines which would assist a designer in
  28. making the following decisions based on the software requirements:
  29.  
  30. 1. The model needed for the application, and the programmer's
  31.    interface to this model.
  32.  
  33. 2. How that model will be visualized on a computer screen.
  34.  
  35. 3. How the model will be manipulated by the user through the user
  36.    interface.  (ie. the functionality of the system.)
  37.  
  38. Of course the desisions made in #2 and #3 would break down further and
  39. eventually get to the hardware bindings.
  40.  
  41.    Once all of these decisions are made, how is it best documented?
  42. Is it best to separate discussions of the model, view and controller?
  43. Or, should discussions be broken down by functionality?  How can
  44. visualations be specified without restricting hardware bindings?  etc.
  45.  
  46.    I have done design before, but this is my first user interface
  47. design and I feel that it should somehow be different.  I also feel
  48. the previous designs that I have participated in were inadequate
  49. because much of it seemed forced to fit in the document and we were
  50. making many design decisions well into implementation.  However, I do
  51. not know how they could have been improved and have never studied a
  52. good design.
  53.  
  54. -- Vasile
  55.