Webpage designed and maintained by
Roisin McGrath , Mary
d'Arcy and Anna
Donaldson
****************************************************************
The Issues
Lets face it, few of us get things absolutely right first time. Remember the first time you had sex? Well, Interface Design is much the same...the more times you go round the cycle, the more practise you have, the better it gets
What is a User Interface Design Environment????
....It is any software environment which supports people in changing and
implementing user interfaces ....
User Interface Implementation Support, an overview... 3 issues
1. Separation
- Can you change the user interface without changing the main application code? Can you implement the core functionality separate from the Interface itself? Here you may contrast Databases with Hypercard...
Advantages of separability = you can have 2 interfaces for the one task
e.g. the web provides the client architect server and procedure services such as CGI scripts and forms Analyse, therefore, UIDE's (User Interface Design Environments). Do they support separability? Hypercard and Mac combine user interface and underlying functionality.
2. Other Usability Issues
-Everything which makes it easier for the programmer to change things must be useful. The aim is to cut down on TIME & TROUBLE. Readable language e.g. script language behind hypercard where you can do a change while it runs. Contrast this incremental compilation with the whole procedural change in C or Pascal where the user does not implement change.
3. Abstraction
- What the designer wants is design actions which relate closely to the ACTIONS (articulatory gulf) and ENTITIES (semantic gulf).
Syntax and objects- are they what the user wants? E.G. you can make a button appear in Hypercard whereas in Pascal or C it would be too complicated.
INTERACTION OBJECTS
This means what appears on screen - that which the user interacts with
3 Aspects
DISPLAY means the appearance of and access to the graphics object. i.e. the buttons, menus which appear on the screen.
STATE refers to the hidden variables ie " Is the print menu open? which button is being held down?" For example, the Print Dialogue box has a few associated variables.
CONTROL refers to the code which decides user input. There are 3 kinds of control associated with Interaction Objects
BUILT-IN RULES
In Hypercard the Interactor has control of the code when mouse operation begins whereas in Finder the Interactor has control where it is let go.
How well does this support UIDE?
Hypercard has the notion of state but remains inflexible, the dispatch is not directly implemented, it can make an object appear but it cannot glue it all together, therefore it is a little clumsy. One must always critique each UIDE as to how well it supports each Interaction Object.Interaction Objects always belong to two kinds of dependancy:
1) IS-A - usually forms hierachy or tree i.e. every object has only one parent which is not so good for HCI as Interaction Objects have three parts. ( Display, State and Control) E.G. This taxonomic hierarchy means that the properties inherit links from the general to the specialised i.e. all buttons inherit a font from a general button object.
2) Part-Of - Attributes are controlled by composite interaction which means the interaction object becomes a Part-Of another and the whole. It is contained by position, size and selection.
E.G. Link by Dependancy - as seen in Mac use when highlighting and dragging. This creates a new interaction object.
Conclusion:
Interaction Objects are conceptual entities important to UID. Multi-faceted IS-A relationships express how interaction objects are similar and share the same code while the Part-Of Relationship is bound to the whole. UIDE vary greatly in supporting these dependancies.
DEMONSTRATION:
On the Mac, the notion of resources,icons, display boxes, and standard messages are stored separately, therefore the user can fiddle about and change things on the interface without changing the code.
When opening the dialogue box the user is offered a saving and quitting option and can add/change the message.
E.G. "Do you want to save?" changed to "Totally Destroy?"
The user can then use the graphics editor to enlarge the command box. The whole performance can be saved within limits and can change the interface of UID
This demonstration provided an example of partial separation: on a MAC the user can edit completely separately. An Apple MAC is strong on UID. Nevertheless this could be miles away from what the user really wants.
A MAC offers the user superficial change it does not offer the user a change in the underlying functionality. E.G. if you wanted to add a routine to 'Inspect Files' to check a similar name was in use: Steve.1 and Steve.2 it cannot be done. The MAC cannot change anything involving fundamental code.
**********************************************
SUMMARY OF EMAIL DISCUSSION
We started an email discussion with the question: To allow us to get a feel for your experiences of UIIS we would be really grateful if you could answer the following questions:
Here is a selection of replies... 1. How many times on average would you amend your user interface eg the menu on your pascal program? i) never ii) 1-5 times iii) 5-10 times iv) more than 10
5-10(Edward Sandeman)
"I like to personalize things on my own PC and do this more as I learn how
to do it. If you mean the MatchMaker Project (Aaagh!) for example I was
for ever amending the user interface to try and make it more friendly and -
er - useful (if you know what I mean)."
2. How effective do you believe Pascal is at allowing you to go round the prototyping cycle?
not very(Edward Sandeman)
i) very effective ii)quite effective iii) not very effective iv)
completely inefficient.
3. Of all the languages you have used which has been the easiest to amend and improve the user interface.
Hypercard(JPNelson)
"The C and Java (Symmantec Cafe) compiler provide better looking interfaces
than Pascal - Java allows you to hide the code and provides a 'customer'
window (consol) which is useful. The customer can't accidently change the
code because of this."
>PASCAL IS THE ONLY ONE(Jenny)
>
Visual Basic(Rudy)
4. Can you think of any very good or, very bad examples of attempting to
alter part of a user interface.
"I suppose it was useful in MatchMaker to have that bit of code that set up the screen for the user and I've already mentioned something similar for Object Orientated Programming (Java or C++)."
"I have found with new PCs that it is not obvious how you set up an icon if
the program does not do it automatically - and that if you are not entirely
sure what you are doing Encarta, for example, will set up a shortcut to a
particular part of the program when you think you have provided an opening
icon."
>
I think any Pascal program interface is bad.(Rudy)
********************************************
Theme tune from 'The Net' on BBC2
Mary and Roisin designed the web page,
Anna collated and managed the replies to the email discussion.
Ta Michael for expert advice!
******************************************
The exercise was useful and will be more productive when we receive email feedback.
******************************************
Further information of interest may be found by:
- Back to Lecture 13
- Forward to Lecture 17....!
- Return to the Index
- Return to Steves' Main Page
**************
Thank you for your help with this Topic 
**************
In conclusion, should you have anything to add, or if you have any other comments to make regarding the material on this Web page:
Mary, Roisin , Anna