Find all notes about
chapter 7 of the course book here
From these notes are
drawn here below the implications for our design and some elements that are
relevant to get inspired.
The presentation of
the laws and principles for interaction design actually raises a certain number
of findings that a designer should be aware of. Some are common sense, but some
are worth being thought through. If any concept isn't clear, please refer to
the full version of the notes for descriptions.
The direct manipulation
seems better than indirect manipulation, especially for our target group:
children. On a tablet, the drag and drop with a finger seems to me
corresponding accurately to what one can expect as being direct manipulation,
as well as clicking buttons. All functionalities of our app involve
interacting with the GUI that way.
Feedback and
feedforward are very powerful in giving the user a clear idea of the efficiency
of the system without even thinking of it. For instance, when the loading time
is high, having an indicator that shows the system is loading, i.e. doing
something, doesn't shorten the waiting time but makes it seem shorter. We
should achieve with our design live rendering without any latency, which is
pretty hard if we actually use live augmented-reality. Also, the loading time
of pictures for games can be of a paramount importance. The feedforward gives
confidence to the user. Displaying instructions such as (Take a photo on a
button that takes photos can be part of that).
One should make good use
of standard models, also, we ought to have a look a which tablet applications
children use most and are the most familiar with, to sort of get inspired and
provide the child with an interactive environment that is known. As Alan Cooper
said, we should obey standards unless there is a truly superior alternative.
Fitts's law states
that the time it takes
to move from a starting position to a final target is determined by two things:
the distance to the target and the size of the target. However, this shouldn't be a problem for us for two reasons. The first is that we are dealing with
tablets, so the interaction of the fingers, i.e. hand motion, is in 3D space
and there is yet no model for that. The second is that we are not in a context
where users must hurry, nor do we need to keep user's full attention to prevent
them from going away (like in Web pages): the tablet remains in the kid's
hands; therefore they must deal with the current action anyway. Hence the
absence of Fitts's law relevance for us. We can just make sure the GUI is simple
enough to avoid users being lost too long, and limiting the number of decisions
at a given time (Hick's law, and in a way the Magical Number 7 concept).
The last principle that can help us is the Poka-Yoke
Principle, that prevents unexpected errors or misuses to happen. Furthermore,
the fact that we should any unnecessary button at a given moment should help us
simplify the UI.
From the part Documentation and Methods of Refinement,
here are some of the brightest ideas. The first is about using
scenarios. Even though we have already worked on them, we focused on the
context under which the visitor experienced the museum. Thus, it was neither
product-oriented nor design-oriented. The author gives an example of a 5 lines
product-oriented scenario that spares days of specifications. Using scenarios,
designers can sketch with words, and a picture can be worth a thousand words
but a few words can also be worth quite a few pictures.
The power of drawn sketches is also enlightened. We
used it a lot and we should probably keep on using it for the design of the GUI
itself. Using a storyboard is also an option, as well as tasks flow and use
cases.
About the wireframes, we oughtn't create
one for the purpose of the course, but it is good to keep in mind that in
real-world a whole lot of documentation is needed.
The various controls examples given are known by all
of us, so this part was not as relevant as the previous one but it was
entertaining.
Last point comes from Bill DeRouchey's experience
feedback on frameworks and controls. He mentions the concept of hero task, this
is the main task a system has to perform, for example changing volume on a
radio, and the design should reflect that hero status. On our GUI,
functionalities, buttons that are most often used should be big. The size
should be in proportion to the importance.
Since we are at a
point of our design that involves making critical decisions, this is probably the right time to discuss some of these points, especially:
As the Poka-Yoke
Principle makes one consider the relevance of each control at any given time,
aren't there some buttons we can remove at some points of our quest? For
instance, should the Map and the Find parents remain on the front layer at any
time, or could we consider that when the child is busy, he won't need or think
of calling his parents?
The concept of
feedforward seems rather important to give used confidence is the use of a
system. Since we are dealing with children, and more than half of them might
have never used a tablet, should we make the assumption that all children 7-12
will have gone through the learning process of manipulating a tablet and
spontaneously think of drag&droping objects, click buttons? Apart from
aesthetics considerations, we probably ought to try to get a better
understanding of children's mental model of a tablet app.
No comments:
Post a Comment