I hope this time everyone bothers to read this documents,
Vesa in particular. To assure that, I'll try to keep it
as short and simple as possible.
Anyway, as you already know I am not satisfied with the
scenario idea by Vesa that was discussed in the last meeting.
It has some good things, but still it isn't as user-friendly and
"optimal" as it should be. In this memo I present the reasons and
then a different approach to the issue so that we wouldn't go on
doing something just because we don't want to think of different options.
- The idea that there would be two modes (scenario / explore)
- The idea of the scenario as events
These ideas are something that I use as a basis for my new idea presented
later in this document.
In addition to some good ideas there are things that I think are not
good and make me think the user will not feel himself confortable with
the product if the current idea is implemented.
- We need tricks (copying comments to different places etc..)
to make the different modes work. The problem here is that if
we are stuck to thinking of the scenario mode as the primary
mode and designing only to it, the explore mode loses a lot
of its usability. Instead we should think of them as a whole (or
even concentrate more on the explore mode). Then we would see that
the modes have a lot in common. They aren't that different really.
- Remember that we were thinking of making the scenario mode optional... :/
This isn't possible, if we don't even bother to think of how
the explore mode should be in order for it to be usable.
- Editing the scenario and the breakpoints in explore mode could be
very much easier if done differently. The record mode is ackward
but OK when creating "scenarios", but definately of no use for
creating notes / breakpoints for the explore mode.
- And then again,
why do the modes need to be so completely separated that they couldn't
have the same event data? Just think of it - I can't come up
with any reasons. :)
Let's think about the software and how the different users use it. First the
teacher wants to create material for
two uses: lectures and self study.
He could do two different files with different ways of editing the breakpoint
information, but why should he have to go through that trouble? Doing it once
would be enough if the software was well-designed! (And isn't that what we want?)
Here's what I think he would like to do:
- He selects the default layer for the animation (where the scenario
starts)
- Then he starts adding events to the animation. Not recording,
but just clicking in correct places in the event column (that
was called breakpoint column in my earlier notes.)
The events can be of different types: breakpoint, note, change layer,
ENC. In explore mode they would all be shown as breakpoints/notes, but
in scenario mode they would control the animation automatically.
- Once he has added all the breakpoints and ENCs to the different layers he
starts thinking in what places he wants to change the layer. He adds
"layer change" events to the scenario.
The result could look like something like this: (Only two layers are shown as they
already present the idea)
Then the teacher goes on to give a lecture. He starts the animation and it will automatically
run through:
- The animation starts on the TRANSPORT layer MSC
- First breakpoint with note is shown
- Encapsulation is shown
- Layer is changed to NETWORK
- Breakpoint
- Layer is changed back to TRANSPORT
- Breakpoint
Very nice, and actually just what we want. But notice that
now here comes the extra values of this approach. When
the teacher notices that one breakpoint is in a wrong place
(people make mistake, you know) instead of recording the
scenario again, he can just remove the breakpoint and
add a new one in the right place.
But this is not all. :) Then the teacher uploads the
scenario on the web, and a student downloads it to
study by herself. She starts the animation in
explore
mode on the transport layer. The animation breaks on all these
events telling her that if she likes, there would be something
interesting she could do. If she wants to, she does what is
suggested and if not, then she just goes on on the same layer.
No extra hazzle is needed, all this can be done with just
one set of "scenario information".
We just need not to be too attached to the ideas that we have aquired earlier!
If this is different from the previous approaches, that
doesn't necessarily mean it's worse - it could as well be
better.. :)
The technical issues are not that important here, because
in any case the technical part of the scenario stuff is
not the difficult part. It's always quite easy and straight-forward.
Instead we need to concentrate on the usability of the software
and its user-friendliness.
Anyway, as we all like to speak about data structures, here
we go :)
The scenario data would be saved in three lists instead
of one so that there would be one list for each layer.
This would make it possible to have events on each layer
in the explore mode simultaneously, so that whichever layer
the user is watching, he gets information about it. When
the animation is running, the software would keep track with
each of the lists so that when the layer is changed (by
user interaction or automatically by the animator triggered by
an event), we can just move to the right list and read the
events from there.
Okay, these are my ideas. They might have something that's
not good, and of course they can be discussed and changed
again. Anyway I think this approach is already much
better than the one we were discussing in our last meeting.
It might not be optimal, but it is better. So, don't discard it
too quickly. If you don't like this idea, I would really like top
hear why. :)
--
JarkkoLaine - 22 Mar 2004
