Le 7 avr. 05, à 06:40, Jesse Ross a écrit :
============================================
THE DISTRO
============================================
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. I personally am interested in a full
distro, and here's why:
- Complete control. By deciding on an official kernel/userland to sit
on top of, you can optimize the environment for that specification. We
_could_ then rely on things like using ReiserFS for metadata support,
or inodes rather than file paths to refer to files (for
shortcuts/aliases). This wouldn't prevent people from porting it to
work on other OSs, but having a clearly defined target platform seems
like a great way to stay focused, to prevent from spreading our
(already small) resources too thin, and to give us more control over
how all the pieces fit together, for a better user experience.
Yep, but I think we can keep portability by offering extra OS support
but with some stripped features.
A note : inodes are a Unixism so we have them with Linux, BSD etc.
… otherwise that's true we should avoid hack things like our own Posix
VFS (would not be used by other OS applications). For mechanisms like
persistency/versioning, it would be better to have them at OS level too
at least in a rudimentary form.
- Eases installation and testing. You (you the developer or you the
user) don't have to worry "will this work on System XYZ?" If you're
the user, you simply download the ISO, burn it, boot and install. As
long as your hardware is supported, you have no problems. If you're
the developer, you simply do all of your testing on the target
platform, and, if it works, great. No need to worry about variances
between the potential host systems. There are an infinite number of
combinations of software out there, and trying to snap into that seems
like a hell of a lot of work for what a small group we are.
- Out-of-the-box solution. If you want someone to try your software,
you don't have to first check whether they're running Windows, Linux
or *BSD. You simply give them the disk and they can use it. No
configuration, no compiling. Usable, right away.
I think we should package it in white box with spectral cows observing
a pixelated river
…
hmm and on the box back part we could have just only one cow sat on a
chair and reading a book about cybernetic history. That would be very
appealing, and we would include a manual inside the box to reach our
usability goal… :-D
============================================
THE INTERFACE
============================================
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. I want a spot where
I can drag snippets of text, or images, or URLs, or email addresses,
or color swatches, or folders, or network locations or whatever.
Anything I think I might use in the near future, I can drop here.
Clicking on said snippet will launch the appropriate application for
content (text will launch a text editor's window, URLs will launch a
browser, folders will launch the workspace manager, etc). 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).
That's precisely the role of Shelf combined with PickDropKit.
- Annotations are a brilliant idea!
- 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...
Spatial orientation can be summarized in my opinion like that : user
owned objects should have a single visible consistent representation on
the screen at any time. Time and spatial attributes maintain most of
such consistency. User owned objects can be documents, folders,
devices, applications, people objects.
Objects like newspaper (news web site), shop (web site store), book
(when you read it on a web site) etc. when accessed in distant way with
a web browser can break spatiality because they haven't true static
locations in real world : they are duplicated a lot and distributed (a
books is available in many libraries, tomatoes in many supermarkets
etc.)… but what's happen when you have a book in on your own shelf ?
It's an ontological problem I would say 8-) … A tomato in a supermarket
is not the same than the one you store in your kitchen. In supermarket,
it is owned by nobody, it is just hosted as a product… when the tomato
is in your kitchen it isn't anymore a product, it is a piece of food
you own.
You can "browse" tomatoes in supermarket because each one hasn't an
individual look/singularity. At home, when you will observe the tomato
and taste it, this precise tomato will become "unique" for you unlike
other ones in supermarket : in your mind, the tomato has now a spatial
and time identity because you own it or owned it.
I will stop here this dramatic story about tomatoes' life :)
- 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.
That would involve to have more and more live search folders everyday
because we are collecting more data everyday (most users are throwing
out less data than they are collecting). Then we would need to organize
such live folders hierarchically to avoid two hundred live folders in
"unique workspace place".
Finally we would have a hierarchical file system of live search
folders, which would be worse than static hierarchical file system we
have actually because spatial orientation would be totally broken. I
still think a hierarchical structure provide spatial location for each
related objects you use (paths being fuzzily tagged in your mind), and
made easier and efficient to look for stuff without remembering
anything really precise about your documents/data.
Pure search oriented Workspace wouldn't support theses "precise fuzzy
tags" and you would have to rely on "incremental attributes lookup"
with lot of noise to parse in search results, in a similar way your
live folders could easily be "spammed" by important documents/data
exchange.
What I would like to develop is mostly rich interconnections support
between hierarchically stored objects/documents, that would be
implemented with filter/transformer view components, you should be able
to apply them to live folders also. Probably something between old
Apple stack idea and Banlu mockup here
<http://maliwan.sourceforge.net/filebrowser.png> (I really like this
idea :-)
============================================
THE TECHNOLOGY
============================================
Here are some random bits of other technologies or ideas that might be
inspiring.
I told the guys I've been reading Jef Raskin's _The Human Interface_
lately. Not all of his ideas are great, but some of them are stellar
(< that's a pun) and really resonated (< and so is that) with me and
with what I read about Étoilé. What was really the trigger is he is
all about productivity and workflow -- exactly the same concepts this
project is trying to find a better solution to. Where I think Raskin
goes wrong is that he tends to favor a more command line approach,
instead of the more intuitive approach of direct manipulation. He also
tends to look at files as textual elements when, for me, the majority
of what I manipulate every day is graphic. Some of his good points:
I agree with your analysis :-).
- 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.
Yes, but that means to support richer semantic at system level with
unified basic set of tools, which can be reused by
applications/services without introducing subtle consistency breakage.
Well "Modes" can never be fully eliminated, however that's true it is
better to have modes, which are reimplemented very often, moved at
higher levels (applications --> system) to improve consistency.
- 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".
Excellent idea, I never thought of it.
- Make alerts that don't require interaction to show up, then fade
out, and keep track of all alerts. You know the JavaScript alert()
function? Horrible. It pops up with some text and an OK button, and
forces the user to disrupt what they're doing to get rid of it. I'm
using Growl < http://www.growl.info/ > now for alerts on downloads and
new emails, and it is exactly how alerts should work: it shows up, it
stays for a bit, it fades away. Elegant, informative and unobtrusive.
Now if only we could build a simple way to pull up old alerts when
you're busy doing something else and the alert fades before you get a
chance to read it, it would be perfect.
I would like to implement that with NotificationKit (an evolved Growl
like framework not written ;-) and ActivityKit (not written too), both
would have associated service controls in top menu (like Mac OS X menu
extras) where applications/services would report their notifications
(or alerts) and activity (like downloading, rendering, copying etc.)…
the content of such services control attached window would have to be
very flexible with various filtering options. For example, front
application activities and notifications would be listed at top. Theses
notifications and activities "object notifications" would be indexed
(and eventually journalized) by ExtendedWorkspaceKit too and then could
appear in your search or be searched.
I have some notes on this stuff, but it seems I haven't added them on
the wiki.
- Everything is undoable. Everything. Forgiveness is a virtue... and
a requirement for a friendly system.
Probably not possible without OS support; but we will try to have the
best undo support possible.
- 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.
Planned too.
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
Very good link.
Well that's the direction we intend to follow.
- http://logicaldesktop.sourceforge.net/screenshots.html (a variation
on sorting using task selection and searching)
hmm I really dislike this one :-)
Thanks,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
