Reunify browse and edit modes?

E. E. Mellor writes:
>I have recently been thinking that I would like Amaya to change certain
>factors of its behaviour when in read-only (browsing) mode.  For example,
>following links and pressing buttons could be single-click actions instead
>of double-clicks.  The toolbar could also change.  For example, the save
>button could be replaced by a "home" button.  These features would make
>Amaya more comfortable to use when browsing.  All of the functionality
>could of course be activated or deactivated depending upon the user's
>configuration.

	I think that editing and browsing are close enough so that
having two seperate modes adds more to the complexity of use than the
rearrangement of commands might save.  Seperate browsing and editing
modes may also continually plague people will repeated common mistakes
stemming from thinking that they are in the wrong mode, such as trying
to select an object and accidentally jumping to it.  When I use a
browser, I sometimes want to have edit-like functionality, such as the
ability to copy text from an active area that is going to send me to
some place if I try to select the text with the cursor.  Many web
browser that do not edit have "save" and "save as" commands.  The only
purpose of having seperate view and edit modes is to improve the user
interface, but since the two modes are so close, I think that the
complexity of learning two interfaces more than cancels the
simplification achived by optimizing the each mode to these sepaerate
but similar activities.

	The analogy to view mode in text editors is misleading,
because view mode just disables certain commands rather than rebinding
new commands.

	By the way, I too think that Amaya would be much more
intuitive to use if a plain single click followed the link, instead of
a double click.

	Also, there is the is a semi-political issue here.  As I
understand the situation, the Amaya teams wants to focus on doing
research on editing, while those of us in the peanut gallery (testers,
debuggers, contributors) are motivated by the possibility of Amaya
becoming a great web browser.  Fortunately, most of the infrastructure
needed to make a "what you see is what you get" web editor solid and
useful is what is improved by people fixing and developing the browser
functionality, such as cleaner and faster page layout, improvements to
libwww, support for more imbedded media types--i.e., "what you see."
So, I think that we in the peanut gallery should try to arrange our
contributions so that they improve the editor functionality when they
improve the browser functionality.  Not splitting the user interface
into two modes would probably be helpful in this regard.

	I don't claim to have a "vote" on a somebody else's project,
but here is what I would suggest in the hopes that his idea is helpful:

	o Use shift-click to select a object for editing.  If I move
	  between objects that I am editing, it is pretty deliberate.
	  My hands are already at the keyboard.  This is not the case
	  for browsing.  So, regular click should follow the link.  If
	  the object is not a hyperlink, then regular click selects
	  the object, just like shift-click.

	o Instead of having a button that switches between "Home" and
	  "Save" deending on mode, get rid of the "Browse/Edit" button
	  so you can have both "Home" and "Save" buttons if you want them.

	o In the long run, the key bindings should be configurable and
	  and should even be able to call user defined Java functions.
	  The built-in button bars should probably someday be replaced by
	  HTML+Java too.  Then we could have contests for cool button
	  bars. :-)

	Anyhow, I hope these suggestions are helpful.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

Received on Thursday, 21 January 1999 04:59:50 UTC