Flutterby™! : Reminder of the morning 2010-01-18 16:31:45.824931+00

Reminder of the morning

2010-01-18 16:31:45.824931+00 by Dan Lyke 8 comments

This is a drum I've beaten since probably the late '90s, but as we're designing software, can we drop the notion of a document that loads into a local cache and needs to be saved regularly? Web development is helping this process, and there are probably aspects of the "File" menu we can't get away from, but if we can work on thinking about software without pushing that memory/disk dichotomy into the way that we use software, we'll end up with happier users.

There's no reason that we as software developers and designers can't take on that cognitive load ourselves, once, rather than making the user do it every time they user our apps.

My first real exposure to the "fileless" style of computing happened when I got my first Newton in the mid-90s. It takes some adjustment to get used to it, that's for sure. Jef Raskin tried doing this with the Canon Cat in the late 80s (he also did a version of literate programming, only with BASIC, which seemed rather unique).

Last year I wrote a sudoku program that has no visible save files—rather, it saves its state when you exit the program, and picks up right where it left off when you restart (it even saves the undo-redo state!).

Also, I did my greylist daemon with a "fileless" mindview. There's no configuration file per se, but you modify a running instance of the program and it saves all the state it needs behind the scenes.

Granted, the traditional "File" menu is a broken metaphor, but it provides a rudimentary form of revision control. I would rather go in the direction of a "Repository" menu with some innovative representation of branches and multiple users, than be stuck with a single version and be afraid to experiment.

As a user I'm not going to be thinking in any way other than the "document" I'm working on. I'm not concerned about the internal workings of the software or anything other than my document. I want to know where to find it, how to manipulate it and what to do with it after I'm through working with it so I can find it again to work on it. How is what you are talking about going to improve upon what I already know how to do enough to warrant my relearning how to do this?

Incidentally, while I've got you programmers on the line, I'd like to beat my own favorite drum: When you design a form to receive telephone numbers, if it's only for one country/protocol, place a block for area code, exchange and number, and jump automatically, or provide one blank, and be tolerant of hyphens or spaces in the entry (edit them out later). Likewise credit card entries - MC and VISA have 4-4-4-4 and AmEx has some other pattern, but you could provide a broad field and be tolerant of spaces or hyphens so we can easily see what we enter. You can edit them our later.

Andy: One of the problems is managers who have complaints like yours but don't understand that their programmers can't really do that without creating a bigger PITA. Doing the "jump automatically" for form entry in a browser means writing a bunch of JavaScript. Which is all fine and good - except that JavaScript on MS IE is different from JavaScript on FireFox. Yes, there is a standard and FireFox does a better job of implementing it...

But about 60% of web users, overall, and about 80% of non-technical web users use IE as their primary browser. So that leaves the programmers having to sort out what actually works in IE and deviating from the standard.

Form validation in the browser has always been a sticking point. It's actually about 10 times more complex than it should be, just based on the technology most managers are told exists. It's also about 100 times more complex than it used to be on mainframe computers.

As for files, I still cling to a paradigm that gives me some sense of comfort. I know that if I copy a file to another machine, the contents are still preserved even if that machine doesn't have the program installed that is used to manipulate it. I know I can copy the file to yet another machine, with the appropriate software, and manipulate the file. I also know that I can save my file and be able to go back to that point in time, no matter what happens to the computer I'm working on (see the earlier bit about moving the file off somewhere else). As early as last week, I was dealing with software, released in the past 6 months, that crashed regularly.

I do believe the cloud metaphor could alleviate most of these problems. But it requires placing a great deal of trust in the cloud. Google has only occasionally given me reasons to doubt my trust. Fortunately, it's just been a few hours here and there of Gmail outage and not data loss or corruption. And even though it's painful, it is much better uptime than when I admin'ed my own server.

The cloud metaphor also forces the shift away from "file in memory" because one of the selling points of the cloud is collaborative editing. You can't have five people editing a single document with each one having a separate copy. Merging the changes becomes a nightmare.

That's a GOOD thing, I've written a lot of things in comment boxes.. that felt great when I wrote them, but then I took a breath and deleted, or edited before I clicked SAVE.

I don't have a particular problem with files and folders (or subdirs) as a mechanism for organizing documents, I think that's a metaphor which works fairly well. It's the cache notion that I think we need to transcend.

On form validation: Please please please don't give me a phone number entry with 3 different fields which auto-skip through some horrific JavaScript abomination! Let me copy and paste into that field. Don't make me see it as three different fields which I start to tab through and then everything breaks and...

And I have no problem with leaving a "publish" button on the web form, but if your browser crashes and you bring it back up, you should still have your writing. Something Firefox is getting better at.