Usability

There are 28 entries in this Category.

Sensible Defaults and Anticipating User Needs

I have written before about sensible defaults in various shapes and forms, but I realized I never really wrote about the logical consequence of that in application design.

To recap: For every application, there are usually one or several typical operations and typical workflows that users may have to perform. A programmer needs to determine those workflows, examine them, and split them up into individual work units that the program can perform.

In some cases, that’s all you have to do: Come up with menu items, buttons and controls that perform the individual subtasks and merrily go on your way. But a good interaction design has to go beyond just letting the user do the operations with a computer instead of with a hammer. You will want to optimize the workflow.

One of the fundamental rules of interaction design comes from the early days of the graphical user interface, when all we had were command-lines. Back then, one bright mind realized that we shouldn’t have the user type in anything the computer already knows. That’s how we got menus and radio buttons in the first place. Instead of expecting you to remember terms, the computer will present sensible answers and let you point at one, as if buying cheese at the cheese counter in a remote Swiss village where they still speak that Latin-descended language few others in the world know.

This may seem to no longer be relevant now that everyone is well-versed in the use of what are now standard controls, but it is also relevant to your workflow. Take an FTP program, where you create your web site locally, and then upload it to the server:

The usual workflow would be to have a list of all the files in the user’s folder, have the user select the ones they want to upload and then push a button to trigger the upload. That’s a good design, right?

Meh.

Look at your workflow. Look at the typical use case. The user has files on disk that are a 1:1 representation of the site the way it should be on the server. Our FTP program knows the folder, it knows the remote directory on the FTP server. The user has changed a few files, and both the local hard disk and the server track change dates. The computer already knows which files the user will want to upload!

So, instead of just being a nice graphical veneer on top of what is essentially the networked version of cp, why not optimize the workflow? If the user does not select any files, why not offer them a list of changed files and ask them: “These 4 files have changed, did you perhaps want to upload them?”

Now, we can’t always assume the user will always want to upload all of these files, so you need to ask. But in that panel that asks, you can let the user remove the files to not upload yet. And always keep in mind that we’re dealing with heuristics here. Some people have one folder containing lots of files for different servers. You don’t want to annoy them by always selecting 50 files for 25 other servers, because she only selected the two for the current server. Not every upload is a full-blown sync.

Unless it looks like something very stupid to do, if the user expressly states an intention, just do that. It’s bad to be a boring app that needs the boring old ten steps when you could do it in five, but it’s worse to be the app that always gets in the user’s way by trying to provide “helpful suggestions”. Clippy the psychotic paperclip anyone … ?

But if the user is vague (like clicking “upload” when nothing is selected), don’t just say “Can’t upload nothing”. If you can, offer to do the most likely thing she was trying to do. And if you have such a feature, maybe it’s a good idea to indicate that in your UI. E.g. mark all files in the list that have changed with a little green up-arrow, and change the name of the “Upload” button to “Upload Changed”, or so. We may not be able to implement the DWIM-button, but we can inch closer and closer to it.

What workflows could you optimize in your (or your favorite) application? Where does your application know things that can be used to anticipate what the user wants?

PS – I had a particular app in mind when I wrote this article, but I didn’t want to point fingers. So I thought long and hard to come up with a different example. Hence, this may seem like a petty, tiny detail, especially in light of the “sync” feature most FTP programs have, but play along. Try to come up with a better example. As long as this article has started you thinking about ways to anticipate user needs, my job is done.

Why I don't want to be Delicious – Beyond the Unboxing Experience

Ages ago, most blogs I read were abuzz with talk about “the delicious generation”. There was talk about “writing your own fucking HIG”, about “steak versus sizzle”, and many other beautiful and colourful phrases summarizing why and what the “Delicious” group of applications was (supposed to be).

Let’s just say that I always felt uncomfortable about the whole concept. Maybe it is because I started programming under classic MacOS, where Human Interface Guidelines were strict, and we had to count every pixel twice before using it for a UI element. Pixels were rare, and colors were few and far between. We had to walk ten miles, uphill, barefoot in the snow just to get an event loop, and even then we had to write it ourselves. And when our app crashed, it took the Mac with it, and we liked it that way. … err … sorry, don’t know where that came from.

All right, I admit there are some things the delicious apps, and their stepchildren, and Apple’s UI experiments in their own mothership-designed apps have given us that I am very grateful for, and which I appreciate:

  • A whack over the head reminding us that we have enough colors and pixels these days that we can use a different texture for a popup button without the risk that no user will recognize it as a popup button.
  • A renaissance of real-world metaphors, but this time in photorealism instead of as the simplified, idealized toys in MacDraw’s and MacPaint’s toolboxes.
  • A new appreciation of professional graphics design and polish.
  • More attention paid to the un-boxing experience and to welcoming new users, including the metaphorical return of the trusted old “Macintosh Intro” and “HyperCard Tour” in the form of welcome screens and tutorial screencasts built right into the applications.
  • Heart and soul for our applications, including tiny features that make our users go “wow!” when they realize someone actually thought of that.
  • A willingness to part from the well-trodden paths of the letter of the Human Interface Guidelines when there is a good, well-researched reason to do so, and it doesn’t violate its spirit.

However, one thing I found consistently missing, was paying attention to users’ workflows and efficiency. Most of the attention seemed to have been paid to the initial un-boxing, leading the user into the application, making them go “wow!”, providing the basic feature set that was needed to sell an application as whatever kind of application it was supposed to be.

File comparison utilities that were only able to compare two files, without the ability to take into account a common ancestor (heck … FileMerge and even diff do that out of the box, for free!). Version control applications that require you to select every single file and add it, are unable to retroactively detect moved files, have no support at all for branches and merging, and hence get their asses kicked by an application with an Eclipse-style Java UI. Disk burning applications that made it too easy to accidentally delete a file while scrolling, and that just passed through features of the disk recording framework, and which haven’t seen more than a single maintenance update in over two years because they are apparently waiting for Apple to add new features instead of doing it themselves. Book databases that crawled to a halt just around the number of items where it would make sense to start keeping a database of them, and then sold the fix to that issue as a major reason for version 2.0.

All of these applications have one thing in common: They seem great at first, but after you’ve used them for a while, they fall down flat on their noses. Yes, not everybody uses an application the same way, and yes, not everyone needs the same features, and yes, you need to build up recognition and a brand identity if you want people to remember your application and you want to stay in business. But you also need to actually do for the user what she expects you to do.

And that’s why I have decided I do not want to be Delicious.

Do I want a professional-looking, polished application? Yes. Do I want to create a program that is inviting and enticing to the user? Yes. Do I want to provide the best, most intuitive user interface for my users? Hell yeah.

But my application also has to be able to support the user in doing their tasks every single day. It has to cope with the user not quitting it and not shutting down their Mac for a month or more on end. It has to honour their priorities and their data, it has to perform well in real-life situations with real-life data. It shouldn’t present cryptic error messages or get stuck in error message loops when an error occurs, and the concept of an “unexpected” error should be anathema. And it should support the user, not just sit by and be idly manipulated. It should have sensible defaults and do the right thing out-of-the-box.

And sure as hell it shouldn’t unnecessarily transmit the user’s data over the web or evaluate it just so I can present it on a map or announce how much money people have made using my app in the last month (!), redirect every operation on the ‘net the users do through my company servers, delete the user’s home folder or encrypt their files when my app thinks their license had been tampered with, send their whole address book to my company servers unencrypted without telling them beforehand, or install code that gets loaded into every application just so I get better crash reports.

Could a Delicious application get that right? Sure. Did any of them? Not that I’ve seen so far. With most of these apps, the graphic designer was driving the bandwagon. The arrangement of things on screen was not decided by how quickly a user can execute several operations that are usually done in sequence. It wasn’t decided by how easily the eye can grasp which screen elements go together, what relationship they have, or what the current state of the user’s data is. The driving design force seemed to be: Will it be a good demo? or Does it look good?.

Now, if you’ve paid attention to usability, the commonly-used term is rarely “look”. It is usually “look and feel”. And the feel is the domain of the interaction designer. And as much as I’d love to say otherwise, the “feel” rarely is delicious. The feel is that gossamer-thin fleeting quality that, after more than twenty years of aping, Windows still hasn’t been able to imitate from the Mac, and that the Mac invented without any help from its grandparents at Xerox PARC. The right feel is the thing to strive for, the feeling that the computer is along for the ride with you, the user, that the application is really there to help you, and is a reliable pillar of support, and not just a colourful banner flying in the wind.

Keynote, iMovie, iTunes and Garage Band, Apple’s apps that were so obviously the inspiration for some of the UI experiments that the delicious generation entertained, got this right. They made things as simple as possible, but no simpler. Did they make a few mis-steps? Yes, Keynote’s “Builds” drawer shamefully hides behind the inspector, waiting to be replaced with a timeline or something similarly easy to manipulate that doesn’t cause a huge bunch of stacked up objects in the middle of your window, but the custom UI in Garage Band made it look approachable, frendly, and that weird wooden edge gives it a real feel. And Keynote’s simplicity isn’t achieved by leaving out text labels and hoping your icon designer is a genius and can cram a complex context into an 8×8 pixel icon badge.

So, think different. Don’t do what the cool kids do. Be Non-Delicious and instead just create applications your users love.

In the interest of full disclosure, I should mention that I occasionally do work for Roxio on Toast, so my comments on disk-burning software may be biased. Then again, this is my personal blog. Everything I write is biased.

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.

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.

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.

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.

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.

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.

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.

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.