[Steering] Long mail. Compartmentalize.
jung at uib.no
Mon May 30 19:16:47 MDT 2005
Cynthia Haynes wrote:
> Many thanks for this report and your comments.
Thanks to Lennie for the pre-view (did I get something cut off? It
suddenly stops at "User tasks") and to Cynthia for comments.
I am sure there is a lot more to come. But the page we got and Cynthia's
comments are a good way to jump start a discussion.
> when we train teachers how
> to teach the MOO to students we stress that they must also explain the
> evolution of the MOO from text-based to web-based and the differences.
I have been thinking. And thinking. Long before this report.
And I can't help but to come to one question: Do we? I don't have the
answer to that question, but I have the question. There are probably a
lot of answers. Over the years and especially the last months, the
potentials of enCore Xpress (I make no difference here just yet) become
clearer and clearer to me. Lambdamoo may very well serve as a more or
less hidden motor, Xpress may function as a web server for may purposes.
Jan told me on the phone they were thinking about v6 already, and the
strategy will go into compartmentalize functions. I remember vividly
Jan's talk when we had our first online gathering last year--he proposed
ideas as (optionally) taking away object creation routine,
programming... I was shocked then, and I thought, well, that would be
ripping the heart out of the whole thing. I'm not so sure any more.
As a test, and because I am curious, I just added a checkbox for "no
chat" on the login page. When ticked, the Xpress main frame is opened
without java/html chat feature (that would be the last step on the
ladder "chat area only - vertical layout - web area only"). Since users
are connected with cookies, once they are authenticated, all works -
object creation, document writing, mailing, even programming (you are
not a part of connected_players() though, with all the implications that
Maybe that could be a solution for those without Java, or for just
browsing the MOO (authenticated, not http09).
Don't get me wrong. I do have feelings for the Chat, telnet, and I still
@grep verbs in text-mode, although I have written a web-grep with is a
100 times better. I'm just thinking.
I was in Trondheim the other day, for a MOO programmer's training
session. We have a project there involving sound. Basically, when a user
connects to a room, he is connected to this room's sound channel
(IP-telephone style). When leaving, he leaves the channel and enters the
one in the room he enters. All that is done automatically. They may
record (!) the sessions as well, with start/stop web clicks; the
recording is then stored in a webfolder elsewhere.
Remember we have talked about accessiblilty? We wonder now how to make
the MOO and/or "the Platform" accessible to a wider range of users.
That's what you have been telling about, and that's the purpose of the
consortium: to make enCore available/accessible/usable for more users.
One group of users are those with disabilities eeeh challenges eeeh
users who are alternately gifted: How can a frameset be read, the Chat,
etc. Another group is those without Java. (disability?) Yet another
group is those with handheld devices. All this time I have been saying:
Well, enCore is a frameset, java, yadayada, that's just the way it is.
But is it really?
What if we segmented the sound device and implemented simple voice
recognition (folks, that is _not_ that far fetched). A user could then
"phone" the MOO and talk to people in that particular MOO-room, and
switch rooms by saying a certain command aloud. And do other stuff, get
his bookmarks read or something. For this user, the MOO would be a
rather hidden motor (the text/commandline at least), but nonetheless a
I'm not saying that we should all shift focus and do cell phone MOOing
hereafter, not at all. I just wanted you to know that we work on these
This project is connected to a large project on mobile technology
(MOTUS2, University of Trondheim). I had an interesting talk with the
leader, and she may be willing to send someone to Texas in August. I
told her that will be a crucial conference, and that I couldn't attend
due to family issues, and how that bugged me... crucial in that
discussion of "compartmentalization" (or simply: modularisation?) of
enCore could lead to new insights in e-learning.
Cynthia, do we have some paperwork on the conference that I could hand on?
> I think it
> is a mistake to only teach students/users to rely on the web-based method of
> doing things.
Why? (that's a real question, not a rhethorical one).
When all works in web, why force users to do the text based thing?
Have you experienced better understanding, better control of the system
and the communicative situation in students who master the text
commands? (again, an honest question). If yes, what is "better
understanding" and "better control"? I'm very curious.
> others to use the Xpress interface to explain how the contextual help info
> works, ie the yellow lightbulb that can be clicked to see information about
> how to work with that object.
I have experienced that many of my users don't find exhaustive help in
the lightbulb-texts. The help function (single source etc.) was
something we said we must discuss.
> In many cases it brings up the old text-based
> obvious verbs, which is confusing if they have not been taught that there
> are two ways to work with many objects, the text-based command line way, and
> the web-based link way.
Correct. But if it confuses, there are two solution: (1) as you say,
tell them/teach them/demand that they understand the
telnet-connection/text-manipulating thing, or (2) not display text
command help in a web contents. I remember we had a discussion around
that, and I voted for putting web help on the web and text help in
telnet. Ie. the text command "help container" would line up the text
based commands, whereas the lightbulb would show you screenshots and
icons and maybe an animation. In either case, I would suggest that the
text help in web be optional (checkbox: show text help in web).
> So, in our view, while the gap is considerable, it it not insurmountable
> if training the trainers attends to these considerations so that the
> trainers can train the users properly.
Still asking myself if there needs to be a gap at all. If we focus on
the gap, yes, there is one, and it is huge, and will be more and more
the more we develop enCore in the "web direction". But do we have to
focus on that gap? Does a user have to learn VisualBasic to master WORD?
Or even to know that WORD is based on VisualBasic? Can't enCore be so
flexible that it serves both "telnet-dummies" (never used a textcommand
before) and "mouse-allergics" (fancies green writing on a black screen)
- and even those who want to do both? Does everyone have to do everything?
I hope you all made it this far.
Thanks for your patience.
More information about the Steering