Much has been said, and been discussed about “spatial views” (found on Mac OS X’s Finder and on BeOS’ Tracker). Ever since the GNOME hackers decided that Nautilus, the file manager in GNOME, would sport a spatial way of working by default, the word “spatial” has became infamous. Colin Charles tries to clear up the waters and explain the advantages of using a spatial interface.
The Spatial Way
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I don’t know how many of you have a really extensive experience of what does mean to be a newbie and learn to use a PC…. I’ve been a teacher for a private informatic school, one of those that put together classes of various people from the retired old man to the 5th grade boy, with every possible variant of work and culture, so I’ve a statistical base of several hundreds of different users which I followed very closely in their first steps (more so because we were paid bonuses accordingly to the students satisfaction and acquired skills…).
From my experience, these are some things I noticed: first of all, drag and drop is for the experienced user. Newbies find it terryfing, expecially old men and women that find difficult to not drop the dragged object in the wrong place.
This was also the case for the double click, often transformed from the inexperienced in a jumpy dnd. Different windows opened in the same time, nearly always bringed only panic, in effects, when I started to teach how to configure w95 to open all in the same window, my job became much more easy. they also liked a lot the tree view… after a while I started to teach directly how to use that instrument…
Quite counterintuitively, often old people liked much more the DOS than windows (I teached at w95 time, so linux was almost not heard of…) even if, being not english speaker, for them commands where meaningless words… and they absolutely loved norton commander… people I teached both windows and dos, often asked me if there was not a nc version for windows (if there is, it was not provided to us from the school so I didn’t teached it..)
I don’t see how you can say this. No level of competency with a GUI filemanager could ever lead to it being faster, unless that GUI filemanager basically copied every feature that common UNIX shells like bash have.
Experience makes me say it. Unless you happen to spend a lot of time doing those few things that a CLI file manager is significantly superior for, then I’d be quite willing to bet, on average, you’d be faster in a GUI filemanager.
It’s well known that things that “feel” faster in one UI often aren’t when actually timed by a stopwatch. Apple discovered this while they were first UI testing MacOS and it is one of the reasons the Mac GUI has remained so mouse centric and keyboard-hostile – so few people would actually benefit.
The trouble with CLI file management is that it requires a great deal of memory (on behalf of the user, not the machine). You have to remember filenames, their locations, command names, etc (tab completion helps a lot with regards to the amount of typing, but doesn’t eliminate the need to have a reasonably good idea what you’re looking for). Basically, it requires a lot more thought to do file management (indeed, most) tasks using a CLI.
In the spatial metaphor, I am essentially “displaying the object representing this directory,” in the sense that nautilus remembers exactly how I left the directory. […] This convenience is all I am talking about.
This is not the spatial metaphor, it is simply a different type of folder display. Windows Explorer can also display folders like this, and it is most certainly *not* spatial.
I don’t understand _at all_ what you mean by the distinguishing feature of a spatial browser being the “inability to open more than one view of a folder.” That is not at all what a spatial browser is, and you are quite mistaken to think so. In nautilus, in spatial mode, I can open more than one view of a folder (go to the View menu and you can display the folder as a list if you like).
Sorry, perhaps I worded it poorly.
The distinguishing hallmark of a spatial browser is that you can’t have two windows displaying the same folder contents simultaneously. That is what I meant by “view” – not the different ways of displaying the objects within a window. (caveat: I haven’t actually *used* GNOME 2.6 yet, so if it doesn’t act like this, then it isn’t using a spatial metaphor – no matter what other people might try to convince you. I am only commenting on spatial browsers in a general sense).
So, basically, if I browse to ~/Documents/New in one window and then try to browse to ~/Documents/New in *another* window, it should raise the orginal window (or close it, but that is less desirable behaviour). Basically, it’s supposed to mimic the Real World, where you can’t have a single object appearing in different places simultaneously.
There are other things that tend to go hand-in-hand (exactly “remembering” window positions, icon layouts, type of display, etc) but these aren’t really fundamental to the concept and also work just as well in a non-spatial file manager.
This is covered in great detail in the Ars Technica article, but that’s what “spatial browsing” boils down to at its core that distinguishes it from other types of file managers.
But although we can argue over all this, one thing is for sure–no filemanager I have ever met has allowed me as rapid access to my files as command line access.
I’d suspect this has as much to do with your knowledge of how to use the relevant GUI file manager as anything else.
There is a reason people like the CLI, you know. It’s not just because Linux hackers are crazy people. It’s because it actually saves a hell-of-a-lot of time.
That depends entirely upon what you’re doing.
Mouse gestures are intuitive, promote muscle memory and are super fast once you get the hang of it…
Whatever else they might be, they are *not* intuitive. They’re an advanced feature for advanced users.
I was thinking a little more, and I thought: the mail application you describe actually isn’t really spatial. I would say that a real spatial document model would have, in “My Computer”:
Whoa, slow down cowboy
.
You’re starting to move outside the domain of the “spatial file manager” here and are moving more towards the fundamental UI metaphor. I’ll comment on what you’ve written and would be quite happy to respond, but IMHO it’s getting a bit OT for this article.
The latter is really important. If you create a new mail, it is automatically saved in the “Unsaved items” folder. If you really don’t want the mail anymore, you can simply trash it. If you do want to save the mail, you just drag it to any folder on disk to save it.
Yes, but remember the problem wasn’t with the mail disappearing, but the file that had been attached to it. Requiring the user to access an email to recover a file is probably not something that would be immediately obvious.
There are also the issues you touched on with regards to things like dragging files into an MP3 player – why would the MP3s be in “unsaved items” when you haven’t modified them at all (ie: they don’t require saving) ?
And this mechanism also solves the problem of how a “Save” window should be constructed in a way that promotes drag-and-drop.
I honestly don’t understand the fascination with making the “save” operation drag & drop. It would be counter productive by making something that should be quick & easy, long and complicated.
Consider this as a better way to do it, while keeping the existing metaphor consistent and not having to come up with heaps of convoluted and complex operations and exceptions.
Basically, there are 3 different scenarios (with regards to “saving) that need to be handled:
1. Creating a new document.
Creating a new file isn’t done by starting the program and starting work, but by creating a new file *in the file manager* and then opening it. This file could be created by either dragging an object from a folder full of “document templates” (OS/2 style), from a File -> New -> [type] menu (Windows style) or, of course, from a right-click context menu.
2. Saving an open document:
Done with a simple “save” keyboard shortcut, menu item or toolbar button. All that happens is the changes made since the last save are committed. Documents should also “autosave” as frequently as possible (ideally after every keystroke).
3. “Saving As” an open document:
Done from the file manager. Create a copy of the existing file (should work even if the file is currently open) and then open it. The file should open with the same contents that were last “saved”.
Implementing this would remain consistent with existing drag & drop operations, not require crippling drag & drop activities with things like compulsory context menus and create a more document-centric interface. It would also allow the complete elimination of Save/Load dialogs, as all relevant operations could be easily and (reasonably) intuitively performed via the hallowed (;) ) drag & drop.
The only problem is that it would represent a fairly fundamental shift away from how people are used to operating (open application, “create” a new file within the app and then save it). The reason you are having so much trouble coming up with a good way to used drag & drop to save things is that you are trying to combine two fundmanetally different metaphors – the document-centric drag & drop activity with the program-centric concept of creating new files *within* the application, instead of from within the broader UI. Personally I think document-centric is better, but the general public seems to disagree (at least, Microsoft have been trying to encourage it since Windows 95 and it *still* hasn’t been adopted, which is a fairly comprehensive rejection).
Of course, Linux advocates (and unix weenies in general) are probably horrified at the necessarily large amounts of interaction between the file manager, desktop environment (which should include the file manager anyway) and applications
.
And about the music player, why can’t it be like a real jukebox? If you put a disc in the jukebox, you don’t have it anywhere else anymore, so why should it be different with computers?
Because while it’s fairly difficult to make a jukebox just disappear by accident, it’s *very* easy to close an application (never mind application crashes). Rest assured, if my CD player disappeared every time I turned it off, or at random intervals, I wouldn’t be putting anything in it I didn’t have a copy of somewhere else
.
Of course, humans make errors, so some kind of undo functionality should always be available. But that is nothing new, right?
Well, it sort of is. Again, it basically boils down to optimising for the common case. Most of the time, people are going to want to fire up an MP3 player, listen to a few songs and then close it again. Having to remember to create copies of the songs and/or remember to drag them out of the MP3 player before closing it simply requires the user to do things that they shouldn’t have to. Remember, computers are supposed to make our lives easier and *reduce* the amount of work we have to do
.
Just like the overwrite behaviour of Windows isn’t really undo-able, I would say that it were better if the original file would be put in the trashbin if you overwrite it.
There are technical problems with doing this, as well as practical ones. From a technical perspective, it would require enough intelligence in the shell (doing it in the filesystem itself would probably not be a good idea) to realise a file was going to be overwritten and then move it somewhere else before the “new” file was written. It would also require a great deal of spare disk space.
From the practical side, it would double (on average) the time taken for overwriting a file and require much more maintenance overhead on behalf of the user (they’d need to remember to empy the trash a lot more often to clean out the accumulating cruft).
Probably a better way to approach this would be built-in file versioning. Whenever a file is overwritten (or changed) it simply stores the new version alongside the old. However, the same problems with regards to disk space apply. NT/XP’s NTFS has the (low-level) capabilities to do this, although since it would store the different versions in “streams” of the same file, it make moving such files between platforms problematic.
Well, no. It isn’t. It provides a different way of saving files; there’s no need to browse to a particular folder multiple times. (It also means you can drag from one program to another, for instance, you can create a file, edit it, open the savebox and drag it straight to a gzip creator, from which you can drag it straight to your email client without ever having written the file to disk. Or you could drag straight from your browser to a tarball extractor and not litter your HD with .tar.bz2 as well as the extracted files. You may or may not find them useful, but I do.)
This could be done better, another way, by moving from the application-centric method of creating files to a more document-centric method and basically eliminating the need for a “Save” operating that involved naming the file. Please see my other reply just above this one for a better explanation.
Is all text on your computer editable? On a webpage, can you edit the text? Well, then textboxes are inconsistent!
You are jumping to ridiculous extremes trying to make a point.
No, all the text in my UI *isn’t* editable – but anything that should be, is and, more importantly *looks* like it is. A titlebar has defined, well understood functions of a) describing a window and b) indicating window status. Overloading it to allow (non-obvious) arbitrary editing ability to do something that *should* be done in the file manager is not a good idea.
Manipulating files is something that should be done in a file manager, or at the very least something that *looks* like a file manager. Applications are for editing an objects *content*, not its metadata.
It makes no sense to save my buddylist window, so why would I try? OTOH, it makes plenty of sense to save my conversation window, so one window titlebar makes sense to edit and the other doesn’t.
Actually I can think of several reasons why someone might want to save their buddy list.
The main problem here is deciding what deserves to get an editable titlebar, in what circumstances and how to inidicate that a titlebar is editable (without negatively impacting how it indicates other things).
Perhaps I worded it poorly. What I meant was, that dragging & dropping (between applications, in particular) is not something that is immediately obvious as possible.
So DnD within a single application is something immedialety obvious?
No. *No* drag & drop ability is immediately obvious. It’s probably one of the most difficult UI manipulations to grasp.
Are users that frightened of computers that they don’t realise they can move objects, just like they can move objects in real life?
Yes. More accureately, they’re frightened because they don’t know what will happen.
Or how about the fact that there’s no difference in look between a menubar and a label? How do I know that clicking one results in nothing, and the other results in a menu coming up, other then learning?
Uh, most UIs these days do something on mouseover to indicate a menu is clickable (and if they don’t, they should). Except MacOS, IIRC, but it doesn’t really need to because there’s only one menubar (so it’s obviously something different).
Further, doing so will involve a very different set of interface semantics to dragging & dropping in, for example, the file manager.
[Further, doing so will involve a very different set of interface semantics to dragging & dropping in, for example, the file manager.]
I don’t quite understand why.
Because in an application you are manipulating an objects *content*, while in the file manager (which is really just an extension of the Desktop UI as a whole) you are manipulating the object itself (or its metadata, if you prefer).
In either case, they’re copying something (filer: a file, text editor: the file) from its present location (filer: a folder, text editor: the screen) to another location (a folder).
Actually in the case of the text editor it’s the contents of the file (ie: the text being display).
The reason it’s different is because of what needs to happen at the target. Whereas with dragging a file around in the file manager the outcome is obvious and fairly limited (the file is either moved or copied into the target and will replace any existing, identical objects), with dragging data around the result may not be (eg: if you drag the same block of text to another text editor window twice, should the next drag replace the existing text as a file would, append to it, insert at the cursor point, open in a new window, etc ?).
I’ve seen this argument before and it’s specious. The Start Menu is simply the starting point for everything you do in Windows. It’s not simply for “starting programs”. The Start Menu is the most logical place for things like “Shut Down” and “Log Off”.
The argument wouldn’t’ve been invented if it weren’t at least vaguely unintuitive.
Just about everything to do with using a computer the first time is (at the very least) “vaguely unintuitive”. The important part is whether or not it remains unintuitive once you’ve learnt the basic “rules” of the system. The placement of the Shut Down command meets this criteria – one of the basic rules with Windows is that everything is accessible, one way or another, via the Start Menu, so it is a logical place to put the Shut Down command.
Yes, but it’s not discoverable *because* it’s not an intuitive action. Indeed, from the aspect of physical device interaction, it’s one of the hardest skills to master (followed by the double click).
Whether something’s physically easy in one medium has little bearing on whether it’s intuitive. I might have a collection of dozens of people here all using touch screens or tablets, neither of which make DnD physically difficult (or no more so then moving a mouse/using a trackpad without DnD is).
It’s not so much that moving the mouse is difficult, it’s that targeting it correctly *and* clicking (and holding) at just the right, then moving the mouse, then releasing it at the right time is a difficult skill to master. Moreoever, I was just raising this as an additional aspect of the difficulty involved in drag & drop, not the only one.
As an aside, using drag & drop on a touch screen vs a mouse would be much more physically demanding because the user has to move their entire arm and hold it up off the desk (or for a screen embedded in a desk, has to hold their head at a bad angle). This is one of the reasons why fancy touch screen or Minority-Report-esque interfaces are unlikely to ever be of interest to people who have to spend a lot of time actually *using* them – simple muscle fatigue makes them practically unusable for any length of time.
However, any normal person would expect only one of them to happen.
Naturally, that’s why they’re the “reasonable” results. The problem is that until the user actually does it, they aren’t going to know *which* one will happen (and at least one of them is destructive, making it “scary”).
A well-designed application will make one of them more obvious, even if others are possible, and will make that the default. Furthermore, a well-designed application will give feedback as to the most likely outcome (for instance, DnDing onto a playlist would result in a horizontal bar between other items on the playlist, indicating that the files will be inserted into the playlist between the two songs on either side of the bar).
Doing this well is actually extremely difficult. In the case of inserting to a playlist it’s realtively easy, but indicating what will happen if the user just drags to the application window is very difficult.
(This is the conclusion from my last post. Sorry about the length, but it’s a topic I have a great deal of interest in).
Again, the big problem here is trying to shoehorn drag & drop into places it just doesn’t belong. In particular, trying to come up with ways of making it intuitive and usable from the application-centric metaphor when a better solution is making the whole UI work better with the document-centric metaphor of drag & drop. Instead of taking some procedure and trying to make drag & drop fit (eg: starting an application, creating a file and then saving it) try thinking about the *outcome* you want and the procedure in broader terms (eg: creating a new text document) and then fitting it into the existing drag & drop paradigm.
I wouldn’t say they’re any harder to learn than memorizing keyboard shortcuts. And I forgot to add before that they should be combined with a pie menu style right click, at least by default.
From Ask Tog:
http://www.asktog.com/columns/022DesignedToGiveFitts.html
“Question 7
Name at least one advantage circular popup menus have over standard, linear popup menus.
With the options displayed around you in a circle, you need only move a pixel or two to enter the “slice of pie” you want. Less travel, good target size. Good design.
They have a second advantage of feeding not only distance, but direction information into your motor memory. As long as the options are few enough, you will soon learn to move your mouse up and to the left to print, down and to the right to fax, etc. In fact, once these simple gestures are learned, you needn’t even display the menu anymore, unless the user hesitates long enough to indicate they may be unsure. (This was borne out during the course of the Fabrik project at Apple in the late 1980s.)”
In a perfect world I imagine both of these working together, along with OpenGL assisted scaling and layering of windows / files, to create a rudimentary “Minority Report” style interface. I see spatial folders as the tip of the iceburg of a more tactile, physical based UI experience.
I wouldn’t say they’re any harder to learn than memorizing keyboard shortcuts.
Which are also, comparitively, quite hard and a feature for advanced users
.
And I forgot to add before that they should be combined with a pie menu style right click, at least by default.
Yes, pie menus are a great idea. The only real problem is displaying readable text in the “slices” (and the whole discoverability problem inherent to right-click/context menus).
Another potential issue is keeping the options in them limited enough such the the movements are still distinguishable (from a mouse gestures perspective). Any more than about 6 slices and I’d suspect it becomes fairly hit-and-miss.
I see spatial folders as the tip of the iceburg of a more tactile, physical based UI experience.
I have to disagree here. Really, we need to *reduce* the amount of physical interaction required. I’m hoping that the computer interface of the (medium-term) future will be something resembling those “chord keyboards” that two devices (one for each hand) with ~5 buttons each. The “mouse cursor” (probably better described as “input focus”) would be positioned by devices in the screen(s) detecting eye movements to see where the user was looking. The “keyboard” would allow the user to influence what the “cursor” was doing (eg: highlighting text, selecting objects, “picking up” objects, etc) and other input would come via sub-vocal speech recognition. Keeping a “regular” keyboard around for input would probably also be a good idea (eg: sore throat).
[DnD saving, moving files straight from one program to another]
This could be done better, another way, by moving from the application-centric method of creating files to a more document-centric method and basically eliminating the need for a “Save” operating that involved naming the file. Please see my other reply just above this one for a better explanation.
Not entirely. I don’t see how you could extract a file you’ve seen on the web without saving it first; or else, I don’t see how you get the option of saving it. If you have the default action when clicking on an archive to run an extractor program, (a) how does it know where to extract to? and (b) what happens if you clicked on a link that you didn’t know took you to an archive and you wanted to save it? Both of these can be answered very simply and with a document-centric model with DnD saving.
Is all text on your computer editable? On a webpage, can you edit the text? Well, then textboxes are inconsistent!
You are jumping to ridiculous extremes trying to make a point.
No, all the text in my UI *isn’t* editable – but anything that should be, is and, more importantly *looks* like it is. A titlebar has defined, well understood functions of a) describing a window and b) indicating window status. Overloading it to allow (non-obvious) arbitrary editing ability to do something that *should* be done in the file manager is not a good idea.
On the case of defined, well-understood functions vs non-obvious arbitrary editing, you have to realise that a different environment will sometimes have to be strange in order to do different things. It’s an aspect of innovation. Secondly, the screenshot in my earlier link wasn’t designed by me. I would personally make it more obvious that the text in the titlebar was editable; or at least, provide some clear environment-specific queues to easily distinguish editable titlebars (names of documents, folders, metadata of MP3s) from uneditable titlebars (dialog boxes etc). If someone could show me why what I think of as uneditable titlebars should be editable, I might change my view.
You keep talking about a document-centric environment, but you describe a filemanager-centric enviroment. In a document-centric environment, why should the tasks of managing documents be limited to the file manager? If I start editing a file, and now I get to a point that it’s on a different topic and the titlebar inaccurately describes the window, why shouldn’t I go off and change what the titlebar says (and thereby changing the icon in the filemanager) rather than switching modes? Why shouldn’t a window simply be a zoomed-in icon, as it were? (The rational for the rather different looks is that when you zoom out far enough, you have to use an icon because you won’t see the individual detail.)
Actually I can think of several reasons why someone might want to save their buddy list.
Elaborate.
The main problem here is deciding what deserves to get an editable titlebar, in what circumstances and how to inidicate that a titlebar is editable (without negatively impacting how it indicates other things).
Indeed. I’m sure it’s not unreasonable to say that all are editable. I also thing most people accustomed to working in an environment that saved/renamed files in this manner would know which titlebars it makes sense to edit and which it doesn’t.
Are users that frightened of computers that they don’t realise they can move objects, just like they can move objects in real life?
Yes. More accureately, they’re frightened because they don’t know what will happen.
And those of us not frightened should suffer as a result? Why should I use the same environment as my grandmother?
Uh, most UIs these days do something on mouseover to indicate a menu is clickable (and if they don’t, they should). Except MacOS, IIRC, but it doesn’t really need to because there’s only one menubar (so it’s obviously something different).
Yet most people got by perfectly well before hand, didn’t they? Nevermind; we happily distinguish between copy-and-pastable text and other text by other cues. Same can happen here.
Because in an application you are manipulating an objects *content*, while in the file manager (which is really just an extension of the Desktop UI as a whole) you are manipulating the object itself (or its metadata, if you prefer).
But if the window represents the document/object, as it should in a truly document/object-centric environment, why shouldn’t it be no different from the icon?
In either case, they’re copying something (filer: a file, text editor: the file) from its present location (filer: a folder, text editor: the screen) to another location (a folder).
Actually in the case of the text editor it’s the contents of the file (ie: the text being display).
Sorry, we’re talking about two different things here. I’ll elaborate later when I have more time
Doing this well is actually extremely difficult. In the case of inserting to a playlist it’s realtively easy, but indicating what will happen if the user just drags to the application window is very difficult.
Document-centric applications would most emphatically *not* open the file. A file dragged into the document would be asking for its contents to be copied into the point of the drop i-beam, conveniently shown at the nearest character gap in the text.
(I’ll elaborate more later today on some of the snipped points, I just don’t have the time right now. At some point in early June I might elaborate on it at great length, but I’m relatively busy till then. If you want to hear my elaboration, email me. My email’s on my website.)
Not entirely. I don’t see how you could extract a file you’ve seen on the web without saving it first; or else, I don’t see how you get the option of saving it.
Ideally, you’d drag the link to wherever you wanted to save it. Or to some icon representing an action (eg: uncompressor, printer) if it were appropriate.
An excellent example though, I hadn’t thought of that
.
If you have the default action when clicking on an archive to run an extractor program, (a) how does it know where to extract to? and (b) what happens if you clicked on a link that you didn’t know took you to an archive and you wanted to save it? Both of these can be answered very simply and with a document-centric model with DnD saving.
Well, it still wouldn’t really be “document centric” if you’re performing file-management related activities within an application…
Also, if all you’re doing is redoing a “Save” that just puts up an icon that can be dragged then IMHO that’s mostly a difference of semantics.
On the case of defined, well-understood functions vs non-obvious arbitrary editing, you have to realise that a different environment will sometimes have to be strange in order to do different things. It’s an aspect of innovation. Secondly, the screenshot in my earlier link wasn’t designed by me. I would personally make it more obvious that the text in the titlebar was editable; or at least, provide some clear environment-specific queues to easily distinguish editable titlebars (names of documents, folders, metadata of MP3s) from uneditable titlebars (dialog boxes etc). If someone could show me why what I think of as uneditable titlebars should be editable, I might change my view.
The trouble is you’d have to make the “editability” of the titlebar obvious, which would then make it look quite different from titlebars that *weren’t* “editable”. So what should be a common, consistent UI element would appear to be arbitrarily different all over the place.
You’re also making the primary purpose of a titlebar something that should be done in the file manager/shell, not a window.
Incidentally, I think you meant “cues” not “queues” (this is not a spelling flame).
You keep talking about a document-centric environment, but you describe a filemanager-centric enviroment.
A filemanager is simply a function of the shell.
In a document-centric environment, why should the tasks of managing documents be limited to the file manager?
Because that’s the only way to access the files
.
If I start editing a file, and now I get to a point that it’s on a different topic and the titlebar inaccurately describes the window, why shouldn’t I go off and change what the titlebar says (and thereby changing the icon in the filemanager) rather than switching modes? Why shouldn’t a window simply be a zoomed-in icon, as it were? (The rational for the rather different looks is that when you zoom out far enough, you have to use an icon because you won’t see the individual detail.)
If you want to think like that, then consider “switching bacK” to the file manager to be “zooming out”.
Basically, (re)naming files by editing the titlebar makes two identical pieces of functionality exposed in completely different places, different contexts, different metaphors and different (user) mindsets. Manipulating filenames is a file manager (/shell) job, it should be done there.
Also, consider a file manager window with the path to the folder (or even just the name) in the titlebar – should it be editable to rename and/or move that folder ?
[Actually I can think of several reasons why someone might want to save their buddy list.]
Elaborate.
Back it up (may not necessarily be saved on the server side).
Print it.
Copy it into another application.
[Yes. More accureately, they’re frightened because they don’t know what will happen.]
And those of us not frightened should suffer as a result?
I’m sorry, but I’m not seeing any “suffering” going on here
.
Why should I use the same environment as my grandmother?
Why shouldn’t you ? There’s no reason an interface can’t be simple *and* efficient.
Uh, most UIs these days do something on mouseover to indicate a menu is clickable (and if they don’t, they should). Except MacOS, IIRC, but it doesn’t really need to because there’s only one menubar (so it’s obviously something different).
Yet most people got by perfectly well before hand, didn’t they?
Evidently not, or they wouldn’t have changed it
.
Nevermind; we happily distinguish between copy-and-pastable text and other text by other cues. Same can happen here.
Actually we can’t. One of my biggest gripes is that most shells don’t allow arbitrary bits of UI text to be selected and then copy-pasted. It often trips users up as well, I’ve seen people trying to select the text in dialog boxes (eg: error notification) in numerous occasions.
More importantly, there’s no obvious distinction between text that is selectable and text that isn’t – it’s something learned by experience, not intuited from UI cues.
But if the window represents the document/object, as it should in a truly document/object-centric environment, why shouldn’t it be no different from the icon?
Sorry, I’m not sure what you’re driving at here.
[In either case, they’re copying something (filer: a file, text editor: the file) from its present location (filer: a folder, text editor: the screen) to another location (a folder).
Actually in the case of the text editor it’s the contents of the file (ie: the text being display).]
Sorry, we’re talking about two different things here. I’ll elaborate later when I have more time
Please do.
Document-centric applications would most emphatically *not* open the file.
Well, “document-centric application” is a bit of a contradiction – in a document-centric UI you should never actually *see* “applications”
.
A file dragged into the document would be asking for its contents to be copied into the point of the drop i-beam, conveniently shown at the nearest character gap in the text.
Why wouldn’t it be inserting an OLE-stle link ? Surely if the user wanted the file’s *contents* he would have opened it and dragged them instead ?
(I’ll elaborate more later today on some of the snipped points, I just don’t have the time right now. At some point in early June I might elaborate on it at great length, but I’m relatively busy till then. If you want to hear my elaboration, email me. My email’s on my website.)
Uh, maybe I’m feeling particularly docile at the moment, but I couldn’t find your email address
. If you read this, please drop me a mail – drsmithy at optusnet dot com dot au.