For those of you who follow this blog, you may have noticed that I was not very active for the past couple of months. I had to relocate to a new place and there’s been a lot going on in my personal life (a lot of good things of course). Anyway, now I’m back and I’m trying to blog about the pile of images that I’ve gathered during this time (about 30+ so expect a lot of posts).
About 5 months ago, my boss who knows I write about usability, sent me a photo of save dialogue box in Emacs complaining why it is so stupid?! Without further ado here is the image:
As you can see it has 7 buttons:
- Yes: saves the file in the suggested name (default action)
- No: cancels the save action
- View This Buffer: cancels the save action and makes sure that the window to view that specific file is visible
- View Changes In This Buffer: cancels the save action and asks Emacs to show you what has changed in the file since last save.
- Save This But No More: tells Emacs to save only this file but not the rest of the files
- Save All Buffers: this button can be used to save several files. In this case, there’s only one file so it’s inappropriate to pollute the UI with an option that doesn’t even make sense. It is the same as “no” button for one file.
- No For All: it is used for not saving any of the changed files. Same as “Save All Buffers” button this is unnecessary for when there is just one file.
Why is it bad? Because there are too many options, half of them are useless or do similar things as the rest! It is just a polluted user interface which confuses the user. One may argue those who use Emacs are used to this level of complexity and in fact they like the “flexibility” that it provides. But my boss is not a novice user. He has created a Linux based operating system from scratch and have been developing C applications for 25+ years and works with Linux on a daily basis (in fact his 7 year old son, terminal and bash scripts in Linux!). So if he can’t get it, who else would? And guess what? He’s not the only one. Jono from Not User’s Fault has also written about it.
This is how I would design that dialog box:
Here is the changes and the reasons:
- Only two buttons: action is clear: save! with two answers: yes and no! If there are multiple files, this dialog can appear for each of them mentioning that individual file name (for example Dreamweaver works like that).
- The Yes button is slightly bigger than the No button and is pre-selected (as the orange outline around it suggests). The reason the Yes button is more dominant is because probably the reason the file is changed is because user has spent some time editing it. So it’s safer to pre-select Yes instead of No. This is the only thing that I haven’t changed from the original design. However, I made the buttons bigger so that it is easier to click them. Not everyone is super quick with targeting a button with mouse. If there’s more space, give more of it to users for convenience.
- The title of the dialog box is changed to represent what is happening. This dialog appears right before the user quits Emacs so the verb would be “Quitting” and the name of the application which is “Emacs”. The original title “Question” is not very descriptive. Of course it is a question. A modal dialog which has a question mark at the end of its message and doesn’t close until you press a button is a question for sure! Use every pixel to show something necessary to the user without polluting the interface with visual noise.
- A save icon is added. It’s not only for aesthetics. Many people don’t read the dialog boxes but they can identify icons with a glimpse of an eye. And even though many younger users haven’t even seen diskettes, the save icon in most applications is presented like that. It has a different color here to make it stand out, but it can as well be gray or black (which in my personal opinion is boring).
- The (X) button is removed from the title bar of the dialog box. I find that quite cryptic when I see it in a dialog box because the (X) button means “Close”. So when a dialog box appears and the user presses “Close”, what does really happen? Is it equal to pressing the No button? Does it “force quit” the application? Does it delete the file? How about being clear and providing a verbal description? Because this (X) button is indeed different from the (X) button on the main window of the application. This one merely cancels the quitting action (didn’t guess that ha?). That’s why I have the “don’t quit” on the window. It is not a very dominant action because most users answer the dialog with Yes or No instead of canceling the Quitting process. But anyway, it’s there if someone needs it. It looks like a link but it behaves same as a button. Why link? because after clicking it, the user will “go” somewhere: to the main application window.
- A suggestion for a better UX: if there are more than 5 unsaved files, a smart design will show a checkbox that says “Do the same with the rest of the 17 files” (assuming there are 17 unsaved files). So if the user checks that checkbox and press yes, all 17 files will be saved and no dialog will be shown for each of them. If the user checks that checkbox and presses no, none of those 17 files will be saved.
And finally I’d like to close this post by words from Jono discussing why even open source project like Emacs still suffers from these usability issues instead of receiving fixes from people:
“It’s open source, so you could, theoretically, change the behavior”, while true, is not generally a constructive response to usability criticism. People with both UI design skills and coding skills are rare. Most people with usability feedback for any given project are not going to be coders. If your project’s response to usability feedback is “show me the code or get lost”, then you’re taking potentially valuable feedback and throwing it in the trash. Over time, the project teaches people not to bother trying to help unless they’re coders. And then it misses out on the best chance to improve its usability.
(the save icon is taken from IBM’s website)
This blog is not about nagging, so just like many other posts, I tried to contact the developers (firstname.lastname@example.org) to hear their words. Unlike PuTTy, the Emac community seems to be quite open minded and active. It is now registered as bug#12635 and within a day I received 3 replies and changed the design accordingly. First let’s see the suggestions:
Eli Zaretskii (email@example.com) suggested:
IMO your suggested dialog goes too far in the other direction: it removes useful options.
It is possible that the options to view the file’s buffer and to review the changes should be renamed, e.g. “Do not save and show the changes” or some such, or maybe the layout should be changed. But removing the options because “users can only cope with 2 at most” is not the best idea.
Likewise with “Save This But No More” and “No To All” and “Save All Buffers” (which perhaps should be relabeled “Yes To All”). These are useful when saving several files, and should appear then.
Can you suggest a better design that leaves the options available?
Andreas Schwab (firstname.lastname@example.org) suggested:
The latter two should probably be replaced by a check box “use this answer for subsequent questions”.
Juri Linkov (email@example.com) suggested:
The most user-friendly UI would tell the user what pressing the button will do exactly. So instead of buttons “Yes”/”No”, it would display more explicit text in buttons: “Save”/”Don’t save” or “Save”/”Discard”.
OTOH, Emacs is special in this regard that actions in the dialog box have their counterparts in the non-GUI version where “y” and “n” are keys to save or skip the buffer. With the goal to maintain compatibility between these two versions, the GUI version could provide accelerator keys in the button text like “_Y_es” and “_N_o”.
But in case when these versions will diverge from each other, and also for the final question: Modified buffers exist; exit anyway?
still more explicit “Yes, discard changes”/”No, cancel” or “Yes, close without saving”/”No, cancel” would be better.
“Don’t quit” to cancel the dialog is very necessary, yes, but a link in a dialog box a quite non-standard element. Much simpler would be to just add the button “Cancel”.
Removing the option “View This Buffer” could be accompanied with displaying the buffer in question unconditionally (this suggestion pertains to the non-GUI version as well).
Regarding the multi-file operation, some applications solve this problem by displaying a list of all unsaved files to help the user decide what to do with all of them.
Emacs already does the same for running processes by displaying their list and asking a simple question: Active processes exist; kill them and exit anyway? “Yes”/”No” I wonder why not to do the same for unsaved buffers?
Some of the suggestions were inspiring and some need more elaboration. In general Emacs is knows as one of the most featureful editors in the market so it’s understandable why developers are hesitant to remove features. I created various designs and went through them using heuristic evaluation to find the optimum interface.
A better solution is a hybrid solution. When less than 3 files (I’ll discuss later why 3 is the optimum number) are changed, show this dialog to for every file:
The cancel action now is on a button. The text on the button indicates clearly what it is going to cancel, but it is possible to say just “Cancel”. It is demonstrated in the final design at the bottom of this post. The save icon was upside down in the IBM version. I chose a better icon (from www.iconarchive.com) that shows the diskette the correct way. There’s also an icon on the Yes and No button with widely used colors for positive (green tick) and negative (red X). A shortcut indicator is added for every button. Also a help button is added at the top. When user clicks on the help button the mouse will have a question mark next to it. Then when user clicks on a button, a little help window shows more description about what that button does. However, everyone who has worked with computers for a while should be familiar with the concept of saving a file. So maybe the help is not really needed if it is too hard to implement.
And when the number of changed files is more than 3, show this dialog:
By default all the checkboxes are set. User can manually uncheck the files that should not be saved. However the background of the files turn red to indicate a warning . When all the checkboxes are selected, the checkbox next to the “Save” title is also checked. In fact user can use that checkbox to select or unselect all other checkboxes at the same time (something like select all functionality in GMail inbox). Just like the single dialog this one has help, icons and colors. It is possible to resize the headers and scroll the list to see more file names.
The advantage of this method to the current Emacs dialog is that it shows the list of files which are changed. Currently when the user clicks on “Save All Buffers” or “No For All” he may not remember the name of all of those files. Maybe there’s a couple of files that he doesn’t want to save but the rest should be saved.
Now why this dialog should be shown for when more than 3 files have changed?
- First of all the multi-file save dialog box is less common than the single-file save dialog. So instead of exposing the user to unwanted complication, we try to show the simplest dialog possible. Users don’t mind clicking the save button or the shortcut (ALT-Y) for a few times, but more than that needs a slightly more complicated interaction design (multi-file save dialog).
- When more than 3 files are changed, the multi-file save dialog needs less clicks and takes less reading. Let’s say 4 files are changed and half of them (2 files) should not be saved. With the first dialog, user should read 4 messages and make a decision and press two different button combination based on every decision: ALT-Y or ALT-N. With the multi-file save dialog, user un-ticks 2 of the 4 items and clicks Save button or presses ALT-S. It is 3 clicks and the interface is much easier to understand for repeated interaction model.
Since the user may see any of these two interaction models, we can make it simpler by assigning the same shortcuts for the save button. In that case the single-file save dialog looks like this:
User may need to take a look at the file before saving. In that case both dialogs supports this interaction:
- In single-file save dialog if the user is not certain about saving or ignoring the changes, he can press “Cancel” and Emacs should immediately show the file in question.
- In multi-file save dialog if the user double clicks on a file name, the save dialog box cancels and the file that was double-clicked immediately shows up.
As a side note: this is another design idea that I came up with but it was unnecessarily complicated and crowded:
I have never thought of Emacs as the most user friendly editor because of its steep learning curve, hidden shortcuts and the fact that it is initially designed for text-based interaction and then ported to the graphical environments. However, it is one of the most featureful editors with a modular design, great extensibility and when you learn the basics it is extremely efficient to work with. Some of the great code gurus that I’ve had the honor to meet used Emacs as their number one editor.
In interaction design we differentiate between power users and casual users. Power users use the software more often than casual users and have the knowledge and training necessary to work with it efficiently, but casual users occasionally use the software and usually get annoyed when they don’t get it. IMHO Emacs is more of a power-user tool and if an interaction flow is too complicated and there is no way to make it simpler, maybe it should not be changed. Meanwhile casual users can use Ecplipse, Notepad++, TextEditor or even Notepad. Nevertheless, I still think the current file save dialog of Emacs is the tip of the ice burg of how many usability “issues” there might be for casual users while power users are used to the way things are and don’t want any change. The final decision is up to the architects of Emacs based on what they think describes their users the best: power users vs. casual users.
Here is the final design:
1 day later I received an email from Jason Rumney (firstname.lastname@example.org) who mentioned an important point:
You have some good ideas, but they seem to be based on a misconception that each dialog in Emacs is individually designed. That may be the case with other applications, but is not with Emacs. Currently Emacs dialogs are quite limited in their capabilities, so the best approach is probably to split this task into two:
1. Improve the options availble in the current dialog.
2. Improve Emacs’s dialog capabilities (a much bigger task, especially if backwards compatibility is to be kept).
So maybe fixing this usability issue needs more resourced, but does it worth it? What do you think? Please share your thoughts in the comment section.