Document Representations

In response to Stuart:

I don’t think it’s a good idea in general to confuse the user with the technical difference between data in memory and data that has a representation on disk.

What I would like to see in the long-term is:

* Every document is stored on disk (and regularly synced), even if it’s as anonymous files in a temporary directory. “Saving” a document should be as simple as giving it a name, which might then move the document to a permanent storing location. In the usual case, I believe that documents should be created first and then edited. I would see temporary documents mostly used for things like working image copies in Gimp.

* Very direct mapping between a document on disk and its corresponding window, e.g. it should be possible to manipulate a window in the same way you can manipulate the icon representation of a document (drag it to the web for uploading, and things like that). I’m not sure if the “icon in a window” approach of OS X is the best way to do it, but that would be one possibility. Nautilus implements something like this with the folder button in the status area for spatial windows, but there is no general way to do this right now.

Generally, creating, naming, moving and deleting files should be a breeze, wherever you are, so that the idea of creating a new document does not seem like a chore or give the user the feeling of creating a mess. Sensible names and places should be suggested and data stored in a way that does not crowd the data that the user cares about most. Also, accessing a document should not have to involve finding the document at its physical location, but still give the option in case the user would like to put it in a specific place for quick access (e.g. the Desktop, as long as it acts as a workspace).

Of course none of these ideas are new, so this is not a useful post in any way. But I think it’s a petty that we still don’t have the means to even allow applications to implement these kind of mechanics in a sensible way. Let’s think about it, and let’s solve it.

Advertisements

12 responses to “Document Representations

  1. Why does the user have to understand that there’s a difference between data-in-memory and data-on-disc? If you think about that, the difference between those two is: here are some documents which you will lose if there is a power failure, and here are some documents which you will not lose. That doesn’t sound like a useful distinction to me 🙂

    Also, the reason I built the thing is precisely because I don’t care about a representation on disc of a quick image I’m throwing together in the Gimp. I’m doing it precisely so I can add it to an email, or upload it to my website, or upload it to imageshack, or upload it to flickr. If you explicitly create a representation of it on disc then I later have to find that representation and delete it. That’s really irritating.

  2. “Why does the user have to understand that there’s a difference between data-in-memory and data-on-disc? If you think about that, the difference between those two is: here are some documents which you will lose if there is a power failure, and here are some documents which you will not lose. That doesn’t sound like a useful distinction to me :-)”

    I completely agree with that, and I hope that my post did not imply otherwise. 🙂 There should be no difference to a user.

    “Also, the reason I built the thing is precisely because I don’t care about a representation on disc of a quick image I’m throwing together in the Gimp. I’m doing it precisely so I can add it to an email, or upload it to my website, or upload it to imageshack, or upload it to flickr. If you explicitly create a representation of it on disc then I later have to find that representation and delete it. That’s really irritating.”

    I think I addressed this point twice in my post: First, this is what temporary documents could be good for, in particular if you create images from pasted data and such. Second, it shouldn’t be irritating and you wouldn’t have to find the document on disk, if the document window itself could be removed just the same (e.g. by dragging it to the trash, via some representation like a document icon or the Nautilus folder button perhaps).

    Also, if you create a quick document and still don’t feel like removing it, it wouldn’t do any harm either as long as it’s stored in a sensible place where it doesn’t get in the way. You never know when you might want to find something you created a couple days ago. Of course disk space filling up is a remaining concern, but it should not be hard for the computer to suggest sensible clean-ups if space ever becomes an issue.

  3. Currently gnome sucks for “pipeline” behavior. When a user wishes to do a series of things, it get ugly because drag and drop doesn’t work from places that matter.

    In windows file selection dialog has drag & drop capability. So at least there is the possibility that if i want to transfer a picture from one application to another i can open the save dialog box, save and then grab it from right there and drop it to whichever application icon i want to open it with.

    In gnome the situation is pretty bad because drag & drop is pretty spotty. For example drag & drop from archive manager to nautilus works only when nautilus is in icon presentation mode (or list presentation, i always forget). So this will be always a first break in a chain of actions (thunar BTW works wonderfully for this situation).

    Let’s open GIMP with the just saved image (which were inside the archive above). Change something, try to archive it and send it back. In gnome every chain in the above series of actions “breaks” because you have to hunt the intermediate objects (edited image, archive etc) in the filesystem.

  4. I think there is a useful distinction between “files on disk” and “files in memory” that every user gets: One of them is open in my image editor window, the other isn’t.

    So having a shortcut to “things open in a window” in my filechooser sounds like an awesome feature. Double so for people that do not work with d’n’d (I personally hate it but there’s definitely older people or people with disabilities who can’t press a button for too long).

  5. “So having a shortcut to “things open in a window” in my filechooser sounds like an awesome feature. Double so for people that do not work with d’n’d (I personally hate it but there’s definitely older people or people with disabilities who can’t press a button for too long).”

    If windows would be tightly matched with documents, having something like “Active Documents” in the file chooser would make a lot of sense. Although it really shouldn’t be required as a replacement for DnD. Something like copy and paste would seem more straight forward (not saying that the file chooser can’t be more useful in some cases).

    It wouldn’t make sense to me to have a specific list of open documents outside the file chooser, as this would essentially duplicate the functionality of the window list (and obviously what you are seeing on screen). It might be interesting to explore if open documents and applications could be accessed in different ways though (from the panel).

  6. While I appreciate what Stuart is trying to do and why he needs to hack together a convenient solution to this specific problem, I cannot for the life of me understand why GNOME has failed, repeatedly, over many, many years to simply implement XDS. Of course not all apps are going to support this initially, but there is 0 incentive to support it in things like FF and OO if the desktop environment in which they are running does not support it. Chicken or egg.

    GNOME needs to embrace XDS and get it’s act together- and going to 3.0 is the *perfect* time to finally do this-compatibility is going to be broken- so seize the day and finally get a really smooth drag and drop functionality going in GNOME. I remember trying some basic drag and drop some number of years ago-dragging a desktop icon for a document onto the app icon on the taskbar- for some apps it worked-for others it did not. This spottiness causes people not to want to count on such.

    I should be able to grab the document in any application (think the working document being viewed in an application) and drop it any other running application or the application icon residing on my desktop or on the panel which knows how to deal with that document. If I have an icon for my printer on the panel I should be able to drag a document from gedit to the printer icon and it should be printed-it should simply work. If I drag the text I am writing in Gedit (a document) into Nautilus it should simply save the file in the current directory, or drop it onto the folder icon on my desktop-one could simply grab the first word of the file and the date/time to create a filename-or throw up a prompt asking me to name it. If I am editing a file in pivitivi (sp?) I should be able to drag it into totem or vice versa. If I have an icon for a sftp server connection I should simply be able to drop a file onto the icon and have it land on that server in that directory. This stuff should just work. There is no good reason that it does not.

    Some will maintain that it is not discoverable. BS. If it works and is reliable 1 properly made video included on the GNOME release notes page and 1 packaged with the distro to be installed in the users home directory during install as an “introduction to drag and drop on the GNOME desktop” would suffice to make people aware of it. I have witnessed new users first trying drag and drop, anticipating that it might work, only to be frustrated that it does not-and that is new users, ones who have never used GNOME before.

    GNOME has hackers working on FF and OO. If GNOME were to embrace XDS as a standard and integrate it at the toolkit level (perhaps via dbus) it surely would not be difficult to get support for this in the non-GNOME applications which we daily use. I do not know the ins- and outs of where(ie. what level) to best integrate XDS support nor the proper mechanisms for supporting it. But one aspect of usability is those things which pervasively penetrate the entirety of a desktop(ie. supported *everywhere* in the desktop), so pervasive that it becomes a “way” to navigate and manipulate the objects in that environment. These things become the “identity” of the desktop itself-ie. those things that we call parts of a desktop are seemlessly drag-and-droppable. Why oh why does GNOME not recognize such things ? Why do other desktop consistently get things like this right while GNOME ignores and glosses over such things ?

    As time goes by I am becoming more disillusioned by the “progress”- each and every dev wants to “re-think” the desktop and “re-imagine” some totally new, totally untested interaction paradigm and remain utterly oblivious to remarkably simple issues of usability which are imminently doable now within the given framework which so many people would profit from. It is so disheartening that I fear the “desktop” will be obliterated and replaced by some task-focused (hold my hand gently while telling me what to do) and that such functionality will be rendered irrelevant because I won’t have that level of control over that which I am working on anymore. Please tell me I am wrong. Proper support for dnd has been the basis for sooooo many bugs, so many users have requested it,so many have complained about it over the years, that the issue has almost become taboo on the mailing lists. GNOME does have some functional dnd, *but* it is not pervasive, it is not reliable, and it does not, because of these factors, become a genuine part of the interface. And this, my friends, is trully, trully sad.

  7. XDS however is not the ultimate answer to all DnD issues. If we would start from the assumption that documents are always stored on disk somehow (temporary or permanently), then XDS isn’t even needed. We would merely need a consistent way to interact with the underlying document from a window. And the latter I find far more important than XDS in the first place, because XDS only solves a small part of the problem.

    Some of the other things you mention should definitely work right now. E.g. dragging text to a Nautilus window does create a new document containing this text (a feature I haven’t found particularly useful yet, but I guess it’s good to have).

    I’m a bit at a loss why dragging documents to a launcher is not working consistently. I just tried with Scratchpad, and noticed that it only works if I set the command to “scratchpad %U” instead of just “scratchpad”. The latter works just fine however when used with “Open With” in Nautilus, is there any reason why it should behave differently if a document is dropped on a launcher?

    It is indeed very important that we get things like this consistently right, so it should be extremely easy to implement this kind of functionality and extremely hard to make a mistake. Little pitfalls like this just shouldn’t exist, even if there is some intriguing explanation for it.

    Another thing that bugs me is, why there is such a big difference between what you can do from the context menu of a document icon, and what you can do from the File menu of this document’s window. Things like “Move to Wastebasket” should really be in there.

    When it comes to document handling, Nautilus is the one application that really gets it right in my view (if we consider a “folder” the type of document Nautilus works on). I wish we had the mechanisms in place to allow other document-handlers to reach the same level of integration.

  8. Nicolas Mailhot

    « Why does the user have to understand that there’s a difference between data-in-memory and data-on-disc? If you think about that, the difference between those two is: here are some documents which you will lose if there is a power failure, and here are some documents which you will not lose. That doesn’t sound like a useful distinction to me »

    It is a very useful distinction at the user level because it cuts boths ways :
    1. In case of crash or other failure, the documents will be lost. You will lose work. Bad
    2. But in case of forced stop, the documents will be lost. The on-disk version is not touched yet, and the system will forget the mistakes you’ve made in the last 10 min while working on a stupid idea. Good

    Hiding the distinctions thus serves no purpose. Users are *happy* that stuff can be made not to have ever happened just by leaving without saving.

  9. “1. In case of crash or other failure, the documents will be lost. You will lose work. Bad”

    That should not happen. Data can be synced to disk transparently at opportune moments. A feat which web applications are strangely often better at than current desktop applications (case in point the WordPress editor). We have a lot of catching up to do in this regard. Browsers do some good with crash recovery. Scratchpad is not likely to lose your data, because everything you typed is stored on disk almost immediately.

    “2. But in case of forced stop, the documents will be lost. The on-disk version is not touched yet, and the system will forget the mistakes you’ve made in the last 10 min while working on a stupid idea. Good”

    Then press a button to delete your stupid idea document (which _should_ be possible, but sadly is not right now). It’s not even an additional click, because you are not bothered by the annoying “unsaved changes” dialog.

  10. iwbcman: Hear hear! I don’t know if any modern systems do it, but the Xerox Alto actually printed that way. If you wanted to print to a certain printer, you simply copied a document icon to that printer’s icon on your desktop (as far as I know, drag-and-drop, alas, wasn’t around yet); if you wanted to e-mail a document, you copied it to your outbox, which was simply an icon on the desktop. There was no special e-mail application, as e-mails were merely documents sent to other people. In fact, there were no applications at all (that is, none exposed to the user), but only one document viewer/editor, and only one document type. It was almost the most document-centric system that ever existed, where people actually worked with their stuff, rather than with “applications”. I find it rather ironic that I covet an interface from the 70s. I think there’s a lot that could be learned from how things used to be done before 1984.

  11. Daniel,

    I am sure that you know the specifics of XDS far better than idea, and are more aware of it’s shortcommings. But rather than argues about XDS let’s focus on what d’n’d should be like on a modern desktop:

    1. I am viewing a PDF and evince highlights the email addresses in the pdf (colors them blue for instance). I should be able to simply drag a document on top of the email address and have evolution spring up with a new window where the document is already attached, the subject name already taken from the document name, the To: field already filled out, and the address already added to my contact list.

    2. I am working on an image in Gimp and have telepathy running with 5 friends online. I should be able to grab the image from the window and drop it on the avatar of my friend from the status menu drop down on my panel and have telepathy automatically send the document if the protocol supports file transfer and if not to defer the file to evolution ie. have evolution spring up with a new window where the document is already attached, the subject name already taken from the document name, the To: field already filled out, and the address already added to my contact list(of course only if that contact is not already present in my contact list-which of course should never be the case because evolution contacts should know all of my telepathy IM friends). Of course the same should also work if I am using evolution instead of telepathy ie. I simply drag the image and drop it on the address of the friend of mine listed in the evolution contact list.

    3. Right now I can drag and drop files into the nautilus burn window to burn a cd. But I should be able to do this by simply dragging the files onto the icon for emtpy CD-RW/DVD. I should also be to drop files on the printer icon in the panel and have them cued( perhaps it would be better to be able to drag it onto the specific printer or PDF icon in the printer management window).

    The point to these examples is that we know what kind of documents we are dealing with (MIME type). The icons can relay this information to the applications associated with the icons. If the application can do something with the file type it should just do it : ie. evince can only present files, nautilus can only save files, printers can only print files, evolution can on email files, empty cd-rom icons only save files. Logic should be present to see the relations between IM contacts and email address and take advantage of the application functionality when choosing what to do: ie. send the file via IM OR email it. I agree with you that much would be gained if we just assume that documents are always stored on the disk- when I grab an image from Gimp it should simply resolve to the filename of the temporary file containing the image, and abiword/gedit should also return the document name when I drag the document from inside the abiword window to some other place or icon on the desktop. But in-use documents being saved temporarily only solves part of the problem. Another part of the problem is building the logic around recognizing mime-types, the associated applications and the specific mime-type-application paired functionality.

    It seems to me your idea of temporary storage coupled together with intelligent dbus use could go a long way to making real d’n’d work. My way of thinking goes like this: each app registers the mime-types that it works with on dbus and it’s functionalities (paired with mime-types). Any time something from inside an application is dragged out of it’s main window a signal is sent to dbus with mime-type context info(containing the temp name of the file corresponding to it-or recognizing an email address or URL), when the user drops this then on some other application, the desktop or an icon, the registered functionality of the application, or the registered mime types associated with the icon should intelligently perform some action according to this logic(ie. display, send, email, print the object being dropped). If I drag an email address from a document onto my evolution icon evolution should present me with the option of adding to my contact list or emailing that address. If I drag it onto FF and FF “knows” that I use gmail for my email then it could open a compose page in a new tab in FF. I should be able to drag a PDF from evince into OO3 and have it imported into OO for editing.

    What would be really cool is for friend of mine listening to music to simply drag a song from banshee onto my icon in telepathy and have a blue underlined text appear in the IM “Music: FooBar” and I could click on that link and either a) have it stream to totem so I can hear what they are listening to or b) allow me to simply drag it to my desktop(ie. if i drag it into banshee it would download and be added to the my music directory and player,/cued, or drag it into totem and be streamed, or onto my blank cd-rom icon ie. downloading, converting to wav and burning it)

    These are the kinds of functionality I would love to see in GNOME. Every single thing a computer can do to reduce the number of steps that I need to do in order to get the desired result is a win. GNOME already has so much unused information floating about and most GNOME apps are oblivious to other GNOME apps. Perhaps I confuse GNOME with the GNU Network Object Model Environment.

  12. I was walking along the road last week with my gal talking about the RAM vs. disk stupidity. Some of our friends don’t know the difference, and being around a geek for the last seven years, she’s got a thorough understanding of this concept. I told her, though, that I don’t think it SHOULD matter, and that eventually it won’t matter because disks will become fast enough that we won’t have to store documents in memory at all. This is not far from what you’re proposing here: temp files with revisions.

    On the larger discussion of work-flow, I’m happy that Abiword lets me edit an embedded image in Gimp, and when I exit Gimp, the embedded image is updated. I don’t ever have to know where or how the image is stored. I wish every program operated that way.

    I’d like just one viewer (kind of Evince + EOG), which all things opened when I first view them. Click from there to edit in the same window (with additional toolbars as necessary). Click to stop editing. I guess this is not dissimilar to a wiki interface, eh?

    Give me task-based workspaces, where I have a project and certain application views on each one, remembered automatically. If I go to my *foo* project page, it moves applications from other workspaces as necessary and changes Evolution from, say, e-mail to tasks, opens certain web pages in a browser, brings up the most common contacts in IM/e-mail, and has recent documents ONLY for that project.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s