The Path of Least Resistance

March 17, 2005 by Ping

This year I attended South by Southwest for the first time and enjoyed meeting lots of interesting folks.  During a session about decentralized social networks, the panelists mentioned the problem that bloggers (especially beginning bloggers) sometimes post personal information about themselves in public without realizing the risks.  Often they may be unaware of the size of their audience — maybe they think only a few friends are reading, or they forget that the posts are public on the Web and show up in Google.  The individual tidbit of information being posted may seem insignificant but can be combined with other posts to yield a detailed personal profile.

The reactions that followed provided absolutely perfect examples of the two classic kinds of responses to security problems.  I really couldn’t have asked for better examples to illustrate my point, even if I had cleverly planted co-conspirators in the audience to read scripted statements.  (And you know I would never do that.)

Classic response #1: Blame the user. One audience member pointed out that the button to publish a blog post says “Publish.” He argued that users ought to know what “publish” means — of course it means their posts will be public.  If they’re clueless enough to publish personal information that puts them at risk, it’s their own fault.

Well, fine.  It is their own fault.  But so what?  That doesn’t make the problem go away.  When we arrive at a “solution” that consists of blaming the user, it’s time to take a step back and ask ourselves what we’re really trying to accomplish.  Is the primary goal to serve the user’s needs or merely to disclaim responsibility?  If we’re really interested in serving the user’s needs, then whether the user is at fault is beside the point.  Users are bound to be at fault sometimes; after all, they are human.  The real issue is whether we, as designers of the tools, can do any better.  If we can improve the user’s chances of getting it right, we should.

Classic response #2: Annoy the user. Blasting the user with warnings is a common quick fix.  Someone at the session recalled the warning message that used to be displayed by Usenet clients when posting to a newsgroup.  (Remember Usenet?  In its day, folks read news an awful lot.  The command to read news was just two letters — rn — rivalling the importance of all the other cryptic two-letter commands like ls and rm and cc.) Before posting an article, the newsreader program would show a scary warning message like this:

This program posts news to thousands of machines throughout the entire civilized world.  Your message will cost the net hundreds if not thousands of dollars to send everywhere.  Please be sure you know what you are doing.  Are you absolutely sure that you want to do this?

One might imagine a similar warning for users of blogging software:

This program posts your article at a public website, where it can be indexed by search engines and viewed on millions of machines throughout the entire civilized world.  This article could be read by your mother, your boss, the CEO of your company, or someone your future self wants to ask out on a date.  Please be sure you know what you are doing.  Are you absolutely sure you want to do this?

In general, I don’t favour warning prompts.  Although warnings may get noticed the first couple of times, they quickly become a pointless irritation.  Warning prompts train users to hit “Okay” without thinking: interrupting the user’s workflow makes the user eager to dismiss the interruption quickly in order to continue the expected workflow.

A case could be made that a warning prompt is adequate in this situation because it’s intended for beginning users.  Maybe it only matters that they notice it the first couple of times.  But after it becomes ineffective, it’s still annoying, which leaves us worse off than we were in the first place.  The industry standard solution is to add a checkbox to the prompt to let the user turn off the warning.

Can we do better? Let’s come at this from a different angle by considering the user’s path of least resistance.

I use LiveJournal to keep a personal journal.  When I post an entry, there’s a little listbox labelled “Security” that looks like this:

LiveJournal privacy setting

The options are “Public”, “Private”, “Friends”, and “Custom”, with “Public” selected by default.  If I take the path of least resistance and just post the entry, it will be published for my mother and the CEO to see.  LJ doesn’t have a separate way to save a draft of the entry; to do that, I have to post it as Private.  But sometimes I forget.  Also, on LJ, the button to post the entry doesn’t say “Publish”.  It just says “Update Journal”.

LiveJournal posting button

In short, doing the safer thing (saving the entry privately) requires more work — I have to remember to change the Security setting.  Doing the riskier thing (publishing the entry to the whole world) requires less work — I just click the button and boom, it’s public.  That’s backwards.

I use WordPress to run this blog.  At the bottom of the box where I’m typing in these words, there are three buttons:

WordPress posting buttons: Save and Continue Editing, Save, or Publish

It takes an equal amount of effort to save the post privately as it does to make it public.  That’s better.  Also, the “Save” button is labelled in bold, suggesting that it’s the default.  That has no effect on the operation of the buttons, but it leans slightly in favour of the safer option.

I went over to TypePad today to see how they handle this issue.  At TypePad, you decide whether your entire blog is public or private.

TypePad privacy options: Publicized, Not Publicized, or Password Protected

The default is Publicized, the most risky option.  This is arguably a less dangerous context than the moment one posts an entry, though, since nothing has been written yet.  And maybe most users would devote more time and attention to making the choice here since it affects the entire blog.

I wondered what I would do if I changed my mind about this setting.  After the blog was set up, I went to the options.  It took a bit of clicking around to find the privacy setting — it’s not in the Control Panel under “Site Access” as one might expect, but instead within “Publicity & Feeds”, which is inside “Edit Configuration”, which you see after you select your blog from the Weblogs list.  Here it is:

TypePad privacy setting: Would you like your weblog to be public?

(I was surprised to find it set to “No” since I had just proceeded with a choice of “Publicized”.)

This is where it gets really interesting.  The question asks whether I would like the weblog to be public, but choosing “No” doesn’t really mean “No”.  “No” means “leave everything publicly viewable but don’t announce the existence of this blog.” A sidebar on the page tries to clarify the issue:

TypePad sidebar: NOTE: Not making your weblog public does not password protect your site.

The combined effect of all this is too prone to error and confusion.  That last sentence of the question seems especially dubious: “If you do not want the general public to know about your weblog, select ‘no’.” I think it suggests an inaccurate level of assurance.  There are lots of ways for people to find out about a blog besides seeing it on TypePad’s lists.

Finally, what about the moment of posting?  TypePad has an option list that defaults to “Publish Now”:

TypePad posting options: Draft or Publish Now.

The buttons provide two possible actions, previewing or saving the entry:

TypePad posting buttons: Preview or Save.

So, to save a draft I have to notice the “Posting Status” option, change it to “Draft”, and then press “Save”.  To publish immediately, I just press “Save” (notice this button doesn’t say “Publish” either).  Again, backwards.

My point?  Consider the possible outcomes and evaluate how much risk each one involves.  The higher-risk outcomes should require greater attention and effort; the lower-risk outcomes should require less.  Ideally, if you arranged all the outcomes in order by risk, they would correspond exactly to arranging the possible user actions in order by difficulty.  That way, when the user makes a mistake, they’re more likely to do something safer than what they wanted instead of something more dangerous than what they wanted.  I like to call this the Principle of the Path of Least Resistance.

Of course, I don’t assume that just switching around the buttons would eliminate the problem of people putting themselves and their jobs at risk by writing stupid things on their blogs.  User education is still important.  The tools themselves can help promote awareness and understanding of the medium: for example, the “Publish” button might be given a slightly more explicit label such as “Post for Public Viewing”.  Collecting and providing readership statistics would help dispel a false sense of privacy—an estimate of the number of unique visitors could be shown right near that “Publish” button.  On posts, an indication of which countries have visited might remind the author of the broad scope of the Internet.  There are lots of possibilities; the important point is that these kinds of information can be provided without interrupting the user with a big warning prompt.  By encouraging awareness without hampering workflow and setting up a safe path of least resistance, we improve the chances that things will turn out the way the user wanted.

The Path of Least Resistance

The new Usable Security weblog, pointed out to me by Matt, has an interesting piece on the path of least resistance in popular logwares, specifically relating to releasing posts into the wild. It’s a worthwhile read, even if the author never really c…


You talk as if publishing something on a blog should be the wrong, or at least the uncommon thing to do. But the reason most people have a blog, rather than a private journal on their computer, is so that it *can* be read by lots of people. This is the reason that, for example, TypePad spends so much time explaining how to get your blog to be seen by more readers. I agree that perhaps more education is necessary that “lots of people” will include your mom, boss, CEO, girlfriend, etc. But putting more resistance on the path that lets me do what I want with blogging tools — that is, make a blog post — will in the end be as annoying as those USENET warnings.

(As far as Livejournal goes, I wouldn’t be surprised if they made a conscious decision to encourage public posts. Making public posts really helps grow the communities that emerge on LJ, which is perhaps its ultimate goal.)


Note that Movable Type, which TypePad is based on, has the default for post saving status set to “Draft” in a default install (this can be modified in the control panel).

One wonders why this inconsistency exists. You would think that two tools coming from the same company (Six Apart) would have a similar post saving procedure.


The images in this post are hard to read because of the max-width in Kubrick. To make the problem worse, Firefox uses nearest-neighbor when it resizes images, so text in resized images becomes unreadable. I plan to change my blog to use a fluid layout with the sidebar on the left to avoid this kind of problem.

There is a problem with the “Preview” button in Movable Type: the preview page uses the MT admin layout and styles, not your blog’s layout and styles. I recently switched to WordPress, which doesn’t seem to have a Preview button at all.


For what it’s worth, I think LiveJournal does allow you to set the default security option to Private–I know for certain you can set it to Friends-Only. But it’s true that this isn’t immediately obvious.

Here is how to set the default privacy level in LiveJournal

Took me a while to find.


Hi! Nice to see you all here. Thanks for dropping by.

Nikita: I think you’re right that encouraging public posts was likely an intentional design decision. I didn’t mean to say that the tools should prevent people from posting, though — I like how WordPress does things because it makes saving a draft at least as easy as posting in public, not because it makes posting in public harder. The issue with LiveJournal and TypePad is that they add more resistance to the safer path.

Jesse: Yeah, it’s a problem. I’ve removed the max-width property, but either way it’s ugly — either the scaling is bad, or the images run into the right margin.


I guess the method in WordPress is the only real compromise. For security, it should be at least as easy to make a private post as it is to make a public one. But, since most people will use WordPress to make public posts, it should be at least as easy to do that as to do anything else.

I like your ideas about labeling “Publish” (or “Update Journal”) more descriptively and providing readership statistics to increase background awareness.

Anonymous wrote:

I came accross this website today searching for any informations. I did not find them, but your site was very interesting.

Anonymous wrote:

Hey friends, Thank you !

Anonymous wrote:

Great stuff here guys, check this site out!

Anonymous wrote:

YOU HAVE GOT SOME KIND OF CLASS IN THIS SITE. Good to see you up and around!

Anonymous wrote:

Hi from New York And thanks for the web site. It was just the thing I had been looking for. It has helped me no end. Thanks again

Anonymous wrote:

Hi from New York And thanks for the web site. It was just the thing I had been looking for. It has helped me no end. Thanks again

Anonymous wrote:

So very glad I found this truly great site :-)


I have admire your unselfishness in taking the time to make this web site.


I have admire your unselfishness in taking the time to make this web site.

Anonymous wrote:

Great Design and useful information. I will be back soon!

Anonymous wrote:

Great Design and useful information. I will be back soon!