---

Message-Id: <199603112109.WAA08144@www42.inria.fr>
From: Bert Bos <Bert.Bos@sophia.inria.fr>
Subject: Re: tamaya tigers
Date: Mon, 11 Mar 1996 22:09:39 +0100

Today is the closing day for submission of Tamaya GUI ideas. If you have any ideas, no matter how wild, neat, controversial, obvious, radical or un-implementable, please send them as soon as possible. Since no mail-into-HTML system seems to have been set up, send them to me, to this list, or anywhere where I will see them.

I will collect and compare the ideas and on Thursday the Sophia team will try to formulate a strategy and a few mock-ups for the GUI that we can present to the Grenoble team.

So, for the record, here are my notes:

• edit-mode versus browse-mode: the one should not suffer under the other. So, if the conflicts cannot be resolved, an explicit mode switch is better.
• if a double click is needed to hyper-jump (because single click is used as a cursor-positioning command), then that is OK with me. But: some people have trouble with pressing the buttons fast enough without moving, so an alternative must be provided as well, such as shift click, or a keyboard equiv.
• on the other hand, double click, triple click, etc. are useful for selecting words, lines (or paragraphs?), etc. as well...
• the default when should be to display a new document in the same window, but opening an extra windows should be possible as well.
• the above could cause the user to loose track of the pages with unfinished edits, so they should stay on screen in reduced form, such as in tabs along the top or side, or as thumbnails on a virtual `shelf'.
• cursor keys should position the cursor in the visual domain, not in the underlying tree.
• but navigating the tree should be only slightly more difficult, e.g., with ALT + cursor key.
• shift + cursor keys are a common way of selecting text, as an alternative to drag-select.
• common operations should have a button-bar equivalent: emphasis, strong, headers, lists, table, color, save, open...
• bold and italic should not be among those easily accessible commands.
• but it would be nice if the button-bar were customizable.
• if there are two modes, edit and browse, then the presence of the button-bar could be the visible indicator of edit-mode.
• zoom buttons
• a structure view (tree-like) in an optional pane of the window
• user must be able to click on the structural view and have the main (WYSIWYG) view scroll to that element, and vice versa
• a click on an element in the structural view selects that element
• minimize the number of dialog boxes
• setting a style for a number of elements at the same time should be possible, as long as the style makes sense. E.g., setting a selected text to bold, even though the selection spans a number of elements.
• process for setting a style:
  1. select whatever you want to set a style to, by drag selecting a range of text, or selecting one or more elements
  2. set the style (see below for methods)
  3. if the selected text didn't correspond exactly to existing elements, insert a SPAN with an ID and add the style rules to the style sheet. Otherwise, ask the user if the style is for these element instances only, or for a class of instances, or for all instances of these elements. (ID's are created automatically, if needed.)
• method for setting a style: open a dialog box with all style options, possibly divided into tabbed-groups. This could be under the right mouse button (on a 3-button mouse) as well as in a menu. There would be a row of radio buttons at the bottom: apply to all instances of this element/these elements (default), apply to class of elements (with combo box for name of class), apply to this instance only.
• the dialog could have a `preview' or `apply' button, as well as an `OK', so that the effects can be seen without having to exit and restart the dialog each time.
• the dialog box also has an area at the top where the selected elements (the elements this style applies to) can be changed, by widening the selection to an ancestor, or by adding/replacing an unrelated element. If the user changes this field, the option at the bottom `apply to this instance only' will be grayed out.
• many DTP programs have a ruler and buttons for font and alignment in the button bar, but this doesn't seem to fit with the structured model: when the user clicks one of these, does it apply to the selected text (or the yet to be typed text), or generically to the current element or the current class. Popping up a dialog box to ask for this doesn't seem like a good idea...
• maybe these button-bar options should only apply to one instance, and the style dialog-box is better (and enough?) for setting generic styles.
• adding a source anchor can be done in two ways: first select the source and then the target, or the other way round. Since I don't know which is more intuitive, maybe we should support both:
  1. select the source anchor (drag-select or otherwise)
  2. make it into an A element (pop-up menu under 3rd button, button-bar, menu item)
  3. a dialog pops up, asking for a URL (combo-box, with current hotlist and other previously seen URL's) or a click in any window, or a drag-select in any window, in order to create a target anchor there.
  or:
  1. select the target anchor (a piece of text, an element, or a whole document) and drag it to the word that is to become the source anchor. By default, one word will be the source anchor, but there will have to be a way to extend the source anchor over several words.
• splitting an element should be easy (return key?)
• joining two elements can be a menu item
• inserting an element must have a keyboard equivalent: Ctrl-I ?
• it would be nice if cut and paste could be done by selecting and then dragging the selected text somewhere else.
• remote save (PUT method)
• resizing an image by direct manipulation. Should the default be to keep the aspect ratio? Maybe dragging one margin keeps the aspect ratio, while dragging a corner doesn't. Or shift plus mouse button keeps aspect ratio, while normal drag doesn't...
• should there be a limit to the number of documents that can be edited concurrently?
• cut and paste should try to keep as much of the structure of the copied text as possible.
• setting attributes directly shoul dnot be necessary, everything that is controlled by attributes can probably be set in WYSIWYG, Direct Manipulation mode.
• which is better: `add a class', `add to class', `apply a class', when adding a CLASS attribute to an element?
• should we ever create in-line STYLE sheets? or STYLE attributes?
• 3 possibilities: private style sheet, import an existing style sheet but add private overrides, use existing style sheet and modify it. When and how should this choice be made?

  Problem: the editor doesn't know if a linked style sheet is used by other documents or not... (should it insert whatever it knows about a style sheet in the style sheet itself, in a structured comment somewhere?)

  1. when the document is opened (or possibly when the style is edited for the first time), a dialog box appears, forcing the user to make this choice. This box can also be used to enter the name (or URL) of a (the) style sheet(s).
  2. the style dialog box has radio buttons that let the user make this choice every time he edits a style.
  3. always create a private, unnamed style sheet in the STYLE element, but provide commands to `@import' an existing style sheet and to name (and save) the style sheet for reuse elsewhere.
• how do you make sure that generated ID's are unique over all documents that share a style sheet, if you can't know what those other documents are? a 32-bit random number should be good enough (if it is random enough). Some hash of the document's URL might do the trick as well. However, the URL might change if the user does a Save-As, forcing a renaming of all ID's.
• adding several style sheets to one document: a menu item `add (or: start, create) another style sheet', leads to a dialog box with a combo-box for a style sheet name and a toggle `this is default style yes/no'.
• overwrite mode needed? (I almost never use it; and when I do, I invariably press backspace or delete by mistake, so that I have to go back to insert mode to fix it)
• provide a few style sheet templates, to be used as a starting point: slide style, plain style, technical report style, prose (book) style.
• auto-save at regular intervals (our software doesn't crash, but the OS might :-) )
• allow private annotations or a To-Do list.
• maybe have the browser add things to the to-do list automatically, whenever a target anchor is removed or a source anchor is created without filling in its target.
• collection management? such as: use link types to print a hierarchical collection; navigate such a collection; check consistency of links in a collection (or check all outgoing links); when a document is saved under a new name, modify all relative URL's (or offer to move the linked documents as well?);
• should hotlist be an HTML document? I don't see the need
• should hotlist be called `bookmarks'?
• a `hotlist' of styles in addition to the normal hotlist
• a hotlist of images as well?
• history list: what happens when the user presses `back'? what happens when the user presses back after having gone back and then somewhere else? what happens when the user reaches a document that he has seen before?
  1. there is a forward button; so after having gone back, the user can go forward again.
  2. 1. after going back and then sideways, all forward information is lost (as it is in most current browsers)
     2. idem, but the history mechanism is smart enough to recognize when the new document is the same as the forward document, and doesn't throw away the forward info in this case.
     3. the existing forward information is turned into a side track, no longer available with back/forward, but accessible through the history display, which shows the history as a cactus-tree.
• a new window starts with an empty history?
• a new session starts with an empty history? or is there a persistent, global history?
• characters that are not on the keyboard can be selected from a palette.
• maybe the user should be able to assign these special symbols to unused keys.
• styles can be set for speech (not WYSIWYG:-) )
• act as OLE client under Windows (maybe also as OLE server?)
• customizations: default start-up page, button-bar, default start-up size, default zoom factor, some key assignments.
• toggle between paged display and scrolled display. (Paged mode might be scrolled as well, but it shows the page breaks in some way.)
• import Netscape & Microsoft extensions, but silently convert them to a style sheet.
• try to repair imported documents, using some kind of minimum changes algorithm, and show the errors
  1. save original somewhere? keep incorrect attributes if they are ignored anyway?
  2. beep when an incorrect document is repaired? (In that case, there must be an option to turn the beep off.)
  3. show flag `bad HTML' in a corner (until the user edits or saves the document, after which it is no longer incorrect)
  4. show errors and corrections with color in the source view.

[more to come...]

Bert

-- 
 Bert Bos ( W 3 C ) http://www.w3.org/
 bert@w3.org INRIA project RODEO/W3C
 http://www.w3.org/pub/WWW/People/Bos/ 2004 Rt des Lucioles / BP 93
 +33 93 65 77 71 06902 Sophia Antipolis Cedex, France

---