- Out-of-the-box solution.
I think we could learn a lot from BeOS 5 Personal Edition in this
respect. You could boot from the CD, you could copy the image to
your hard drive and boot from Windows 9x (this kind of thing isn't
possible with Windows NT, unfortunately), or you could create a
partition on your hard disk and install to that from within the live
image. The time from getting the CD to running the OS was under a
minute. The amount of time between starting the OS and having it
installed was not much more (the ability to install from the LiveCD,
rather than having a separate install routing is also something we
should consider - don't make users wait an hour or so from getting
the CD to seeing what the system looks and feels like).
Yes...I envisioned exactly this as well. The installer CD *IS* the
LiveCD, and the LiveCD is the installer CD. There is no difference,
they are one in the same. It just makes sense this way.
This is how I envisioned it as well.
Additionally, let's ask "what extra work will go into supporting a
full OS instead of just a DE?"
That depends on the base system we use. If we chose Linux, then it
depends if we are doing a Linux-from-scratch approach (in which case
we have a large amount of work to build and test packages), or basing
it on a specific distribution (in which case we have to ensure our
packages work on that system, and probably, at least, create a custom
installer and liveCD etc.)
Well, I've also thought about this a lot, and while an LFS approach
would be nice, I personally think it's a waste of time. We wouldn't
consider doing this with any BSD, so why would you consider doing it
with Linux? Customization of a pre-existing distro is perfectly fine,
and saves us a lot of time. There many, many, many people working on
Linux-based distros, and to be so presumptuous as to reject their work
and claim we can do something better is not only probably completely
untrue, it's unachievable...
Open source means you don't have to reinvent the wheel. LFS seems like
an exceptional amount of work just to get us to a point many others are
already at. I don't know about all of the technical details of the
different OSs to really make any decisions about this, but it seems to
me we should be working with a small team who is already supporting a
distro and would be interested in integrating with our desktop efforts.
Now where to find this team... :) (Gürkan are you out there??)
============================================
THE INTERFACE
============================================
- 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.
Possibly. This seems to be where Apple is going (apparently
implementing Spotlight is less effort than fixing the Finder…). I
rather like managing my own documents, and I can usually find them
quite easily. My main gripe with current systems is not that they
are hierarchical (the human mind is particularly well evolved to
interact with hierarchies, and they are a good model), it is the fact
that there is no separation between the model and the view of the
filesystem.
Yeah...I kind of think that stuffing this down your potential users'
throats is not going to make you many fans. I want to manage my own
files in folders, and it bothers me when iTunes insists on doing it
for me, for instance. There's more than one way to organize your
music.
Should we have to manage our files, though? I'm totally the same way as
you -- I have everything meticulously organized and arranged and can
almost move blindly through my file structure. But should we have to?
Organizing files and descending through a file hierarchy can both
consume a lot of time and really test your memory. It seems like if we
didn't have to put effort into organizing, that effort could instead be
put into being more productive. Might a search-based file manager be a
more efficient way of locating and viewing files, even if it means
giving up control on where your files actually are?
To put it another way, when you are thinking about a file you want to
work on, do you think about it in terms of its address, or its
attributes? For recent files, it might be easier to find them based on
where you last put them. For older or archived folders, it's probably
easier to remember the unique characteristics of that file, and search
makes a lot of sense here. But even for recent files, where they live
doesn't have to be a "hard" folder, it could be a "soft" (Live Search)
folder with a query based on date (like Recent Items), or on another
searchable tag, maybe even a user-defined key like "project" or
"client".
Now, pretend you don't have Live Search _folders_. Pretend that when
you perform a search, the results just show up in a new window. The
folders aren't really important anyway -- it's the window the files
show up in that's important and that gives a sense of relationship
between the files. We perceive that as a folder, but it's not. It has
no parent; it doesn't exist as a location. It is instead a filtered
view of the contents of your file system, and that view can be saved
for quick reference.
It's like folders, but without any of the time spent in organization
and without the limitations of one parent per file.
- 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".
A while ago, I proposed the idea that a clipboard should actually
work as a clipboard. The current clipping should be added to the
top, and when it is removed the previous clipping should be at the
top of the pile. The biggest advantage of this is that a copy
operation would no longer be destructive (i.e. you can return to your
previous clipboard contents by removing the top page from your
clipboard). This would require the addition of an inverse-cut
operation (something that would take the contents of the top page of
the clipboard and remove it) - I suggested that copying an empty
selection could be used for this in existing applications, although a
more intuitive solution would be better in the long-term.
Interestingly, this is exactly how Microsoft Office 2003's extended
clipboard system works under Windows. It works well, but I have never
personally found the need for the feature.
I was referring to actual selections, not items copied and stored in
the pasteboard. If I click-and-drag to select (not copy) text from my
text editor, then click-and-drag somewhere else to make a new
selection, both selections should still exist and be visible and badged
in some way. Both can then be manipulated, such as swapped with one
another or have formatting changes applied to them or whatever.
The multi-item clipboard/pasteboard is similar to the idea I was
referring to with the buffer earlier in my initial email.
J.
