Frames in v5

This document was written after an online meeting at the Symposium August 13th 2005. It addresses concerns reveiled there about the introduction of a new frame in the frameset of version 5 of enCore/Xpress (in its current beta stage). I have used the v5 frameset with the additional frame for a year in three different MOOs of mine now, all of them in regular scholarly use. I have given this a lot of thought, and I have drawn many user experiences and feedback. I will try to explain the rationale behind the frameset.

I hope that this document will raise a few questions about layout and space (metaphorically and computer-screen-wise), and generate a vivid discussion about what we want in enCore and why, and how we want it. It is my hope that this will lead to an implementation of the best of all (viable) solutions. I hope we find it together.

Consider Real Life

In the next days, please do this experiment. Open a door in a public space, at school or at home, and immediately close your eyes. Try to make a picture of what you saw in that split second. My bet is: You will have noticed if there were people there or not. You could probably tell the approximate number of people. My bet is that you won't be able to remember how many newpapers were on the table, if there was a slide projector or a box standing about. I think we (humans) are scanning for people first, no matter what. Then, if someone enters a room, he/she is automatically turned to and looked at, either in a welcoming or in a reserved manner. If someone leaves without saying anything, most of the time he/she tries to at least get eye contact to "ask permission" or to inform the group of leaving. Not doing any of those things is often consider somewhat rude.

I think we all agree on the fact that people's presence and absence play a main role in the concept of rooms and spaces we experience.

Then, pick up a newspaper from the table. Look at it. Read it. Do you still see the room around? Unless it's a really breathtaking story, I would bet that yes, you are. You will probably have a fair impression about who is in that room, while reading, because you will see coming and leaving in the corner of your eye, or hear movements.

Consider enCore 4

How is that implemented in enCore? What we see after login is a frameset. There is a menu area, a chat area and a web area. The web area shows the room you are initially connected to. It shows a list of exits to other rooms, and it shows a list of objects. Amougst these objects, you will find a mixture of web resources like documents and links, tools like recorders and slide projectors, and people. There can be connected or disconnected people (more on the notion of "being active" later). The object list is ordered by entry, last object comes last. There is no difference between objects and people.

This room is shown in a space technically called "web_frame". This same frame is used for displaying other things. When you click on a document, this document is shown in the space the room was displayed in. The room disappears, unlike the real-life newspaper experiment above. In this document, you can click on links which will open in the exact same frame, and you are going deeper and deeper into in-moo or external content. The room is, mentally, somewhere in the background (at best), but graphically, it is not visible, like it would be in real world. And unless you are very familiar to MOO and accoustumed to its notion of rooms, you have no indication that you are still in a room, let alone what room and who and what's there.

The Look-button confuses most of my users (at least at first), they have no idea why "look" should mean "view the room" instead of "read, refresh or magnify the thing/document you are reading right now".

This (the documents covering web_frame) is an important part of the reason many of my users never got the idea that there were real-life metaphor rooms, and that they in fact were part of it. What many of them do, is log in, find the recorder log of the last (unattended) class, click on it, read it and/or print it and log off again. They are using the MOO for browsing resources, and even ask me to please make it more windows-like, with a folder and document hierarchy, since the way it is now is so weird, unintuitive and cumbersome. My guess is: If the current room always were a non-vanishing part of the GUI, those users (or: many modern users) would more easily accept rooms as structuring unit, and not search for folder and document hierarchy.

The role of the room as a structuring unit is down-played considerably when the space it is displayed in is also used for other, non-room-things. So let's stick to the word web_frame, and let's not call it room_frame or "the room", because conceptually, it isn't.

Updating. Very much unlike real life, the web_frame is not updated on any entering and leaving of people. Neither should it: When I am reading a document, I don't want to have the frame reloaded with the room just because someone enters or leaves (although I want to be informed of that, just not in the web_frame), especially when I am doing form data things, like solving language tests forinstance. But even in a room display, there is reason not to reload the frame: When there is a video clip or sound connected to the room. That would compare to a movie theater rewinding the movie, or a symphony orchestra taking it from the beginning just because someone's too late.

The list of objects in a room contains people. As a means of helping the user to understand if the person behind the icon is available for talking, there is a tag saying "inactive" or "sleeping". The "inactive" tag is inherited from telnet-text-only moo. There, it makes sense, since all activity, reading and writing, is done through the text command parser. In a GUI, where users can click and read, write on documents and do many relevant things outside the parser, this is usually missleading, and, to some, even insulting: They simply haven't been inactive. The notion of "sleeping" is very virtual-world, but not really comprehensible to the common/modern user. In addition to that (inactivity and sleep), the list is not updated, and somebody recently very active in chat may still be displayed as inactive, or even sleeping. Or somebody disconnected may still be displayed as active.

Now, I am fully aware that the chat may (or may not) announce a person's coming and leaving, but we are discussing the GUI and how and why we put information on the graphically enhanced part(s) of the screen, and how we can make this information consistent with the informatino in the chat - or, simply, consistent with the virtual world.

Consider v5

The frameset in v5 (or: its current state) is an effort to address many of the issues, or problems, explained above.

1. I wanted one space which always shows the room the user is in, and is not overwritten by other non- room stuff. This space is internally called player_frame, but to me, and this is my major point in this document: it is really a room_frame, leaving the web_frame for other resources. The web_frame defaults to a richer display of the room, but that doesn't mean that the player_frame is "doubling" the room header, it is rather the other way round.
   So the choice to make a frame of its own, to me, really contributes to the notion of spaciality instead of decreasing it. The idea was to have all exits there as well, maybe as a folded/unfolding list, but I haven't come that far (yet). This is meant to increase awareness of the room.
2. That space should be updated immediately and reliably on each movement in and out, and on each changement of any user's away-message. This is meant to increase awareness of the fellow users.
3. Since the primary action one takes with co-connected people is chatting, I chose to move this space nearer to the chat. All other chat room facilities I know have a list of who's there near by, and that makes sense. Chatting and people in a room belongs together. This is meant to increase awareness of the fact that rooms and people belong together. I can't really see that it moves them out of space.
4. Moving the players nearer to the chat is also due to the floating feature. Some v5 users have already seen, and made use of, the menu_frame being able to "float" and to "dock" upon mouse click. The idea is to have both the menu_frame and chat_area floating and docking. This allows for leaving a big window to the associated web resources, and maybe even to minimize or close it completely, keeping only the Chat area, and thus simulating a telnet client. If this is being used, there should still be a player_frame telling who is in that room and what they are doing. In order to make the layout consistent in docking/floating, I chose to have the player_frame above the Chat.
5. People are, graphically, moved out of the web_frame room display. Since they play a special role for the room and fellow users, they should not be mixed with objects. I had that in early versions of my hacks: one list for objects, and one for users. But that was not good enough: They should also be updated on every change, because everything else would be missleading. Since updating doesn't work this way in web_frame, and can't, I chose to move them out graphically to a screen space where they still are visible when the user chooses to read a document.
6. People's activity is now measured, or detected, in two ways. In addition to telnet idle_seconds(), I introduced a new feature I call Xpress_idle. Every page served to one particular user is logged on the user with the time of its serving, thus keeping track of web activity. The Who browser listing is sortable by name, location, connected time, and those two idleness values. I took away the inactive/sleep tags. Only connected people appear in the player_frame, while sleeping, i.e., disconnected, people still appear in web_frame, as objects/bodies, not persons. I made a quick away/back- feature to easier and faster notify the others of shorter absences (@doing).
   Activity messages or information don't have anything to do with the frameset, but in the light of the problem of updating frames, it makes sense to mention these options here. Moving the players graphically to this frame of its own means also being able to reliably display their activity state or message.
7. The same goes for recording. It is an ethical thing to inform users of the fact that their utterances are being logged, and I would even say that it is an unethical thing not to do so. So I wanted to make that fact stand out. Along with rooms and people, the recording of conversation is conceptually a big issue. Again, due to updating issues in the web_frame, this hasn't always been clear, or possible to make clear, in the GUI. The fact that the old look_self command is suspended by default in Xpress, thus not showing the flashing ASCII- recorder, means that the user had no clue if he was being recorded or not - especially if he missed the announcement "XYZ starts the recorder, and a red flashing light...". There are, admittedly, other types of logs, forinstance the Xpress log which works like a recorder on a person. This logging is not shown to other users (to the best of my knowledge). And the HTML chat log is a kind of an automatic and endless Xpress log. I think we must inform users of that.

Consider other options

Consider the user

There has been a proposal to have the player_frame be switched on and off globally by a wizard. I reckon it would be a true|false bit on the Xpress client object. But in much of the v5 code, such preferences are taken from the global object, thus forced on all users, and put on the individual user. So if there is going to be a choice, I think it must be on the user, not on the platform. Meaning, each user must be able to decide for him/herself if one or the other or the third layout suits him/her best. Like it is with the language feature, or the vertical/horizontal alignment of frames. Then, the user should be able to individually choose if user icons should be displayed next to the user (maybe there is too little space for all the icons in a low-res screen, like in the first picture linked to in the introduction of this document); meaning: it shouldn't be switched off globally.

Consider the global concept

For the sake of the argument, let's say you agree with the statements, or claims, from the first section (Consider Real Life). And let's say you agree that they should be reflected in a GUI MOO. And let's say you agree that they should be reflected in the GUI part of the GUI MOO, not be left to the the non-GUI part .

Then, a near-perfect translation from the mental concept into a computer interface could be something like this: [badly and quickly cut-and-pasted mockup- picture].

This is one single frame, or window, depicting the room one is connected to. This frame is updated continously, upon each user movement, thus giving a true rendering of the people connected and available. Now, inside this window, there is an "inline frame" or "embedded object" for chat, because chatting is in rooms, not outside, or, graphically, next to it. This chat frame is independently updated on every utterance or server message. When clicking on a resource, this resource is opened in a half- transparent, movable, smaller, overlaying window which lets you see through it and thus have a fair control over the changements in the background, i.e., in the room, while you read it. This window would stay on top until you close it, while you have access to the room behind, including access to the links for switching rooms.

Due to technical reasons, this won't work. At least if the rendering is through HMTL and common browsers. Which I think all agree it should be.

So what is the next best thing? I think the current state of v5 already makes fair attempts in meeting the wishes expressed. Going back to having user icons in the object list in the web_frame, with all its backdraws, is, in my opinion, not nearly as good as having the player_frame like it is now in v5. But maybe there are even better solutions.

Let's say we keep the player_frame. It is possible to beef it up, so that the description, a picture (but not multimedia like sound and video) and the exit and object list is displayed there. This would consume space, and one would automatically propose to move that player_frame to the right, where the web_frame is now. They could actually switch places. All non-room resources (links, documents, but also the default video resource in that room) could be displayed in a smaller frame, like the player_frame is now. A detail: Take ambient (musically enhanced) MOOs. Music could be played from within the menu frame, which isn't updated often and thus won't break the musical flow. There is no need for a graphical representation of sound, so it can be placed anywhere and doesn't mess up the frame, or screen. Switching rooms to a room with another background music could trigger the menu frame to be updated (v5 does that already) with another background sound.

Let's say we keep the player_frame. I don't really care where it goes. It could be a small vertical stripe between the chat area and the web frame, making the chat history visually higher. Or it could be better to have it positioned on the right, under the web_frame, thus giving an impression of a continued list. The frame border could be set to "none" or zero, giving the impression of one single "room document" (not recommended, but possible). It could even be an iframe inside the web_frame, which would be targetable and (if I understand iframes) independently updatable. iframes are not widely supported though, and they are not HTML 4.0 Strict, but if we find out it suits us best, maybe we can live with that.

Let's say we don't keep the player_frame. What then?

Anyway, any changes to the current state of v5 should be made optional on a user level, giving the wiz the possiblity to set a global default after his/her wish, but leaving the final choice to the user.