At 23:40 Uhr -0500 06.04.2005, Jesse Ross wrote:
I asked Nicolas, Quentin and Banlu about their
ideas on developing Étoilé as a full operating
system (on top of Linux or *BSD or Hurd (one
day... maybe...)). All three mentioned being in
favor of doing a desktop environment instead.
Jesse,
I agree with your points that, for the end user,
this will be a desirable goal. However, I also
think that maintaining a distro is a hell of a
lot of additional work. So, the "from scratch"
approach someone else mentioned is right out. As
to focusing on a particular existing distro at
first, it depends on the contributors. What
distros do you know? Which ones are you using
right now? If we picked distro X, would you be
able to run it on your hardware?
If we pick the wrong distro, we might lock out
90% of contributors from the start. So, I
personally would maybe try to integrate with
GNUstep Startup and similar projects to make it
easy to install, but to otherwise try to cover
all of GNUstep's deployment platforms for now (or
at least those platforms most of us are using).
Most parts of the GNUstep Desktop(tm) (be it
called Etoile, Garma, or Hamster in a Box) will
run just fine on any Unix-like OS. A good part of
those will probably even run on any GNUstep
installation, or even under Cocoa. So, in the
interest of not draining away valuable expertise
by tying them up in maintaining a unix
distribution, I'd prefer if we postponed that
decision until we come across a component that
actually does something system-dependent. And in
that case, its developer will probably start on
his/her system anyway, and then we can port it to
the other platforms (OpenSSH-style, as someone
else mentioned here).
Of course, when someone designs someone that
depends on OS or hardware features, it should be
understood that there should be an implementation
of a hardware abstraction layer so ports need to
replace as little as necessary.
Here are some things that I want in an interface
and some counterpoints to things I've read in
the archives and on the wiki. Everything that I
said here <
https://mail.gna.org/public/gnustep-ui/2005-02/msg00050.html >
still applies, except for maybe the desktop
being used as the home folder. Here's some more
stuff and more fleshed out stuff (since this is
probably a more appropriate place :)
- A buffer or visual pasteboard / quick launcher.
So, essentially a global shelf? Sounds great to
me. On MacOS X the desktop is for that, but since
the desktop is always in back this is kind of
annoying. In Filie I'm planning to eventually use
the image at the top of the Sidebar for that.
Dragging the snippet into another application
will act as if I had that snippet as the current
item in the pasteboard (text, including URLs and
email addresses, will paste as text, images will
paste as images, folders could paste the path or
copy or move the folder, depending on the target
of the drop, etc).
I hope you mean it will work just like the
popular drag & drop implementations (Windows,
MacOS), though. I wouldn't want to have it fake
something by way of the copy/paste clipboard.
(Note that drag & drop on OpenStep uses a
dedicated NSPasteboard object for data exchange,
so I suppose you meant the right thing, but said
it in a misleading way?)
- Annotations are a brilliant idea!
You're talking about file annotations as in
GWorkspace? I guess so, yes. Though I'd probably
integrate that with general metadata storage. So
you can attach anything, be it keywords or text
snippets, or maybe even references to other
files, source URLs for downloaded files etc.
- Spacial interfaces can be extremely painful
and lead to a lot of windows on the screen. I do
like 1 window for 1 folder -- that's a good
idea, as is keeping the location and view of a
specific folder consistent. Browser navigation
is really slick for deep hierarchies -- we just
need to find a way to unify the two concepts.
Or...
I think the problem with spatial interfaces is
better solved on the window manager level. They
have the same problems that gave web browsers
tabbed browsing. Since we find ourselves using
more and more applications with more and more
windows to do more and more things, it's only
natural that popular apps will start running out
of screen space one by one.
So, take a look at nice implementations to
solutions for this and try to come up with
something that combines their advantages. Here's
a selection of interesting approaches:
-> Unix Workspaces
-> Regular Tabbed Browsing
-> OmniWeb's innovative take on tabbed browsing
-> Apple's Expose
-> Sun's LookingGlass with windows that can be rotated
-> WindowShade
-> Iconizing Windows
-> Minimizing windows
-> Adobe's tabbed palettes with drag & drop-reorganizing
I think if you mix all of this together (i.e.
OmniWeb-style workspaces with little preview
icons, the option to dock several windows to each
other and to zoom in/out and flip unneeded
windows to the side for a moment as well as just
drop a few unneeded windows into the shelf for
later, or something along that line) you may just
find a good solution. Or make a royal mess. We'll
just have to experiment.
- Ditch the ability for regular users to create
folders altogether and put all files in one spot
(probably their home folder merged with a Shared
folder for all system users). Make the workspace
manager an awesome searching and filtering tool.
Add buttons to the workspace manager for "Music"
or "Photos" or "Letters to my boss since last
Tuesday" or whatever, and just make those
shortcuts for queries (live search folders).
Never use a Save dialog again -- when you make a
new file, just give it a name and it's
automatically added to the user's home folder,
ready to be searched on.
Yeah, looks like what Apple seem to be working
on. (Symbolic) links already are a
low-performance attempt at providing the ability
to have one file in several folders, but now that
systems are powerful enough for live search and
algorithms are available for caching information
needed for these queries, this is definitely
something to look into.
That said, I don't think we will want the user's
home folder to be the dump for this kind of
files. Rather, I think the actual files should go
in an "All Files" subfolder of the home folder.
The user can then keep the home folder nice and
clean and put only links to really important
files in there, and live search folders that
search "All Files". (Of course, All Files would
be searchable as well, you won't *have to* create
live search folders for that)
Something like that.
The problem with this is that it mainly only
works with 1-level hierarchies. What about deeper
ones? What if I want a folder that always shows
all my bills, in folders, one per year. And each
year-folder would have folders containing the
actual bills, one for each month? That would be a
live search folder of live search folders that
automatically creates new folders...
We really need an entirely different thinking
for our "canned searches" than we have for
current live searches. This will be a lot of
work, with a lot of thinking to be done
beforehand. Things like Spotlight and Beagle are
only the foundation upon which we need to build.
I told the guys I've been reading Jef Raskin's _The Human Interface_ lately.
Isn't that "Humane"? He *was* kinda picky about
that distinction, wasn't he? :-)
- Eliminate model interfaces as much as
possible. Different applications (tend to) mean
different modes (different key commands,
different interaction methods). By breaking
applications down to services that can be
summoned and combined as needed, Étoilé seems to
be working on making this idea more of a reality.
If you mean "modal", then yeah, modes tend to be
overused in software design. That said, there
*are* many valid uses of modes, some we don't
even realize, even though we constantly encounter
them in Real Life(tm).
- Build a history of selections. If I make a
selection in a body of text, that is selection
0. If I make a new selection, the new selection
is numbered 0 and the previous one is numbered
1. This goes on for as many selections as we can
technically handle. All the selections might be
badged by their historical number (or some other
visual method). Swapping two pieces of text now
becomes insanely easy: just have a menu item
labeled "Swap". This is far superior to "select,
cut, paste, select, cut, find previous insertion
point, paste".
This is a great idea. However, the problem will
be to find an implementation that actually works.
Having too many selections at a time can make it
hard to find the current one, or can make the
whole screen very busy. But yes, it's definitely
something I'd want to see in software eventually.
But this will be something that we'll need to
implement in testing apps (or a GNUstep branch or
whatever) and see how well it works.
- Make alerts that don't require interaction to
show up, then fade out, and keep track of all
alerts.
This is dangerous. The reason why many alerts
are so annoying is not because they require you
to click the "OK" button, but because they are
unnecessary. My favorite example is the Unix app
MetaCard, which always asks you "Do you really
want to quit?" when you choose the "Quit" menu
item, simply because the programmer was too lazy
to implement a proper "Save Changes?" dialog that
only triggers when you've actually changed
something.
That said, a facility like Growl is a useful
*addition* for advanced users. There have been
applications for a long time that have a "Don't
show this alert anymore" checkbox on dialog
windows that not everyone may want to be warned
about. I don't see why we couldn't have a
standardized popup there that lets the user
choose other options like "log & auto-OK after 10
seconds".
For beginners, however, this should be done via
actual dialog windows. Otherwise it is too easy
for them to miss a new window because they're
concentrated on another part of the screen.
- Everything is undoable. Everything.
Forgiveness is a virtue... and a requirement for
a friendly system.
Fundamental to every modern user interface.
- Incremental search. Like OS X is using
everywhere, like Filie has, like Google Suggest
<
http://www.google.com/webhp?complete=1&hl=en >.
Good idea -- let's make that type of search
really easy for developers to implement.
Agreed. Also have a look at what Apple have for
this. NSSearchField and SearchKit might be good
candidates (though I think SearchKit isn't ObjC,
I thought I'd mention it so GNUstep's search API
gets designed in a way that lets me implement an
OS X version based on SearchKit).
On a different note, the Google Gmail mantra
"Search, don't sort" seems like a really good
thing to keep in mind. You're already going down
that route with Lucene; here are some other
links with ideas:
- http://www.mozilla.org/blue-sky/misc/199805/intertwingle.html
-
http://logicaldesktop.sourceforge.net/screenshots.html
(a variation on sorting using task selection and
searching)
I've been wondering for a while why there's no
E-Mail program that has a Google-like API ...
surely this would be even easier to implement
locally ... ?
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
