[9fans] acme: some thoughts about design

[9fans] acme: some thoughts about design

[cej]

Hi, there!

First... I love Acme's design: chording, no-menus, etc... Nothing pops up, or falls at me, etc,etc...

The thing I don't like [very much] is taglines [as a place for commands]:
they waste screen space, show redundant info (same commands all the time)
couldn't we have a *single* command 'window'[==acme's frame, not rio window]
which would behave much like tagline: show current window's tag plus list of predefined/pasted commands
this would save space on screen, and [IMHO] would bemore elegant solution.
Another frame with [sorted] listing of window tags could ease navigation...

would love also to have acme as an optional universal glue for programs,
eg., Edit functions could move outside to [something like a commandline]Sam (enhanced sed) that would 
then use Acme's frame to display files...

Just a prick in a wasp's nest, I feel, but I would love 
to hear from you, even if [especially if] I missed the point! Don't shoot me.

No need to say that implementation is far, far beyond my skills :-(((


Sincerely yours,
++pac.

Re: [9fans] acme: some thoughts about design

[Matthias Teege]

> The thing I don't like [very much] is taglines [as a place for commands]:
> they waste screen space, show redundant info (same commands all the time)
> couldn't we have a *single* command 'window'[==acme's frame, not rio window]

A "command window" introduce a mode. It's better If you can
input a command in any place and execute it with a "execute key" like
acme does.

Matthias

Re: Re: [9fans] acme: some thoughts about design

[Russ Cox]

> > The thing I don't like [very much] is taglines [as a place for commands]:

if you don't want to use the taglines for commands, don't.

the taglines are necessary -- how else would you know
which file was which?  putting extra stuff in them that can
be ignored seems like an efficient use of space, not a waste.

Re: Re: [9fans] acme: some thoughts about design

[Matthias Teege]

On Sat May 29 15:09:51 GMT 2004, russcox@gmail.com wrote:
> the taglines are necessary -- how else would you know
> which file was which?  putting extra stuff in them that can

Don't use files ;-) It is a computer task to save my input but
I dont understand why I must tell the computer where to store.

If I have a usefull search interface I didnt need any filename or
directory structure. A user isn't interessted in filesystems.

Matthias

Re: Re: [9fans] acme: some thoughts about design

[9nut]

> Don't use files ;-) It is a computer task to save my input but
> I dont understand why I must tell the computer where to store.

Obviously a failure of vision on Rob's part!  ☺

It is an interesting thought that has come up before in various
contexts (look at the discussion about annotated filesystem in the
archives) but I don't see how this applies to Acme tags.

Put (was: [9fans] acme: some thoughts about design)

[FODEMESI Gergely]

On Sat, 29 May 2004 9nut@9netics.com wrote:

> > Don't use files ;-) It is a computer task to save my input but
> > I dont understand why I must tell the computer where to store.

Even in 1997 I met people who thought, that a user should not be obliged
to know when, where and what to save or that the concept of saving should
exist at all. (A real visionary might have thought about this probably
decades ago.)

> Obviously a failure of vision on Rob's part!

Put might have come from an idea like above (ie. "save" is not the best
way to express the real need), or it was just shorter than "Save".

 gergo

Re: Re: [9fans] acme: some thoughts about design

[Tristan Seligmann]

On Mon, May 31, 2004 at 14:46:04 +0900, YAMANASHI Takeshi wrote:
> > > mithrandi, i Ainil en-Balandor, a faer Ambar
> > Translation?
>
> I'm not a native of the language, but it could be like this:
> 	grey pilgrim, the goddes in the land of god, a sprit of the earth

That translation should suffice :)

--
mithrandi, i Ainil en-Balandor, a faer Ambar

Re: Re: [9fans] acme: some thoughts about design

[a]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1258 bytes --]

i don't think anybody's seriously questioning the general
utility of search capabilities. but the directed graph we
currently have is very useful for all sorts of things. it
is, for example, a very "natural" (but see later) layout
for source trees and related documentation.

i really like (and have for a while) the "tagging" idea
(although i don't think i ever thought to call it that).
it's still active on the part of the user (which i like,
but folks interested in having the idea of saving go away
likely won't), and organizes things based on ideas the
user has about the document, not arbitrary search.

there is no "natural" way to store files on a computer.
our brains weren't designed for it. any scheme we come up
with to store them runs smack up against that. we can try
to find useful ways that we can adapt easily to, but that
really is the best we're getting. and be very careful
about choosing what seem to be "natural" ways to store or
organize stuff - read "The Anti-Mac Interface" or any of
the many papers on how the desktop metaphor seriously
limits the utility of an interface.

i can't find the attribution just now, but "the only
intuitive user interface is the nipple. after that, it's
all learned."
ÎÐÉ

Re: Re: [9fans] acme: some thoughts about design

[YAMANASHI Takeshi]

> > mithrandi, i Ainil en-Balandor, a faer Ambar
> Translation?

I'm not a native of the language, but it could be like this:
	grey pilgrim, the goddes in the land of god, a sprit of the earth
--
Namaarie

Re: Re: [9fans] acme: some thoughts about design

[Joel Salomon]

dvd@davidashen.net said:
> http://www.gmail.com/

Which nobody can test without an explicit invitation (hint, hint), but
columnists who have it say they like it (forget who at the moment).

--Joel

Re: Re: [9fans] acme: some thoughts about design

[Joel Salomon]

Tristan Seligmann said:
> Maybe not a search engine, but even something like being able to "tag" a
> document with various categories etc. and then being able to view files
> matching a combination of tags would be more powerful than "just" an
> HFS.

Hans Reiser, in "Name Spaces As Tools for Integrating the Operating System
Rather Than As Ends in Themselves" http://www.namesys.com/whitepaper.html
has some interesting thought along those lines, where "paths" can be
semi-structured:
 [subject/[illegal strike] to/elves from/santa document-type/RFC822
ultimatum]
unstructured:
 [santa illegal strike ultimatum elves]
or completely structured:
[subject/strike to/elves from/santa document-type/RFC8221]

he says:
> [this last] query is structurally equivalent to a relational query. Many
> authors (e.g. semantic database designers) have written papers with good
> examples of standard column names which might be worth teaching to users.
> So long as they are an option made available to the user rather than a
> requirement demanded of the user, the increased selectivity they provide
> can be helpful.

He's likely to implement under linux first, but this idea really needs its
own OS to realize fully.

<ramble>
Automatic indexing of a file system is another idea that could be useful -
maybe atop venti, along with fossil? some program to index blocks as they
are written to venti and associate the index block with the data block.
Get access permissions from fossil. Get fancy and check file types
(file(1)), and have specialized indexers for different types (though M$
has a couple of patents you'd likely be stepping on here). Probably good
for a master's thesis in computer science.
</ramble>

> mithrandi, i Ainil en-Balandor, a faer Ambar
Translation?

--Joel

Re: Re: [9fans] acme: some thoughts about design

[Tristan Seligmann]

On Sun, May 30, 2004 at 01:59:21 +0200, boyd, rounin wrote:
> > The problem is, if I want to associate a file with, say, "computers" and
> > "vaccuum cleaners", how do I layout my filesystem?
>
> organisation?  smarts?
>
> reverting to a serach engine is excessive.

Maybe not a search engine, but even something like being able to "tag" a
document with various categories etc. and then being able to view files
matching a combination of tags would be more powerful than "just" an
HFS.

--
mithrandi, i Ainil en-Balandor, a faer Ambar

Re: Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> The problem is, if I want to associate a file with, say, "computers" and
> "vaccuum cleaners", how do I layout my filesystem?

organisation?  smarts?

reverting to a serach engine is excessive.

oh, i can't find my remote control ... hmm, better find it with a search engine.

Re: Re: [9fans] acme: some thoughts about design

[Tristan Seligmann]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Sun, May 30, 2004 at 00:48:40 +0200, boyd, rounin wrote:
> > really has 1 or 2
> 
> run du -a lately?

The problem is, if I want to associate a file with, say, "computers" and
"vaccuum cleaners", how do I layout my filesystem? (let's say the file
is a write-up about computer-controlled vaccuum cleaners)

> > It may be a great low-level implementation, but being
> > able to say "find the e-mail I wrote to Timothy last week" is a lot more
> > useful to the user.
> 
> really?  mbox/Timothy/* or mbox/Timothy/YYYY/MMDD/*

Ok, now what about "all work-related e-mail I wrote about cars last
month"?

All of these queries can be "displayed" via a hierarchical file view,
but not simultaneously; you could of course build multiple "views" using
symlinks or unions or similar, but that's what I'd consider
"higher-level".

-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

[-- Attachment #2.1: Type: text/plain, Size: 333 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/pgp-signature; name="signature.asc"
	Content-Description: Digital signature
	Content-Disposition: inline

[-- Attachment #2.2: signature.asc.suspect --]
[-- Type: application/octet-stream, Size: 196 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAuSMzpNuXDQIV94oRAniKAJ9JFHoi3LyNeERKi08yEEV5zum5AgCeO3cR
LQwylAh3aXdh8VPYLIWSfPs=
=rUWi
-----END PGP SIGNATURE-----

Re: Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> From: "Tristan Seligmann" <mithrandi@mithrandi.za.net>

send ascii text, this not the NSA.

Re: Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> A 2-dimensional hierarchy is hopelessly inadequate for storing
> information in a "natural" way.

nonsense.

> really has 1 or 2

run du -a lately?

> It may be a great low-level implementation, but being
> able to say "find the e-mail I wrote to Timothy last week" is a lot more
> useful to the user.

really?  mbox/Timothy/* or mbox/Timothy/YYYY/MMDD/*

Re: Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> Hierarchy is your friend.

yup

RE: Re: [9fans] acme: some thoughts about design

[Tiit Lankots]

> of the "google fs". But If you need "structure" you can store 
> your "path" inside the document und use the search engine to 
> rebuild the structure on the fly. Operas M2 is a example for that.

I.e., you're emulating the hierarchy more or less by hand, just because
the
system doesn't provide you with one. Don't underestimate the expressive
power of 2-dimensional structures. People are used to them and usually
are good at manipulating with them, both on a mental and a physical
level.

The Google counterexample doesn't apply, because internet is
one-dimensional
per se.

RE: Re: [9fans] acme: some thoughts about design

[Matthias Teege]

On Sat May 29 16:59:54 GMT 2004, t.lankots@aprote.ee wrote:
> A smart user is. When your file count passes 200 000, you won't know
> your
> left from your right in a flat file space. Hierarchy is your friend.

Take a look at google. There are more then 200000 Dokuments
indexed and the user didnt now anything about the structure
of the "google fs". But If you need "structure" you can store your
"path" inside the document und use the search engine to
rebuild the structure on the fly. Operas M2 is a example for
that.

Matthias

Re: Re: [9fans] acme: some thoughts about design

[dvd]

> A 2-dimensional hierarchy is hopelessly inadequate for storing
> information in a "natural" way. People retrieve information along many
> different "vectors" all the time, and a hierachical filesystem only
> really has 1 or 2. It may be a great low-level implementation, but being
> able to say "find the e-mail I wrote to Timothy last week" is a lot more
> useful to the user.

http://www.gmail.com/

Re: Re: [9fans] acme: some thoughts about design

[Tristan Seligmann]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

On Sat, May 29, 2004 at 19:51:56 +0300, Tiit Lankots wrote:
> > If I have a usefull search interface I didnt need any 
> > filename or directory structure. A user isn't interessted in 
> > filesystems.
> 
> A smart user is. When your file count passes 200 000, you won't know
> your
> left from your right in a flat file space. Hierarchy is your friend.

A 2-dimensional hierarchy is hopelessly inadequate for storing
information in a "natural" way. People retrieve information along many
different "vectors" all the time, and a hierachical filesystem only
really has 1 or 2. It may be a great low-level implementation, but being
able to say "find the e-mail I wrote to Timothy last week" is a lot more
useful to the user.

-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

[-- Attachment #2.1: Type: text/plain, Size: 333 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/pgp-signature; name="signature.asc"
	Content-Description: Digital signature
	Content-Disposition: inline

[-- Attachment #2.2: signature.asc.suspect --]
[-- Type: application/octet-stream, Size: 196 bytes --]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAuME6pNuXDQIV94oRAmQJAJ0ZmTsVYpEtwwmaeWFF1BT8Ry6tmgCeMfok
VRFhF0lX8kpkTim4H8O25YE=
=Tn8l
-----END PGP SIGNATURE-----

RE: Re: [9fans] acme: some thoughts about design

[Tiit Lankots]

> If I have a usefull search interface I didnt need any 
> filename or directory structure. A user isn't interessted in 
> filesystems.

A smart user is. When your file count passes 200 000, you won't know
your
left from your right in a flat file space. Hierarchy is your friend.