Usability

There are 26 entries in this Category.

Across-the-Room GUI

 

[Demonstration of a small progress bar and a large one at 100% and at the smaller size as seen from across the room]One important aspect of interaction design is determining typical usage patterns for your application. What many people overlook here, is that these patterns don’t just happen inside your application, but may also be influenced by what happens outside, in the real world, in the user’s home. As an example, let’s take a feature that a friend of mine implemented in Toast 8:

As you are no doubt aware, Toast is a disc burning application. Most of the user interaction here is pretty straightforward: You drag files into a window, and then click a button to burn the disc. And this point is exactly where it gets complicated: when you burn a disc, your computer gets busy. Not only does it have to encode video content if you are burning a DVD, and decode the original data. After that it also has to write all that data that that was generated to a silver disc.

A lot of data is moved around during this, and you do not want to put additional strain on your machine, for fear of causing the CD drive to run out of data and creating a coaster. Of course, there is buffer underrun protection, but if your Mac starts thrashing, your backup CD could still become a coaster. So what many people do, is just leave the computer alone for a while and go to the other end of the room to do something else.

Knowing that the user does that is what gives you an opportunity to create a better user experience: Imagine the user is, for example, vacuuming the room, or cooking lunch, or reading a book. They will occasionally glance at the computer display, to determine whether disc burning has finished.

Now, today’s progress bars are roughly 16 pixels tall. Not really suitable for reading from across the room. Furthermore, when the window isn’t frontmost, progress bars actually turn a pale gray and become slightly transparent. This makes it a lot harder to read to them from a distance, since pale gray and the white of the track merge into the background. So, what my friend did for Toast, was to create a custom progress bar control that was not only bigger and had stronger colors when inactive, but also showed different colors for the different phases of progress.

This not only made it easy for the user to spot the progress bar from across the room, it also made it obvious whether Toast was currently verifying the disc, or whether it was still writing the lead-in or whether it was actually in the process of burning a particular track.

[Toast 9's scross-the-room progress bar close up and at a distance]

As with any custom user interface, one has to be very careful here. There is a reason why progress bars turn pale in the background: all of the user interface is designed so that color and strong lines will draw you to the current, focused window first. Since Toast actually needs color to make the current phase obvious from across the room, it was decided to not have an animation in the progress bar, which would otherwise have overwhelmed the user interface while the user is sitting in front of the machine.

From what I have heard, this feature has been welcomed by the overall user community. Many of the professional users seem to be starting a burn job on one machine and then continuing to work on another.

I recently came across a backup application that not only used a small progress bar, but also had it on a blue surface. This didn’t just interfere with the partly transparent progress bar in a background window, it also made it hard to distinguish the blue background from the blue part of the progress bar. It was hard to see where the bar started and ended, only the little white “unfinished” area was still clearly visible.

I sent the developer an e-mail with a suggestion for fixing this. If you are a developer, I encourage you to look at your progress bars. If any of them shows for a longer time, it might be a good idea to ensure that it can be read more easily from across the room. You don’t have to go as far as the Toast developers went, but simply choosing the bigger progress bar size in Interface Builder, and making sure there is enough white space around the progress bar that it can easily be spotted, and its edges can easily be made out from a distance, would already help.

Posted on 2008-09-28 at 11:00 Leave a Comment

This post is filed under Macintosh, Programming, Usability and tagged , , .

Hellp mee spel…?

Two important things in usability that are often overlooked are spelling and grammar. If users have problems following your sentences or recognizing the words you are using for important user interface elements (and not every user is a native speaker, and though they may be good at a language, they may still have problems recognizing a sentence’s parts if one word misleads them), they will have issues using your application.

Moreover, if your spelling and grammar are shoddy, this reflects badly on the rest of the app: If they couldn’t even bother to make sure the writing is OK, how must the code behind it look?

My sister just sent me a link to an article that illustrates with numerous examples that running the spell checker over your text will miss many mistakes:

Misused Words

You will want to go there and read it. There’s always one word that one wasn’t aware of was actually spelled differently.

Posted on 2008-02-14 at 14:04 Leave a Comment

This post is filed under Links, Usability and tagged , , , , .

Saying No in Software Design

A post on macSB made me stumble across a couple of nice articles on usability in open source software. They’re not only relevant to open source, but also to any other software design. Often users ask for a particular feature, and then a programmer just has to know when to say ‘no’ and when to say ‘yes, but…’

A programmer can’t just add every requested feature, and a programmer can’t just leave design up to the users. Designing software is the programmer’s job. Generally, users are exceedingly smart people, with lots of qualifications any of us can only dream of, but few of them are software engineers or user interaction designers. They needn’t be. The programmer has to accept user feedback and do some more work on it to turn it into a design that is not only possible to implement, but that also accounts for other factors the user may not have been aware of when he made the request.

But just like a typical user is not a programmer, a programmer is rarely a typical user. Some of the articles below elaborate on both of these aspects. The former is generally characterized as needing the ability (or the hierarchy, or the infrastructure) to say ‘No’, and the latter is in one of these characterized as “Designing for Aunt Tilly”. I’ll link to each article, then make a few comments. They open in a new window, so feel free to read them and then come back.

10 Ways to make OSS more humane

While this article is a nice, short introduction with some good examples and 5 DO’s and 5 DON’T's, it suffers from being a little imprecise and simplifying the problem somewhat. For example, a coherent design is needed, yes, and committees sometimes have to make compromises that end up making nobody happy, true, but still I wouldn’t make a rule like “Get a benevolent dictator”.

You don’t want someone who bosses people around, even with the best intentions. Instead, you want a professional servant of the people who is so well-respected that people will just listen. You want a person with qualifications. Be it just that this person has shown before that they can design an application, be it that this person has professional credentials as a lead programmer, interaction designer, executive producer or whatever else the project might ask for at a particular time.

You need someone that people trust. But of course you also want someone who is worthy of that trust, who is willing to stand back and listen to users or contributors, and is able to see and accept what good they bring to the project, but who will then be able to make the unpopular decisions, too, and make sure they’re followed through.

My guess is that Jono DiCarlo would agree with that, and that this is what he meant by “benevolent dictator”. After all, someone may be needed as a tie-breaker, because even an arbitrary decision from a dictator (or better, arbiter or ombudsman) is better than everything stopping in its tracks because the team can’t come to a decision. But I’ve seen a project fail because its benevolent dictator decided things with the best of intentions, but just didn’t have the trust and respect needed.

The Luxury of Ignorance

As I mentioned above, most users have other qualifications than being programmers, or system administrators or whatever. They are trying to get actual work done, and our software is just a tool to do that. They don’t have fun installing it, or configuring it, or activating it on every install, or writing scripts to schedule a recording of a TV show.

They want to see a great 5-year story arc, or write a great novel, create a funny movie about comic book characters. Hence, our programs should respect and support the user, and get out of the way otherwise. The user should be free not to have to learn about network interfaces and determining the computer’s IP address just to watch a movie on their iPhone. Or, as ESR so aptly put it, the user should have the luxury of ignorance of all the hard work your program is doing behind the scenes.

Ronco Spray-on usability

Eric S. Raymond’s article has its own flaws, but John Gruber summarized them much better than I could do. Because ESR’s article proves itself: ESR is the one-eyed among the blind, just like we are as programmers: The task he’s doing, and where he demands that it be made to suit Aunt Tilly, is a task Aunt Tilly would never try to do. That doesn’t mean Eric’s point is wrong, but it shows us that we can’t rely on ourselves to assess usability for typical users. We’ll just have to remember test our designs on actual users occasionally.

Rise of Interface Elegance in Software

Steven Garrity does a nice summary of the important points again, and adds that designing for real users is different from designing for the stereotypical “power user” or doing dumbed-down versions for some imaginary “average user”. If we design for discoverability, ease of use and ease of learning, we don’t need various “user levels” or “Advanced” areas that can be uncollapsed.

If we provide smart and sensible defaults, and keep unnecessary or conflicting options out of the UI, we can create applications that do the right thing for users just beginning to learn our programs, while once they become more comfortable with our programs, they will start looking for and discover additional options. And at this time, they will be able to also understand these options. We don’t have to design for several users at the same time, we essentially design for one user progressing through time, we design for the fourth dimension.

But this isn’t done by hiding buttons or shortening menus, this is done by hiding things in plain view, just at a little distance. The most-used, most important things are in the main window, in plain view. Some bigger, some smaller, all in an order that fits with the user’s reading order as well as with the order in which the user will probably need them (without enforcing this order, of course).

Secondary things go in popups and other menus, and things that are used rarely or not by everyone can be put in secondary windows that have to be explicitly shown, but which are obvious to a person looking for this feature (like the Apple DVD Player’s “zoom” feature, which sits in a small floating palette, and which lets you see more of your image, bigger on the screen, but with the black bars cut off).

ESR follows up along similar lines in his follow-up to Luxury of Ignorance.

Posted on 2007-10-11 at 17:02 Leave a Comment

This post is filed under Usability and tagged , , , , .

Dealing with it with Natural Language entry

John Gruber just posted a little piece titled Deal With It. He points out something that annoyed me since System 6′s Alarm Clock widget (or was it Calendar?):

Controls like the system standard date and time controls walk the fine line of compromise: They always enforce a valid date and are composed of separate fields that you tab through individually, but when you type the date or time separator, they move to the next field. So, if you go into Date & Time in System Preferences and click the time there and enter 12:34, it will automatically put the minutes into the next field, even though your first click selected the hours.

Stupidly, iCal really implements the components as separate fields and requires you to type the tab key whenever you want to enter the next date component. Type the date separator and it just beeps at you. IMHO that’s the main point that makes it annoying.

However, even if a custom control for entering formatted values may require as many or as few keystrokes as a free-form text field, the field will feel more natural. As long as it is clear what you are expected to enter into the field, and how to enter it. This can be done with the little grey “placeholder” text some fields on Mac OS X have these days, but is very hard to get right.

For instance, it’s not quite easy to parse any kind of date a user may type into a date & time field. Some of the ambiguity can be resolved using the system’s locale-specific date & time settings (quick: 10/09/2007 — 10th of September or 9th of October?), but coding everything, including “in 3 days”, “3 days from now”, “next wednesday” and all variations that may exist in a particular language, can be a lot of work and require a good deal of processing. And once you start accepting simple things like “Today” and “Tomorrow”, where do you stop? What about “Next Easter” or “The Next Monday that is the 1st of a month”…

And suddenly we’re in the area of the Uncanny Valley and the Turing Test: How much can I expect a free-form field to understand? Many people will not even try such complex expressions because no other program understands those. If Apple implemented a consistent free-form date field, users would slowly learn that every application has a field that works, would learn in one that they can do more complex stuff with it, and then would try that in other apps as well. That’s how MacOS has always used consistency to the user’s benefit.

But still, they’d have to learn the limited language the computer understands. It would just be another command-line. And making a restricted language too close to English has often been the downfall of English-like programming languages: The closer a language is to natural language, the more we tend to only memorize the general meaning. Then, when it comes time to use that command again, we reconstruct the sentence, get one word wrong and have no idea why the stupid computer doesn’t understand. We dive nose-first into the uncanny valley.

However, John’s posting makes me think that not the graphical user interface, but actually the command line will be the future of user input. Right now, our level of interaction is that of the typical European in rural China: Point at two things, and hope the other understands. Once dictation matures, this can change to a degree. We can enter commands by voice, like speech recognition already allows to a degree, but we’d also have to be able to dictate new data, names, addresses, whatever, to make this feasible.

This would not replace the GUI with that speech-controlled command-line, but augment it. Right now, we’re at the verge: NSDateFormatter already understands a lot. But you still have to know (or test) its limits to use it. But luckily, our users are getting more proficient. Somewhere in the middle, our coding skills and users will meet, and voice-control will be an everyday occurrence. Until then, we’ll have to cope with The Stupid Computer(tm) and its stubborn misunderstandings…

But yes, the future is the command-line, not the WIMP-interface.

Update: I’ve had the time to read the complete Three Hypotheses of Human Interface Design-article that John Gruber referenced in excerpts. Maybe I’m not getting it, or maybe it’s the equations that are actually important, but I think in general most of the things written there can be found in other HCI books:

Measuring the number of actions and weighting them is a very common task in usability research. For example, Jef Raskin’s book The Humane Interface provides some examples of this in one of the early chapters, so the readers at least have the basics down before he starts with his actual theses.

Similarly, cognitive load, and how much more important it is than many people think is covered in Steve Krug’s Don’t Make Me Think, where he also points out how people are always spending about 80% of brain power on what they actually want to achieve, and only 20% on actually using your application.

So, no, I don’t think the author actually invented it (well, it may be a double-creation, but like everything, it’s been there before), but his article is a good starting point into the subject matter, IMHO.

Posted on 2007-03-25 at 12:08 Leave a Comment

This post is filed under Macintosh, Programming, Usability and tagged , , , .

Red Sweater Blog: Build your own damn HIG

Daniel Jalkut recently blogged about building your own damn HIG, where he takes inspiration from John Gruber’s C4 speech on why the Human Interface Guidelines may be dead. If you haven’t read it yet, you may want to so so now.

One thing he overlooks is that, just maybe, computers have become more sophisticated: Back when the Macintosh came out, resource limits forced elements on screen to be simple. Now that we have more colors and more pixels, and bigger hard disks, there’s room for more variation, without making things too difficult to recognize.

Similarly, back then Apple pretty much had to introduce people to the GUI. “educate” the users. Nobody knew insertion marks, pointers, the mouse, menus… These days most people are familiar with the basics. Just like a caveman would probably not have understood what a button was before the invention, the race as a whole had to learn, so to say. What would be an odd, stuck pebble, maybe, that you can push a button and cause something else to happen, maybe miles away, is a more recent invention.

That you can move a mouse and a pointer will move synchronously on the screen, and that the “world” on the screen basically works the same as the real world, is even more recent. But these days, children see their parents use a computer, and much of a computer’s chips and usability has partially made it into simpler devices, be it the iPod or your TV or your cable box.

I also think that he’s overlooking a third option, apart from ignoring the HIG or just following your stomach: Doing your own usability research and creating your own UI, inspired by the basic conventions of the platform you’re on (not applicable items are shown dimmed, close boxes have an “X” symbol and either a certain shape or color…).

I often recommend the book GUI Bloopers by Jeff Johnson to people who don’t know about usability. Why? Because even though it mainly has screen shots from Windows 95 and System 7, it is still perfectly applicable to today’s user interfaces. With the vocabulary of these simpler operating system user interfaces, with these prototypical, I might even say archetypical graphics as examples, it shows you the thought behind the guidelines, not the word up front.

It’s like the Bible: “An eye for an eye” doesn’t mean: If someone hits you, hit back. Rather, it tells you to consider commensurability: If someone pokes out your eye, don’t kill his family as it happened in those days. So, what seems to be a very violent command to today’s audience, was actually an obvious call for moderation in the context of ages past.

And before I go off on a tangent, I’d better close this posting.

Posted on 2006-10-27 at 11:28 Leave a Comment

This post is filed under Macintosh, Programming, Usability and tagged , , , , .

Don't validate your address forms!

One of the things that I often have problems with, especially on new web sites from US-based companies, is how they treat addresses and phone numbers. So, here’s a few rules that should help you make sure international users/clients can use your address form.

The ground rule is, you shouldn’t validate the form in any way, because e.g. in Germany addresses are pretty freeform. E.g. most US forms expect a zip code and postal code. While the former doesn’t exist in Germany (they’re kinda “built in” to the postal code there), the latter goes before the city. Also, keep in mind that assuming the order of the first and last names may not work for some countries (though that’s mostly outside Europe, so I won’t try giving any examples for fear of exposing my cluelessness). Similarly, in Germany the street number goes after the street.

Deutsche Post uses machines to pre-sort mail over here, even for hand-written addresses, and that means if they’re wrongly formatted, they will first get delivered to a wrong place, and only then a human will see they’re wrong and re-deliver them to the right place.

E.g., valid addresses in Germany could be:

Firstname Lastname
Streetname 123a/1
Suburb
12345 City

 

Or it may be

Company
12345 City

 

Or it may be

Firstname Lastname
Areaname
12345 City

 

Or it may be

Firstname Lastname
bei PersonTheyreStayingWithName
Street-name-or-so 12
Appartment 7
12345 City

 

Or you may have Mannheim, where the streets are divided into blocks and you have

Firstname Lastname
P4,7
68123 Mannheim

 

And I haven’t even accounted for PO boxes here, though they’re about the same as the “Area” address above.

So, you can neither assume that the actual address has the form “Number Street”, nor “Street Number”, nor that the building number is just a number (there are dashes, slashes, capital and lowercase letters, apartment numbers etc.).

Also be careful with length limits, because I know people who lived in streets called “Straße des 15. Juli 123″ or “Großherzog-Friedrich-Straße 1234″. Both of which had problems with many paper forms and some web forms (but in paper forms you can just write narrower or on the edge). Oh, and Berlin used to hold the record with a street named “Prinz-August-Wilhelm-von-Württemberg-Straße” (a whopping 43 characters long, though recently renamed)

Though in general, most German addresses can be made to fit into the following scheme:

Name:
Address:
Address 2:
Postal code (5 digits, but may start with zero):
City:

if you want to support other countries besides Germany, you should probably use one field for postal code and city, and not validate that in any way, because the UK have alphanumeric postal codes, while Switzerland has only four digits…

My best recommendation is to get beta testers from as many countries as you can and have them supply you with example addresses, especially particularly long and short ones, as well as odd ones. That way you can test your form. Where that isn’t possible, think about adding a (maybe optional) freeform address field where people can enter addresses that don’t fit your proposed scheme.

And did I mention that you better not try to restrict or format international phone numbers? In particular, be sure to allow for “+”, “-” and brackets so they can include the international prefix, and don’t auto-group numbers because e.g. German area codes can be four or five digits in length, and lose their leading zero when called internationally… So, a valid number would be something like:

+49 (0)1234 12345678-123

but can also be

+49 (0)12 1234

 

The dash above can be ignored, but it’s still bound to make the typical US phone number field choke.

 

If you know foreign addresses that don’t fit the above two-address-field scheme, please leave a comment with an (anonymized!) example. I’d be interested in working out a scheme for addresses here that people can just apply to their forms to have it work internationally.

Posted on 2006-09-30 at 12:16 Leave a Comment

This post is filed under Usability and tagged , , , , , , .

So, when will it be more secure?

In ye olde days, when someone talked about an inherently insecure operating system that indiscriminately launched downloaded applications, it was Windows. But in recent updates to the system and Safari, Apple has made similar mistakes, even the same ones the designers of Windows made. That there are no viruses for MacOS X at this point in time seems to me to be more a coincidence than a sign of OS X’s impeccable design as a secure Unix.

When OS X was first introduced, I complained that even having a console was already more insecure than OS 9. Though true, it’s like complaining having a front door makes your house more attractive to burglars, so I’m not going to complain about this. Instead, let’s look at other, worse loopholes.

Unix security and the typical Mac

Unix security generally works per-user. In the days of time-sharing mainframes with attached terminals, that was enough granularity. Even though every program ran on the same mainframe, no user could see the others’ files or run a program that did more than damage his own files. Whenever a virus is executed on a Unix system, it is bound by what the user running it can do. So, everyone talking about how Unix permissions make it impossible for a virus to do much damage, is probably talking about the whole computer. It’s true: operating system files are only modifiable by administrator users or the all-powerful root user.

However, when you look at the typical Mac user’s system, you’ll notice two things:

  1. There is only one user. The one that has been created when you installed the OS. And it’s an administrator.
  2. The files the user cares about are not the system files. It’s easy to reinstall the OS when your computer goes south. But the files that are really hard to get back are generally the ones the user created herself. And since computers aren’t a purpose unto themselves, but rather just a tool for creating correspondence, music, managing photographs or whatever, only those files are worth protecting.

To Apple’s credit, they actually managed that better than it may seem from my comment above: An administrator is by no means an all-powerful user, but instead is a user that can be made to be almost as powerful as root, but isn’t by default. So, as long as you don’t indiscriminately enter your password on a Mac, an admin account is seldom more dangerous than a regular un-privileged user account. But even that user can delete all their own files.

I can’t feel my hands!!!

The problem is that there are so many applications these days that require an administrator password. Heck, even Mail.app asks for a password (not the admin password, but still) every time something goes wrong, even if it wasn’t an authentication error. This de-sensibilises users. When an app asks for their password, they may just go: Oh, it’s mail checking for messages in the background… and just type in their password. Agreed, it is fairly unwise to have the same password on your Mac and your mail account, but it happens.

Then came Safari and started launching and auto-extracting downloaded archives and disk images, and then even launching installers in them. Finally, they made Safari auto-install Dashboard widgets. It’s a convenience, but one we already cried out about when Internet Explorer had that bug.

Apple’s fix was to start showing a dialog window saying: This archive may contain an application, do you really want to go on? whenever you downloaded an archive. But not just in the cases that were actually dangerous or before it tried to launch some app, no. They did it for every darn archive.

Like on Windows, such oodles of questions and dialog windows eventually make users stop reading what’s in the dialog window, just entering their passwords, clicking OK left and right.

Introducing … Address book, iLife and the new iTunes!

One reason why e-mail viruses such as Sober have been so devastating is that they accessed Outlook’s address book and sent themselves to everyone in your address book. Not to be trumped by Microsoft, Apple quickly caught up in this regard and gave us AddressBook.app, which allows viruses to easily query your contacts’ addresses.

Then came iLife’s resource browser, which shows us how neatly apps can be integrated. They could query your list of photographs and easily send them along to make the message look more authentic. If you don’t think this may be a problem, the new iTunes reminds you that even Apple can’t be trusted to not transfer your currently playing songs over the net…

True, iLife’s resource browser isn’t available to other programmers besides Apple’s but that’s not really important, because actually getting at the playlists and photos isn’t very hard. After all, all applications have free access to all of their user’s files.

Apple already has a solution from the Unix world to fix this: Access control lists (ACLs). Access control lists essentially allow for much more granularity on who may do what to which file. A little extension of that, and they could simply prevent all applications from reading your address book, walking your photo library, calling home via the internet or deleting your TextEdit files, except those that you actually give permission.

Yes, during the first launch or during installation you’d have to ask the user whether they want to give an app the correct permissions, and that’d confuse newbies a bit more, but with a sensible set of default permission sets, the list of things to let the app do could be as short as:

  • Send E-Mail (to your address book contacts)
  • Manage the iPhoto library
  • Access files not owned by this application

(Of course, Apple would need to find the most common permission combinations and create human-readable names for these combinations, otherwise the lists would get so long that users wouldn’t read them anymore)

If they added a more reliable and powerful facility for sending feedback and bug-report e-mails through Mail.app, and added something for updating third-party applications (like Shovel or Sparkle) to the system, most apps wouldn’t even need the first item. Users would just get a prepared E-Mail in Mail.app, with a system profile or so as the attachment, and could decide themselves whether to send it or not.

When an application tries to use a permission it doesn’t have, the OS could show a warning and offer to the user to permit/prohibit this action once or forever. So, if a screen saver suddenly wants access to your address book, you’ll know it’s a trojan… It’s definitely not an ideal situation to ask the user this many questions, but most users seldom install new applications, thus keeping them wary of these requests.

So, why all of this?

Apple needs to get access control lists adopted for such purposes quickly, before the first Mac virus hits and destroys its reputation, or even worse, users’ data. Safari needs to be fixed to not just say "There may be an application", but rather to be more precise. When you download a Dashboard widget, it should not tell you there may be an application, but rather it should ask you "You just downloaded a widget, shall I install it? It may be dangerous!". And it should not ever warn about applications when the archive only contains a text file.

I’m not a security guru. I’m just a programmer. But when even I see the glaring security holes, it’s time to act on that.

Posted on 2006-01-11 at 13:30 2 Comments

This post is filed under Macintosh, Usability.

Installation and Uninstallation on MacOS X

Soeren found an article on easier deinstallation on O’Reilly. The general idea (for the pointy-haired bosses among you who don’t have time to read it) is that every application would get an additional .plist file in its bundle containing the paths of files (like its prefs file) that can be safely deleted along with the application to clean up support files, like the ones in ~/Library/Application Support.

Problems of this approach

My one regular reader may not be surprised to hear that I don’t think the paths idea is a robust enough approach. For one, it would break when the user renames a hard disk. Secondly, some support files’ paths (e.g. Photoshop’s swap files) could be configurable, and then the .plist-info would need to be modified. And it’d be even messier if several users could provide different places to keep these files.

Putting support files in the app bundle itself, as some commenter suggested, has similar problems, especially if the software is on a server and shared between hundreds of users. It’d circumvent users’ disk quota and make permissions for an app bundle unnecessarily complex.

Alternative solution

My suggestion would be to simply add some sort of metadata to such support files and then use the Spotlight index to get rid of such files. Whether it’s done using access control lists, an xattr that simply says: kIsSupportFileOwnedBy = de.zathras.talkingmoose, or they define an OS9-style creator code in your Info.plist that says that all files with this creator are deletable support files, I don’t really care.

If all apps were required to give their support files such attributes, one could even have hard disk clean-up apps that can quickly find any orphaned files, like it was possible on Classic MacOS with creator codes (e.g. FileBuddy checked for files with unknown creators and offered to delete them). It should also be supported by NSDocument without too much work … NSDocument‘s bad support for creator and typecodes is the main reason for bad creator support, along with an ambiguous policy on Apple’s part and the discontinuation of the type/creator registry on their homepage ages ago.

Maybe it should even be a list of owning apps’ bundle IDs in an xattr. That would allow extending this to other kinds of files. E.g. a shared Framework could be auto-deleted when all apps that own it have gone.

Of course, Finder should generally ask whether the admin wants to delete all support files for all users who’ve used this app. After all, they may want to remove the global copy of the app and give two users who still need it local copies when an app is phased out. In that case, they’d want to be able to keep those users’ files.

Other installation/uninstallation improvements

While I’m at it, here’s an idea for making all applications drop-installable, even when they need an installer/uninstaller: Apple could support install and uninstall executables (which could be any of applications, shell scripts or .pkg files) that reside in an application’s bundle in a standardised location:

Users simply copy over the app, and when they first launch it, the Finder runs the installer in it, deploying all needed files. When you delete it, Finder finds the uninstaller and offers to run that.

Posted on 2006-01-05 at 14:22 Leave a Comment

This post is filed under Usability and tagged , , , , , , , , , .

Consistency and Uniqueness…

Soeren must have hit a gold mine of great ideas for postings somewhere. Today he posted a few interesting thoughts on consistency vs. uniqueness. He raises some valid points, and I’m torn between agreeing and objecting. Here’s why:

I fully agree with Soeren – and even to some extent with Wil Shipley – that custom UI and a custom look aren’t bad. For example, I liked the fact iChat and iTunes were the only brushed-metal apps on my Mac way back when. It allowed me to more easily pick them out of the pile of windows to quickly answer an instant message or pick a different song.

I even think it might be handy to have something like “labels” to let you tint each application in a different colour, if you want to. I also think that brand identity – as long as it doesn’t get in the way of actually using the program – is a good thing, for exactly the same reason: A particular icon style and colour scheme make it easier to pick out partially-obscured windows.

However, I do not think that custom controls should be used very often. Apart from issues like accessibility or wrong mouse tracking behaviour (like the built-in “undo” that you get when you click a button and then release the mouse outside instead of over it), the problem is that users still get confused:

I still have people asking me whether they should single-click or double-click, simply because there’s no clear rule anymore now that a single click launches an item in the dock and the dock – as opposed to, say, the launcher – uses icons instead of buttons. And if you’ve ever seen someone double-click a “delete” icon in a window toolbar, making them inadvertently delete two list items and not noticing it, you’ll know that this isn’t necessarily harmless.

So, as soon as developers start introducing odd-shaped buttons, people will wonder: Is this like a segmented control or some bevel buttons which can be used like checkboxes or radio buttons? Is this a button that will immediately trigger an action? While often the use of nouns, verbs or adjectives as labels gives away what a button does (if it has a text label and not just an icon), there are other cases where it’s ambiguous. Ideally, developers would either pick decent wording or make the control look like all others that work the same way on this system. But when developers use system controls, they have those as a safety net for that case where the wording is ambiguous (e.g. “debug title” could mean “title for debugging” or “debug a title”, and it’s easy to overlook such ambiguities because the developer’s mind is already on the right track).

The guys who did Apple’s HIG had oodles of reasons for recommending you don’t roll your own controls if you can avoid it. But they don’t outright forbid it. So, play it safe as much as you can, and only do custom stuff if you have a very good reason to do it, and if you’ve had all options available (including standard controls) thoroughly tested, not only by you, but also by lots of test users, disabled people, and complete newbies to the Mac.

Posted on 2005-11-17 at 13:03 Leave a Comment

This post is filed under Macintosh, Programming, Usability and tagged , , , , .

Soeren on icons on menus

I just came across a piece on icons next to menu items. One thing it doesn’t address is the added clutter, and the alignment issues between a piece of text and its icon (and menu items with an icon and those without them). I’m not sure why they aren’t used very much on MacOS, although support’s been there since at least System 6. Safari has an icon next to its bookmark items, and the dock displays little window icons next to the entry for a window in the dock menu, and there’s files’ icons in the dock menu for a folder (like in ye olde days in the Apple menu). If you insist, I’ll also count menu icons, but there aren’t many more. Windows is different here. Lots of icons next to menu items, and you also see that on ported apps occasionally. I wonder whether that’s just historical, pragmatical (i.e. having to design an icon for every menu item is too expensive, and reuse isn’t desirable here) or whether there’s actual usability research behind that.

Posted on 2005-11-14 at 14:18 Leave a Comment

This post is filed under Links, Usability and tagged , , .

« Back
More »