[Steering] Long mail. Compartmentalize.

[Daniel Jung]

Hi all,

Cynthia Haynes wrote:
 > Lennie,
 >     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 
brings along).

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 
server.

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 
things here.

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.

- Daniel