Unnamed Grand Project UI design ideas

 

(This page contains very old ideas only - no factual information here. SecureSqueak will only have a minimal UI such as a command line, and it is up to an "image maintainer" to add a real UI to it)

 

SecureSqueak is meant to be a secure version of Squeak. This means that regardless of what the user does or what happens across the network, it will not crash. Specifically:

 

• Remote code loaded into Squeak cannot crash the system, directly or indirectly.
• Remote code cannot cause a denial of service to other code running locally. This means that limitations on the amount of memory remote code can use and the number of threads that code can make are present.
• The UI will never freeze up as it currently does under Squeak. This includes when the system is under high load or when parts of the UI are waiting on something. The UI is as multi-threaded as possible.
• If a debugger pops up, it will only run code in the objects it is debugging in a very careful manner. Currently in Squeak, a bad printOn: routine or rogue UI element can stuff up the debugger.
• The running image is recoverable if everything turns to custard (which it won't, because the image is secure).

 

The environment that remote code will run in will provide secure basic operations such that the remote code can create it's own GUI environment. The access point for remotely loaded code is a "Site", which a "SiteBrowser" will call methods on when that Site is visited. A Site will be provided with:

 

• A Canvas to draw on. This includes all basic drawing primitives.
• Event handling, including "draw request" events. Draw request events happen n times a second.
• Special APIs for providing links on the canvas to other projects, site information, etc.

 

Site-based design

 

Rather than store objects in folders, a user would store objects in sites. Sites can contain links to other sites (cf: subfolders). Instead of a directory tree, a user would have a tree of bookmarks to sites, possibly stored in an easily accessable pane on a side of the screen. A user also needs a place to keep objects that can live in a particular kind of site; perhaps the bookmark system could also handle these?

 

Each site acts like a Squeak project does now. The user has a number of objects (Morphs, perhaps?) on that site - how the site actually works depends on the site's implementation.

 

The user can create new sites by copying an old one, or copying a template. That template would have facilities to create new objects on that site.

 

Ideally, the SiteBrowser (which implements the back button, history and authentication of Sites) would be easily upgradable. Perhaps it's package could be downloaded from a central web site and authenticated? This would involve authentication and key-signing of packages.

 

Ideally, some part of the screen would be reserved for showing external authentication of pages. This part of the screen would also be used for other widgets such as the browsing controls.

 

A full-screen mode would be made possible using a keystroke. Alt-Enter?

 

The ESC button could be a hot-key / panic button that would reset lots of things (sound, full-screen mode) and bring the user back to his "home" screen. Shift-ESC could pop up a basic text console where the user's home screen can be repaired. (In RiscOS, F12 will bring up and dismiss a console)

 

A special type of subcanvas would be used navigate to other pages.

 

F1...F2 could be used like tabs. They would bring the user to each of those pages.

 

or: The user's "desktop" (a window with a hierarchy of that user's objects) is a list of "Workspaces", with sites in each workspace. Workspaces are full-screen. Workspaces remember the window configuration of the sites in them. Sites can exist in multiple workspaces, in which case they would have different window locations. (if a site is made full-screen, should it become a workspace?)

 

Site Controls

Each site on screen needs to be able to:

• Be closed. Note that "minimise" and "close" would mean the same thing. Also note that re-opening should open an already open instance if present.
• Be made full-screen.
• Become a window with controls? Move window, maximise, close? Be attached to a side of the screen or another Site? Split the screen like Emacs?
• Have its own volume control with mute button.
• Navigation? (Arguably, each site should be responsible for its navigation. One window should be one site; if a back button is needed then the site can implement it.)
• Have a title and icon. The icon can be dragged and dropped elsewhere - e.g. on a bookmarks window.
• Have authentication info.
• Perhaps have a toolbar? This would be a set of subcanvases that react to click events such that the application can pop up menus.
• Dominion information, settings?
• Choose which user to authenticate as?

 

Umm... some ideas?:

 

Currently an ASCII-art screenshot look like this:

 

 

 

[back] [forward] [home]   /site1 /site2 /site3      12:34pm

[current page description]  [page flags, e.g. "authenticated"]

-----------------------------------------------------------------

rest of screen from here down is a Canvas.

This is just bouncing ideas around. The [back], [forward] and [home] buttons act like they do in a web browser. The Canvas part of a screen displays a current "site", like a web site, and the navigation buttons allow you to move from site to site. These are like Squeak's projects.

 

The "/site 1\" etc are tabs, much like in Firefox. Each has a site underneath it. The navigation buttons work only for the current tab.

 

To the right is a clock. Perhaps this area is also good for other applets, such as CPU load, some chat program, speaker volume, media controller (play/pause) etc.

 

The current page description is a permanent area of screen which shows information about the current site. This area is used to show whether the site is officially secure, authenticated or whatever. If this were not present, there would be no way for the user to determine (easily) if the current site was not fraudulently pretending to be another; the text displayed comes from some central repository of registered / authenticated sites.

 

Somehow, the Canvas can have areas which are presented as "links", which are hyperlinks to other sites. In this way, each site cannot programmatically move the user to another site (which would be insecure) but can present the navigation framework with a means to allow the user to move from site to site.

 

The whole area above the canvas with these controls is running well-tested code and cannot be interfered with by the code that manipulates the Canvas. It remains reactive regardless of what is happening in the Canvas below it, and can switch the user between sites should one break.

 

The UI would require some unbreakable way of handling exceptions and bugs in code. One idea is to have a text console, which could be a site. Another is to open up a debugger in a new site such that any broken UI implementations cannot affect the working of the debugger.

 

The top pane could simply hold widgets, and the rest of the screen could be a navigatable canvas. Examples of widgets are a back button and other nav buttons, text-entry search box, time, volume, bookmarks, etc. These can be dragged and dropped up there or can be cut and paste. Some must remain fixed so that a broken pane still has enough functionality to be fixed.

 

 "break"

Each Site would have two Interfaces: an editable one and a read-only one. The editable Interface is the one that the site author keeps so that he can edit that site and update contents. The read-only interface is the one the audience sees. To edit the site, the editable Interface is passed to a development environment (which... would be another site?). [An Interface is an object which implements a particular subset of methods, and each method implementation simply passes the invocation to the object it is interfacing. In this way, it is possible to disconnect the Interface preventing further access to the target object.]

 

 

 

Drag and drop

 

The manipulation of objects will be based very much on drag and drop, cut and paste. Draggin and dropping can be considered a short-cut version of cut and paste.

 

Cut and paste has the following operations:

• Cut the original (i.e. a live link).
• Cut a copy.
• Copy the original.
• Copy a copy.
• Paste the original.
• Paste a link.
• Paste an icon?
• Paste a read-only version of the original which updates as the original updates.
• Delete the orignal.

 

 

One way of simplifying this is the following set of operations:

• Cut (the original, anything previously on the clipboard is moved to the rubbish or the undo system?). - CTRL-x
• Copy (the original, ditto with old clipboard items?). - CTRL-c
• Paste a copy. CTRL-v
• Paste the original read-only. (CTRL-b)
• Paste the original, editable. (CTRL-SHIFT-b)

 

 

Of course, this needs some more thought. Cutting and pasting could work either with a link to the object, so that the same object is represented graphically in multiple places, or by copying the object so that modifications will be local to the copied version.

 

Dragging and dropping need to have all the above operations as well. Perhaps cut,copy and paste could being a drag+drop by attaching that object to the mouse pointer? E.g.:

• Normal drag and drop - cut the original, paste it to the destination.
• CTRL-drag and drop - copy, paste a read-only link to the original.
• SHIFT-drag and drop - copy, paste a copy of the original.
• CTRL-SHIFT-drag and drop - copy, paste a writable link to the original.

 

( I don't like the above - it doesn't feel natural; CTRL and SHIFT should have meanings which can be combined.).

 

Sometimes dragging and dropping has preferred options - for example, to store an object in your shortcuts, a pasted link to the original is desired. Some examples:

• Dragging to a folder would mean a link to the original is pasted.
• Dragging an object from one folder to another would usually mean that object is moved (cut, paste original).
• Dragging to a printer could use a copy or a link of any sort.
• Dragging to an email would need the type of link specified.
• Dragging an old version of an object from a version control window would mean the object is read-only (although this might be achieved by other means?).
• Pasting ordinary text would be a copy of the original text.
• Pasting an object into a document could be of any sort.
• Pasting a private object into a suspicious Site would mean that the original writable version should not be linked. The UI should make it possible to paste the original, but with confirmation.
• Sometimes copying or cutting would need a confirmation box to determine exactly what is being copied. E.g. some type of factory, disk space allocation or resource of some sort?
• Copying from a factory (a template?) would always mean a copy is made. The user should be dissuaded from copying the factory original or cutting it, although these should be possible (e.g. to send the template to friends or co-workers).
• Dragging to the rubbish bin would mean cutting the original.

 

These need to be mapped to sensible keyboard short-cuts and mouse bindings.

 

From a primitive point of view, dragging, dropping, cutting and pasting are core facilities available to a Site, perhaps as part of the canvas architecture. Objects can be cut and paste between sites and across canvases. Under the mouse is a little canvas which represents the current object being dragged around.

 

When an object is being edited, there will be some way to drag and drop that whole object to another place. For example, a document editor needs some way of grabbing that whole document and dragging it, for example, to the printer, the trash bin, or an email. One way of achieving this would be to have window titles with an icon:

 

[ICON]  Object title

 

This would be the title bar of the window. Minimising the window would reduce it to the same icon and title. The icon reacts to the dragging, dropping, cutting and pasting controls above, and has a useful context menu pertaining to the document in question. Other objects in the system would be similarly tangible, e.g. printers, folders etc.

 

Some dialog boxes could contain particular "drop" areas for such icons, or perhaps even "drag out" areas. Say for example, that a print operation didn't immediately print something but rather produced a "Printable" object in a "drag-out" area of a dialog. The user could then preview that "Printable" (which would be a number of A4 pages), and drag+drop or copy that Printable to a printer.

 

Site Design

 

Websites these days tend to follow a fairly standard template. In most websites, you typically have:

• Products, Services with descriptions.
• Support
  • On-line support
  • Forums
  • Knowledge base
  • Documentation
• Downloads (if any)
• Online shop
• Contact information
• Custom applications such as online accounts, calculators, polls, etc.
• Forms that can be submitted (typically feedback or application forms).
• Search site

 

Within that site, there may be widgets that could be:

• payment requests
• contact information: voice, chat, (templated) email, ... that would invoke that particular application.
• links to other sites.
• bookmarkable or savable links (is any link bookmarkable?)

Each page might have comments.