[danengel]

Here's an interesting article about crufty interfaces. What do you think?

Why do we have to "save" documents when working with them? I don't have to save what I write on a piece of paper.

Why do we have to remember file paths?

Why do applications crash?? I can't believe this, it's 2003, mankind had more than 20 years to think about this problem and most apps are still crap.

I find it surprising to how much garbage one gets used to and doesn't even notice it. In a way, computers suck big time. Still love wasting my time with them, though

-- Daniel

[Skywalkers new Hand]

Originally posted by danengel:
Why do we have to "save" documents when working with them? I don't have to save what I write on a piece of paper.

Because many times when working on something you want to make some crazy changes to see how it looks and not have it save.

Also I would like to see a piece of paper do the things I do with a computer.

[Phanguye]

Originally posted by danengel:
Here's an interesting article about crufty interfaces. What do you think?

Why do we have to "save" documents when working with them? I don't have to save what I write on a piece of paper.

Why do we have to remember file paths?

Why do applications crash?? I can't believe this, it's 2003, mankind had more than 20 years to think about this problem and most apps are still crap.

I find it surprising to how much garbage one gets used to and doesn't even notice it. In a way, computers suck big time. Still love wasting my time with them, though

-- Daniel

i hate when people make absolute claims that interfaces should mimic paper and physical folders perfectly

the problem is that, it doesnt make sense, writing on a computer isnt comparable to writing on a piece of paper... and it is because of these fundimental differences that a computer is more productive

why should we limit how productive a computer can be by tying it down to metaphors from a physical world

[cpac]

Not all that well thought out an article.

The points you seem to have seized upon:

(1) Why do we "save" ? documents - because working with electronic media is FUNDAMENTALLY DIFFERENT that working with pen and paper, and IT SHOULD BE. Word and other programs have auto-save features built in so that generally you don't lose much work in the relatively rare event of a crash. We use the "save" command to tell a document we actually want to make the changes we've entered permanent - many times I open a document make a few changes for a quick print-out but then don't want to save the changes I've made - I would think this would be even more common with graphics programs.

(2) Why do we have to remember file paths? - who says we do? Things show up nicely in the "recent items" menus, both the application-specific ones and the System-Wide ones. There's the whole "favorites" folder things as well, and high level searching capabilities. Remembering a file path is no more difficult than remembering which physical file/binder/box you put an actual document into, and it comes with the added bonus of efficient searching in case you forget.

(3) Why do applications crash? Well, 'cause it's a relatively young/new operating system. They don't crash nearly as much as they used to, and now if you use one app that crashes it doesn't affect your other apps. I can't remember the last time I lost work because of a crash...

[chabig]

Your analogy is flawed. Actually, I do have to save things I write on paper. That usually means filing it somewhere where it can be retrieved when needed. And it prevents it from being lost in the trash.

Write on paper = edit on screen
File paper = save file
Throw away scratch paper = close without saving
which file cabinet/drawer/folder... = path to file
Throw away previously filed paper = delete file

Chris

[zewm]

Originally posted by cpac:
I can't remember the last time I lost work because of a crash...

on a mac.. over here in the PC world, crashes happen almost within the hour

My computer crashed literally 8 times this morning

anyway, I totally agree to the fact that a computer ISN'T paper. In fact, I think we have it easier on computer. The fact that we can edit to any extent, without wasting paper, or having annoying marks all over your work to indicate that you did change things.. is proof positive. And maybe once I can afford a mac, I will also improve my grammer

[Toyin]

I understand the argument to some extent. I think ideally all changes would be saved the instant you make them. This document should also remember the last "x" states of the document and preferrably the entire history of the document. This way you would still have the ability to undo and have protection from crashes.

I agree that we have more than enough computer power and hard drive space in 2003 to make this a reality.

[Sage]

I've never understood why everything on the computer needs to be an office space metaphor... some of the analogies are good, such as a paper icon for a document, folders for directories, and a trash can. Some things just don't need it though... for example, I like the direction that Apple is taking with "tabs"-- Instead of using tabs, they'll be using neat push-button-control thingies with a recessed well for the "information" to dynamically change... that's the kind of stuff I want to see on computers.

[Catfish_Man]

Originally posted by danengel:

Why do applications crash?? I can't believe this, it's 2003, mankind had more than 20 years to think about this problem and most apps are still crap.
-- Daniel

Go develop some software. You'll find out very quickly why applications crash. A lot of it is because of schedules, changing requirements, and because modern software is far too complex for any human to understand (the largest program I know of that is essentially bug free is TeX, and iirc it's been feature frozen for over a decade, and was made by someone who is widely regarded as one of the best programmers alive today). If apps have stopped crashing in 2020 I'll be very very surprised (assuming the application paradigm is still around then). To give you an idea of how hard it is, according to one study NASA typically has one error per 10,000 lines of code (compared to 25 per 1,000 lines in a normal program). The cost of this kind of care is immense. Each line of code cost them approximately $1,000. In a 5 million line program (Windows is up to 35 million+ now), that would be 500 errors. In a normal software company, that would have been 125,000 errors.

[Karnac T. Magnificent]

Originally posted by Phanguye:
why should we limit how productive a computer can be by tying it down to metaphors from a physical world

ill never give up my black warrior and my legal pad. you technophiles make me so sick. computers are the devil and you all are going to rot in hell. you are such a tool phanguye. please permanently confine yourself to your room.

[Catfish_Man]

Originally posted by Karnac T. Magnificent:
ill never give up my black warrior and my legal pad. you technophiles make me so sick. computers are the devil and you all are going to rot in hell. you are such a tool phanguye. please permanently confine yourself to your room.

I think I'd have to mod this one surreal +1 if this was slashdot. Great first post

[Nonsuch]

Originally posted by Karnac T. Magnificent:
ill never give up my black warrior and my legal pad. you technophiles make me so sick. computers are the devil and you all are going to rot in hell. you are such a tool phanguye. please permanently confine yourself to your room.

Wow ... someone registered to post this.

[Phanguye]

Originally posted by Karnac T. Magnificent:
ill never give up my black warrior and my legal pad. you technophiles make me so sick. computers are the devil and you all are going to rot in hell. you are such a tool phanguye. please permanently confine yourself to your room.

oh man that is great... welcome to the monkey house karnac

[mpt]

I’m the one who wrote the original article, and I have to admit I find it amusing how people misinterpret it. (Though I suppose I should have been clearer, when proposing something that was so different from the status quo.)

Take for example Phanguye’s comment:

i hate when people make absolute claims that interfaces should mimic paper and physical folders perfectly

Where did I say that interfaces should mimic paper and physical folders perfectly? Oh, wait, I didn’t. Straw man. Please try again.

More interesting is cpac:

working with electronic media is FUNDAMENTALLY DIFFERENT that [sic] working with pen and paper, and IT SHOULD BE.

Unfortunately, putting something in capital letters doesn’t make it true. Working with electronic media is indeed different from working with pen and paper — but then, working with pen and paper is different from working with brush and papyrus, and working with brush and papyrus was different from working with chisel and clay, and working with chisel and clay was different from working with ochre and cave walls. So what?

The important difference is in what happens to your work when you’re done. For about 4975 of the past 5000 years, when anyone wrote or painted something, the default behavior was for it to stay written, until it was thrown in the Trash (or otherwise disposed of). All of a sudden, with the introduction of computers, this has changed: now, the default behavior (if you have a power cut, for example) is for your work to be deleted! You need to go to rather absurd lengths (“File”, “Save”, choose a folder, type a name, “Save” ) to tell the computer that you don’t want your work thrown away.

That’s pretty stupid, but it made a bit of sense, for about fifteen years, while we had really slow computers with really slow floppy disk drives. Now that computers and hard disks are much faster, people on this forum are trying to invent other reasons to continue with the current behavior — the current 25-year-old exception to the 5000-year-old rule — and doing a very poor job of it. Come on, you’re Mac users! Think of some decent reasons!

Here’s some to start you off:

1. “But we have really big files now — multi-hundred-megabyte Photoshop files, and stuff like that. I don’t want to be slowed down by those files being saved all the time.” (Answer: That’s what we call the tail wagging the dog. Currently life is being made easier for the few people doing humungous work in Photoshop, causing pain for the much larger number of people doing basic work in programs like Word and Keynote. That’s not fair.)

2. “So stuff would get auto-saved on my desktop, and then I’d have to drag it into the right folder (or into the Trash) myself? What a pain!” (Answer: That would be faster than the current way, because you could put multiple documents in the same folder at once, rather than filing documents one at a time like you have to do now. And you’d be able to do filing whenever you wanted to do it — at the end of the day, or the end of the week, for example — rather than having to file each document separately when you closed it.)

3. “But often I just make a new document as a temporary scratchpad. I don’t want my desktop covered with scratchpad files!” (Answer: Typing Command+Delete to send the currently open document to the Trash would be quicker than typing Command+W then Command+D[on’t Save] like you have to do now. Of course, “Undo” in the Finder would restore the file out of the Trash and open it up for editing again.)

4. “But it’s different! People won’t understand it!” (Answer: Yeah, and automatic ignition was different when it was first introduced, too. That doesn’t mean we should still be turning a crankhandle every time we start a car.)

-- mpt

[danengel]

Go develop some software. You'll find out very quickly why applications crash. A lot of it is because of schedules, changing requirements, and because modern software is far too complex for any human to understand

I just wonder how it is possible that when changing "i++" to "i--" on one of a million lines of code, the application wouldn't work anymore. Why are there no methodologies to prevent such faults?

[danengel]

Your analogy is flawed. Actually, I do have to save things I write on paper. That usually means filing it somewhere where it can be retrieved when needed. And it prevents it from being lost in the trash.

Write on paper = edit on screen
File paper = save file
Throw away scratch paper = close without saving
which file cabinet/drawer/folder... = path to file
Throw away previously filed paper = delete file

I like the way I don't have to save things in MacJournal, or FileMaker (at least when I last used it a few years ago). It seems more natural.

When I write something on paper, I have to choose neither a name nor a location for it, it's just somewhere on my desk. It IS saved, but not filed yet. Filing would mean to put it into a folder, but there are many unfiled notes on my desk with which I work. If I don't save something on the computer, it is lost, unrecoverably.

About file names: I recognize a note based on its appearance, the color of the paper, its size, the pen I used when writing it, not because I gave it a name like "Note about the Cake.txt". (To hell with extensions, anyway )

[Chuckit]

Originally posted by danengel:
I just wonder how it is possible that when changing "i++" to "i--" on one of a million lines of code, the application wouldn't work anymore. Why are there no methodologies to prevent such faults?

What, like an NSDoWhatImThinkingInsteadOfWhatIWrite option?

[danengel]

What, like an NSDoWhatImThinkingInsteadOfWhatIWrite option?

Are there no ways to systematically proove the correctness of an algorithm? I mean, important applications for the military, NASA, air or train traffic control cannot rely on "John Smart wrote this, don't worry, he's really bright", but need some real proof that they work under all circumstances, for any input data, for the most stupid user etc.

[Phanguye]

Originally posted by danengel:
Are there no ways to systematically proove the correctness of an algorithm? I mean, important applications for the military, NASA, air or train traffic control cannot rely on "John Smart wrote this, don't worry, he's really bright", but need some real proof that they work under all circumstances, for any input data, for the most stupid user etc.

there are ways to systematically test programs... unit tested developement using JUnit is now starting to catch on in some companies (such as IBM)... however, writing unit tests for every method in a large program is very time consuming... and time is money, and therefore most businesses will never adopt unit tested developement policies

beyond that the problem is.. the error might only come up one in a thousand times or one in a million... so it is hard to forsee every error... programers are not perfect, in fact we are normally sleep deprived and over worked...

but in reality, for your small little third party apps... there is no reason for their to be errors like we see... that is just a rush... and remember bad programs have killed people so you have to be careful

[Toyin]

Originally posted by Toyin:
I understand the argument to some extent. I think ideally all changes would be saved the instant you make them. This document should also remember the last "x" states of the document and preferrably the entire history of the document. This way you would still have the ability to undo and have protection from crashes.

I agree that we have more than enough computer power and hard drive space in 2003 to make this a reality.

I still agree with my statement above. It would probably work with large Photoshop and video files as well. The key would be developing a system where a file is built up of every step it took to make it. It's the same concept as a journaled HD but on a much smaller scale.

As for filing documents that could be a user option. The user could decide to move the document at any point along it's creation. There really is no need to change current work behaviors much.

[ameat]

Originally posted by danengel:
Are there no ways to systematically proove the correctness of an algorithm? I mean, important applications for the military, NASA, air or train traffic control cannot rely on "John Smart wrote this, don't worry, he's really bright", but need some real proof that they work under all circumstances, for any input data, for the most stupid user etc.

...it's called unit and system testing. you systematically overload your algorithm/application and watch how it handles the input. ideally for security purposes, you should explicitly declare what IS allowed rather than what isn't. however these are really two different issues...the correctness of an algorithm is separate from a stupid user...you test the algorithm and you test your means for preventing said stupid user from providing any bad input to your functioning algorithm.

[cpac]

Originally posted by mpt:
More interesting is cpac:
Unfortunately, putting something in capital letters doesn’t make it true. Working with electronic media is indeed different from working with pen and paper; but then, working with pen and paper is different from working with brush and papyrus, and working with brush and papyrus was different from working with chisel and clay, and working with chisel and clay was different from working with ochre and cave walls. So what?

So why is it necessarily better to have work be saved automatically? Just because people did it that way out of necessity for the last 5000 years doesn't make it right...

Never before have people had the option of continual modification/updating/testing their work, and the new functionality demands a new way of working.

now, the default behavior (if you have a power cut, for example) is for your work to be deleted!

Ok, (1) how often do you really have a power cut? (work on a laptop and there's virtually zero risk of this ever happening). (2) You don't lose all your work, at most you lose whatever you've done since your last save, and if you're working in an MS Office document, (or a document with any other program that have auto-save functionality) you lose very little, if anything.

That's pretty stupid, but it made a bit of sense, for about fifteen years, while we had really slow computers with really slow floppy disk drives. Now that computers and hard disks are much faster, people on this forum are trying to invent other reasons to continue with the current behavior; the current 25-year-old exception to the 5000-year-old rule; and doing a very poor job of it. Come on, you're Mac users! Think of some decent reasons!

You ignore the ones listed above:

Many people make changes to a document to see how they look, or to get a quick draft of possible changes. With the possibility that things on screen are changable people want a way to denote a fixed state - enter the concept of "saving."

(the proposed solutions of remembering each step in the process of creating the document is already creating nightmares for companies and law firms all over the world - Word documents, for example, frequently have information about the changes that were made to that document allowing one to peer into less well-phrased statements and/or the creation process of that document - it is this fear that is driving most companies/law firms to require that documents sent outside the firm be in .pdf format, though this is still far from standard practice)

In short, 5000 years mean nothing when you've got a completely new metaphore: changeable documents. It doesn't make sense to make changeable documents imitate the 5000 years worth of non-changeable documents. Think Different!

Why is 5000 years of "cruft" better than 25 years of cruft?

(as an aside, I notice you ignore the arguments w/r/t remembering file paths, crashing apps, or quitting applications -- these are places where your article is even more misguided than it is with respect to "saving)

[Cipher13]

Originally posted by danengel:
Why do we have to "save" documents when working with them? I don't have to save what I write on a piece of paper.

Cause if you f*ck up, you can fix it. F*ck up a piece of paper, and you're gone. That's a Good Thing™.

Originally posted by danengel:
Why do we have to remember file paths?

Why do you have to remember where you put your pieces of paper?

Originally posted by danengel:
Why do applications crash?? I can't believe this, it's 2003, mankind had more than 20 years to think about this problem and most apps are still crap.

Because programmers are not perfect beings? With unlimited funding?|

This paper "metaphor" can't go too far, or we'll wind up back at 5000BCE... with a piece of paper.

EDIT: cpac: beat me to it.

[mpt]

Originally posted by cpac:
So why is it necessarily better to have work be saved automatically?

Because when your work is saved automatically:[list=1][*]you don’t get interrupted with a confirmation alert every time you close a document you didn’t save immediately beforehand;[*]the safety of your work isn’t dependent on you doing the right thing with that alert (which is important, since ordinary humans usually don’t read alerts);[*]filing is quicker and more convenient, because you can file several documents all at once, whenever you want to do it, rather than when the computer wants you to do it.[/list=1]

Just because people did it that way out of necessity for the last 5000 years doesn't make it right...

True enough. But if you are going to change the behavior, it should be to increase people’s productivity and peace of mind, not decrease it. (Ever wondered why computer rage is so much more common than, say, pen rage or typewriter rage? Often it’s not because the computer is unreliable, but because it’s reliably doing something which doesn’t suit humans — like throwing their work away by default.)

Never before have people had the option of continual modification/updating/testing their work, and the new functionality demands a new way of working.

Like Cipher13, you’re conflating reverting with undoing. “Oh, but reverting is useful for going back to a known-good version!” is a very poor excuse for not implementing a multi-level undo in which such a reversion could be just as easy.

You do cite a legitimate concern with this model:

… Word documents, for example, frequently have information about the changes that were made to that document allowing one to peer into less well-phrased statements and/or the creation process … it is this fear that is driving most companies/law firms to require that documents sent outside the firm be in .pdf format …

I suppose you’d understand this more if you were a Linux user than a Mac user, but that’s a good thing. You shouldn’t have to pay a Microsoft tax to read something a lawyer sent you. They should Publish it to you, whether via a printer (no revision history there!), fax (ditto), e-mailed PDF (ditto), or e-mailed HTML (ditto). All those options should be available from the same dialog (something Panther is taking baby steps towards).

The current “auto-save” in MS Office et al. still requires you to battle through at least one confirmation alert and filepicker, so it’s still not good enough.

(as an aside, I notice you ignore the arguments w/r/t remembering file paths,

You’ll have to ask danengel what he was talking about there. Nowhere did my article say we have to remember file paths.

crashing apps

What arguments? This seems a red herring — except that you’re likely to lose more data from a crash, on average, in a program where you have to remember to save yourself, than in a program which saves automatically.

or quitting applications

Again, what arguments? Nobody here has discussed that section of my article at all — which has been an unexpected luxury for me, since it’s quite a bit harder to explain Quit-less apps to usability laypeople than it is to explain Save-less apps.

-- mpt

[Arkham_c]

There is a programming methodology called "XP", short for eXtreme Programming. It's not "extreme" in the sense of the X-Games. Rather, the idea is to take the best practices of programming, and push them to the limit. Examples include:

1) If code reviews are good, do code reviews all the time (continually, via pair programming)

2) If testing is good, write tests for everything. You write the test before you begin coding. That way, you know when you're done (when it passes the test).

3) If releases are good, release often. XP suggests daily or weekly releases.

There are several other good principles of XP, and of they're followed, development goes a lot faster and produces code that's much less likely to crash.

More info here: http://www.extremeprogramming.org/

[cpac]

Originally posted by mpt:
Because when your work is saved automatically:[list=1][*]you don't get interrupted with a confirmation alert every time you close a document you didn’t save immediately beforehand;[*]the safety of your work isn't dependent on you doing the right thing with that alert (which is important, since ordinary humans usually don't read alerts);[*]filing is quicker and more convenient, because you can file several documents all at once, whenever you want to do it, rather than when the computer wants you to do it.[/list=1]

Ok, First, the "annoyance" of remember-to-save boxes. There are two possible scenarios: either (1) you made changes since your last save that you want to save or (2)you made changes since your last save that you don't want to save. In the first case, this is a handy reminder, in the second it's a brief annoyance. Either way, it gives you the choice of whether the changes you made to your document are the type you want to be more permanent. Auto-saving makes this a no-choice scenario, and choice, particularly with easily modified media, (including anything on a computer screen), is a good thing.

Second, the "safety" of your work isn't dependent on you doing the right thing with that alert - just your work since the last save, i.e. the last time you deemed your work in a state worthy of making pseudo-permanent. (Admittedly, those confined to Windows dialogs have the bewildering choice of "Ok" or "Cancel" but Mac users have the much less confusing "Save" "Don't Save" and "Cancel" buttons all laid out for them. There's little danger of incorrectly dismissing these dialogs.

Third, filing a document is something that occurs once, one time, the first time you save a document, and thereafter is not necessary. Just as auto-save would (in your example) put documents on the desktop for later "group" filing (only more efficient if many things are going to the same place); you can simply leave the name of the document as the default and tell the system to always save everything to the Desktop - there's no more thought involved here than in other situations. Either way you'd end up with Document 1 and Document 2 on your desktop, both equally easy to deal with.

True enough. But if you are going to change the behavior, it should be to increase people's productivity and peace of mind, not decrease it. (Ever wondered why computer rage is so much more common than, say, pen rage or typewriter rage? Often it's not because the computer is unreliable, but because it's reliably doing something which doesn't suit humans; like throwing their work away by default.) Like Cipher13, you're conflating reverting with undoing. "Oh, but reverting is useful for going back to a known-good version!" is a very poor excuse for not implementing a multi-level undo in which such a reversion could be just as easy.

You've got a handful of arguments going on here. In turn:

"Change in behavior should increase productivty" - sure but whos to say the multiple level undo etc. will make people any more productive? It's a mere choice where the world has gone one way and you'd prefer it another way.

"Change in behavior should increase peace of mind" - is it more worrysome to think everything you type/draw/do in a document is being recorded in a master list of changes to be undone/redone at any point, or that you might have to remember to save every once in a while? (While we're at it, file corruption hasn't been solved, and if every change to every document had to be recorded in a document's history, what happens when that history becomes corrupt? disaster?)

"Computer rage more common than 'pen rage' or 'typewriter rage'"" - Well as for pen rage, I think that's stupid. People would get more angry at pens if they had to draft large documents using them (and every screw up was made in ink--permanent). Hell, I think the massive switch to computers as *the* means of producing documents is all the evidence of latent pen rage you'd ever need. - "Typewriter rage" is the same - people got plenty fed up with typewriters when they were in more common use - the fact that they aren't shows people prefer computers.

"Computer rage due to reliability at doing unexpected" - Nope. In my experience the thing that makes most people angry at computers is Microsoft software. It crashes like nobody's business, and has unintuitive dialogs with buttons like "Ok" and "Cancel" rather than the Mac's "Save" and "Don't Save." After crashes, most rage comes from inexperience regarding how to make a program do what you want it to do. This is simple lack of knowledge (and again M$ is partially to blame with all the things they automatically "help" you out with formatting-wise).

You do cite a legitimate concern with this model: I suppose you'd understand this more if you were a Linux user than a Mac user, but that's a good thing. You shouldn't have to pay a Microsoft tax to read something a lawyer sent you. They should Publish it to you, whether via a printer (no revision history there!), fax (ditto), e-mailed PDF (ditto), or e-mailed HTML (ditto). All those options should be available from the same dialog (something Panther is taking baby steps towards).

I agree it's a good thing, but the primary problem comes in sharing documents in editable format. As soon as you need to share things in an editable format, AND have a history of changes, you've got sharing of the history of changes, and that's unacceptable. (And what's with the condescending Linux talk? You think I don't wish there were viable .doc and .xls alternatives, just because I use a platform that has a version of Office?)

Nobody here has discussed that section of my article at all; which has been an unexpected luxury for me, since it's quite a bit harder to explain Quit-less apps to usability laypeople than it is to explain Save-less apps.

Then allow me to be the first.

from your article:
Trouble is, the “Quit” command has always been annoying and confusing people, because it’s exposing an implementation detail — the lack of multitasking in the operating system. It annoys people, because occasionally they choose “Quit” by accident, losing their careful arrangement of windows, documents, toolboxes, and the like with an instantaneity which is totally disproportionate to how difficult it was to open and arrange them all in the first place. And it confuses people, because a program can be running without any windows being open, so — while all open windows may belong to the file manager, which is now always running in the background — menus and keyboard shortcuts get sent to the invisible program instead, producing unexpected behavior.

Fortunately, technology has improved since 1984. We have the power, in today’s computers, to run more than one program at once, and to load programs in less than five seconds.

We have the technology. So why do we still punish people by including “Quit” or “Exit” menu items in programs? Cruft.

Ok, right off the bat, does "quit" really pose that many problems for people?

You suggest an inadvertent "Quit" loses window positions etc. Not in any good apps I know of. Try OminGraffle, or Photoshop - all the tool bars, palattes, etc. remember their position perfectly as soon as I launch the program again. Maybe you've just been using lousy software...

You criticize the ability of a program to be open with no windows open - this again is a choice (vs. the Windows way of doing things). But how in the world does having all applications always open address this (supposed) problem?


---------------------------------------

Basically I didn't address this and other arguments of yours ealier because they are, as I wrote in my first reply, not well thought out.

[ambush]

Originally posted by danengel:
Why do applications crash?? I can't believe this, it's 2003, mankind had more than 20 years to think about this problem and most apps are still crap.

Because they're coded by human beings and they make errors.

suppose you tell the computer to access an int at 0x0E83F2 and it does not exist because you already freed it. What the *hell* do you expect the computer to do?

In classic non unix mac, It'd crash and maybe seriously affect the whole system. But in UNIX, most kernel detect and kill the proc. That's clever.

And for the rest, there's a thing called abstraction. High level abstraction is good, but extremely high abstraction sucks.

[Uncle Skeleton]

Originally posted by mpt:
(Ever wondered why computer rage is so much more common than, say, pen rage or typewriter rage?

I appologize in advance for the fact that this rediculous argument was already addressed, but neither the scientist in me nor the obsessive prick in me could let it slide....

you're comparing the numbers of references to the different forms of authorship without considering the disparity of usage between the forms, and your sole source of data on those numbers is one of those very forms of authorship? <homer>oh, so they have the internet on computers now!</homer>

[holygoat]

Originally posted by danengel:
Are there no ways to systematically proove the correctness of an algorithm? I mean, important applications for the military, NASA, air or train traffic control cannot rely on "John Smart wrote this, don't worry, he's really bright", but need some real proof that they work under all circumstances, for any input data, for the most stupid user etc.

It's possible to prove the correctness of a program - not just test it, as previous posters have suggested.
It's called Formal Methods, and it's far too difficult for most programmers because of the mathematical content.
As a result, and because it's time consuming, it's expensive.
Anything which absolutely must be fully functional (e.g. for safety reasons) is often formally specified.

Remember, testing can show the presence of a bug, but never that none exist.
They're complementary techniques.

Google for "Formal Methods" if you want more.

Maybe if I feel like it after dinner I'll approach the main slant of this post

[holygoat]

There have been plenty of good responses already, but here are my thoughts.

LyX, the X11 LaTeX-based word processor, auto-saves regularly - even if you haven't already saved to a filename. Word does something similar. So if the program crashes, or the system dies, your work does not.
If you close deliberately, you can ignore the auto-save. That's a good thing - imagine if everything you ever wanted to jot down or print was saved. I'd spend half my time deleting things I only wanted to print.

The alternative to saving is entering a filename when you start (as in databases), or having to rename afterwards (as proposed). So auto-saving is not a time-saver. Auto-recovery of in-progress work is a good thing, but it's not the same thing.

Someone suggested saving changes automatically, with undo levels being saved. Two problems are clear from this:

(1) Things get pretty complicated, pretty fast. Programs would have to be quite intelligent to avoid ballooning file sizes (imagine copying and pasting the same large image inside a document - how many times will that come up in the changed file?), and loading the file would essentially have to reconstruct the document from the history, which would get pretty time-consuming with my 350-page report.

(2) If I want to then send on my document to someone else, I want to send the final document, not a bloated history of my writing. There have been plenty of leaks where Government departments have uploaded files as Word documents - which tracks changes, so prior drafts can be recovered from the file. This would be a nightmarish extension of that.
Maybe I'd have to edit the file again and use some weird function called... mmm... "Save"?


I think my point is that saving provides choice (whether to retain the document, what to call it, where to file it, and what changes to keep, as well as manual version control). The only advantage of a non-saving approach is protection against accidental loss - and there are better existing ways of dealing with this.

I hope that came out OK

[holygoat]

Regarding Quit-proofing: the PocketPC does not allow manual quitting of applications; instead, they are minimised. To truly quit means going into the memory management section and closing programs from there.

People liked that so much that every launch program started allowing application quitting, and even most vendors bundled some way of killing programs.

It doesn't matter how much RAM you have, you always want more. If every application I have on this machine was open constantly, my pagefile would be full, and booting would take forever. Instead, I keep the ones I need open; no more. "Quit" is a very natural action - put away my paints, close my bureau, lock the shed. Multi-tasking is similarly natural - leave the paints out, put the lawnmower off to one side.

Saying that Quit annoys and confuses people because it exposes a lack of multitasking is naive; while, e.g. MS-DOS needed Quit for that reason, multitasking OSes are by no means new. Quit has remained because of very real resource constraints and a definite desire for control - sometimes I want to close a program.
If you consider some programs that are noticeable resource or processor hogs (I can think of a few), you'd need to implement some kind of "Sleep" feature... maybe we should call it "Quit"?

The problem with your points, mpt, is that the functions you call crufty solve very real problems, and intrinsically follow metaphors (scratch paper, filing, and starting/finishing/postponing tasks). Any disjunctions with expectations are down to poor implementations (e.g. not allowing auto-recovery, forgetting interface settings), not a problem with the functionality.
I can't see a saveless, quitless environment being useful without a move to a component-based (a.o.t. program-based) operating system. And saveless I wouldn't like to see at all.

[strokemouth]

Originally posted by danengel:
I find it surprising to how much garbage one gets used to and doesn't even notice it.

-- Daniel

You mean like trying to do everything on their computer in the same manner as with tangible documents?

[Toyin]

I'm not saying folks arguing against this article are not forward thinking, but if in 10 years I'm still working with documents like I am today, I'll be pretty disappointed. I still think that auto-save and running-history(ASRH) is the most natural option in the future. I understand some of the points raised in this thread and I'll attempt to describe how I think ASRH should function.

1) Viewable History The argument that History should not be visible to others is easy to get around. Instead of a save and save as functions there would be 'save as' and 'export' options:

Export: This allows you to export the document as is (no history). This would also give advanced users an option to export files to different file formats. This way you can still export a .doc or .psd file to colleagues who can further edit the document.
Save as: This would allow users to decide exactly how they want to save the document. With ASRH the user would be allowed to decide how much history they would like saved with the document. A dialogue would allow you to save the document from a certain time or user selected milestones and wipe any previous history. This leads to the next argument.

2) Large document sizes As always options are important. Depending on how anal you are options should exist to decide how often you want to save a document. You could choose every keystroke (with your Future 20ghz G6 standard with 128gb of ram and 100 terabytes of storage) or you could save every few minutes (for those still stuck with a 10yr old dual 2ghz G5). The 'save as' function would allow you to save the document as is and wipe the entire history. Re-opening the document starts a new history which could be wiped later using the 'save as' function.

3) File Corruption. And files don't get corrupted now? I don't think that really makes ASRH impossible. As hard drive space and storage speed increase I'm sure RAID like options will exist making corruption less likely.

I think with todays technology ASRH is possible with many of the documents we use. I found this thread interesting because I was using Quicken 2003 last week and thought, "why don't all files just save changes instantly like quicken?" Other things I use like my Palm also remember changes instantly. Add a history component and I think you've got something.

File directories are being dealt with slowly. I think Apple is already taking a step in the right direction by using a more iTunes approach with the Finder.

Addendum: 2 other apps that "auto save" their states. Address book and iCal.

[mpt]

Originally posted by cpac:
Ok, First, the "annoyance" of remember-to-save boxes. There are two possible scenarios: either (1) you made changes since your last save that you want to save or (2) you made changes since your last save that you don't want to save.

Sure, sure. The same applies to driving a car. Every few minutes, there are two possible scenarios: either (1) you want to continue from where you are now, or (2) you want to jump back to where you were a few minutes ago. So whenever you try to get out of a car, the door should be locked until you deal with an alert box: “Save changes to ‘Chevrolet1’? If you don’t save, you will be teleported back to where you were 17 minutes ago, and may suffer whiplash.” Expecting drivers who don’t like where they’ve gone to actually turn around and go back (i.e. use the Undo function) is much too difficult; instead, they should get the option to teleport back, and the rest of us should have to read a confirmation alert every time we try to open the door.

(Yes, that’s a silly analogy, but I doubt there’s any analogy to the current model which isn’t silly. Geeks like us have gotten so used to the current model, we’ve become blinded to how silly it is.)

Auto-saving makes this a no-choice scenario

That is simply not true. There’s no reason why writing a file to disk should magically disable multi-level undo.

you can simply leave the name of the document as the default and tell the system to always save everything to the Desktop - there's no more thought involved here than in other situations. Either way you'd end up with Document 1 and Document 2 on your desktop, both equally easy to deal with.

Equally easy, except that: (1) one way forces me to navigate an alert box and a filepicker dialog, and the other doesn’t; (2) one interrupts me nearly n times when I have n documents open and try to shut down the computer, and the other doesn’t; (3) one forces me to file documents one at a time, and the other doesn’t. Hmmmm. I guess they’re not equally easy after all.

(While we're at it, file corruption hasn't been solved, and if every change to every document had to be recorded in a document's history, what happens when that history becomes corrupt? disaster?)

No more disastrous than if exactly the same corruption happened to a file without any revision history! Nice try, though.

Hell, I think the massive switch to computers as *the* means of producing documents is all the evidence of latent pen rage you'd ever need. - "Typewriter rage" is the same …

Certainly computers are more convenient in many ways, but cars were more convenient than horses even when the cars had to be started with crank handles. Doesn’t mean we should still be using crank handles today.

"Computer rage due to reliability at doing unexpected" - Nope. In my experience the thing that makes most people angry at computers is Microsoft software.

Fascinating. But the time I spend watching people — of widely varying ages, nationalities, and skill levels — using computers varies between about 45 and 55 hours a week. If you’re going to persuade me that your experience exceeds mine, you may need to be a bit more specific. It’s true that Mac OS causes less death-by-a-thousand-cuts rage than Windows does (it has more consistency and attention to detail), but the biggest problems (like throwing away people’s work by default, forgetting Web browser state, and forcing people to know what “applications&#8221 are) are common to both platforms.

As soon as you need to share things in an editable format, AND have a history of changes, you've got sharing of the history of changes, and that's unacceptable.

Nonsense. Publishing should strip the edit history no matter how you do it (printing, faxing, e-mailing, sending via iChat, whatever), while still keeping the edit history in your own private version.

You suggest an inadvertent "Quit" loses window positions etc. Not in any good apps I know of. Try OminGraffle, or Photoshop - all the tool bars, palattes, etc. remember their position perfectly as soon as I launch the program again. Maybe you've just been using lousy software...

Last time I launched Photoshop (admittedly, this was version 4, and it might have changed since then), it didn’t reopen the documents I had open when I quit it previously. The same applies to Word, Excel, PowerPoint, Safari, Quicktime Player, Internet Explorer for Mac … Often it would be annoying if it did reopen the documents I had open previously — but if it doesn’t, then the ease of doing Quit is totally out of line with the ease of undoing it.

You criticize the ability of a program to be open with no windows open - this again is a choice

Really? Can you give any examples of programs which offer it as a choice (e.g. a Preferences checkbox labelled “Continue running when all windows are closed” )? I don’t know of any.

But how in the world does having all applications always open address this (supposed) problem?

Where did I say all applications should always be open? Oh, wait, I didn’t. Straw man. Please try again.

Basically I didn't address this and other arguments of yours ealier because they are, as I wrote in my first reply, not well thought out.

Well, make up your mind. Either you have arguments against them or you don’t.

… On preview: What Toyin said. (And strokemouth is making exactly the same mistake Phanguye did.)

-- mpt

[Glennfield]

We have the power, in today’s computers, to run more than one program at once, and to load programs in less than five seconds.

We have the technology. So why do we still punish people by including “Quit” or “Exit” menu items in programs?

Get back to me on this when we have the power to load programs instantly. I'd very rapidly get annoyed with Word, Mozilla, or Photoshop if it quit every time I closed one window to open a new one. (Scenario: Double-click on image file. Wait 5+ seconds while Photoshop loads. Whoops, that's the wrong file. Close it. Double-click on the correct file. Whoops, Photoshop quit when I closed the other file. Gotta wait another 5+ seconds for it to relaunch... )

We have the technology. So why do we still make people use filepickers at all?

I'm afraid I'm not quite following your argument here. Are you arguing that the file picker interface (intended for the specific purpose of selecting a single file) should be identical to the file manager (intended for a wide variety of file managing tasks)? Or that there should be no file picker at all, and the user should use the file manager for that purpose? Or something else altogether?

[holygoat]

Originally posted by Toyin:
1) Viewable History The argument that History should not be visible to others is easy to get around. Instead of a save and save as functions there would be 'save as' and 'export' options:

Kinda loses some of the simplicity. Another way of implementing this is to have a separate file for the undo history (can't be in a fork, as that might be transmitted with the file).

I found this thread is interesting because I was use Quicken 2003 last week and thought, "why don't all files just save changes instantly like quicken?" Other things I use like my Palm also remember changes instantly. Add a history component and I think you've got something.

The reason Quicken doesn't need saves is because changes are database transactions. That's why in Access, for example, you create the file first.
Similarly, Palms don't have separate filestore and RAM - so a change to your running program's data is immediately reflected in the stored data (as they are literally the same thing).

To do this on the desktop would basically be to save constantly, or implement every application as a database, neither of which are really feasible for non-trivial documents.

[Uncle Skeleton]

Originally posted by mpt:
(like throwing away people’s work by default)

it's funny you should use that term, because the NSDefaultButton option is always to save the work. All you have to do is hit enter.

Can you give any examples of programs which offer it as a choice (e.g. a Preferences checkbox labelled “Continue running when all windows are closed” )?

I know I've seen such an option somewhere, but I don't keep track because it doesn't bother me. But Apple has made it exceptionally easy to code such an option in cocoa

Incidentally, have your thousands of hours watching users been at Windows or a variety of OSs?

[dru]

Originally posted by danengel:
Are there no ways to systematically proove the correctness of an algorithm? I mean, important applications for the military, NASA, air or train traffic control cannot rely on "John Smart wrote this, don't worry, he's really bright", but need some real proof that they work under all circumstances, for any input data, for the most stupid user etc.

There are. When I was studying computer science we learned that you can mathematically prove an algorithm but it will take far longer and a team of PhD's. I vaguely recall a claim of three months per line of code.

It's just not worth it all but the most important cases and definitely not at the consumer's level. Sorry.

Air Traffic Control doesn't and couldn't practically test for all cases as the system was/is just too complex and why it's not replaced every two years with a new version. Now and then there *are* situations that never came up before. That's why there are humans to intervene. Scary but that's reality. Be thankful for the "John Smarts" of the world that it works as well as it does.

[dru]

Originally posted by holygoat:
Kinda loses some of the simplicity. Another way of implementing this is to have a separate file for the undo history (can't be in a fork, as that might be transmitted with the file).



The reason Quicken doesn't need saves is because changes are database transactions. That's why in Access, for example, you create the file first.
Similarly, Palms don't have separate filestore and RAM - so a change to your running program's data is immediately reflected in the stored data (as they are literally the same thing).

To do this on the desktop would basically be to save constantly, or implement every application as a database, neither of which are really feasible for non-trivial documents.

Yes and no. IBM called this concept "Perfect Save" and implemented it in OS/2 2.0's user interface in 1992. Every change you made in a dialog box (filtering viewable contents of a folder, setting an icon, renaming a file, etc.) was automatically reflected. There was no "Apply" like NeXT or Windows 95, but there was "Undo" as well as "Default". Documents were created and named first by dragging a piece of stationery off a template stored in the Templates folder. Of course, the system also supported the Windows 3.0 and Mac-style "launch an app" and work as well.

In the mid-1990's Apple & IBM's OpenDoc was moving in this "no need to save" direction as well by make documents via Stationery. Gone was "Save As", it became "Save A Copy" but the title of the document being edited didn't change to the new name. IBM/Apple's Taligent project also worked with this stationery and document-based metaphor.

The system didn't fail because it was conceptually bad but because it didn't become mature enough in the marketplace before it was necessarily tabled when Apple was distracted by the doomed Copland project and it became clear OS/2 would not have an opportunity to fairly complete on the desktop against Windows.

Back in those days a bearded Steve Jobs gave an interview (was it to Information Weekly?) wherein he suggested Apple & IBM should adopt NeXT's technology and that with Microsoft's monopolistic dominance the industry was headed for a "Dark Ages". Aren't we glad NeXT "merged" with Apple about two years later?

[cpac]

mpt,

The "save" debate has been discussed to death. But to continue to beat a dead horse...

Your car metaphor in inept because creating a document on a computer is not a linear (or mostly linear) process like driving a car to a destination is. There would be a lot more turning around than you seem to contemplate.

I don't mean to suggest that file corruption would necessarily be more disastrous with a revision history file, just that it'd be more likely with the constant writing to disc every time, e.g. one hit paste, made a word bold, hit "delete" or just typed a single character. (These would all get saved in revision history right? If not, how could it know my document state and the changes I've made at any given point?)

You can't argue that the lack of pen rage or typewriter rage is due to the way those mediums "save" information. Even by comparing them to cars and horses.

I never said I watched people work on computers for a living, I just said in my experience what people's frustrations were due to.

the biggest problems (like throwing away people's work by default, forgetting Web browser state, and forcing people to know what "applications" are) are common to both platforms.

How are these problems on a Mac? (1) The default is always for "Save changes" not to discard them. (2) Forgetting Web browser state? - you mean what page they're at? I'd be very annoyed if it always opened my previous page. If you just mean window size/toolbar state then you need to get a nicer browser. (3) You'll have to be more specific about knowing what applications are - it's not too hard if you don't on a mac. Find the file you want to edit, double click it, and poof, you're editing it. No need to know much about applications there...

Last time I launched Photoshop (admittedly, this was version 4, and it might have changed since then), it didn't reopen the documents I had open when I quit it previously. The same applies to Word, Excel, PowerPoint, Safari, Quicktime Player, Internet Explorer for Mac

Photoshop's up to 7 now, and about to go to 8. I'd say there've been a few changes since you last used it. In terms of reopening documents when launching apps, two thoughts: (1) some applications allow you to do this (OmniGraffle/OmniOutliner, e.g., I'm too tired to see if Photoshop has such a preference at the moment...) (2) -as you say "Often it would be annoying if it did reopen the documents I had open previously". In the rare case of inadvertent quits, which again, I'd say, are much more common on windows (where closing all windows=quitting the app) than it is on a Mac where you must hit command-Q or select Quit from the Application's menu, why wouldn't you just double click on the document you were working on? That takes care of restoring your open state pretty fast...

Really? Can you give any examples of programs which offer it as a choice (e.g. a Preferences checkbox labelled Continue running when all windows are closed )? I don't know of any.

That's part of the choice between Windows and Mac. In Windows, closing all windows=quitting the app, on a Mac apps generally keep running when all windows are closed, and as I believe another poster pointed out, the choice is an easy one for Mac developers to make - couldn't be that hard to make it a preference if you really get annoyed by one behavior or the other.

I interpreted your request for "quit-less" applications to suggest leaving all applications open, or at least all applications once launched the first time (you drew the comparison to IE on windows suggesting it was going the right direction with this) As I've clearly misunderstood your less-than-crystal clear explanation, please elaborate.
---------------------

Basically I think it's clear that those elements you suggest are "cruft" are at least debatably not so, but are better ways of working, preferred by many.

[Xeo]

Originally posted by danengel:
Why do we have to remember file paths?

My friends don't even try to remember file paths. Cmd-F is their best friend. They even use it to find files they have on their desktop...

[mpt]

Originally posted by Glennfield:
Get back to me on this when we have the power to load programs instantly.

Ha ha, the Jack Straws Effect strikes again. Thanks for bringing back the memories.

Are you arguing that the file picker interface (intended for the specific purpose of selecting a single file) should be identical to the file manager (intended for a wide variety of file managing tasks)? Or that there should be no file picker at all, and the user should use the file manager for that purpose?

The latter.

Originally posted by Uncle Skeleton:
Incidentally, have your thousands of hours watching users been at Windows or a variety of OSs?

Since 2000, it’s been Windows users. (Before that it was mostly Mac OS and a bit of Solaris, though not as intensively.) I use a Mac at home, so I know which poor design details are particular to Windows (useless button labels, for example), and which are shared between Windows and Mac OS.

Originally posted by cpac:
Your car metaphor in inept because creating a document on a computer is not a linear (or mostly linear) process like driving a car to a destination is. There would be a lot more turning around than you seem to contemplate.

And using Undo is a lot faster than switching into reverse gear, so it evens out.

You can't argue that the lack of pen rage or typewriter rage is due to the way those mediums "save" information.

Why not?

Posted by cpac, also mentioned by Uncle Skeleton:
(1) The default is always for "Save changes" not to discard them.

That’s true if you gravitate to the Enter key on the keyboard. But it’s still easier to delete your work (one mouse click, or one key-combo, or one power cut) than to keep it (one mouse click, or one key-press, plus however much it takes to get to the right folder, since you’re urged to choose a folder right then, plus however much it takes to type a name, since you’re urged to choose a name right then too, plus another click or key-press).

(2) Forgetting Web browser state? - you mean what page they're at?

Yes, and what scroll position they’re at, and what zoom level they’ve chosen, and what text they’ve entered in any form elements, and where the insertion point is. So if, for example, I compose an 800-word message in Yahoo Mail with Safari 1.0, and I finish it with the words “Your loving husband, Wilfred”, but at the start of “Wilfred” I accidentally type Command+W instead of Shift+W … Instead of losing my entire message, and heaving a brick through the computer screen in fury, I can just double-click on the “Yahoo Mail - Compose” icon that has been deposited on my desktop, and the browser window will reopen with my message exactly as it was before I closed it. Just like any other document in the saveless environment. (If, on the other hand, I really don’t want to keep the message I just wrote, I can drag that desktop icon — or the browser window’s own proxy icon — to the Trash. Again, just like any other document in the saveless environment.)

(3) You'll have to be more specific about knowing what applications are - it's not too hard if you don't on a mac. Find the file you want to edit, double click it, and poof, you're editing it.

Sure, but you still need to know about applications to understand what Quit is going to do. You also need to know about them if you want to create a document. (There have been a few meagre attempts to fix the latter problem, but thanks to a tragedy of the commons, they confine themselves to a single suite — e.g. Starting Points in AppleWorks, or the Project Gallery in Microsoft Office for Mac.)

why wouldn't you just double click on the document you were working on? That takes care of restoring your open state pretty fast...

Sure — if you had only one document open.

I interpreted your request for "quit-less" applications to suggest leaving all applications open, or at least all applications once launched the first time …

Viewers, file manager modules, editors, and tools plugging in to those editors, would all stay in memory only for as long as that memory didn’t need to be used for anything else. Just like virtual memory works today, but on a more granular level. Programs like iTunes, iPhoto, and your browser’s bookmark and cookie managers would be replaced by file manager modules, offering specialized views and operations for particular folders. Programs like Photoshop, Quark XPress, and Word would become minimal, near-instantly-launching editors, into which tools would be loaded whenever they were needed (with a few perhaps being preloaded based on your previous usage patterns).

holygoat was correct in that this would be a component-based, not application-based, environment — in other words, the exact opposite of where Mac OS is going currently. So I suppose I’m wasting my time advocating it on a Mac forum, eh.

-- mpt

[CharlesS]

Well I'm on vacation and am posting this from an internet cafe, so I won't really be able to participate in any regular discussion here. Nevertheless, I just wanted to put in my two cents: the 'save' feature is a very good thing. Anyone who used HyperCard knows that it was absolutely great in every way except for the way it saved everything you did instantly. I accidentally hosed a HyperCard stack once, and I was screwed because there was no 'revert' or 'close without saving' feature.

[Mediaman_12]

Viewers, file manager modules, editors, and tools plugging in to those editors, would all stay in memory only for as long as that memory didn’t need to be used for anything else. Just like virtual memory works today, but on a more granular level. Programs like iTunes, iPhoto, and your browser’s bookmark and cookie managers would be replaced by file manager modules, offering specialized views and operations for particular folders. Programs like Photoshop, Quark XPress, and Word would become minimal, near-instantly-launching editors, into which tools would be loaded whenever they were needed (with a few perhaps being preloaded based on your previous usage patterns).

Did you copy that from the OpenDoc description? This is exactly what the OpenDoc concept was. No giant apps just modules that could be loaded in and out dynamicaly in to do just what you wanted at that moment.

The problem with perpetual save is when you use one document as a template for another. With continuous saving you have to remember to do the 'save as' first, before you do any changes to the older document (that you still want to keep).
example: When my Mom is typing letters she often uses an old letter as a 'template'. With the perpetual saving she would have to remmember to do a 'save as or export' before she started typing he new letter over the old one even if she didn't want to save the new letter(this 'previous as template' is even something I use every day).
I would also hate to see a often changed large Photoshop file if the entire document history is saved allong with the file (the the moment if you close a photoshop file the history is lost).

[holygoat]

Originally posted by cpac:
In Windows, closing all windows=quitting the app, on a Mac apps generally keep running when all windows are closed

Just thought I'd clarify this - it's not as difficult as it sounds. Windows uses MDI rather than multiple windows as a model: unlike the Mac, there is no equivalence between documents and windows.
In Windows, you'd get the Photoshop MDI window with no document windows if you had no documents open - so you can have no documents open, but still have the program open.
To quit, close the main window. You'll be prompted to save, discard, or cancel for each edited file, which I find quite convenient.

By contrast, the Mac doesn't use MDI, so it's less obvious that Photoshop is still open - but you waste less screen estate. Just a different approach. You must use the menu or keyboard to quit, as there's no window open to close.

[devNevyn]

Originally posted by danengel:

Why do we have to remember file paths?

You don't.

(Very good article, it's a recommended read)

[Mediaman_12]

Originally posted by holygoat:
By contrast, the Mac doesn't use MDI, so it's less obvious that Photoshop is still open - but you waste less screen estate. Just a different approach. You must use the menu or keyboard to quit, as there's no window open to close.

But this isn't uniform, only Adobe's (and some copy cats) apps work like this. Most have the menubar glued to the top of your document (Word for example) close the last document and the app closes with no warning. So to continue working in the app, create a new document for example, requires the relaunch of the app.
I think this approach form Adobe is a legacy from when there apps originated on the Mac and where 'ported' to windows
With the excellent memory management in OSX an app being open or closed is irrelevant.

[holygoat]

Originally posted by Mediaman_12:
But this isn't uniform, only Adobe's (and some copy cats) apps work like this. Most have the menubar glued to the top of your document (Word for example) close the last document and the app closes with no warning. So to continue working in the app, create a new document for example, requires the relaunch of the app.
I think this approach form Adobe is a legacy from when there apps originated on the Mac and where 'ported' to windows
With the excellent memory management in OSX an app being open or closed is irrelevant.

I'm assuming you're referring to Windows here.

The Windows paradigm is MDI. Starting with Office XP, you had the option to put each document in its own window, with its own taskbar entry - essentially, a copy of Word for each document, tied to that document alone. Windows XP extended that to other applications, so you can move away from MDI if you want - but even in Office you can turn this off.

It's not the same as on the Mac, where the application and document are quite separate, but MDI does allow you to close all of your documents and still have the application open.

I find this very useful when toying with lots of files in Photoshop - I can keep it open, and use drag-n-drop into the MDI backpane to open files that might not be associated in Explorer. The same with Word.

You might look on MDI as making a Mac-desktop-in-a-window - maximise it and you have a Mac menu bar and desktop, with document windows. It's an interesting viewpoint on an old approach.

You are, of course, absolutely right regarding non document-centric applications - WinAmp, for instance, doesn't stay open when you close the main window. But document-centric Windows applications, such as Office and Photoshop, employ MDI to allow the application to stay open with no documents active.

[BuonRotto]

Yeah, to me, the new sometimes-MDI-sometimes-not thing in XP you describe there is so much more inconsistent and annoying to deal with than the difference between metal vs. pinstripe appearances. I hate MDI myself, and I'm using XP, so the new way is somewhat improved to me. But with mostly MDI apps, a sort of half-assed non-MDI arrangement for Office and others, and a taskbar that has plenty of functionality but whose job to keep track of that stuff is made all the more difficult by this smorgasbord.

OS X of course has its own identity crisis in the sense that there are indexes or container windows like iTunes, iMovie(?), iCal, Address Book, etc. where a window is not equivalent to a document. It's something that's come into play that the original Finder and Mac OS didn't really consider. Seems to me this is where metal comes in to differentiate the type of window content: pinstripes where window = document, and metal for the indices. Perhaps different handling of these apps beyond the appearance difference, and the behavior of the index app quitting when you close its last window.

Anyway, they both have their cruft in that sense, don't they? One size doesn't fit all anymore when it comes to windowing.

[Uncle Skeleton]

QuickTime (the original brushed metal app?) and Safari would both break that metaphore