One of the strengths of RISC OS is the ability for people to drag’n’drop objects around the desktop. It’s usually hard to describe how well this works, but other operating systems are rapidly catching up. While RISC OS still arguably has the edge, Drobe spoke to a number of professionals who rely on the drag’n’drop in RISC OS.
Why We Love Drag-and-Drop on RISC OS
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 read it…maybe I just dont get it! Maybe you have to try it to get it! Count me as dense.
Mac OS was always (as far back as I remember) good at drag and drop. You could drag and drop from most places to the desktop to creat climppings, and then drag these into places you want them.
I think the single mouse button forced the developers to use drag and drop where otherwise they might have put a contextual menu.
Good drag and drop? Not really.
Take for example the simple task of extracting a ZIP file, then going into the folder, cutting the file and then going up directory and pasting. This is a very common action.
Because there is no cut for files in OS X, you are forced to drag. You can use column view, or open two windows. This is additional window management, and I don’t always have my windows that way. There’s no way for me to, when dragging a folder, go up one folder. I have to renavigate from / or ~. I can’t drag the file onto the back button and the finder window go back as expected. I can’t drag onto the path button and go to any parent path, as expected. I cannot drag onto the proxy icon and subnavigate, like expected. I can’t drag onto a minimized window (like I can with Windows), like expected.
Drag and drop has a lot of room for polish in OS X. Nothing obvious, natural, or helpful is possible when dragging files.
Good Drag and drop? Yes. Awesome drag and drop? Maybe, depends on how and who.
As for cutting files, dragging and dropping them moves them. If you want to copy or make an alias instead, hold down a modifier key. As for having two windows open, you really don’t need to if you learn the ins and outs of spring loaded folders. One thing I do miss from the OS 8/9 days is tabbed folders that would pop open when dragging something over the tab. I would love it if they put something like that into Leopard.
Further good examples of Mac OS Drag and drop is with pictures and such, or even a frame from a movie. Drag and drop it to any app that supports it or to the desktop.
Regards,
NeoX
Drag and drop has a lot of room for polish in OS X. Nothing obvious, natural, or helpful is possible when dragging files.
I completely agree with your first statement.
As for the second one, “nothing” is a bit too strong. For instance, while you can’t “go up” in the directory (in this case meaning going to a previous folder), you can drill down with spring-loaded folders, which OS X inherithed (after much complaints) from OS 9.
I can’t drag onto a minimized window (like I can with Windows), like expected.
True, it would be nice if implemented. OTOH, for non-minimized windows you can start a drag, call up expose (I have it set to screen corner activation, but the default keyboard method works too) and hold the icon over a window to bring it to the front.
Also, while in Windows you would drag a text file onto an open (empty or not) notepad document to open it, in OS X you drag it to the application icon in the doc, not into a window. Dragging a file into a document window in OS X doesn’t mean “replace this document with the one I’m dragging” but “insert the document I’m dragging at this point in the open document”. Different semantics.
Take for example the simple task of extracting a ZIP file, then going into the folder, cutting the file and then going up directory and pasting. This is a very common action.
Actually, in RISC OS, it didn’t work like that.
Starting with RISC OS 3, archives were treated and behaved like regular directories no matter where you accessed them from, whether the command line or the filer. They were both simultaneously a file and directory, and you could tell them apart by the icon assigned to their file type.
FileCore (which is the system module that deals with file systems) allows you to write image file systems, and the handlers for archives were written as image file systems.
And to think I had to wait over a decade until another OS even barely approached this.
For all its problems, RISC OS really does kick an awful lot of ass.
I tried the “full” ROX Desktop in the past, which tries to mimic RISC OS. The idea is that you use drag ‘n’ drop for nearly everything.
Want to hear an MP3? Drop it to the player. Print a file? Drop it to printer. Unzip it? Drop it to unzipper, etc. No need for right click menus etc., keep the complexity to a consumer device level (whenever possible).
This metaphor advertises a healthy dose of “everything is an object” (not the excuse for overengineering) and is attractive to both laypersons (simple to understand, by analogy to real life) and tech people (who would find this clean and “elegant”)
I am sure other OS/Desktops support this too to varying degrees, but at least Windows/Gnome/KDE don’t advertise it enough and they don’t push it enough to be the dominating use pattern.
I assume Smalltalk and NeXT pioneered this approach.
Edited 2006-08-06 18:49
Hmmm – that sounds a little bit like the good ole PMShell/Workplaceshell – the graphical shell of OS/2-eCS.
Hmmm – that sounds a little bit like the good ole PMShell/Workplaceshell – the graphical shell of OS/2-eCS.
Not to mention good ole Sierra/Lucasgames adventures 😉
This metaphor advertises a healthy dose of “everything is an object” (not the excuse for overengineering)
When it comes to the metaphor of “everything is an object” i much longer prefer the right-click approach.
If something is an object, right clicking on it shows me all the operation i can do with it, without the need of other objects.
Drag and drop looks more like a “procedural approach” where the object is the data and the place where you “drop” it is the function.
Want to hear an MP3? Drop it to the player… Unzip it? Drop it to unzipper
Eh. Those sound like they’d be better candidates for double clicking. To be honest, I don’t like the concept of unzipping at all; probably the nicest thing about Windows is that explorer can browse zip files. Rather than having an extractor, you can just open it up and drag the files to where you want them, which can save my desktop from being swamped with files in the cases when people don’t put stuff in a folder before zipping.
> can save my desktop from being swamped with files in the cases when people don’t put stuff in a folder before zipping.
That’s just because uncompressors are badly done, what they should do is:
– if the archive contains only one file or one directory, open it in the current directory (by default updating the timestamp of the uncompressed file / directory to the current time but with an option to preserve the time if desired).
– if the archive contains several file or directories, create a directory with the archive name and extract the files inside.
The current behaviour is stupid: either you get lots of files on your current directory or you get a directory contains an unique subdirectory, bah.
No. A compressed archive is just that–an archive of files. Now, here’s a question for you: what’s an uncompressed archive? Why, it’s a folder, of course. Now tell me, why would you want to invent a completely new interface for something that’s practically identical to a current one? That doesn’t even mention the extreme inconsistency within the concept itself–what if I want all the files to unzip into this directory?
I was talking about compressed archive, so why are you replying about uncompressed?
An additionnal ‘special’ interface to manipulate compressed archive (the winzip right-click) is useful because accessing individual files in the archives is significantly slower.
Currently in winzip when you right click, you have the choice to put the file in the current directory or to put it in a subdirectory, but if you want to put them into their own directory you have to know whether the files are already in their own directory or not, which is stupid.
RISC OS actually deals with archives (zip files etc) very well. It has something called “image file systems” which allows files to be treated as directories. So not only can you browse an archive’s contents and copy things out of it using drag and drop, you can also load zipped files into an application without unzipping them or even save directly from an application to the zip (and apps don’t need to be specially coded to support this).
I love ROXFiler, and I’m using it as my main filemanager on various Linux desktops (Feather Linux seems to use it by default, and both Puppy and DSL make it available as an installable module).
As a long-time OS/2 and 68k Mac user, it makes me feel right at home. 🙂 Though it sounds like RISCOS may have been there first. Regardless, though, it’s a very cool way to manage files…
Maybe I do everything wrong but in gnome when I want to listen to music I simply drag the files over into the application I have open for playing music. Does this count?
Can someone give some obvious examples of how drag and drop works on risc as compared to those examples on linux and windows?
There are no ‘file requesters’ for loading and saving. The icon that represents the file that you are working on is accessable from a context menu (there are no drop down menus, only pop up, context menus). You drop this file where ever you want.
You can drop the file into a filer window to save the complete document. Also, you could drop a document into another document and the applications will know what to do. For example, a wordprocessor might set up a live OLE link if you drop a spreadsheet into the phrase. This works for complete documents via ‘save as’ and selected documents via ‘save selection’.
When using other OSes, how often can you see the folder that you want to save to in a filemanager, yet you have to go through the file requester dialog to find the folder again?
Also, RISC OS has a GUI that doesn’t encourage you to work full screen all of the time like most modern ones do.
Other operating systems may come close to RISC OS drag and drop today, but when I first used tried it in the late 80s it was very impressive.
The first demo of RISC OS that I watched showed a simple DTP document being created purely using the built in apps and drag and drop. A picture and some text were opened in !Paint (bitmap drawing) and !Edit (text editor), then a few frames were made in a blank !Draw (vector graphics) document. Selections from the image and text were then simply dragged into the frames to instantly create a page layout. I was very impressed with the elegance of that compared with importing using file dialogs.
Along with the elegant window management and menu system in RISC OS, its drag and drop made it a wonderful OS for DTP, where you’re building a document from a number of different sources and have multiple documents open simultaneously. When you consider how much cheaper Acorn’s computers were than equivalent Macs, it’s amazing that they didn’t have more success in the DTP market. I suppose people were put off by the lack of mainstream apps and Acorn’s image as a supplier of computers for education.
Of course Acorn didn’t invent the idea of drag and drop, but I don’t think any other OS around at the time had such a complete, elegant and powerful implementation of it, not even NeXTSTEP or OS/2. I think Mac System 6 allowed you to open documents using drag and drop (or did that come with System 7 in the 90s?), but you definitely couldn’t drag selections between documents, and I don’t think you could even drag a file from the Finder into a running app. In RISC OS you could drag and drop documents from the Filer, or selections from a document, to running app icons on the Iconbar (its Dock/Taskbar equivalent), as well as into open documents.
Of course modern OSes come close to catching up with RISC OS, even though their drag and drop generally isn’t as consistent, but the one remaining drag and drop feature that’s pretty much unique to RISC OS is drag and drop saving. I simply can’t understand why modern GUIs stick with clumsy and crippled file dialogs for saving files, when drag and drop saving is such a logical, consistent and elegant idea.
In my opinion file dialogs for saving are a throw back to the days of single tasking GUIs like the original Mac OS or Atari TOS, where the full file manager wasn’t available while you were running another application. Most of the time I have my document directories open, yet in Windows/Mac/Linux I still have to navigate to them in a file dialog when I want to save. Drag and drop saving is particularly nice if you want to save documents to several different locations that are buried deep in the file system. You can simply keep the directories you’re using open and quickly bring them to the front for saving.
Of course modern file dialogs, with their lists of recently used files/directories and other quick navigation features, are a lot better than the ones we suffered back in the Windows 3 and System 6 days. But why are they needed when you can quickly access a much more powerful multi-window file manager that allows for faster access to different folders?
I have to say I too am impressed by drag-n-drop saving. It makes so much sense from a interface-metafor point of view. Of course it helps that the window manager in RISC OS supports both the spatial and browser-mode of managing windows, depending on wether you open folders with the left mouse-button, or the right mouse-button. Integrate some shortcuts to your deskbar, and voila: excellent workflow, without the metafor-sheer of being confronted with the trappings of your filesystem.
Of course modern OSes come close to catching up with RISC OS, even though their drag and drop generally isn’t as consistent, but the one remaining drag and drop feature that’s pretty much unique to RISC OS is drag and drop saving. I simply can’t understand why modern GUIs stick with clumsy and crippled file dialogs for saving files, when drag and drop saving is such a logical, consistent and elegant idea.
In my opinion file dialogs for saving are a throw back to the days of single tasking GUIs like the original Mac OS or Atari TOS, where the full file manager wasn’t available while you were running another application. Most of the time I have my document directories open, yet in Windows/Mac/Linux I still have to navigate to them in a file dialog when I want to save. Drag and drop saving is particularly nice if you want to save documents to several different locations that are buried deep in the file system. You can simply keep the directories you’re using open and quickly bring them to the front for saving.
The entire concept of saving is already a fairly dated procedure. When you write a paper do you have to save it to keep the changes? no. When you scribble on a piece of paper does it automatically disappear when you throw it in the corner? The technical hurdles of such a system has long ago gone away, even for the more extreme approach of saving every revision of every document. Why should I have to open an application to create a document if I’m already in the folder I want to create it in? Why isn’t there just a ‘create’ menu that allows me to create any sort of document I want in the file manager, then open it to modify?
Exactly, one thing though: Drag and drop saving would still be a wonderful solution for exporting.
Been following GNOME 3.0? This seems to be where it’s headed..
Nope, never even heard anything about it. I have other problems with gnome and really pretty much every distro, although that would definitely be an improvement.
Doesn’t the Apple Newton OS have an utter lack of ‘save’ options in its programs? I autosaves everything I think. Not sure though, never used it.
> I think Mac System 6 allowed you to open documents
> using drag and drop (or did that come with System 7
> in the 90s?), but you definitely couldn’t drag
> selections between documents, and I don’t think you
> could even drag a file from the Finder into a
> running app.
Nope. System 6 did drag and drop. The only bit that I have never tried is the “Drag sections”.
A good site to look at for Mac info (IMO) is http://www.folklore.org – from the horses mouth, so to speak.
I have the feeling that many (ex-)Archie users have extremely rose tinted glasses. All I remember from my (fairly extensive) 3 or 4 years use of Archies (college and at home on an A3000) was that they were horrible. Slow, crash prone, horrible to program for. It was also crippled with a similar file typing scheme than MacOS IIRC.
To be honest – many things about RISCOS look like things in MacOS. As to who was first – dunno.
Edited 2006-08-07 10:38
You couldn’t drag from the Finder to a running app in System 6, at least not by default. System 6 was still single-tasking IIRC.
Maybe you could with MultiFinder…
Miltifinder was part of System 6. I’ll fire up my Mac Classic and look – if I can be bothered 😉
In my opinion file dialogs for saving are a throw back to the days of single tasking GUIs like the original Mac OS or Atari TOS, where the full file manager wasn’t available while you were running another application. Most of the time I have my document directories open, yet in Windows/Mac/Linux I still have to navigate to them in a file dialog when I want to save. Drag and drop saving is particularly nice if you want to save documents to several different locations that are buried deep in the file system. You can simply keep the directories you’re using open and quickly bring them to the front for saving.
On OS X, you can do that… sort of. 🙂
Instead of dragging a file to save to an already open folder, you do the exact opposite: drag the folder in which you want to save it (or the proxy icon for it in the window titlebar, if the folder is already open) to the file save dialog.
If you want to overwrite a file, drag a file into the file save dialog instead.
yeah, works in KDE too. but i think it’s rather different 😉
What has RISC got to do with dragging and dropping? RISC is hardware, dragging and dropping is software. Please excuse my ignorance.
RISC OS was the revolutionary operating system devised by Acorn, back in 1987 to power the world’s first ARM based personal computers (despite what Apple claimed at the time!). Yes, Acorn were also the inventors of the ARM (Acorn Risc Machine) chip, which is arguably the most abundant micro processor in the world today, powering thousands of devices from mobile phones, personal electronic organisers and printers to desktop computers and video game consoles.
> back in 1987 to power the world’s first ARM based
> personal computers (despite what Apple claimed at
> the time!).
Okay. The Mac arrived in 1984. Apple did not claim it was ARM. It did have the first widely available GUI interface. That interface relied heavily on drag and drop.
Apple then used PowerPC processors in their Macintosh computers. Not ARM.
I’m not really clear what you are getting at.
If you said “first RISC based” personal computers, then *that* might make some sense, I guess.
> If you said “first RISC based” personal computers,
> then *that* might make some sense, I guess.
I think this is indeed what flywheel meant. Apple made some claims in adverts about them being the first company to ship RISC-based personal computers, to which Acorn objected at the time:
http://tinyurl.com/mmk5o
All a bit ironic, given the direction ARM and Apple have subsequently gone!
You missed the “OS” part of the title of the article. This is about “RISC OS,” not “RISC.”
>> You missed the “OS” part of the title of the article. This is about “RISC OS,” not “RISC.” <<
Ahh, thank you!
After reading http://en.wikipedia.org/wiki/RISC_OS I do have to say that that’s pretty impressive for 1987.
‘Twas always one of the features I liked about BeOS. Especially:
– drag a folder / file onto an Open/Save box and the window changes to that folder
– text can be dragged from one entry field to another, E.g. if I mistakenly type a message subject in the address line, it can be selected and dragged to the subject line
– if you open an image in ShowImage, drag to make a selection, and then drag the selection to the Desktop / a folder, a new file will be created with the contents of the selection – and dragging with the right mouse button gives a pop-up to select the desired file format
– in the same way, audio clippings can be dragged from the SoundRecorder app (right-dragging lets you choose the codec)
– the same thing works with text selections / clippings and most applications, of course
– while playing a video in MediaPlayer, you can drag-and-dropping from the video window creates an image file of the current video frame
most of these things work in KDE now, tough some annoying exceptions are there – like how you can’t drag’n’drop text from konqueror. but i guess KDE 4 will fill in the last few voids 😉
most of these things work in KDE now, tough some annoying exceptions are there – like how you can’t drag’n’drop text from konqueror. but i guess KDE 4 will fill in the last few voids 😉
That makes sense. Based on my limited knowledge of programming, those sorts of things are much simpler when a C++ API is used (as is the case with BeOS and KDE, IIRC).
If only the creators of all of these great old operating systems had paid more attention to decent marketing and provided better environments for new developers, the world would have been a much better place now with true competition in the operating system market instead of a world of Microsoft dominated desktops.
nice, realy nice.
done it have something similar to what lisa had, where you just dragged a “pad” of a empty file type to create new files? (edit: after a re-read i see that it does. and in a interesting way even)
only refinement i can see is if the “save as” didnt need a dialog but had a icon of some sort allways present in one of the corners of the window. want to save the file with a new name? drag said icon where you want to save it and give it a name.
if the program window was just closed, the file would be autosaved (no question asked). but the filesystem should support logging of changes so that you could roll the file back all the way to its original creation variant if you wanted to.
Edited 2006-08-07 05:31
only refinement i can see is if the “save as” didnt need a dialog but had a icon of some sort allways present in one of the corners of the window. want to save the file with a new name? drag said icon where you want to save it and give it a name.
Agreed, except I would take it one step further by integrating with the window manager. Let the user edit the file name directly in the title bar, and put the dragable icon next to the name. Changing the name in the title bar doesn’t affect any existing files, only which name to use next time the file is saved (ctrl-s would save in the same folder as the old file).
What does RISC OS have over Windows, for example? right now in Windows I can drag-n-drop anything from/to any window, and if the application accepts it, the mouse cursor changes. I really do not understand what is you can do with Risc OS that you can’t with WinXP.
And let’s not forget the Amiga: you could drag-n-drop even from two different video modes!
right now in Windows I can drag-n-drop anything from/to any window
Is that so? Try dragging a pain and simple txt file into an open Word document. Windows will already mess up with such a simple operation. (Admitedly, I have Office 2003 which is not the newest, things might have changed somewhat since then, but I strongly doubt it has catched up with RISC OS from the ’80s)
Is that so? Try dragging a pain and simple txt file into an open Word document.
I just did and it opens as a document as it should. Your point was?
My point was that:
1) Here it creates an icon inside the Word document. When double-clicking the icon it asks if you’re sure you want to open that other program, it could be very dangerous. (Office 2003 on XP)
2) What it should do is import the text from the file into the document.
Nope. System 6 did drag and drop. The only bit that I have never tried is the “Drag sections”.
I definitely remember using System 6 on a Mac II and finding that I couldn’t drag and drop files into document windows of the application I was using. Presumably it was dependant on the application whether this was supported, while in RISC OS drag and drop was pervasive. Also, the lack of an equivalent to the Iconbar in System 6 prevented the use drag and drop to quickly open a document in a running app like you could in RISC OS. System 6 had drag and drop, but it was nowhere near as powerful and consistent as drag and drop in RISC OS.
I have the feeling that many (ex-)Archie users have extremely rose tinted glasses. All I remember from my (fairly extensive) 3 or 4 years use of Archies (college and at home on an A3000) was that they were horrible. Slow, crash prone, horrible to program for. It was also crippled with a similar file typing scheme than MacOS IIRC.
That depends on what you’re comparing them with. Obviously compared with a modern PC/Mac running a UNIX or NT based OS, a 1980s Acorn with RISC OS is going to be relatively slow and unstable, but in my opinion that isn’t true when compared with the alternatives around at the time.
For the price of an Archimedes with colour graphics and a RISC CPU you could barely even pick up a Mac Classic a tiny mono monitor. A Mac II was far more expensive yet still had a slower CPU than the Acorn’s ARM. Amigas and even IBM PC clones were also more expensive than equivalent Acorns, and obviously the PCs were crippled by their terrible OS/GUI.
Like Amiga OS, Windows 3 and Mac OS, RISC OS lacked memory protection and could be brought down by a misbehaving application, but in my experience it certainly wasn’t less stable than those other OSes. I experiences far fewer crashes in RISC OS 3.1 than in any version of System 7, despite primarily running mainstream apps on a Mac that was kept clean of extensions. One nice thing about RISC OS was that the OS was in ROM, it couldn’t be damaged by software and restarting a RISC OS system took seconds.
Of course it’s the GUI that we were discussing here, I think even the hardcore RISC OS fans would admit that the underlying technology is dated compared with modern operating systems; it’s the elegant GUI that keeps people using it. In my opinion the GUI was far ahead of its time and was better than Windows 3 or System 6/7 in almost every way. It wasn’t just the powerful drag and drop that this article focuses on; its use of contextual menus, document centric UI and elegant window management features all contributed to making it one of the most elegant and productive GUIs ever designed. When it comes to getting work done I think RISC OS still beats the latest versions of Windows and compares well with Mac OS X, not bad for a GUI that hasn’t changed much in over 15 years.
This isn’t nostalgia for a computer a used years ago, and I’m not looking back with “rose tinted glasses”. I still own and use RISC OS hardware and can compare it side by side with my computers running Windows XP, Linux and Mac OS X.
How’s d’n’d compared to BeOS (haven’t used RISC OS)?
GNOME recently did some usability analysis and found that saving was one of their major UI problems:
http://primates.ximian.com/~federico/docs/gnome-deployments-2006/in…
So maybe something will get done. I wrote a blog post about ROX’s saving a while back here:
http://rox.sourceforge.net/desktop/node/318