Fog Creek Software
Discussion Board

Question about Citydesk interface

I have a question about citydesk intrerface.  On opening a new HTML file., a button called "Save and Close" appears.

I, like most  am accustomed to have a "Save" button  at the top left hand corner. Why is it "Save and Close". This leads to files being closed acidentaly. After working for a few minutes My hand goes automatically to what i think is the save button and then .....

I am **not** complaining .  I am only curious why it is like this. I mean what is the specific reason?

Sunday, October 27, 2002

Cuz Joel prefers Ctrl+S.  After about 3 days I find I'm using it as well.  Interesting... it was the only short cut that I wasn't already using...hmm

Brad Siemens
Sunday, October 27, 2002

If you are saving your work, then 9 out of ten times, you are probably going to close the form at the time right?? Why not kill two birds with one stone?

I mean, when you are done, are you not going to save, and then close? Why should this be two steps? Ask 99 people out of 100, that when they close the doc, should they save it? In fact, I bet I could ask 100,000 people, and they would all agree that the doc should be saved when you close it.

As for the use of the "save" prompt in general should get rid of it.

I do accept that perhaps a “save” button should exist, but that is only for users of existing products because they expect it.

I use word all day, and every time I close word, it asks me if I want to save the document. I mean how stupid and annoying can you get? If I am closing word, it should make that assumption for me. In fact, that is what good software is all about. Making good assumptions, so the end user does not have to. The original designer of visual basic has a book out right now where he spend a whole chapter why a save button is dumb.

When you look at how Outlook, or even a better example is the palm pilot. These things never ask you to save a document. You just close it..and move on to the next task. You of course do want the users to be aware of the
undo-option...that is a must...but prompts for saving stuff is dumb.

Can you imagine opening a file cabinet, and placing a document inside..and then the file cabinet you really want to file this document? This is nuts! If you already have gone as far as opening the file cabinet, then I
don't think one needs to asked much more. Thank good ness the file cabinets was invented *before* software! After a few hundred times of doing this, one wonders what the designer ate for breakfast that day. Hint, don't be a bad
designer and inflict unnecessary pain on your users.

How about when you put the key in your car and turn it. Now the car will ask:
  Do you want to start the car?

Can you see how stupid this is?

You can spend tons of your time developing this kind of stuff. I just don't get it why one needs a save button. I would perhaps allow a button called "save and close button" in these cases (and that is what Joel did).

Using Un-Do is exactly what you should be teaching your users to do in the first place. Teach them to undo, and then you have to don't bother them all day long while they just want to get their job done. Let them work fast, and if they make a mistake, then teach them about the un-do.

When I put a new phone number into my Palm, I just move on to the next task...I am most thankfull that it does not ask me to save.....

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, October 27, 2002

Autosaving upon close needs to have a switch though to turn it off.  Oftentimes I work with people who hit keys while scanning files on my machine, and it's disastrous when they save.

Maybe that's an argument to saving to a database or scm rather than a filesystem.

Sunday, October 27, 2002

I would say that 9 times out of 10, when I hit Save I *don't* want to close the document. Any experienced computer user saves regularly so that if a program crashes or the power goes out, they don't lose the work they've done since opening the document.

I miss having a Save button in CityDesk, and frequently close the document accidentally when I just meant to save it (I'm used to clicking the save button in every other application I use, such as Word, Excel, Outlook, etc). Then I have to go hunting for the article again to open it back up.

And yes, Outlook does have a Save button. It frequently asks me if I want to save changes to contacts, draft emails, etc. And I like that.

I'd hate it if applications like Word automatically saved on exit. That's how errors creep into documents.

Darren Collins
Sunday, October 27, 2002

>>I would say that 9 times out of 10, when I hit Save I *don't* want to close the document. Any experienced computer user saves regularly so that if a program crashes or the power goes out, they don't lose the work they've done since opening the document.

Then just use ctrl-s (it works for all of those applications including City desk). If you *really* are an experienced computer user, then I cannot imagine that you actually stop typing, grab the mouse, move it up to click on the save icon *just* to save. That is a huge amount of work, and you now have to move your cursor/mouse back to the place you were working on in the document??.  It only makes sense to go up there when *are* in fact done. Use ctrl-s.

I will concede that a save icon is not a bad idea..but the save should be implied. (I am a heavy notebook user, and also use ctrl-s, and even alt f-x to exit).

In addition, 9 out of ten times, a user wants to save the document when they close it. In fact, I bet when you close a document, 9 out of 10 times you want save it before you close it.

My whole point here is lets not annoy millions of users because one software developer did not take time to figure out what should be done here.

This whole problem stems from the concept of a file, and the designer of the program being concerned about the hardware, and not the user of the product. Just try teaching a new user why you have to save a document when you close it, you will get blank stares.

That why the palm pilot is so simple and easy to use. Saves are always implied.

While your draft email does ask to you save, in fact when you hit send, you actually are saving the document to the outbox. Thus, in fact, the save is implied. Should you be asked to save before you send?

Good software designs make assumptions. The designers assumed that when you hit send, you also want to save. This is my whole point.

More and more software is staring to work this way.

This all comes down to habits, and our prier expose to computers.

As far as accidental changes to word, then turn on document protection. That is what it is for. Heck, why not turn on revision control? I have walked into a company and seen people working on a “paper” copy of document. I asked them why? Well, we need to track changes? I showed them how to enable document revisions in word. This is a great and often un-used feature of word that allows multiple people to review and maintain a document. You can then hand it off to other people (via email) , and view their comments and revisions of each person. The revisions are even highlighted in a different color.

Lets again not use the lame excuse of a accidental change to a document to interfere with the millions of users who want to close their document and have it saved with such pain and suffering.

When you are in excel, and modify a cell, should it ask to save the change to the cell? How about when you move to the next row? It turns out in most database systems, a row is actually a record from a database. Again, if you look products like ms-access, they *never* ask you save data. It is implied, and was designed that way ten years ago.

Many of these prompts are due to the designers of the product thinking in terms of a computer and memory and a hard disk. Excel does not expose the row data as a separate record, nor does it ask you to save. It could very well work this way...but it still should NOT ask you to save each row.

This is really an issue of the quirks and habits of a few being imposed on the what good design should be for the many.

Products like QuickBooks are actually highly relational database products, but they in fact hide this very well. Heck, they don’t even talk about double entry booking keeping.

Good cars are the ones that hide the inner workings, and annoy the users the least.

Closing a document should be a implied save.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, October 27, 2002

I second the inclusion of a simple "save" button. I don't use this product, but anything which goes against majority ui design is, sadly, bad ui design. It's not what is most logical that's important these days, but what the user expects (in cases like this one).

Also, the argument to use Ctrl+S is only applicable if you can easily use a keyboard - oh you say, surely everyone can - no. Disabled users, Tablet PC users, and various other categories, are used to using buttons for common functions. They know how they work. Don't break common functionality is my take on this.

Andrew Cherry
Sunday, October 27, 2002

I would suggest that when you close a file in CityDesk, it should automatically save the file if it is not the first time the file has been saved.

In other words, if the file is new (and has not yet been saved for the first time), when you close the file the application should first ask you if you want to save it.

I say this because sometimes you create a new file and begin working on it just because you need a canvas to futz around in-- like scrap paper.

I'm pretty sure Jeff Raskin covers this issue in his book "The Humane Interface".

Que scais je?
Sunday, October 27, 2002

I agree that there should also be a normal Save button on the toolbar. I've found myself accidently hitting Save and Close when all I want to do is save the file I'm working on.

It seems strange that this inconsistency has appeared in a GUI designed by someone who so strongly advocates 'doing what the user expects' in interfaces. Just about everyone would expect the button with a little disk on it to save the file and NOT close, but the CityDesk UI does exactly the opposite.

Having said that, I have found CityDesk to be one the best programs I have ever used.

Daniel Searson
Sunday, October 27, 2002

Albert, I'm not against having a "Save and Close" button, and I do use it a lot.

What I'm saying is that all the other document-centric PC applications have gotten users into the habit of clicking a button somewhere up near the top left of the toolbar to save the current document. The CityDesk "Save and Close" button looks like a Save button at a quick glance, and muscle-memory reinforces the split-second action of clicking on it. But often, the user didn't really want to exit, just to save the article, so they have to go hunting for it in the folders, open it back up, and find their place in it again.

User interfaces shouldn't surprise users. Even if I accepted your claim that 9 out of 10 times when you click Save, you also want to exit, that means that 10% of the time the interface is surprising the user.

Anecdotal evidence on the CityDesk message board suggests that lots of other people get annoyed by the Save and Close button as well. Theory aside, practical experience of users suggests that something should be done about that button.

All I'd really like to see is two buttons - one just for Save, and one for Save and Close. I can't understand why you object to that.

Darren Collins
Sunday, October 27, 2002

"Lets again not use the lame excuse of a accidental change to a document to interfere with the millions of users who want to close their document and have it saved with such pain and suffering."

Pain and suffering comes from overwritten data.  I currently work on an app that autosaves-on-exit, and as a designer you have to make the conscious choice whether to prefer safety or ease of use.

For most of your Palm apps, you want to get in & out quick.  There autosave-on-exit is vital.  For Emacs, you stay in there for hours and it's very configurable, so why not be safe by default.

But as I said, having a switch for a power-user to choose, or revision control would be nice.

Sunday, October 27, 2002

Actually, as mentioned, I do agree that a "save" icon should probably be up there. This reason is the same that several people mentioned here:

........It is expected.

The "user" model is what most people expect, and I think most here seem to agree that the save Icon would not hurt CityDesk.

On the other hand, we now all learned what it need to change it!!!

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, October 28, 2002

The people who have been objecting to Albert's arguments seem to do so mainly because of accidental changes that might get save automatically.
But didn't Albert suggest an undo-feature? So what's the harm in having an accidental change once in a blue moon if you can undo it anyhow? In fact, why bother everyone all of the time with this save business, just because sometimes some people have other intentions? Wouldn't it make more sense to offer these people their own tools to serve their purposes? Surely no one objects to doing some extra work whenever they want something that is out of the ordinary to make the ordinary simpler? As long as that extra work is marginal of course.

Monday, October 28, 2002

The thing that I find a bit odd about CityDesk is the fact that the toolbar buttons do not correspond to the menu items. I'm not saying that this is right or wrong but it is different from what I'm used to. A shortcoming is that there's no keyboard shortcut for Preview.

Also, I find the undo feature in the CityDesk article editor to be practically useless. I think this must be a limitation of the DHTML edit control that they're using.

John Topley
Monday, October 28, 2002

The button with a little disk on it should only save the file and not close it.

Arguing against this is like arguing against the fundamental laws of physics.

Monday, October 28, 2002

"The button with a little disk on it should only save the file and not close it."


"Arguing against this is like arguing against the fundamental laws of physics. "

No. Actually arguing it is useless for us as users - save that on here i'd expect the designers to listen and change things if they thought it was important to enough users - but most certainly should be debated by designers.

Robert Moir
Monday, October 28, 2002

I've gotten used to it and my sense is that there may be some changes to this in future versions.

But another feature is more of a problem for me: Preview is really "Save and preview."  Most times I'd like to preview before I save.  I realize that this could break the CityDesk publish process but it causes me problems as it is now.

Right now I have a temporary unpublished article in all my CityDesk sites.  If I'm making significant or risky changes to an article, I copy the article to my temporary article first and edit and preview it there.

Monday, October 28, 2002

This is one of those great UI discussions in which there are advantages and disadvantages to both sides, and you can't please everybody, and the designer is stuck making a decision that seems least bad.

The Save and Close button is actually copied from Outlook, where it is extremely popular. Indeed a lot of people really like "Save and Close" and consider it a valuable innovation. I think that the Save and Close button is most useful in contexts like Outlook Contacts, where after you make a small change you are unlikely to continue editing.

For longer items, like word-processing documents, you save many times before you close, so this isn't the ideal UI.

In the case of CityDesk, people with very short articles (like webloggers) generally prefer "save and close," people who work on long essays that they save frequently would probably prefer "save." But even of the people who write long articles, most of them are touch-typists who would rather use Ctrl+S for save rather than spend time reaching for the mouse.

So "Save and Close" generally irritates most the people that are writing long articles but haven't gotten into the Ctrl+S habit.

I agree with the point that it is inconsistent with other UIs and not what people expect from an icon with a floppy disk. We could change the icon to eliminate the surprise factor.

I don't really like the idea of having two icons, save and save and close; in practice interfaces like this are very confusing and the chance of making a mistake is much higher. Every time you click a button you have to concentrate on which one you want. Some of you may have noticed this effect with the "Preview" and "Insert Picture" icons, which sort of look the same: I often hit the wrong one and as a result I have to force myself to concentrate on which one I really want to hit. We need to make those icons less similar.

Joel Spolsky
Monday, October 28, 2002

It would perhaps be more descriptive to call the button "Close and Save", since that's really what it's doing: it's closing the article, and incidentally also saving your changes. Which of course may not be what the user wants. In general, the tasks of saving and of closing are very different, and do not necesarily follow one another. Wouldn't it save a few headaches to have two buttons to do the two tasks?

(As far as Ctrl-S, I think options that are only available via keyboard shortcut are bad UI design.)

Monday, October 28, 2002

The "Save on close" prompt it's not bad design, but becomes invaluable when you are working on a big document and accidentally hit the close button.

One can argue that the "Ctrl-S" shorcut will do the trick. Indeed, but that action implies a very small mind-context change, and when you are working "on the flow" such switching is not allowed.

Real-life files and cabinets metaphores doesn't apply here. In real life, you cannot destroy a document accidentally while having it in front of you and hovering your hand over and inadvertently "touching" it.  Well, perhaps Uri Geller can.  Also, while writing on a typewriter, your page doens't just vanish, you have to pull it to discard it. A very concious movement that can't be mistaken.

When using a UI, you can do a lot of things by mistake. The program have the responsability of prevent mistakes that can be painful, like losing a full page of the next Mozart's Requiem.

(Pardon my english, etc.)

Leonardo Herrera
Monday, October 28, 2002

Erik said:

"The people who have been objecting to Albert's arguments seem to do so mainly because of accidental changes that might get save automatically.
But didn't Albert suggest an undo-feature? So what's the harm in having an accidental change once in a blue moon if you can undo it anyhow?"

That presumes an undo function that behaves in a certain way. Currently, I'm switching between two programmer's editors - PFE and TextPad.

The undo function in PFE can undo changes up to the last time the file was saved. Press ctrl-S, lose your change history.

The undo function in TextPad can undo changes since the current session was started.

What you're presuming is an undo function that retains a history of changes performed in previous editing sessions. Perhaps a word processor which stores it as "hidden" information in the file can do this; for what I do it would have to be implemented as a separate file associated with the text file.

As a related aside, I have one word processor file (a tech-support response fax form) that I load, edit, print, and exit without saving. All I do is fill in is the customer name, fax number, number of pages, and my responses to their questions. An implicit save on exit would really mess it up for me.

Steve Wheeler
Monday, October 28, 2002

"What you're presuming is an undo function that retains a history of changes performed in previous editing sessions."

Surely. Which is not that far fetched, is it? I mean, why forget changes after something so arbitrary as a session? It fits more closely to our (human) mental model. A session is something artificial that is there for the benefit of the computer/program. I don't need it, but I can appreciate why it's there anyway. I just don't want to be burdened by it anymore than necessary.

"An implicit save on exit would really mess it up for me."

For you, at that time, yes.
So that means you need a facility to accomplish your goals too. Now between saving and not saving, what would be more probable? Right now things seem reverse. To get the more probable result, you need to take explicit action, while achieving the less probable, you don't.
People will usually appreciate it when you make the probable as simple as possible, as long as the less probable is still achievable with only minor inconvenience.
People certainly do not appreciate it if they have to be inconvenienced all the time, just because some of the time they might want something different.

Tuesday, October 29, 2002


Is there any feasible way to remove the need for an explicit save? If changes where always persistent and undo more advanced, you might lose the button altogether...

Tuesday, October 29, 2002

What about a "Save" and a "Close" button, naturally the "Close" prompts for a save if any changes have occured, otherwise it just closes.

This is the best way.

Tuesday, October 29, 2002

"I mean, why forget changes after something so arbitrary as a session?"

Ok, I'm not sure why this is but... I've never thought of this. What is more strange, I'm absolutely in love with this.

There are some problem though:

Where do you store the undo steps?
- In the same file?
- What if that file is edited A LOT?
- Would it just cause the file to grow like crazy?
- Maybe it forgets items after so many bytes of data (say, it remembers about 300 steps back)?
- Maybe they are stored in a separate file? A hidden XML file?

Could this be applied to database application?
- Would it be configured to follow changes to a record?
- What about related records?
- Would it follow a transaction? Undoing everything in the transaction?
- Would this cause a lot of fragmentation?

I do love the idea, now I just need to figure out how to implement it.....

Tuesday, October 29, 2002

Personally, I'm trying to eliminate explicit saves in my programming projects.  I find that it works well if you design the system with this principle in mind.

About saving undo steps:  They could be saved in a separate file, or in the same file that's being edited; it depends on the application.  It would strike me as more sensible to store them in the same file, if possible.  If the file's edited a lot, well then, you store a significant amount of data.  But hard drives are big enough that I don't think that'll be a significant problem any time soon.  Also remember that undo steps should be very small.  And you'd definitely want to keep the number of undos remembered down to a reasonable number (hundreds, probably).

Database applications can be very different beasts, because databases are designed with saving (committing) in mind as an explicit construct with definitive goals and reasons for existence.  OTOH, note that most databases already have an undo feature implemented with the "rollback" command.

One of my most important breakthroughs was to write a thread which periodically saves all open files, if there are any changes to them (say, once every fifteen seconds).  Thus, even if my application crashes, the user can re-open the document and it'll be in the same state it was in when the app crashed (except, perhaps, for a few seconds' worth of updates), and can apply any undos, as well.  And since it's implemented as a separate thread, the app itself won't slow to a crawl when saving that 1.5 MB file.

Brent P. Newhall
Tuesday, October 29, 2002

"Where do you store the undo steps?"

That's the big question. For a word processor document, the obvious place is to store them in the same file. For what I do (mostly straight text files, which appears to put me in the distinct minority), it would be a significant problem to do that.

Yes, you could put them as diffs in specially-formatted comments, but I'd need an editor that understood commenting conventions for C, Basic, LEX/YACC, Forth, and various assembly languages. In addition, I'd need the editor to hide all of the "diff" comments so they didn't interfere with my reading of the code.

If you put the undo information into a separate file, you run the risk of getting them out of synchronization.

In the RSN future :-) when we have an ideal common file format that everything from compilers to databases to browsers understands, this problem may (should?) go by the wayside.

Right now, "one size fits all" doesn't, and for me, I'd rather deal with a "File has changed. Save before exiting?" prompt than have to remember to deal with undoing everything I've done before an automatic save occurs when I exit.

And to continue on that theme, if undo can go beyond some milestone such as "last save" or "start of session," what happens if we accidentally undo too many times? Should we store infinite "redo" information also? And what happens if you make 5 changes, undo 3 of them, make 2 more changes, undo 3, and redo 2? Which set of changes gets made when you have a choice? Isn't this the problem that version control systems already solve?

Steve Wheeler
Tuesday, October 29, 2002

Yes, from a UI point of view, having the application save for you is almost always right.

However, it leads to a few problems.

1) Now you need to distinguish between reading a document and writing a document. Outlook can do this, you can read email messages but if you want to change them, you hit 'edit'. Internet Explorer + Edit Button + HTML Editor is similar but very clumsy.

1a) You also need to have the concept of 'save as' or 'use this document as a template'. People might even do things in the 'wrong' order, and you want to 'fix it' for them.

2) Creating a new document (via new or save as or whatever) leaves turds before they're named. Like piles of drafts in Outlook. How do you manage this?

3) People also like 'scratch' copies for various reasons, this is also hard to manage.

4) You should keep a backup version, that way if you accidentally save you can go back a version. Peristant undo could fit in here: save the undo for this + previous version, and throw out all previous; you can get previous undos by opening the backup copies.

BTW, I've never used citydesk but it's quite clear that if you have a button which closes with save, it should NOT have an icon different from the standard 'save' icon.

Tuesday, October 29, 2002

last sentence edit mangling:
it should have an icon DIFFERENT from the standard 'save' icon.

Tuesday, October 29, 2002

"Isn't this the problem that version control systems already solve?"

Just to clarify, we are not talking about infinite undo in a development environment (although you could I guess), we are talking about it in end-user applications (Word, Excel, CitiDesk, etc.).

Version control works find for us, but we are tad bit more technical than, say, my mother. She still has trouble understanding the word “Default” because “that is what banks do when you don’t pay” (and that makes Default = Bad). So, to tell her she can undo changes but only “in the session” is like saying “sky Lucy pink pretty”. It just makes no sense to her.

Personally, I think Word has found the solution to auto-save vs. manual-save. It auto-saves every file to a temporary file. If the system crashes, it “recovers” your changes for you from this temp file. Otherwise it saves manually (or asks at closing) to the main file. This feature has saved my butt more than once.

Marc LaFleur
Wednesday, October 30, 2002

Many people have picked up my suggestion for undo across sessions and implicit saves. I should make absolutely clear that none of this is my own original idea. I had noticed the nuissances of the current model, but it was someone else who did me the courtesy of writing about it.

Now, as many have noticed, this introduces a whole set of other problems that need to be solved. But these are technical problems and there are legions of great engineers out there to solve them. Some of you have sort of started already. You are now on your way to conforming technology to humans. Something which is long overdue.

Wednesday, October 30, 2002

Saved Undo lists were around on the Archi back when I was in high school. There's no reason we can't do them.

Mr Jack
Wednesday, October 30, 2002

See, that's the spirit :-)

For the people still getting used to the idea and who have noticed that you might lose some of the comfort of having a session, think about this:

Now you can open a document, do a few things, then decide to loose the changes of the entire session by closing and not saving. That's a powerful notion and should not be lost in favour of other unrelated things. Instead, why not organise undo in a fashion that session barriers may be respected if you want to. So have a 'lose all changes since session start' command. In fact, there are probably additional ways to organise undo to have meaning to yoyr way of working. Other than the current way it is organised, which merely reflects the machines way of working.

Wednesday, October 30, 2002

Well , i would vote for a "Save" button instead of a "Save and Close" button.

Now if i were a designer and had a choice between

1) Implementing a feature many guys think as a great  but none would miss if it were not there. This is the "Save and Close" button. Also this has the risk of pissing a great many people who expect a "Save" button
2) Implement the "Save" button and dont displease anyone
Not many(probably none) would expect a "Save and Close"

The choice to me seems pretty clear. I would choose 2) anytime because i dont want to piss of anyone.

Wednesday, October 30, 2002

*  Recent Topics

*  Fog Creek Home