OSNews

I have embraced the idea... but it's not quite yet here sadly.

Vista allows some metatagging, but it's not a single click far (it's 4 clicks deep . Zeta/Haiku with just lack an interface to the meta-attributes to be the del.icio.us of the OSs.

The point is, quoting MS, that: "As development of Windows Vista continued, we got a lot of feedback that said people weren't ready to move to a library-based file explorer just yet, so we scaled back on the Library vision a bit."

Edited 2006-11-02 10:50

something like this:
http://nepomuk.semanticdesktop.org/xwiki/bin/view/Main1/
??

KDE is going that route anyway, Strigi for search and trying to make the desktop something different from a file-manager.

Removing a file manager would be stupid anyway in KDE (again), exploring files is the same as exploring the internet, the "normal" users wouldn't need to know that the internet browser is also a file browser, while the "power" user can still use a decent file browser. Why throwing something usefull away while it can be implemented in a similar program.

The idea of using several programs for the job, is gradually finding acceptance for example in music programs that handle the music files...

Hello

take a look at oberon and plan9 to see other "options" to the common sense of a "computer shell".

gabi

...that the world primarily focus on idiots? So because many people are too dumb to sort their files in an sane way, having the ability to sort is bad? I don't think so.

There are probably better interface designs then WIMP, but i have yet to see one that realy works better.

I'm quite happy with my KDE, but if i wanted to explore new interface designs i would start with getting rid of the concept of having Windows. I can't remember it's name right now, but i have once seen an Windowsmanager that handled every Window as a Tab in a big tabbed sheet.
It realy looked like it could be very usable, unfortunately it wasted incredible amounts of screenspace. Since i tryed it on my Widescreen Notebook with only 1280*800 pixels there wasn't enough space left to the app on the y axis, so i did not use it much, but otherwise i might have given it a longer look.

I think that requiring the user to enter tags each time he/she saves something is just as much micro management as navigating to/creating folders.

So gather as much metadata as possible:
1) When a file is downloaded from a web site, save the title, url, and maybe even words from the site as metadata.
2) When a file is saved from an email, again, store the subject, sender, (full text of the message) as metadata.
3) When a file is stored on cd/ipod ... etc.

Full text search ala beagle is nice, but it won't help you with a joke stored as 025454565.jpg in your 2GB "downloads" folder.

Seriously, I'm all for innovation and new methods of storing/retrieving important data, but I'm terrified of the idea of misspelling something or just hitting "save" and forgetting to add important criterias etc. My brain is a brain, nothing more nothing less, it's filled with memory errors and CRC errors.

Anyway, I'd prefer something optional here as a first step to at least improving file hierarchy that would make at least my life easier and surely many backupadmins.

Why isn't all available file systems today and softwares used for production purposes a lot more aware of versioning? What I'm saying here is that on my computer I always store files according to a versioning scheme (as in x.y.z versioning depending on size of changes). Now what I would want is that the computer itself stores "original document/image/file" and let's say autosaves every 5 minutes or when user demands saves and "tags them". For instance saying "Version where it is sent to Mr X" and if changes to that file later on, you can always reverse changes back.

Instead like today storing it as a new file with a new name in order to keep "original" wouldn't it be better to simply let the filestructures as well as the software on top always keep original and store "changes along the way" and rebuild files that way when requested for. If for some reason you wanna remove backdata, that option should be available to.

For me at least, this would lessen number of files dramatically, and make everything better.

Yes, this technology exists today, I'm aware of that. But how can it not be standard and widely adopted?

Anyone else agreeing about this?

I really like this idea, I had one which is quite similar. Maybe some of my ideas can help you improve your prototype (I will try to join your sourceforge project, as soon as I have finished one of my three current development projects):

- When data is stored you already have a lot of informations that are hardly used: User (+ Data From LDAP for example, Buisness Unit or somethings like that | Date | FileType | ... You should be able to query this data in... For example if I want to know what buisness reports where done in Nov. 06 I don't care about the format or the user, I only Care about the Keywords Finance and so on...

- I would try not to redesign the whole UI, just redesign the "Save As" Dialog, this can be implemented quickly in various libraries (GTK, QT, ... )

- Make Revision Copies of Files Smaller than 100MB, Diskspace is no matter today ..


Just my 2 Cents... Keep on realizing your idea, it's a great starting point!

- Patrick H

Edited 2006-11-02 12:17

WIMP systems may not be the end-all of designs, but they do work wether you have 10 files or 100,000 files.

Most alternative designs I have seen would fine as long as you are not dealing with too many items, but once you go over the limit (diffirent for each system) you quickly get bogged down.

Worse with meta-data you usually only find you need a key piece only after you collect a lot of file first - adding the meta-data after the fact can be a pain.

I have made this mistake using BeOS, adding the meta-data would have taken weeks, figuring out an automatic way to update the meta-data was not easy, most users could not have done it and that is the problem. At some point or another the work of maintaining your system does become hard.

My first thought was this:

You go out for a long weekend and take 200 photos on your digi cam. You then connect your camera and then start uploading, and then, holy crap, you have to enter meta tags for 200 photos!

This would involve opening each one individually and thinking deeply enough to get intelligent search results. I'm guessing you might be sitting there for hours. No way.

And 200 is a small number. My wife frequently takes 1000+ photos during a photography shoot and that just makes my head spin thinking about tagging all of those!

Nope, I'm sticking with folders for now.

I agree 100% with the author.

The WIMP metaphor is clumsy. It's very inefficient and complicated for no reason at all.

The PC will have an XBox360-like interface one day (where everything is fullscreen).

...but file management, indexing service and desktop metaphor has nothing to do with each other.

True, the main stream OS'es have issues with the desktop metaphor, but that's because they only implement a minor part of the desktop metaphor.

Windows have the potential to be a killer on the desktop, but Windows, OS X and KDE/Gnome all make the same mistake, relying on huge blobs for functionality.

However - the article is mostly about indexing services and I can definitely support it.

Beagle on Linux, Spotlight on OS X and Windows Indexing Service on Windows.

I'd like to point out that Windows have been ahead here for many years. Unfortunately MS have decided not to make a major thing out of it. Use the ordinary search window and write queries in the free text search field. It's not userfriendly but it gives you the same search functionality known from Google Desktop Search, Windows Desktop Search (an unnecessary extension, really) and beagle.

Indexing Services and Virtual Folders are natural parts of a Desktop. And BeOS/Haiku and SkyOS can show off a few things here, even though the query builder in BeOS is cumbersome for a power user.

One of the major reasons file management is becoming increasingly complex is because package managers tend to do a crappy job.

Another reason is because we - the users - have a tendency to scatter our own files all over the place. That's where indexing services are really good (and of course message data from chats, as well as mails).

In other words, you want to move to a flat filing system where each program tags every file, and all of those files are searchable, and rely on the apps to sort the files insted of a file manager.

Sounds an awful lot like PalmOS4.

A lot of what has been said in the article and above could possibly work with home desktop machines, but how does it translate into a work environment? The idea of Linux and the BSDs being a multi user system seems to have been lost in this topic. The same goes for file servers of any flavor including Novell's OES, Windows Server 2003, any Linux Distro out there. Rights management and top down flow would be negated. There would have to be a user interface, which represent the file system in a way completely different from the actual layout. It would have to be a shell on top of a shell. Even then, how to you share directories through that interface?

I'm in a project where we are currently working on a very similar product. While we may not have any working code yet, we have already spend a great deal of time on the user interface and have some new ideas on how to integrating sharing of files into this interface.

http://www.iola.dk/en/current_project

Edited 2006-11-02 14:13

Take that desktop metaphor and bury it in the backyard under the third rock next to your beegees collection.

so you add an indexing service and take out the file manager?
where to you win doing this?

leave the file manager alone
add a good indexing service, and make the file manager aware of it...

in the other hand, i am a good indexing service... why my stupid pc is going to be even good?

and yes the world is make to please idiots...
because they are idiots we have to be idiots as well

educate the idiots, don't make them more idiots...

bye

I will come to your house and kill you if you attempt to force me to enter metadata for every file that comes onto my machine. That idea is genuinely that awful.

The current state of affairs is bad. That I do not deny. The problem comes from the vast increase in the amount of stuff which is coming in. When I first started with Linux, the /etc directory was easy to use; now it is a cluttered mess. The same goes with dotfiles (which you want to add to?!?!) in my home directory.

The problem I have is that I have more crap coming in than I can easily manage with the current crop of tools. I have too many files and folders. I need some drawers.

Come up with a drawer app. Then we'll talk and I won't kill you.

Edited 2006-11-02 15:50

WIMP is like democracy.

It has been said that democracy is the worst form of government except all the others that have been tried. -- Sir Winston Churchill

And then the obligatory GUI versus CLI run-down:

Compare WIMP to typing textual commands. When you want to accomplish a task using WIMP, you will point at things and try to waggle the mouse in a way that the computer will try to decipher. In other words, you are using sign language.

When you want to accomplish a task using textual commands, you type in what you want the computer to do. In other words, you are using real language.

Of course both are only analogies, but (as I have commented on OSNews before when this topic has come up) pointing at things and grunting (clicking) seems far less elegant than explaining verbally what you want. WIMP is like a step back to a pre-civilized human.

I'm not saying it is exclusively a bad thing, but sometimes it makes me wonder...

so i read the article, moaned at having to have the e17 libs to try this thing out and instead decided to look at the website first to see if it was worth the trouble.

on the front page is this:

"Multitasking is a myth. Only power users exploit it. Casual users do one thing at a time."

i suggest he reads more usability research as he'll find that yes, bobby, people do multitask. theory is nice but when field research with sound methodology shows otherwise, i know as a scientist which i'll trust more.

"The only other application 99% of casual users use in parallel is their music player to have background music"

and what is instant messaging exactly then? *sigh*

this is the biggest problem surrounding UI development today, both in the open and proprietary worlds: people are wandering around trying out their hunches and papering over the obvious holes with excuses and personal theory.

my favourite was a recent video where the "researcher" claimed his prototype made the interface disappear when the gestures he was using were not intuitive/obvious and there was a button bar at the top of the touch screen! *sigh*

oh well ..

This article is nice ideas relly, not very usefull but nice :p

Just kiddin, I understand u fully when i look at the overfilled desktop from downloaded files in the background, and yes I have a warm feeling managing my little file hirarchy on 4 disks 2 OS's and alot of files, but tagging won't really help cos it's difficult for a computer to understand what i need and I don't remember what exactly I tagged.
The problem will persist till we create a real AI, someone to talk to, who understands us and the very content of files, yep yep yep that's the real end of Desktop metaphor my friend.

I have a feeling there is something wrong in this article.

Desktop clutter is bad. But why is the desktop cluttered? Because visual way of doing things (WIMP) is not suitable for manipulating large quantities of information/items/data. There's nothing wrong with the _logical_ way of arranging things in directories. WIMP is the opposite of the directory tree.

The library that stores a million books has no problem finding the correct volume because the books lay on indexed shelves installed in indexed racks that stand in indexed storage rooms. And the library has the catalogue!

Why don't we just make our computer use this library metaphor?

I was doing a database recently with an archivist, who was very impressed with the importance of picking the right categories or keywords to use to categorize the items. Thinking there was something a bit odd about this, I consulted a friend who is something of an expert in these matters.

He laughed long and hard. Then he told me that numerous studies had shown that people cannot in fact use keywords effectively to find things. They forget what they have tagged. Their interests change. What is a keyword for one is not for another.

What people do effectively (maybe not efficiently) is drill down, use tree type searching. They have a much better, largely unconscious, way of finding stuff.

The desktop metaphor works because it allows rapid drill down, and rapid reassignment.

So we still have keywords. But he was right - no-one uses them. They drill down, or if all else fails, they do full text searches for whatever words occur to them.

I'm surprised by the number of negative reactions. All Kostis is saying is that files are a technical artifact in which most people wouldn't be interested if they didn't have to be. Files are a needlessly overloaded concept - some files contain data (most interesting to users), some files contain configuration (considerably less interesting) and some contain programs (which are only interesting in so far as you launch them from files). This is both confusing and dangerous for non-geeks.

Kostis is simply suggesting that we get away from the tired old concept of files and programs and get to the concept of data and capabilities. Windows' start menu and its attempts at hiding "system" files from users are a weak attempt at doing this. The web (think Google Mail, Google Maps, Google ...), has done a comparatively better job of focusing on data and capability, which is probably why users seem to have an easier time learning and using web interfaces than traditional desktop apps, even though the web interfaces are often less slick. Sure, there's a lot of files being used there, but it's all managed by experts working in data centers.

As to tagging and metadata, the current scheme for naming files is nothing but a simplistic tagging mechanism that encodes relationship (folders), identity (file name) and type (extension). There's no reason that a tag-based storage mechanism can't use these fields as a starting point but then add considerable value where additional metadata is available (either via the data source or by the user).

The key to successfully moving beyond the file system is to provide a competent browser mechanism that gives users a fall back for when they can't remember specific searchable terms and that lets them instead explore their data and use spatial memory to recognize matches. It might also be nice to provide an expert system that helps users who start with a vague idea of what they're looking for to iteratively narrow their results. Think of a good librarian - you might walk into the library knowing very little about what you're looking for, but by questioning you about your objectives, (s)he can help you find exactly the right book.

At the end of the day, software that makes you do anything that's not directly related to your real work objectives should be considered a failure. To Kostis (and to me) that means that users should never have to touch anything called a "file" unless it's actually a file (e.g. my 2006 tax file).

And assign the user for tagging content is ridiculous. I think a simplified hierarchic system and dynamic metadata on filesystem objects is much better. It should be programs that assign AND read/write metadata to/from filesystem objects NOT the user. Example, a camera, the camera could add metadata kamera="cannon" and model="400" to the picture.

the metadata could be added like File.add("key",value)
example: File.add("kamera","cannon"), File.add("model","400"). The folder metaphor is greate! but what is needed by todays operative system, is to clean up the todays messy structure AND as default only present for the user his starting point/home directory.

I have two points:

1.) Programmers and programs would still need to know the exact location of a file, so file managers will ALWAYS be necessary. What would happen if your photo-album screen saver picked up on your porn directory when you had family over? The only way to separate files with these kinds of details, is to have a human organize them.

2.) You should spend your time on something far more important to technology than making computers easier to use for users that obviously can't comprehend them enough to ever use them to their full potential. They'd be better off with real filing cabinets and folders.

Its amazing how many people can't comprehend how to navigate a file hierarchy and organize files. Those of us "gifted" enough to understand know that there are very simple tools to locate files quickly if we cannot find them -- utilities such as slocate.

Edit: It should be noted that I'm disagreeing with the author's philosophy of UI design as stated in his Manifesto on his SourceForge page, much more than I am criticizing anything he says in this article. That said....

Oh man.... where to begin.... Sure, tags and searches are good... everyone knows that already. But some of these other ideas if implemented in a mainstream OS would take UI back to the stone age. Luckily even Microsoft has done enough user testing to realize that the amount of oversimplification suggested actually makes everything much harder and more annoying for most people.

From the Manifesto:
>User interfaces should be simple, discoverable >adaptable. Casual users should find their way easily >after some minutes. Intermediate users should be able >to delve a little deeper. Power users should resort to >the command line if they want to do something >extraordinary.

Simple and discoverable: good. However, it must also be remembered the more similar an interface is to something that came before it, the more likely it is to be discoverable to the user. Hence, WIMP apps that follow certain conventions are easier for most people to use than new, nonstandard interfaces. As for power users needing to resort to the command line: NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO!!!!!!!!!!!!!!!!!! That's my take. I know I'm not the only one.


>Unix GUI applications should mirror the console ones. >They should be small, reusable and focused on a single >area. Monolithic designs are to be avoided. It should >be easy to obsolete, replace or upgrade functionality.

Only if they're easy to link together, like Unix console apps (this is something already done on the Amiga and now on OS X with Automator). In practice, though, it's often actually much easier for end users to have one app, like iTunes, that's always open, then search around for a specialized one to burn CDs, one to rip CDs, and one to listen to music. (Not to mention tagging, downloading, finding podcasts, the list goes on and on... there's a reason iTunes is popular even with non-ipod owners.)

>There should be only two ways to accomplish a task. >Following the beaten path (easy but slow) for the >casual user or bypassing the path (hard but quicker) >for the power user. Any other way might confuse the >casual user or angry the power user.

Hit the nail on the head, by stating the absolute, complete wrong way of thinking about this. The author believes there can only be "the path of the beginner" and "the path of the expert." That goes completely against the reason that personal computers have become popular: because there is a sliding scale of functionality that increases with use. With the author's binary separated model, how would normal users ever be encouraged to venture into more powerful pursuits? Just tell them to RTFM? This would just encourage more elitism and make the majority of people more helpless to use the computer the way they want.

Apple has it right: Give users a path to more power, while making that power as easy to use as possible. Encourage people to discover functionality they didn't know existed. But don't throw functionality out for the sake of the grandmas.

Edited 2006-11-02 21:21