You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
642 lines
27 KiB
642 lines
27 KiB
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org" />
|
|
<meta http-equiv="Content-Type" content="text/html" />
|
|
<meta name="Author" content="Tim Berners-Lee" />
|
|
<title>
|
|
Tim Berners-Lee - Consistent User Interface
|
|
</title>
|
|
<link href="di.css" rel="stylesheet" type="text/css" />
|
|
</head>
|
|
<body bgcolor="#DDFFDD" text="#000000">
|
|
<p>
|
|
<a href="../Overview.html"><img alt="W3C" border="0" src=
|
|
"w3c_home.gif" /></a>
|
|
</p>
|
|
<address>
|
|
Tim Berners-Lee
|
|
<p>
|
|
Date: February 6, 1997, updated 9/97
|
|
</p>
|
|
<p>
|
|
Status: personal view. Editing status: Italic text is
|
|
rough. Requires complete edit and possibly massaging, but
|
|
content is basically there.
|
|
</p>
|
|
<p>
|
|
Audience: Those people who asked what I meant by a
|
|
consistent user interface and then said, "Don't just say
|
|
it, write it down!". For software developers in the hope
|
|
that some of this will come true. This has worked
|
|
before. I'm a bit embarassed, as everyone has pet ideas
|
|
about how the UI is frustrating, and listening to them can
|
|
be tedious, I know! Perhaps this is why I haven't written
|
|
this down before.
|
|
</p>
|
|
</address>
|
|
<p>
|
|
<a href="Overview.html">Up to Design Issues</a>
|
|
</p>
|
|
<h3>
|
|
Web Architecture: 5
|
|
</h3>
|
|
<p>
|
|
See also <a href="../Talks/9702ComNet/slide1.htm">ComNet 97
|
|
talk</a>.
|
|
</p>
|
|
<hr />
|
|
<h1>
|
|
Cleaning up the User Interface
|
|
</h1>
|
|
<p>
|
|
Tim BL 6 Feb 97
|
|
</p>
|
|
<p>
|
|
We can talk in the abstract about the sorts of things we'd
|
|
like to do, but it is a wise thought experiment, to imagine
|
|
how the user interface to a more powerful Web would be. So
|
|
here is a an attempt to do that thought experiment. There are
|
|
no screen mockups -- as I said, you have to use your
|
|
imagination.
|
|
</p>
|
|
<h3>
|
|
<a name="Consistency" id="Consistency">Consistency</a>
|
|
</h3>
|
|
<p>
|
|
First of, all, the interface to a universal space should have
|
|
a certain universal consistency. Currently, the user
|
|
interface yu see on your PC or Mac has a few unfortunate
|
|
inconsistencies which make it more difficult to use, and less
|
|
powerful. One is that the "desktop" interface to the file
|
|
system is different from the "browser". (See talk at Boston
|
|
Web Conference WWW4, Dec 1995). It is crazy, if you think
|
|
about it, that the whole screen is use to represent the
|
|
information which happens to be on your local file system,
|
|
using the metaphors of folders, while one window is used to
|
|
represent the information in the rest of the world, using the
|
|
metaphor of hypertext. What's the difference between
|
|
hypertext and a desktop anyway? You can double click on
|
|
things you find in either. Why can't I put folders into my
|
|
hypertext documents? Why can't I write on the desk? Folders
|
|
should be just another sort of document. My home page could
|
|
be one, or it could be a hypertext document. The concepts of
|
|
"folder" and "document" could be extended until they were the
|
|
same, but I don't think that that would be necessarily a good
|
|
idea. It's OK to have differet forms of object for distinctly
|
|
different uses.
|
|
</p>
|
|
<h3>
|
|
<a name="Location" id="Location">Location fixation</a>
|
|
</h3>
|
|
<p>
|
|
The only fundamental difference between a hypertext document
|
|
and a folder is that there is a special relationship between
|
|
any document and the folder where is "is". Unix allows a file
|
|
to be in more than one directory (with hard links) provided
|
|
they are on the same disk. DOS requires a file to be in just
|
|
one directory, which again must be on the same disk. Users
|
|
should not have to worry about what disks files are on.
|
|
Suppose the system just files everything under its creator an
|
|
d its creation date, and the rest of the system is just
|
|
pointers (soft links, hypertext links, shortcuts), Then a
|
|
folder becomes a useful sort of document for helping us
|
|
organize things, but not a container with implications on
|
|
physical storage. The relationship between a folder and a
|
|
file in it becomes just a hypertext link. Ah, consistency!
|
|
</p>
|
|
<h3>
|
|
<a name="Protocol" id="Protocol">Protocol - Smotocol</a>
|
|
</h3>
|
|
<p>
|
|
Another inconsistency is the current strange division between
|
|
mail, browser, and news reader tools. Each have editors. The
|
|
editors are in some cases plain text, and in some cases
|
|
fancier things such as HTML. On the Internet, a mail agent
|
|
allows you to use the Simple Mail Transfer Protocol, a news
|
|
agent allows you to use the Network News Transfer Protocol,
|
|
and a web editor allows you to use the Hypertext Transfer
|
|
Protocol. This is of course totally meaningless to a user.
|
|
From the user's point of view, the mail program allows you to
|
|
move data between mailboxes (folders by any other name) and
|
|
also allows you to link it into someone else's "In" box. I
|
|
say "link" as it creates the relationship "this message (file
|
|
by any other name) is in this mailbox (folder)", which we
|
|
said above should be a link.
|
|
</p>
|
|
<p>
|
|
A news editor allows you to link a news document to a widely
|
|
visible group (box, folder by any other name) which is
|
|
visible to people all over the world. Functionally, it is
|
|
very like mailing something to a list of people, as it
|
|
creates links to the document from groups in each of their
|
|
news readers.
|
|
</p>
|
|
<p>
|
|
A web editor allows you to upload a document into a web
|
|
server, though the way in which you do that varies. (The
|
|
original meaning of the HTTP "put" operation was to have been
|
|
a very equivalent "make new document and make link from this"
|
|
operation.)
|
|
</p>
|
|
<p>
|
|
Now suppose you want to create a bit of information and you
|
|
want to link it from a few individual's "in" boxes, a few
|
|
news groups and a few hypertext documents. You also want it
|
|
to show up in various folders. Which application should you
|
|
use?
|
|
</p>
|
|
<p>
|
|
Clearly, this is a choice which the user should not have to
|
|
make. Conceptually, a number of links are being made. In
|
|
practice, various protocols will be used by the system. In
|
|
the future, combined protocols may exist which efficiently
|
|
perform all these functions as appropriate. Let's not bother
|
|
the user with this. When I create an object, I want to pick
|
|
the type of object I am creating. I also think it is
|
|
reasonable, if anyone else is going to have access to the
|
|
object, for me to specify the access list and the
|
|
distribution terms: I am controlling my new intellectual
|
|
property. It is also useful for me to specify what sort of
|
|
quality of storage I want for the document. Do I want it
|
|
archived reliably for posterity? Do I want it instantly
|
|
available very rapidly and reliably? The answers to these
|
|
questions will determine where the system will store my data.
|
|
The last thing I want to be asked is the filename.
|
|
</p>
|
|
<p>
|
|
The "save as" filename dialog box is one of the things
|
|
currently holding up our civilization. It doesn't ask the
|
|
right information from the user. It asks it not when you are
|
|
creating the document (and thinking about it at that high
|
|
level) but when you have finished and are about to do (and
|
|
thinking about) something else. [See <a href=
|
|
"http://www.cooper.com/articles/vbpj_secondary_storage_dilemma.html">
|
|
Cooper on this</a>]. As you move information from your head
|
|
into a computer, everything can be intuitive until this step
|
|
asks you to think of the disks and the operating system.
|
|
</p>
|
|
<table border="1" cellpadding="2">
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
Creators of documents should be able to specify
|
|
<ul>
|
|
<li>Access lists and distribution terms
|
|
</li>
|
|
<li>Quality of storage
|
|
</li>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>
|
|
Of course, I won't want to be negotiating each of these
|
|
parameters every time I create a new object, so probably I
|
|
will have a set of templates, standard genres of document,
|
|
for which these things have been set. In the case of HTML
|
|
files, I will probably want to associate a default content
|
|
and a default style sheet with each template. This will make
|
|
it easier for me and for my readers to get an intuitive feel
|
|
for the access and archival status of documents at a glance.
|
|
</p>
|
|
<p>
|
|
I will get back a URI from this operation. The quality of
|
|
storage is part of the agreement between me, as a creator of
|
|
an object, and the service I use to create and support that
|
|
URI.
|
|
</p>
|
|
<p>
|
|
Sure, people like to pick URIs so that they can be mnemonic.
|
|
I don't mind that. The problem is when the URIs are picked so
|
|
that it is difficult to support them in the future. (See the
|
|
section on naming, and HTTP PUT).
|
|
</p>
|
|
<p>
|
|
Let's assume that this inconsistency will be dealt with in
|
|
future.
|
|
</p>
|
|
<h3>
|
|
<a name="Signing" id="Signing">Signing: From Documents to
|
|
Deeds</a>
|
|
</h3>
|
|
<p>
|
|
So the consistent user interface we have so far is one in
|
|
which we are at home with documents and links, and we
|
|
communicate by massaging the documents and the links.
|
|
The whole thing is "quasi-static" -- at any one time
|
|
you can believe you understand a part of it. It has
|
|
state. When you change its state you can see what you are
|
|
doing.
|
|
</p>
|
|
<p>
|
|
That's not enough. It's not enough because in this
|
|
model everything is malleable: every document is a "living"
|
|
document. Everything can change. This is great for an
|
|
encyclopaedia but its no good for a check book. It
|
|
contains description, but because action is represented only
|
|
in the limited constrained form to those actions which can be
|
|
viewed as changes of state, there are things we just can't
|
|
do. We can do idempotent actions -- those which are just as
|
|
good if you do them twice as if you do them once. This
|
|
doesn't work for paying bills.
|
|
</p>
|
|
<p>
|
|
We can introduce actions which count (or if you like,
|
|
"actions which you can count") in two ways which boil down to
|
|
the same thing. One way is for us to enrich the concept
|
|
of operations on the net from "GET", "PUT" and "LINK" to a
|
|
whole plethora of different functions. We would
|
|
probably divide were sources by their object "class", which
|
|
would define what set of operations are available for each
|
|
resource. This is the familiar world of distributed object
|
|
oriented programming.
|
|
</p>
|
|
<p>
|
|
The second way is that we would allow, in the user interface,
|
|
documents to be signed. A signature on paper is a
|
|
special thing (in principle). It is a countable
|
|
operation. You make a signature on the document and it
|
|
becomes something different. No longer duplicatable at
|
|
will, you act of signing is caught -- and you can be held to
|
|
it. The document becomes something which has been done:
|
|
a <b>deed</b>. This is the familiar world of legal process.
|
|
On the web, it happens when you press a "submit" button
|
|
and your order is submitted to the mail order company. When
|
|
you make a document into a deed, it freezes. You can't
|
|
change deeds. You can revoke them or cancel them out
|
|
with other deeds, but you can't change one. Deeds are not
|
|
living documents. In fact, lots of documents are in
|
|
practice frozen in that they aren't going to change much.
|
|
But they may not be deeds: noone has explicitly made an
|
|
action on them.
|
|
</p>
|
|
<p>
|
|
The two forms are equivalent, as when you make a deed, you
|
|
can in the document write the name and parameters of any
|
|
function you want executed, and submit it to a remote
|
|
operation agent. Similarly, whenever a remote non-idempotent
|
|
operation is made using some Remote Procedure Call
|
|
protocol, in practice the protocol involves making some
|
|
message up containing the parameters, and directly or
|
|
indirectly putting on it some sequence number or identifier
|
|
to prevent it from being accidentally operated on twice.
|
|
Both are abstract representations of a commitment, and
|
|
action which counts.
|
|
</p>
|
|
<p>
|
|
As we're talking about user interface here, I'd like to see a
|
|
clean interface for making a deed, which makes it quite clear
|
|
to me that I am committing something, and not just doing
|
|
another search. I suppose I have a set of "rubber
|
|
stamp" icons which leave a name/date stamp on a document.
|
|
Different stamps can be made with different levels of
|
|
security. They may represent actions by different
|
|
people, different roles, with different levels of authority.
|
|
I guess I'd have one for stamping W3C Recommendations
|
|
which have been though the process, and a totally different
|
|
one for ordering medium sized purchases on my credit card.
|
|
</p>
|
|
<p>
|
|
Deeds don't have to be signed digitally (but it helps).
|
|
Every time you press "send" in your email you are
|
|
making a deed. The document freezes. You may even be
|
|
digitally signing it. You lose control -- you can't take it
|
|
back.
|
|
</p>
|
|
<p>
|
|
Socially, we will have to accept electreonic deeds. Also, we
|
|
will have to define the limits of commitment which someone
|
|
can imply by changing living documents without explicitly
|
|
making a deed.
|
|
</p>
|
|
<p>
|
|
@@@@
|
|
</p>
|
|
<h3>
|
|
<a name="OhYeah" id="OhYeah">The "Oh yeah?" button</a>
|
|
</h3>
|
|
<p>
|
|
See also WWW4 Boston talk.
|
|
</p>
|
|
<p>
|
|
Deeds are ways we tell the computer, the system, other
|
|
people, the Web, to trust something. How does the Web
|
|
tell us?
|
|
</p>
|
|
<p>
|
|
It can happen in lots of ways but again it needs a clear user
|
|
interface. It's no good for one's computer to be aware
|
|
of the lack of security about a document if the user can
|
|
ignore it. But then, most of the time as user I want to
|
|
concentrate on the content not on the metadata: so I don't
|
|
want the security to be too intrusive. The machine can check
|
|
back the reasons why it might trust a document automatically
|
|
or when asked. Here is just one way I could accept it.
|
|
</p>
|
|
<p>
|
|
At the toolbar (menu, whatever) associated with a document
|
|
there is a button marked "Oh, yeah?". You press it when
|
|
you loses that feeling of trust. It says to the Web,
|
|
"so how do I know I can trust this information?". The
|
|
software then goes directly or indirectly back to
|
|
metainformation about the document, which suggests a number
|
|
of reasons. These are like incomplete logiocal proofs. One
|
|
might say,
|
|
</p>
|
|
<blockquote>
|
|
"This offer for sale is signed with a key mentioned in a list
|
|
of keys (<i>linked</i>) which asserts that tthe Internet
|
|
Consumers Association endoses it as reputable for consumer
|
|
trade in 1997 for transactions up to up to $5000. The list is
|
|
signed with key (<i>value</i>) which you may trust as an
|
|
authority for such statements."
|
|
</blockquote>
|
|
<p>
|
|
Your computer fetches the list and verifies the signature
|
|
because it has found in a personal statement that you trust
|
|
the given key as being valid for such statements. That is,
|
|
you have said, or whoever your trusted to set up your profile
|
|
said,
|
|
</p>
|
|
<blockquote>
|
|
"Key (value) is good for verification of any statement of the
|
|
form `the Internet Consumers Association endoses page(p) as
|
|
reputable for consumer trade in 1997 for transactions up to
|
|
up to $5000. '"
|
|
</blockquote>
|
|
<p>
|
|
and you have also said that
|
|
</p>
|
|
<blockquote>
|
|
"I trust for purchases up to $3000 any page(p) for which `the
|
|
Internet Consumers Association endoses page(p) as reputable
|
|
for consumer trade in 1997 for transactions up to up to
|
|
$5000."
|
|
</blockquote>
|
|
<p>
|
|
The result of pressing on the "Oh, yeah?" button is either a
|
|
list of assumptions on whcih the trust is based, or of course
|
|
an error message indicating either that a signature has
|
|
failed, or that the system couldn't find a path of trust from
|
|
you to the page.
|
|
</p>
|
|
<p>
|
|
Notice that to do this, we do not need a system which can
|
|
derive a proof or disproof of any arbitrary logical
|
|
assertion. The client will be helped by the server, in that
|
|
the server will have an incentive to send a suggested proof
|
|
or set opf possible proof paths. Therefore it won't be
|
|
necessry for the client to search all over the web for
|
|
the path.
|
|
</p>
|
|
<p>
|
|
The "Oh, yeah?" button is in fact the realively easy bit of
|
|
human interface. Allowing the user to make statements above
|
|
and understand them is much more difficult. About as
|
|
difficult as programming a VCR clock: too difficult. So
|
|
I imagine that the subset of the logic language which is
|
|
offered to most users will be simple: certainly not Turing
|
|
complete!
|
|
</p>
|
|
<h3>
|
|
Programming the space: Macros by example.
|
|
</h3>
|
|
<p>
|
|
@@@ TBD
|
|
</p>
|
|
<h2>
|
|
<a name="Specific" id="Specific">Specific notes</a> on
|
|
Windows UI and Typical Web browsers
|
|
</h2>
|
|
<p>
|
|
(1997)
|
|
</p>
|
|
<p>
|
|
The gist of it is the need for greater consistency in the UI
|
|
and the underlying system.
|
|
</p>
|
|
<h3>
|
|
Consistency
|
|
</h3>
|
|
<p>
|
|
Some basic principles:
|
|
</p>
|
|
<p>
|
|
1. Anything of any value and persistence must have a URI so
|
|
that it can be referenced (yes, I know Microsoft have a
|
|
Moniker scheme but now it has to be URIs to go global).
|
|
</p>
|
|
<p>
|
|
2. Any place I can use a URI I can use any URI.
|
|
</p>
|
|
<p>
|
|
3. Links are an evident as a primary user interface metaphor,
|
|
with a consistent drag/drop or control/drag/drop for link
|
|
creation, and consistent ways of viewing by link type.
|
|
</p>
|
|
<p>
|
|
4. The system should generate persistent URIs wherever
|
|
possible. These can be just URLs in file or http space but
|
|
they should not change. This is a longer term thing.
|
|
</p>
|
|
<p>
|
|
5. Things like start menus, bookmarks, favorites, recent
|
|
document lists, toolbars, should be viewable as discreet
|
|
objects in familiar ways. A Good Thing is the ability to
|
|
easily see and manipulate the start menu in Explorer (right
|
|
click Start). A Bad Thing is a modeful "organize favorites"
|
|
dialog box is the most inconsistent outdated constraining way
|
|
of moving things around I have seen in a while. A
|
|
modeless "Goto bookmarks" is better, but
|
|
</p>
|
|
<p>
|
|
I propose that any set or hierarchical structure should have
|
|
a consistent windows explorer interface. You clearly feel
|
|
that anything which is a set can also have an HTML view. In
|
|
that case, I want HTML views of everything. Look at al the
|
|
containers we have:
|
|
</p>
|
|
<ul>
|
|
<li>Deskto
|
|
</li>
|
|
<li>Folder
|
|
</li>
|
|
<li>Start menu
|
|
</li>
|
|
<li>Toolbars
|
|
</li>
|
|
<li>Web pages
|
|
</li>
|
|
<li>Mailboxes
|
|
</li>
|
|
<li>Bookmarks
|
|
</li>
|
|
<li>Favorites
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
These must have consistent interfaces.
|
|
</p>
|
|
<p>
|
|
Some of these we can do without. Favorites, most of the Start
|
|
Menu, and mailboxes are all ways of classifying things. They
|
|
should all basically have the same interface and frankly I
|
|
don't see the need for them being different. I want to put my
|
|
inbox in my start menu. I want to be able to chose whether
|
|
something I put in a menu is terminal or expanded. In
|
|
general. (I could always put a link to the Favorites folder
|
|
into the start menu but it wouldn't be expanded as a menu.
|
|
I'd like general control over menus.
|
|
</p>
|
|
<p>
|
|
(Examples of things I want to do: Bookmark mail messages of
|
|
interest, indeed any object. Save a web page in a
|
|
mailbox (which would freeze it in the cache and keep a
|
|
pointer to it)
|
|
</p>
|
|
<p>
|
|
...
|
|
</p>
|
|
<p>
|
|
)
|
|
</p>
|
|
<p>
|
|
Dialog boxes are as we really know bad UI. The "Save As" and
|
|
"Open" dialog boxes are a pain (I always want to be able to
|
|
delete and rename files in them) because the are constraining
|
|
and inconsistent, and they block until you get out. I'd be
|
|
happy for an open box to simply launch an explorer window or
|
|
select a current one, while providing a receptacle for icons
|
|
which are to be opened. I'd like that receptacle (which is
|
|
just the application icon) to be a URI I can save in any of
|
|
the containers above.
|
|
</p>
|
|
<p>
|
|
The history list should of course be a something which works
|
|
across all applications. A time-based view is a neat history
|
|
lis, but it should apply across everything I have done in any
|
|
applicationt. Make it generic so it works on any object. Make
|
|
the index of everything I have done (maybe my whole click
|
|
stream) be available as such an object, to be viewed just
|
|
like a mailbox. I should even be able to make a link into it.
|
|
</p>
|
|
<h3>
|
|
Maito: addresses
|
|
</h3>
|
|
<p>
|
|
A mailto address is a misnomer (my fault I feel as I didn't
|
|
think when we created it) as it is not supposed to be a verb
|
|
"start a mail message to this person", it is supposed to be a
|
|
reference to a web object, a mailbox. So clicking on a link
|
|
to it should bring up a representation of the mailbox. This
|
|
for example might include (subject to my preferences) an
|
|
address book entry and a list of the messages sent to/from
|
|
[Cc] the person recently to my knowledge. Then I could mail
|
|
something to someone by linking (dragging) the mailbox icon
|
|
to or from the document icon.
|
|
</p>
|
|
<h3>
|
|
Modularity: MIME types and Operations
|
|
</h3>
|
|
<p>
|
|
The OS as a concept is currently having trouble with
|
|
modularity -- the module used to be an application which
|
|
provided its own communication and document types. Now the
|
|
MIME types are orthogonal. I see new applications as either
|
|
producing new mime type support or new link functionality (or
|
|
both) but separably.
|
|
</p>
|
|
<p>
|
|
I should be able to mail anything. Suppose I am editing a
|
|
photo. The tool bars are photo editing toolbars. WhenI want
|
|
to mail it, I find the person I want to mail it to (any way:
|
|
not from an adders book forcibly -- I can put my friends in
|
|
my start menu or anywhere or of course find them on the web).
|
|
I drag the document onto the person icon. Now that
|
|
relationship gives me a choice (To, Cc, etc), and I will now
|
|
get an extra toolbar for controlling the mail options. If I
|
|
drag it to a newsgroup, the functionality will be exactly the
|
|
same though the options may be different. I can then the
|
|
links from the message by type (To, Cc, newsgroup, embedded
|
|
hypertext link, version info, etc etc) in a consistent way. I
|
|
regard dragging the icon of the document to a folder as being
|
|
making a link too. The system should stop regarding folders
|
|
as where things are stored. That has got to be decoupled, to
|
|
separate the logical thing (I classify this as important
|
|
travel) from the physical thing (I put this on drive C:).
|
|
That is going to be a steady change, but early simple steps
|
|
are
|
|
</p>
|
|
<ul>
|
|
<li>allow the user to specify the algorithm for defining the
|
|
filenames for new objects of each type, when defining
|
|
templates, with a macro like<br />
|
|
http://my.co.com/BY/<user>/<yymm>/NOTE/<seq>.txt
|
|
</li>
|
|
<li>give a good default set of macros which will result in
|
|
filenames which don't have to change later
|
|
</li>
|
|
<li>ask when defining the template or creating a file without
|
|
a template for a storage quality which will determine in the
|
|
short term the filename and in the long term a way in
|
|
which the system will duplicate, backup and distribute the
|
|
document
|
|
</li>
|
|
<li>ask at the same time for a default Acess Control List for
|
|
the template.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
When I hit "Send" or "Commit", then the document is frozen,
|
|
and the mail engines and NNTP software [and version
|
|
control software] starts to actual implement the links,
|
|
and the web server allows appropriate access. All this is
|
|
under the hood, which you can lift to see how its getting on
|
|
if you like.
|
|
</p>
|
|
<h3>
|
|
Archival and Access levels
|
|
</h3>
|
|
<p>
|
|
This storage quality is a common parameter which I want to be
|
|
able to change for anything. For example, I may decide that a
|
|
web page or a newsgroup article I want to have on a "personal
|
|
archive" availability. S I just change it with a menu item.
|
|
No "Save As". No filenames. It has a URI already. And then I
|
|
know it will always be available to me on my desktop
|
|
and laptop. Just like that.
|
|
</p>
|
|
<p>
|
|
The two toolbars of persistence level (think of name for
|
|
that) and access level are so important they deserve
|
|
space maybe in that space to the R of the menu bar, or in
|
|
window title banner. At least in icon form. I don't expect to
|
|
have many combinations of them once I have customized the
|
|
combinations I need with the archive and access wizard.
|
|
</p>
|
|
<p>
|
|
The archive status includes important flags for disconnected
|
|
working -- is this object to be replicated and if so how
|
|
often, etc.
|
|
</p>
|
|
<h3>
|
|
Disconnected operation
|
|
</h3>
|
|
<p>
|
|
The system has got toknow what its connectivity is at any
|
|
time. Without a reboot! I would like this to be a switch
|
|
available across the board, switching IPs and diconnected
|
|
operation.
|
|
</p>
|
|
<hr />
|
|
<p>
|
|
<a href="Overview.html">Up to Design Issues</a>; On to
|
|
<a href="Editor.html">Editing interfaces</a>
|
|
</p>
|
|
<p>
|
|
$Id: UI.html,v 1.5 2009/08/27 21:38:09 timbl Exp $
|
|
</p>
|
|
</body>
|
|
</html>
|