About Those Frames Part III

No-frames Xpress Client.

In the previous two posts of this series I talked about why I wanted to examine changing the current Frames based interface for enCore, and the non-frames version of the Xpress Login screen that resulted. In this post I'll describe a non-frames version of the Xpress Client itself.

The Xpress client is a fundamental part of the Xpress interface because it is what the user interacts with the most frequently as Guest, Programmer, or Wizard. Since it is so fundamental to the operation of the whole enCore system any changes made should not interfere with the usability.


The client is a typical web page layout with a menu in a header bar and two columns below. The columns hold the text input and output from the MOO on the left and the WEB display generated by the MOO on the right.  In the existing frames based layout this is really very easy to generate with a frameset document whose contents are the output of the verbs on the xpress_client object.


I figured the same kind of changes I made for the Login screen should work, that is replacing the frameset document with an HTML layout that used iframes and CSS. If possible I wanted to avoid having to change anything other than verbs on the client object itself.

A key thing I wanted was to keep the layout the same at any screen size from fullscreen on a desktop monitor to a screen on a smartphone or tablet. I also wanted the columns to resize cleanly as the client window size changes and without adding extraneous scrollbars.  This is handled by the flexbox system like I used for the login.

Keeping the menu bar in place relative to the columns below was tricky and that is handled by a CSS directive called box-sizing. You can read the gory details of what it does here.

So thanks to Google 😀 and lots of experimenting I applied these tools to the same DIV / iframe setup I used for the login screen.

Surprisingly this worked pretty well, once the inevitable tweaks to make it look the same and behave well at multiple screen sizes were made of course. 

Here is the resulting CSS:

<style>
/*I love me some border-box*/
       * {
        box-sizing: border-box;
       }

       /*Just removing default browser padding/margin*/
        html,
        body {
            padding: 0;
            margin: 0;
            color: #ebebeb;
  }
        /*Flexbox gives us the flexiness we need.
        The top just stays put as there is no scrolling on the body due to the page
        never exceeding viewport height*/
       .menu-frame {
            display: flex;
            align-items: center;
            justify-content: center;
            background-color: darkgreen;
            font-size: 3rem;
            position: relative;
            z-index: 10;
            height: 65px;
        }
        /*This is our main wrapping element, it's made 100vh high to ensure
        it is always the correct size and then moved into place and padded 
        with negative margin and padding*/
        .Container {
            display: flex;
            overflow: hidden;
            height: 100vh;
            margin-top: -65px;
            padding-top: 65px;
            position: relative;
            width: 100%;
            backface-visibility: hidden;
            will-change: overflow;
        }

        .java-frame,
        .web-frame {
            overflow: hidden;
            height: auto;
            padding-bottom: 0.5rem;
        }

        .java-frame {
            width: 50%;
            background-color: white;
        }

        .web-frame {
            flex:1;
            background-color: white;
        }
</style>

I modified the Xpress_Client object to get this code from a .CSS property for easy editing.

The only verb I needed to modify was :vertical_layout horizontal_layout and here is the modified verb that resulted:

"===========================================================";
"Copyright (C) 1999-2004, Jan Rune Holmevik";
"Generates the main enCore Xpress client user screen using three frames";
"Modified to use iframes and DIVs instead of frames";
"KRJ June 2017";
"Vertical layout only!";
"===========================================================";
if (caller != $httpd)
  return E_PERM;
endif
user = args[1];
html = {};
base_url = tostr("http://", $network.site, ":", $network.webport, "/Xpress_client/");
menu = tostr(base_url, "menu.html");
java = tostr(base_url, "java.html");
web = tostr(base_url, "web.html");
html = $list_utils:append(html, this.CSS);
html = {@html, "  <div class=\"menu-frame\">"};
html = {@html, tostr("               <iframe src=\"", menu, "\" name=\"", this.menu_frame, "\" width=\"100%\"  height=\"100%\" noresize=\"noresize\" scrolling=\"no\" marginwidth=\"0\" marginheight=\"0\" frameborder=\"", this.frameborder, "\"></iframe>")};
html = {@html, "  </div>"};
html = {@html, "  <div class=\"Container\">"};
html = {@html, "      <div class=\"java-frame\">"};
html = {@html, tostr("                    <iframe src=\"", java, "\" name=\"", this.java_frame, "\"height=\"100%\" width=\"100%\" scrolling=\"no\" marginwidth=\"0\" marginheight=\"0\" frameborder=\"", this.frameborder, "\"> </iframe>")};
html = {@html, "      </div>"};
html = {@html, "      <div class=\"web-frame\">"};
html = {@html, tostr("                    <iframe src=\"", web, "\" name=\"", this.web_frame, "\" height=\"100%\" width=\"100%\" scrolling=\"auto\" marginwidth=\"", this.frame_marginwidth, "\" marginheight=\"", this.frame_marginheight, "\" frameborder=\"", this.frameborder, "\"> </iframe>")};
html = {@html, "      </div> "};
html = {@html, "  </div>"};
result = this:build(user, html, tostr($httpd.server_name, $core_version), "", "", "", "", this.doctype_frameset);
return result;
"Last modified Sat Jun 17 10:54:40 2017 MDT by Wizard (#2).";


Now the existing Xpress_Client has lots of options for changing the display. Things like whether the client is aligned vertically or horizontally and how big the text display is relative to the web display.  To keep things simple the no-frames client only handles the vertical display, which I think most people use anyways.  Allowing those settings to be changed I will leave as an exercise for the reader 😀

Again to test this safely I did an "@dump with create $Xpress_Client", created a new enCore_CGI_Application object called Xpress_Client_Noframes, pasted the @dump into it making an exact copy of the original which I could modify, and then replaced the object number in #0 for the Xpress_Client with the new object. If it didn't work, more times than not frankly, I would just change the object number in #0 back to the original using the text client and still be able to login with the old client. 

This same system should be able to be used for any of the utilities in enCore too. Some of them like the Program Editor, Help Browser, and Mail Client would be tricky given the number of frames they use but I don't see any reason they couldn't be converted in a similar way.

I hope this client will be useful.

Let me know if you try it and how it works, and as always suggestions and critiques are welcome.

Thanks for reading.
KJ 

About those frames... Part II

Happy Canada Day!

Previously I wrote about why I wanted to examine changing the current Frames based interface for enCore.

After much experimentation, reading up on "current" web development tools, plus a dash of hair pulling, some heavy coffee consumption, and staring at the ceiling going "Why me..." for longer than my wife thought healthy 😆, I have a no-frames version of both the login page and the Xpress Client.


I'll start with the Login page first. Mainly because it is just a two column layout with one fixed page, the welcome page, and the login page. The welcome page is a static html file and the login screen is built by a verb on the Xpress_login object and is also basically an html file.

I experimented with a pure html/CSS/javascript design but I couldn't make it robust. That is it was difficult to make it work without changing more of the MOO code associated with the login object itself. So following my "If it isn't broke don't fix it "plan, I looked for ways to use the existing functionality as much as possible.

The best option turned out to be the last remaining "frame" allowed in current web development, the lowly iframe!

I replaced the frameset with a page using divs that held two iframes whose source is the output of the two verbs on the Xpress_login object.  The problem was then to arrange the display of the page in such a way that extraneous scrollbars from the iframes were removed  and the page would resize without getting too badly messed up.  This took a while to do and much of what I tried looked OK at full screen but scrambled badly when the browser screen was shrunk to what a mobile or tablet user would see..

However, since we need to be using HTML5 capable browsers anyways I figured I might as well use some of the newer CSS tools. Flexbox and viewport relative sizes were the key.

The resulting page is mobile friendly, and does not need any javascript at all.  I put the required CSS in a property on the object called login_css, and added it to the html being generated by the verb.
It still uses two vertical columns and the login column is a fixed size but that could be changed using flexbox settings in the CSS if desired.

Here is the revised verb on Xpress_Login:

"===========================================================";
"Copyright (C) 2001-2004, Jan Rune Holmevik";
"Generates the main enCore Xpress Login Screen";
"Revised to us a defined welcome page named on this.welcome_page";
"KRJ Sep 3, 2015";
"Revised to replace Frame set layout with CSS/iframe";
"KRJ June 9, 2017";
"===========================================================";
if (caller != $httpd)
  return E_PERM;
endif
{user, ?message = ""} = args;
html = {};
base_url = tostr($encore_web_utils:baseurl(), "/Xpress_Login/");
login = tostr(base_url, "login");
"Revised Welcome Screen to use locally hosted webpage";
"Set page name in this.welcome_page";
welcome = tostr($xpress_client.external_baseurl, this.welcome_page);
if (message)
  message = tostr("onload=\"", message, "\"");
endif
html = $list_utils:append(html, this.login_css);
html = {@html, "<body>"};
html = {@html, "    <div id=\"wrap\">"};
html = {@html, "        <div id=\"login-frame\">"};
html = {@html, tostr("               <iframe src=\"", login, "\" name=\"login\" width=\"100%\" height=\"100%\" noresize=\"noresize\" marginwidth=\"", this.frame_marginwidth, "\" marginheight=\"", this.frame_marginheight, "\" frameborder=\"", this.frameborder, "\" title=\"Login frame\"></iframe>")};
html = {@html, "        </div>"};
html = {@html, "        <div id=\"welcome-frame\">"};
html = {@html, tostr("               <iframe src=\"", welcome, "\" name=\"welcome\" width=\"100%\" height=\"100%\" marginwidth=\"", this.frame_marginwidth, "\" marginheight=\"", this.frame_marginheight, "\" frameborder=\"", this.frameborder, "\" title=\"Welcome screen\"></iframe>")};
html = {@html, "        </div>"};
html = {@html, "    </div>"};
html = {@html, "</body>"};
html = this:build(user, html, "Login", message, "", "", "", this.doctype_frameset);
return html;
"Last modified Fri Jun  9 21:17:55 2017 MDT by Wizard (#2).";
"===========================================================";

And here is the CSS data:

<style>
        body,
 html {
     margin:0;
     padding:0;
     color:#000;
     background:grey;
 }
 #wrap {
     display: flex;
     height:100%;
 }
 #welcome-frame {
     flex: 1;  /* grow */
     background:white;
 }
 #login-frame {
     height:450px;/* fall back for old browsers */
     height:100vh;
            flex: 0 0 200px; /* do not grow, do not shrink, start at 200px */
 }
</style>

Note that this must be stored in .login_css as a list of strings. I used the object editor to store the CSS as a description and then copied that over using the program editor.

The magic here is the way the CSS "display:flex" allows the columns to dynamically resize as the browser window does. Because the CSS is held in a separate property it can be edited and adjusted without messing with the verb so lots of customization is possible.

To test this safely I did an "@dump with create $Xpress_Login", created a new enCore_CGI_Application object called Xpress_Login_Noframes, pasted the @dump into it making an exact copy of the original, then replaced the object number in #0 for the Xpress_Login with the new object. That way, as I messed things up (which happend A LOT) I could change the object number back to the default value when logged in through the text only client, and still be able to use Xpress. 

Next time I'll discuss the more complicated layout for the Xpress_Client.

Thanks for reading
KJ

About those frames... Part I

I have been playing around with trying to update the enCore Xpress user interface.
"Trying" is the key word here.😑

First a little background on why this is something to even worry about.

The user interface and many of the more useful utilities included in the Xpress system are "frames based" layouts. Frames are a way to split a webpage up into independent pieces each with their own URL and context. This is a 1990's technology, a solution for the problem of how to include other web resources inside a webpage, that retained all the formatting, and allowed easy update of a piece without disturbing the rest of the page etc. The frame was basically a window in which to display content from somewhere else.

Practically its main use in the days before CSS and JavaScript was to keep a menu of links available even as the main content frame changed. Since loading a new page always caused the page to reload completely keeping state information was tricky and necessitated a bunch of cookies and other fragile data structures.  Now as far as Xpress is concerned frames were the perfect vehicle to enable the simple web server running inside the MOO to display easily. Each frame was a way to display the output of  a MOO verb. Because frames could reference each other easily it was possible to maintain state through logged in session and update the display as required.

Now frames have always been controversial because they break some of the fundamental attributes of the Web. Things like search engine indexing, bookmarking, and even the "back" button on the browser.

Want to get treated like a pariah in web development circles?
Ask about how to setup something using frames!

AJAX, which used JavaScript and XML data, was a way to do part of what we need.  I experimented with it in my AJAX auto updating room back in 2011. It allowed the web page for a room or object to automatically update the list of objects contained as it changed without having to do a "look" to refresh the web display.  But AJAX causes a lot of traffic to the MOO web server, it essentially polls the object looking for changes. Since unlike the formal web server running alongside the actual MOO executable, the in-moo web server can impact the lag that a user experiences. When it is creating and updating the display NOTHING ELSE CAN RUN.  I considered this a reasonable trade off since it only happens when a room is actually being displayed. However to use it for the Xpress interface itself would entail constant polling from every connection, from every frame of the interface, all the time! Maybe OK for one or two users but would kill a system like Literary Worlds which quite happily handles 100 or more users at once with the current frames based interface.

Definitely not an optimal solution to get rid of the frames.


So...
For our purposes using enCore, FRAMES ARE PERFECT!  Now that we no longer need the JAVA applet to connect we have a pure web based application I.E. a Web App!  Web apps are a different critter entirely from a typical webpage. For one thing Google doesn't ever get to index the inside chunks of a web app display, nobody bookmarks parts of a web app, and the browser's back button doesn't work in a web app like it does on a typical webpage anyway.

Notice that these are the main complaints that the web development community had about frames!
If you look at how typical web apps are coded you'll see a tremendous amount of complexity, and therefore fragility, needed just to do what Xpress does with a simple frameset document.

I'm a big fan of 'if it isn't broken don't fix it' so I wouldn't mess with Xpress except for one thing...

Frames are no longer included in HTML5, not just "deprecated" but actually gone! While most browsers still know how to display them that may not continue. Already support for frames is beginning to disappear in mobile browsers.  This means that if we want to continue to keep enCore and its Xpress interface working we should, reluctantly, see about changing the interface away from frames.

So far my initial messing around has been very discouraging.  In the next parts of this series I will try to explain what I've tried and what worked and what didn't.

Thanks for reading.

Part II is here.

How Time Flies When You Are Having Fun!

Wow!

There is an old saying that states:

Life is what happens when you have other plans.

Definitely holds true for me.

Since I lasted posted to this blog lots of things have happened with the enCore Learning Environment.
Some good some bad.

The Bad is that the enCore Consortium folded. Partly as a result of the unfortunate passing of one of the key movers and shakers, Barbara McManus, and difficulty in getting access to the old domain to maintain the mail list.

The Good is that we now have a JAVA free client for enCore V4 MOOs that is a drop in replacement for the JAVA based Mootcan applet. Jack Lewis at Western Michigan University created and supports the client at Literary Worlds and they have kindly made the client available to all enCore systems.

So where to from here?

I know there is still a lot of interest in enCore, more so now that we no longer have to fight with JAVA restriction policies at many educational institutions.

I know that those of us who have used these systems over the years have collected a fair amount of information tricks and tools and new users and builders could benefit mightily from access to that.

Community support via the old encore mail list was excellent and really helped those of us struggling with making enCore perform all the tricks our imaginations wanted it to.

Thus I have created a new Google Group to become the hub for support of this system.
You can access the Group here: https://groups.google.com/d/forum/encore-learning-environment

This group is not currently open to the public but feel free to request membership and I'll add you.

The Barn is hosted still at Literary Worlds here: http://brn227.brown.wmich.edu/Barn/news.htm

Watch the group and this blog for more interesting MOO news over the coming months.

Thanks for reading.
KJ


 

I'm in print!

I just received my copy of  Teaching Literature in Virtual Worlds 
This very interesting collection of articles, edited by Dr. Allen Webb of Western Michigan University, includes a chapter by me "On the Building of Worlds". 
Very cool, if I do say so myself.
The articles discuss many of the Worlds created at Literary Worlds, which is hosted at Western Michigan here: http://brn227.brown.wmich.edu:7000/
Ciao
KJ

New AJAX updating Room files available at the Barn

I have put the files for the new room up at the Barn.
You can get the zip file here:
http://www.encore-consortium.org/Barn/files/objects/EnCore/rooms_with_ajax.zip
The zip has two files one, ahah2.js, is the javascript that handles the AJAX communications.  This file should be put in a directory called edit_area in the root of your encore directory.  The other file is an @dump of a room with the  auto updating capabilities for the objects list.
This room has a property called js_base_url which is used if you cannot store the ahah2.js file in the encore directory. As long as the directory you have access to is on the same server as the moo it will work.
It is currently set to my directory at Literary Worlds so make sure you change it to your directory or set it to 0.
Let me know if you have questions or problems and also how it works for you if you try it out.
If you just want to see this room in action you can check out the test room at Literary Worlds by logging in as a guest at: http://brn227.brown.wmich.edu:7000/
Once logged in @go to #5446
There is a box there you can pick up and drop to see the update in action.
Enjoy
Ciao
KJ

New Experiment: Room contents display enCore V4

Continuing along on my experimentation with the user interface in enCore v4, it occurred to me that one of the issues I've had is how the room display is static, relative to the text side.  Where this can be an issue is with a busy class all logged in at once.  The text side is flying with all the comings, goings and chatting amonst the class members, while at the same time the room display, with the list of contents and exits, is frozen. Only a look command or click on the look icon will refresh it.

Several times I have entered a room with people chatting and they did not notice me entering because the text message scrolled past, lost in the chatter, and at the same time the list of the rooms contents didn't change either. They were quite surprised when I started talking!

How to get around that?

Here is my latest experiment... AJAX, Asynchronous Javascript and XML. This is the underpinnings of the infamous WEB 2.0 jazz we've been hearing about for years now.  I found a small javascript file called AHAH, Asynchronous HTML and HTTP, which is a simple implementation of AJAX that only deals with html rather than XML.  You can read about it here: http://microformats.org/wiki/rest/ahah

What this javascript file does is allow us to update PARTS of a webpage on demand or automatically without reloading the whole page. For my experiment I had it update the contents display of the room every second.  The javascript calls a verb on the room that sends back the current list of objects in the room.  The code then checks to see if the contents have changed since the last time and if so it updates the list in the display.

Very cool.

I had to change the SPANs with classes to DIVs with ids, which needed a bit of CSS gigerypokery to line up, but that was it.

The javascript file is very small so does not add any delay to the page when first loaded.

A pleasant surprise was the way the code was able to access the verb on the room, it did not need any path info at all, it knew the host it was being called from and simply returned the verb output without complaint. (Not sure why that works frankly)

This tool should have great use for interactive objects, since pieces of the display can change without having to refresh the whole lot.  Think of communication devices, games, viewports, graphics displays etc. According to the notes with the javascript there can be multiple instances of the updaters on the same page.

I will try to put the code into a package for the Barn in a bit.

New Xpress Program Editor coming along nicely

Good Day All

I have continued to mess around with my revised Program Editor for V4 enCore.
My latest experiment has worked pretty well, surprisingly.

This version has added the ability to insert Breakpoints into a verb so that execution of the verb will stop and the values of selected variables will be spooled out to the programmer. The programmer then has the option to continue the execution of the verb or to kill it.  This is most useful when troubleshooting looping code as the Breakpoint can be used to allow a kind of step through, examining the loop as it executes.

I have a version of my Ewebbed enCore package that includes the new editor.  I will be putting this up at the Barn shortly.

While the new editor works OK, it is pretty rough and I'm sure there are some gotchas so the usual cautions about using beta class software apply :-) I would be interested in any comments or suggestion you might have so please send them along.

I would also really appreciate anybody who has a good handle on verb and html security to take a look at the way I've set this up, to make sure I haven't left any massive security holes anywhere. The Checkpoint and Breakpoint verbs must be Wiz owned which always makes me a bit nervous.
Ciao
KJ

Revising the User Interface in enCore

Here is a "blast from the past". At least this one is in the current century.
This is a post I made to the enCore mailing list way back in 2005.
What is interesting to me is that many of my comments seem to still apply.  If anything they are more applicable now. Plus I know way more about how enCore works so it is actually feasible to do this myself.
So many projects so little time :-)
Thanks for reading.
KJ
=================

http://mirror.lardbucket.org/encore/0002.html
From: Kevin Jepson
Date: Wed Aug 17 2005 - 16:12:20 CDT

Good Afternoon Folks

Ok, here is one way I think we could easily change the interface to bring back some of the immersive qualities that we have been talking about.

Note: "easily" is relative, Daniel might not agree :)

The following is a crude cut and paste mock-up using my version 4 EnCore MOO.

You'll notice that it is pretty much a standard version 4 layout when set for horizontal.
This horizontal layout is important, IMHO, because it ties into the scrolling text structure, unlike the vertical one which forces the user to switch "back and forth". This layout does reduce the graphics space available for illustrations within the room description a bit without scrolling, though.

The list of users shown on the right hand side could also be a version of the "Who Frame" that Daniel has added to V5.
If a hidden frame was used for that a similar hidden frame could be used for the contents. While that would reduce the space for the description even more it would fix the layout. That way when moving, objects, people and exits could easily be updated and kept current without loosing them in the refresh or to the vagaries of the rooms decorations.

The "Exit Frame" lists the obvious exits of the room and makes them clickable. The key thing here is that the link is the DIRECTION of the exit. A user can also type that direction in the chat to move as well.  The exit frame would update only when the user moves and could be updated by the look cmd.

I would also make sure that exit messages were turned back on so that the users would get feedback on their movements and those of others.

This isn't really a big change but I do think it would drastically change a users perception of the "space" in which they are "moving".

Javascript, moo code and webpages Oh My!

It seems that sometimes a bad Internet connection is a good thing.

I've been on a sort of "Busman's Holiday" out to Vancouver Island and the Sunshine Coast over the last two weeks.  During that time we have generally had an Internet connection of some sort, but it has almost always been a bit intermittent.

Normally this state of affairs would be sub-optimal for me to be sure.
This time however, I took the opportunity to apply myself to learning the esoteric art of JavaScript coding... Don't laugh, I have never had to do anything with it before now!

What got me thinking about this was how well the Edit Area Javascript package worked when I integrated it into the Xpress Program Editor in V4 enCore.  You can see some screen shots of the editor here .  The Edit Area Javascript package was created by Christophe Dolivet and can be downloaded here .

The Edit Area system adds a lot of nice capabilities to the enCore editor without using much if any MOO code.  I figured "how hard could it be to do something like that?" Heh...

After two weeks of reading from one of those 2" thick 4lb dead tree chunks, that purports to be "everything you need to know", and lots of experimenting on a copy of my Ewebbed enCore package running in a Virtual Box copy of XP on my Ubuntu EEEpc Netbook (?!?), I managed to add a "debugger" to the program editor.

Shiny new Ewebbed enCore Package available at The Barn

I have just uploaded a revised version of my Ewebbed enCore package to the Barn for download.

This version incorporates the new Xpress Program Editor and also includes a copy of the Neil Fraser's MOO Inspector.  You can download the complete package from this link.

http://www.encore-consortium.org/Barn/files/docs/Ewebbed-enCore-V4-a2.zip

The instructions and some documentation is here:

http://www.encore-consortium.org/Barn/files/docs/README-INSTALL-V4-a2.htm

You can see some screenshots of the Ewebbed enCore system in action here.
------ 

For those of you who are not familiar with the Ewebbed enCore package allow me to explain.

One of the hurdles I had when first learning to code for LambdaMOO based systems was the lack of places to experiment.  Pure text based systems were pretty rare and open ones that allowed new users to be programmers were even rarer!  So I went looking for a way to easily setup a local MOO to play with.