Separability
For example when using the Web the server is completely separate from the browser - so the page you are currently viewing is the only the browsers representation of our html file. Separability is not an issue for ALL interfaces however - simple word processors and other WYSIWYG applications do not require it.
This depends on a number of issues such as the usability of code, the learnability / guessability factors (i.e. first time use and subsequent use), response time whether code is compiled or interpreted, also whether the layout is appropriate for the goal in mind.
Is the designer given the tools and support needed for
the ideal completion of the task ?, for example when creating web pages
(such as this one), we used BBEdit for holding the html code, but were
unable to see until completion the completed form/layout, and its relative
position to other 'pages' , 'links'. The notion of linked sites therefore
remains conceptual rather than concrete. So what are possible ways of approaching
this problem ?
One possible solution is the increasing number of of
template/wizards available, but again we need to consider whether these
can fulfil the designers ideals, or whether they impose further constraints.
Some work environments provide a basis for construction of tools, but if we wish to design a specific interface outside the application range , can this be done simply ? (e.g. hypercard, and the attachment of an arbitrary graphic to a button as its icon).
We need to ask questions such as :
'Are the abstractions offered suitable for the designer , e.g. within the correct range, are all designs possible ?'
'Do most people follow the path of least resistance ? , i.e. are the types of interface we produce influenced by the default provided in the software already available?'
'Is the user really insisting on generality and scope or are they guided' into using a particular style ?'
The 3 aspects of interaction
objects :
Some applications provide poor support in respect of these objects. the resource editing capabilities built into the Macintosh are an example of a reasonable attempt to overcome these difficulties.
Most applications use more than one arena but many UIIS
can only manipulate one of these at a time. When calling a card in Hypercard
it is only one shape and size - if you wished to change this you would
need to fall back upon the inherent coding of the MacOS as the necessary
support does not exist within the Hypercard application itself.
This model was designed to support the needs of a specific user group
Radiologists performing X-rays.
It provided a task model editor, allowing the radiologist to enter basic task information which formed the basis for designing an appropriate interface model.
The intention of the Adept model was to create an interface which would provide the staff with a high degree of support. One possible problem arising is the loss in terms of graphical presentation and resolution.
We asked the class the following
questions :
'Would you go out of your way and spend time to implement your ideas and design onto the working environment you find yourself in ?'
' Have you ever used wizards/templates for working , have you found them useful ?'
'Do you always plan your work, and do you find it helps
you ?'
Bob says :