Re: RGSG

[Kai Wetzel <k wetzel welfen-netz com>]

Tom Vogt wrote:
[...]
> > 1)  IBM research--they'll open File up first.
> a) they're used to it
> b) it's the left most thing. ibm research - the leftmost thing will be used
> most often, no matter what the <beep> it's called.

Hmm, will they use the leftmost thing most often,
no matter what the <beep> it contains ?  E.g. if the
menu formerly known as File at position 5 out
of 7 menus, they'll use the contained functionality less
often ?

[...]
> > 3)  What happens in a file?  Input/Output.
> try telling THAT to the secretary.

As an aside ... don't think i/o!  Think filing cabinet.
The file menu is the menu which represemnts the
functionality of the stored work and the present
work.  The destiction between persistent storage
and transient memory is sad, but it's something we
can't fully prevent from beeing present, given todays
"prepare for shutdown" hardware.

Interestingly, the German MacOS calls the mneu
"Ablage" which means something along the lines
of "where you put", "tray", or so :°)

[...]
> step down from your file-centric view. look at the app the way a
> know-nothing user (knu?) sees it.

Hmm, I don't find "file-centric view" a good term -
There was a proposal to shift from an application-centric
view to a document-centric view, but that's another matter.

I agree that the word file, beeing very ambiguous in the
english language as it seems, isn't as good as the
inventors, in front of a bunch of very simple applications,
though.

I would say it's useful to descibe one way of
dealing w/ persistent data, and I agree it's beeing
appropriate less in the future, not more.

common persistent data access categories (roughly):
- file ( load -> modify -> <revert> - submit )
- file cluster (e.g. project-based systems such as an IDE)
- database (simple case: get record(s), modify, submit, very
  flexible, of course )

For the latter two I don't see "File" as a good choice,
it _could_ be used for the first _category_, but I see
the point of using alternatives here, as well.

[...]
> > Settings belong in an *edit* menu, no?  What do you do...you edit
> > settings...
> 
> <sigh>
> 
> forget it.

I happen to agree w/ you here.  It's not a good idea to put
stuff like this into Edit.  The "Edit" menu is just the
"Selection" menu, only shorter :-D  If we used a predicate ->
object order in respect to menus, we could as well use
"change" and put a lot of stuff under that one ;O)  Seriously,
the object -> predicate order (as the basic order used in
the menu structure)* because the possible actions you can
perform on an object is _severely_ limited, unlike in
natural language use.

*some others:
- category -> predicate object
- -> (activate) item
- -> (select) item

kai