1. ID Conceptual Models (Mental Models) Summary
CSSE 477
October, 2011
From Ch 2 and Ch 8 of the ID book
See examples of user models at end!

2. Where you’re using these
In term project, next assignment –
Get user feedback to your prototype
Build / revise a mental model of users
From which you should develop a conceptual model of your system
Then go for system implementation
User feedback
Mental model
of them
Conceptual model
Of the system
Build actual system
From big picture

3. User model

4. From problem space to design space
The user’s mental model of what’s happening
From problem space to design space
Having a good understanding of the problem space can help inform the design space
e.g. what kind of interface, behavior, functionality to provide
But before deciding upon these it is important to develop a conceptual model
Ch 2 Slide 7

5. The user’s mental model of what’s happening
Conceptual model
Need to first think about how the system will appear to users (i.e. how they will understand it)
A conceptual model is a high level description of:
“the proposed system in terms of a set of integrated ideas and concepts about what it should do, behave and look like, that will be understandable by the users in the manner intended”
Ch 2 Slide 8

6. First steps in formulating a conceptual model
The user’s mental model of what’s happening
First steps in formulating a conceptual model
What will the users be doing when carrying out their tasks?
How will the system support these?
What kind of interface metaphor, if any, will be appropriate?
What kinds of interaction modes and styles to use?
Always keep in mind when making design decisions how the user will understand the underlying conceptual model
Ch 2 Slide 9

7. Conceptual models Many kinds and ways of classifying them
The user’s mental model of what’s happening
Conceptual models
Many kinds and ways of classifying them
Here we describe them in terms of core activities and objects
Also in terms of interface metaphors
Ch 2 Slide 10

8. Conceptual models based on activities
The user’s mental model of what’s happening
Conceptual models based on activities
Giving instructions
issuing commands using keyboard and function keys and selecting options via menus
Conversing
interacting with the system as if having a conversation
Manipulating and navigating
acting on objects and interacting with virtual objects
Exploring and browsing
finding out and learning things
Ch 2 Slide 11

9. Conceptual models based on objects
The user’s mental model of what’s happening
Conceptual models based on objects
Usually based on an analogy with something in the physical world
Examples include books, tools, vehicles
Classic: Star Interface based on office objects
Johnson et al (1989)
Ch 2 Slide 21

10. Which conceptual model is best?
The user’s mental model of what’s happening
Which conceptual model is best?
Direct manipulation is good for ‘doing’ types of tasks, e.g. designing, drawing, flying, driving, sizing windows
Issuing instructions is good for repetitive tasks, e.g. spell-checking, file management
Having a conversation is good for children, computer-phobic, disabled users and specialised applications (e.g. phone services)
Hybrid conceptual models are often employed, where different ways of carrying out the same actions is supported at the interface - but can take longer to learn
Ch 2 Slide 23

11. The user’s mental model of what’s happening
Interface metaphors
Interface designed to be similar to a physical entity but also has own properties
e.g. desktop metaphor, web portals
Can be based on activity, object or a combination of both
Exploit user’s familiar knowledge, helping them to understand ‘the unfamiliar’
Conjures up the essence of the unfamiliar activity, enabling users to leverage of this to understand more aspects of the unfamiliar functionality
Ch 2 Slide 24

12. Benefits of interface metaphors
The user’s mental model of what’s happening
Benefits of interface metaphors
Makes learning new systems easier
Helps users understand the underlying conceptual model
Can be very innovative and enable the realm of computers and their applications to be made more accessible to a greater diversity of users
Ch 2 Slide 25

13. Problems with interface metaphors
The user’s mental model of what’s happening
Problems with interface metaphors
Break conventional and cultural rules
e.g. recycle bin placed on desktop
Can constrain designers in the way they conceptualize a problem space
Conflict with design principles
Forces users to only understand the system in terms of the metaphor
Designers can inadvertently use bad existing designs and transfer the bad parts over
Limits designers’ imagination in coming up with new conceptual models
Ch 2 Slide 26

14. Conceptual models: from interaction mode to style
The user’s mental model of what’s happening
Conceptual models: from interaction mode to style
Interaction mode:
what the user is doing when interacting with a system, e.g. instructing, talking, browsing or other
Interaction style:
the kind of interface used to support the mode, e.g. speech, menu-based, gesture
Ch 2 Slide 27

15. Many kinds of interaction styles available…
The user’s mental model of what’s happening
Many kinds of interaction styles available…
Command
Speech
Data-entry
Form fill-in
Query
Graphical
Web
Pen
Augmented reality
Gesture and even...
Ch 2 Slide 28

16. System model

17. Conceptual design: from requirements to design
The resulting conceptual model of your system
Conceptual design: from requirements to design
Transform user requirements/needs into a conceptual model
“a description of the proposed system in terms of a set of integrated ideas and concepts about what it should do, behave and look like, that will be understandable by the users in the manner intended”
Don’t move to a solution too quickly. Iterate, iterate, iterate
Consider alternatives: prototyping helps
Ch 8 Slide 16

18. Three perspectives for a conceptual model
The resulting conceptual model of your system
Three perspectives for a conceptual model
Which interaction mode?
How the user invokes actions
Activity-based: instructing, conversing, manipulating and navigating, exploring and browsing.
Object-based: structured around real-world objects
Ch 8 Slide 17

19. Three perspectives for a conceptual model
The resulting conceptual model of your system
Three perspectives for a conceptual model
Which interaction paradigm?
desktop paradigm, with WIMP interface (windows, icons, menus and pointers),
ubiquitous computing
pervasive computing
wearable computing
mobile devices and so on.
Is there a suitable metaphor?
(contd)….
Ch 8 Slide 18

20. Is there a suitable metaphor?
The resulting conceptual model of your system
Is there a suitable metaphor?
Interface metaphors combine familiar knowledge with new knowledge in a way that will help the user understand the product.
Three steps: understand functionality, identify potential problem areas, generate metaphors
Evaluate metaphors:
How much structure does it provide?
How much is relevant to the problem?
Is it easy to represent?
Will the audience understand it?
How extensible is it?
Ch 8 Slide 19

21. Expanding the conceptual model
The resulting conceptual model of your system
Expanding the conceptual model
What functions will the product perform?
What will the product do and what will the human do (task allocation)?
How are the functions related to each other?
sequential or parallel?
categorisations, e.g. all actions related to telephone memory storage
What information needs to be available?
What data is required to perform the task?
How is this data to be transformed by the system?
Ch 8 Slide 20

22. Using scenarios in conceptual design
The resulting conceptual model of your system
Using scenarios in conceptual design
Express proposed or imagined situations
Used throughout design in various ways
scripts for user evaluation of prototypes
concrete examples of tasks
as a means of co-operation across professional boundaries
Plus and minus scenarios to explore extreme cases
Ch 8 Slide 21

23. Using prototypes in conceptual design
The resulting conceptual model of your system
Using prototypes in conceptual design
Allow evaluation of emerging ideas
Low-fidelity prototypes used early on, high-fidelity prototypes used later
Ch 8 Slide 22

24. Examples of User Models
These are all taken from prior classes.
For a drink recipe system
For a Music Library System
For a shared text editing system
For a customized spreadsheet system
For a Log File Parser System
The last one is the most complete, and follows the current assignment!

25. Examples of User Models, cntd
1. For a drink recipe system:
Because the testers are mostly college students, they will immediately understand the problem space.
I believe users of the system will easily figure out how to register, but may be confused by the password rules. I also think they might try and search for a recipe by ingredient instead of by name. I think that they will easily figure out how to add a recipe to their favorites list, as long as they have either a) A list of recipes displayed or b) a recipe selected. If they were to, say, try to start from the main screen and add a recipe to favorites they may be confused. I think users may ask what exactly a recipe is. I also think that adding a recipe will be easily accomplished, and that editing a recipe will be slightly more challenging, as they will have to re-find the recipe they created. After this task has been performed once, replication will be trivial. Users will find the clean interface refreshing.
The interface is a bit like a search engine and a liquor cabinet.

26. Examples of User Models, cntd
2. For a Music Library System (Start of description)
Users of the system will have three basic types, each with different usability concerns:
Requestors: These users will only have access to the song library and be able to submit requests of the songs they are browsing.
Understanding of problem space: Requestors will know what songs they want and what the meaning of song terminology is. There is no assumption that they have any specific familiarity with WMHD or this type of user interface.
Usability Goals: Learnability and Effectiveness.
Interface Metaphor: It’s kind of like the Rose class registration page. You can browse listings and search based on criteria and select.
Design Principles: Visibility and Feedback. The users can use feedback to use the site without the need of instructions. They should be able to do things without a lot of navigation to simply request a song.
Interaction type: Exploring. Users browse the library.
More of this one – see notes, below!
DJs: In addition to browsing the music library, DJs are able to play songs and accept requests.
Understanding of problem space: DJs will have a more clear knowledge of the domain, being acquainted with the radio terminology and schedule.
Usability Goals: Effectiveness, Utility, and Memorability
Interface Metaphor: It’s kind of like all of Banner Web. In addition to using the schedule lookup, you can view other reports and make changes.
Design Principles: Visibility and Consistency. They can use the system in the same way every time without a lot of navigation.
Interaction Type: Manipulating and Exploring. Browsing and editing the library.
Administrators: Administrative users will be more concerned with admin-specific features.
Understanding of problem space: While they will have a working knowledge of the song bank and data that is held in the system, most of their concern will be on scheduling and staff management.
Usability Goals: Safety, Utility, Memorability.
Design Principles: Constraints. The radio station should be managed by the rules set forth by the station manual.
Interface Metaphor: It’s kind of like the registrar view of Banner web. They care that everything else works, but really only concentrate on adjusting schedules and cleaning up student lists.
Interaction Type: Instruction. They set the schedule.

27. Examples of User Models, cntd
3. For a shared text editing system  (start of description)
There is currently no system that allows multiple people to edit a document in real-time on multiple computers. This makes peer-programming with someone who is not in the same room very difficult. Current systems either do not allow multiple users to edit the same document at the same time or do not update all the documents in real time. And so it is important that our project meets several usability goals. The system must be easy to learn so that new users will not be hampered by using this system. The system also must allow users to effectively perform text edits without a lot of extra administrative work. It’s also important for the system to be efficient so that edits to a document on one computer show up in real-time on other computers in the session. The target users for our system are developers who are coordinating work from potentially remote locations. Therefore, the interface metaphor is a combination of an online instant messaging program (like AOL Instant Messenger) and a text editor from an Integrated Development Environment (like Visual Studio).
More of this one – see notes, below!
We hope that users will notice and like the feedback that our system provides. For example, the system highlights lines when the user has permission to edit those lines. Likewise, the system highlights lines in red when the user no longer has permission to edit those lines. We also hope that users will notice and like the constraints that the system imposes. After a user has joined a session, the Join option is grayed out so that they are unable to join a second session while currently in a session. We think that there may be some visibility issues. For example, to send a chat message a user must press enter after typing a message into a text box, but there is no send button next to the text box to indicate that the pressing enter would send the message.
We used an instructing interaction type. The entire system is built off of responding to commands that the users may issue. (When the user changes lines, free the previous line permission and request the next line permission. When the user sends a text message, forward the message to the selected individuals. And so on.) Given that our system is intended for developers, the idea of having the system respond to the user’s commands seems very appropriate. The other interaction types would probably cause the system to have a higher learning curve and make it take longer for users to get desired tasks completed.
The predominant aspects of cognition for the users’ activities will be perception and recognition (to notice when they receive text messages, when another user acquires a line permission, or when the users acquire new line permissions) and memory (to know how to send special text messages or how to connect to a session).  We hope that the interface metaphors will guide users through the activities they perform on our system.  So when a user wants to edit a line, they will assume they have to click on the line to edit it.  In the background, our system will then request permission to edit the line and highlight the line in green if the user has permission to edit the line or the line will already be in red if the user doesn’t have permission to edit the line.  This process should provide enough transparency for users to feel comfortable while using the system and for the users to feel reasonably close to the system.
We predict that our system will be fairly easy to use, but there will be some learning curve.  We anticipate that the chatting features won’t be as intuitive as they could be.  Users may not immediately understand that the checkboxes next to people’s names allow private chat messages to be sent to only those users who are checked.  Likewise it may not be obvious for users to press return to send messages to other users, but we hope that the interface metaphor will get them past that hurdle.  The text editing features should be handled behind the scenes, so the users should find text editing to be very usable.

28. Examples of User Models, cntd
4. For a customized spreadsheet system
We expect that people will be lost due to the overwhelming amount of data which presented to them within the program. Though we feel the data is very cleanly organized and in good relationship to one another, most typical users will not want to have to take the time to look in depth into all the information. We instead believe that users will want a way to view the information in such a way that they can grep the data “at a glance”. In order to do this, we have built in a graphing feature which displays the data in a clean and very easy to read chart (which is also highly customizable).

29. Examples of User Models, cntd
5. For a Log File Parser System (start of description)
Problem Space Understanding
The usability testers of the system should have a good idea of the problem space. Although the specifics of the log files they will be testing the system with are unknown, they have had experience with going through log files and understand the importance of being able to flag entries or write comments on certain entries. If it were possible to get Northrop Grumman’s engineers to be a part of our usability study, it would likely be more fruitful than using people unfamiliar with the log files, but that isn’t feasible for our usability study on such short notice.
More of this one – see notes, below!
Usability Goals
So, discounting the fact that users will not understand the significance of the data they’re viewing, the following are the goals the team wishes to make apparent in using the LFP:
Commenting, flagging, and bookmarking entries without more than two clicks, and should be apparent immediately how to do this
Merging the log files into one seamless log file should take no more than 5 seconds to find and understand what it does
Understanding that log files have to be saved before any of the comments, queries, etc. will be added to the metadata file and before changes to the file itself will occur.
We believe usability goals the users will have will include that the software be intuitive and require as few clicks as necessary to get a task done. The users will not want to waste their time trying to figure out what needs to be done, so the product will need to have a very short learning curve (less than 5 mintues).
Interface Metaphors
Regarding the interface metaphor, the users will likely react by positing that it’s a lot like visual database that you would see using Microsoft SQL visually, with the ability to click checkmarks and change values that affect actual values in rows.
Design Principles
Obviously, design principles will be noticed by programming-minded people who test the software. We would expect some of our subjects to be able to point out the feedback we are trying to give in the UI status bar. Also, they should notice that the product follows many other programs’ default behaviors (especially the shortcuts), so they should agree it has good consistency.
Interaction Type
Obviously, a system like this is going to be an instructive interaction type, where users use menu commands to tell the UI what do and how the domain objects should act. The will be a kind of exploring at first, but once a user gets used to the system, it will be mostly instructive.
Cognition
Many of the principles of cognition should be seen in our product:
Memory – since the system is not very complicated, being able to remember how the system works and what commands are necessary should be pretty easy, and recognizing many of the menu items should be easy to do
Perception – the layout of the UI makes it very easy to see where things are and where things go, thanks to the labels on boxes, and its generally intuitive design
Attention – nothings too cluttered and nothing is overly graphical to detract from what the product is meant to be used for
Norman’s Mental Model
For the purpose of this test process, many of the users of the system might not have definite goals to achieve, since the data they are viewing isn’t meaningful to them. Much of the underlying interface structure should be apparent to programming-minded people, although perhaps some of the people who will be tested won’t be able to connect to the interface easily due to the same problem of not understanding the actual use of the log files being examined and manipulated.
Ease of Use
The following are the expected reactions to using the LFP:
Users will be happy to see keyboard shortcuts
In the past, we have seen some problems with people trying to drag-and-drop log files onto each other in order to get the synthesized view
Users will be able to easily discover how to bookmark, flag, and comment on entries
Users might not be able to understand how comments and entry edits are saved (there is no button for it)
Users may want to be able to middle-click opened log file tabs to close them
Querying should be straightforward and understandable
Users will react well to having query histories