Saddest Map In America – “Missed Connections” data mining from Craigslist

Entertaining infographic and commentary by Andrew Sullivan on where missed connections occurred most frequently on a per state basis. Highlights: California = 24 Hour Fitness, the south = Walmart, Nevada = Casino

Slips vs mistakes – what WordPress gets wrong that Blogger and Tumblr get right

You’ve just finished a blog post and are in the process of scheduling it to go out at a certain time to maximize exposure. You click the confirmation button, only to see your post go live immediately rather than the time you scheduled.

Oops. What went wrong? This happened to me once (and nearly multiple times) due to poor UI design on WordPress.com. Fortunately I only lost a few potential page views; in other cases early releases of information have cost businesses dearly.

Scheduling a post

Here is the dialog for publishing on WordPress.

If we click Edit, UI elements reveal themselves for choosing a date and time at which to publish the post.

It was at this point where I pressed the Publish button and my post went live immediately. Do you see what I did wrong?

Slips vs mistakes

From my time in Scott Klemmer’s Human-Computer Interaction (HCI) course, I learned that errors can divided into two classes – slips and mistakes.

A slip is when the user has the correct mental model of the interaction yet makes an error on accident. For instance, if two buttons are close together and you click one rather than the other on accident, that would be a slip. These can often be addressed through things such as making touch targets bigger and adding separation between buttons. From the screenshot, you can see that the Publish button is very large and there’s nothing next to it to accidentally press. (The decision to have the Move to trash button on the same row is rather strange, but it is sufficiently far away that I did not accidentally click on it). This is not the type of error I made.

A mistake stems from the user having the incorrect mental model. That is precisely what happened to me. I did not accidentally press the Publish button; I intentionally pressed it but I had the wrong idea to what would happen. Let’s investigate why.

Convention

What makes interfaces intuitive? Part of it comes from adhering to convention and following the Principle of Least Astonishment. The Wikipedia article sums it up nicely:

In more practical terms, the principle aims to exploit users’ pre-existing knowledge as a way to minimize the learning curve for instance by designing interfaces borrowing heavily from “functionally similar or analogous programs with which your users are likely to be familiar.”

This publishing widget violates conventions in a few ways.

Discarding unsaved user input without warning.

Many programs will warn if you’re about to do something destructive to unsaved input. For instance, if you are half way through a message in Gmail and attempt to close the tab or browser, you will see the popup warning:

Similarly, all Cocoa applications on Macs will clearly show unsaved state and warn if you try to close a program without saving:

If there are form elements whose state is about to be destroyed by an action, it would make sense to issue a warning about that. This WordPress form does not do the user that courtesy.

Too much state

Most programmers understand that there is state saved on both the server and client. The client will fetch the data from the server and adjust its UI controls to match. Changes to the UI controls don’t automatically get sent to the server; generally there’s some final OK/Cancel action to either accept or discard the changes. Normal users should not need to know this – it should just work. This control exposes too much information unnecessarily. Why would one care what the current server side state is vs what’s in the UI control for each individual section? Why wouldn’t she just set the options the way she likes and hit one button to apply all of the changes?

Even if she understands the distinction between client side and server side state (like I do), it is an extremely unfamiliar interface to have to hit OK on a subsection of a form before finally submitting it. I cannot think of one other example that does this. It is convention that hitting the big Confirm button at the end of a form will use whatever information is currently in the form.

In addition to not expecting to have to hit another OK button in order to have my changes applied, this form suffers an additional problem – there is too little contrast between the OK button and the form. Note how the OK button all but disappears with the least amount of blur:

The eye is naturally drawn towards the big blue button in the lower right, which is exactly what I clicked on.

If I had pressed OK, then the Publish button would have changed its text to “Schedule.” Without knowing that that change would occur, I assumed that this control behaved like all others I had used before and so made the mistake.

Alternatives

Let’s look at alternative blogging sites and see how they do things better.

Blogger

Blogger separates the configuration of the publishing options from the publish button itself.

Once you click on the Schedule button, the Schedule section expands. Note that only one section can be expanded at once, unlike the WordPress widget.

The “Automatic” option really means Now, which should be phrased more clearly. Clicking on the “Set date and time” option brings up a date picker:

The setting is immediately applied if you click Publish, regardless of whether you have hit Done or not. If you do hit Done, the state is saved and the Scheduling section is collapsed.

There is no Cancel option – if you don’t want to change the date, just put it back to what it was before.

This approach works well. My one complaint is that the Publish text does not change to something akin to Schedule when a date is selected. I had to use trial and error to see what would happen on clicking Publish when a date had been chosen but before the Done button had been pressed – would it publish immediately like WordPress or would it respect the date options? Fortunately it does the most sensible thing and treats the state of the UI controls as the source of truth.

Tumblr

Tumblr takes an approach similar to WordPress but executes it much better. They optimize for the case of immediate publishing, hiding most of the options behind a disclosure button:

When you click the “Publish on…” menu item, a few things happen. First, there’s a check box next to the item, indicating unequivocally that this is the current selected option. Contrast this with WordPress, which has the confusing case of showing two states in the same area:

Next, notice that the text of the action button immediately changes from “Create post” to “Schedule post”, further cementing the fact that the post will not be immediately created. Finally, note that the button is grayed out and disabled – it cannot be clicked until the menu is dismissed and the changes are implicitly accepted. Once the menu is dismissed, the button is enabled.

This does everything correctly. It optimizes for the most common use case while hiding complexity. It uses bold visual cues to explain the state of the system. It follows conventions and makes it much less likely that the user will make a Mistake – the mental model of the user is much less likely to be at odds with that of the designer.

Conclusion

Understanding the mental model of the user is crucial for user interface designers. The WordPress designers have chosen to expose strange implementation details which make the act of scheduling a future post extremely confusing and error prone. For each option that can be modified, there is a saved state and the current UI state. Each section must be explicitly saved with ‘OK’ in order for changes to take effect. This leads to confusion in the UI because there is contradictory information being shown – on the one hand dates have been chosen but on the other text says ‘Publish Immediately’. If that isn’t confusing enough, the use of OK/Cancel within subsections of a form is not a standard design pattern. Finally, the OK/Cancel options are small and low contrast and thus are less likely to be seen.

I have shown how Blogger and Tumblr address the task of scheduling posts in two different but superior ways to WordPress. Blogger separates the Publish action from the configuration of scheduling, while at the same time making the current state of those settings take place immediately without explicitly confirming the selection. Because of this simplicity, there is no need for cancel or undo button. Tumblr hides the scheduling details behind a button but makes it absolutely clear through both a large checkbox and an immediate change in button text what will happen when you click it.

The general principles to take away from this case study are:

1. Keep things simple
2. Follow convention
3. Update button text immediately when UI changes are made

In my mistake, there was no real harm done. Since this same confusing interface is present for setting privacy options, I can only hope people trying to post privately do not make the mistake I did.

Python – “dict comprehension”

I learned a new way to initialize dictionaries that I had never seen before, and I thought I’d share it with you. I previously blogged about three ways of creating dictionaries in Python. I showed that you can use an iterable of (key, value) tuples to initialize a dict:

professions_dict = dict(zip(names, professions))

Another way along these same lines is to perform the iteration within a list comprehension. Say that we have an iterable of Person objects, each of which has a name and profession. The professions_dict could be created as follows:

professions_dict = dict([(x.name, x.profession) for x in people])

What I didn’t realize is you can skip the tuples and call to dict, and use the comprehension within the dictionary literal itself:

professions_dict = {x.name: x.profession for x in people}

In my opinion this is much cleaner. The syntax and official documentation can be found in 5.2.5. Displays for sets and dictionaries.

Book Review: Unofficial LEGO Technic Builder’s Guide by Pawel “Sariel” Kmiec

Unofficial LEGO Technic Builder’s Guide by Pawel “Sariel” Kmiec, published by No Starch Press.

Disclaimer: I received a free copy of this book to review from O’Reilly.

I have a deep and abiding love for all things LEGO. Growing up, I assembled a few Technic sets but never really tried to make any creations on my own with that system. I received a great set last Christmas, the well-loved 8421 crane model.

I enjoyed the process of assembling it tremendously, as it had great small details like working doors on the cab and a brilliant modular design. I was eager to review this book because Technic interests me but I know so little about it.

Bottom line up front – this is one of the best, most informative books I have read. It exceeded my expectations in its breadth and depth of topics covered and its effective use of illustrations. It is divided into five sections – basics, mechanics, motors, advanced mechanics, and modeling.

I did not expect such a thorough explanation of all the physic and mechanical engineering principles that are necessary to make working models. The first Basics section covers such concepts as speed, torque, power, friction, traction, and backlash. The author proceeds to cover more specific concepts related to vehicles, such as drive trains, front wheel versus rear wheel drive, turning radius, and center of gravity. I was familiar with some of these terms but not others (for instance, “Backlash describes the gaps between mating components, such as two gears”).

Only after exhaustively covering these basic mechanical principles does the author tackle Technic specific elements, such as pins, axle holes, units of measure in the LEGO system, important ratios (for instance, 3 plates = 1 brick in height), and the difference between beams and bricks (studless vs studfull). This section was very interesting to me as it gives precise names to pieces that are hard to describe otherwise.

The second section of the book covers mechanics, with an in depth looks at gears, chains and pulleys, levers and linkages, pneumatics, and reinforcing models to avoid being pulled apart by the stresses of the system. Almost all of these concepts were new to me, with the exception of gear ratios. The author introduces real world mechanical devices/techniques (such as the Chebyshev linkage), describes what they are used for (converting rotational motion into a straight line), and includes a fully realized Technic version of each system. Some of the systems are laid out in multiple steps, while others have just a single image of the completed structure. Still images allow you to get a sense of how the systems work, but the author also includes links to videos of some of the systems, which are much easier for me to understand.

Chebyshev linkage figure

The third section of the book is an exhaustive look at all of the LEGO motors and their stats (torque + speed), as well as examples of what each is particularly well suited for (or not, as he has clear disdain for some of the models).

Advanced mechanics covers steering, suspensions, tracked vehicles, transmissions, and the use of adders and subtractors. I found this section particularly interesting because I’ve never bothered to take the time to understand how a real world car works. After reading through the explanations and mentally visualizing how the gears would turn in each example, I have a much better understanding of what happens when gears shift in a car, or how suspensions help to keep vehicles in contact with the ground (not just to provide a smoother ride and act as shock absorbers, which I erroneously thought).

The book concludes with a section on creating models, and the tradeoffs involved with using Technic to mimic real life objects. There is a natural trade off between form vs function, and the author encourages prospective builders to decide which one they’re willing to sacrifice before beginning to build. He discusses how to use blueprints to determine at which scale the model should be built, based on the fact that certain Technic elements are only available in a small range of sizes. For instance, if you’re modeling a car, you are limited by the size of the wheels – you could not build a 1/4 scale model, for instance, with off the shelf Technic components.

Conclusion

As I said up front, this book blew me away with the amount of technical details it presented in a clear, easy to comprehend format. I found the figures in the book absolutely crucial to my understanding; I estimate that there are at least 200 such figures. Some are photographs (usually of his finished creations), but most are high quality 3D renders. The author makes consistent use of color throughout a section, and details what the color scheme means (for instance, a red axle might always be the one that is connected to the motor, while a green one is on the output side of the equation). My one nitpick is that it’s very hard to make out some of the figures on a monochrome display (i.e. the Kindle), but I was able to consult the beautiful PDF version if I needed clarification.

This could have been a dry textbook, but instead it’s fun and eminently readable. The author’s quirky sense of humor manifests itself in some of the photographs, in which a hamster appears, ostensibly for scale. I’m inspired to try my hand at building my own Technic creations, and that’s about the highest compliment I can pay this book.

Kindle Paperwhite – Touching is good

When I was in college, one of the students had the original version of the Kindle. It was big, clunky, and slow, but I instantly saw its potential. I’ve since owned three copies of the gray Kindle with keyboard (don’t ask), and that was a huge advance in terms of form factor, speed, and resolution.

I recently bought a Paperwhite to replace my most recently broken Kindle. Here are my initial thoughts after having used it for about 2 weeks.

Video clip of pressing to define

Video clip of dragging to select text

 

Good

• Refresh rate is noticeably faster
• Resolution is better – text is very crisp
• Getting definitions of a word is much easier – takes one long press on the word rather than navigating through the whole page with the directional pad
• Extremely small; fits easily into a jacket pocket
• Light works very well and does not strain my eyes
• UI has improved – navigating through books stored on the cloud vs on the device is very straightforward
• Highlighting is very intuitive and easy to do
• High quality virtual keyboard – very responsive
• All the games I tried have been updated to support virtual keyboard – including the New York Times crossword puzzles
• Much easier to find the books to borrow in this version – use the same unified Kindle store to search, then if it’s available, will show up as a download/borrow option
• Nice option to see how much time is left in the chapter vs book – tap in lower left corner or access from the menu
• Really great walkthrough of the different tap zones and what they do when you first turn on the device

Bad

• For both the highlight and define gesture, you need to hold your finger on the start word for a fraction of a second longer than I’d like. If you move your finger or remove it before that time, you’ll turn the page. I’ve accidentally turned the page a few times.
• Since the only way to turn the page is by tapping the screen, it’s easy to accidentally click on a link. When the link is external, it’s easy to undo – hit back on the browser. If it’s internal, to a later chapter, you get dumped later in the book with no way to get back. This is extremely confusing and disorienting. If you only read novels, this is a non-issue, but for tech books it can be a problem.

Ugly

• Light is uneven at the bottom; more evident in a dark room

Conclusion

This device is amazing, and any negatives I’ve highlighted are far outweighed by the positives. Everyone I’ve shown it to has loved it, and even those who were concerned about a touch screen on an e-reader have appreciated its responsiveness and UI.

This is by far the best e-reader I’ve ever used. Here’s hoping I have better luck with this version than the last three.

Don’t you love being beaten to the punch?

I just found an old document titled ‘email instapaper idea’, from 12/13/10 whose body was:

“You get an e-mail address, when you send e-mails to it it parses the body looking for links. That link is then fed into Instapaper and later synced to your mobile device”

Fortunately Instapaper had the same idea I did and implemented it beautifully; I use this feature daily to send myself interesting articles via Twitter. If you haven’t discovered it yourself, go to http://www.instapaper.com/extras after registering.

Example #135235 that ideas are cheap. Implementation is what matters.

Upgrading a Leopard machine to Snow Leopard

I’ve been bad about upgrading the OS of my MacBook, and now it’s hopelessly out of date. A lot of software no longer runs on Leopard, including Chrome autoupdate, TextMate, and GIMP. Lack of Chrome autoupdate means no updated Flash, which means no YouTube. Time for an upgrade.

Unfortunately, you cannot upgrade to Mountain Lion without going through Snow Leopard first, and Snow Leopard is no longer sold in stores or on the apple.com site. After calling a local Apple store, I found out that the only way to get the upgrade is to call 1-800-MY-APPLE and ask for an upgrade. They’ll ask you for the serial number of your Mac in order to ensure compatibility, your email address, and standard billing information. The cost of the upgrade disk, without expedited shipping, came out to about $26 in my case.

Hope this helps those of you who procrastinated like me and are searching for information about where to get the Snow Leopard upgrade.

Link of the day: How Google Builds Its Maps

I’m a little late to the party, but the Atlantic has a great article on Google Maps. In the light of the recent bad press about the maps in iOS 6 (see e.g. David Pogue’s article  and http://theamazingios6maps.tumblr.com/), it’s important to realize how much hard work, both in terms of engineers and highly skilled data ‘massagers’, goes into making a great maps product.

Interesting side note: I was going to bring back up the great article on 41latitude.com which illustrated Google maps’ superior legibility (which I blogged about in May of 2011) but the post has been removed and according to Quora the author is now working at Apple.

Book Review: Team Geek by Ben Collins-Sussman and Brian W. Fitzpatrick

Team Geek: A Software Developer’s Guide to Working Well with Others, by Ben Collins-Sussman, Brian W. Fitzpatrick

Disclaimers: I received a free copy of this book to review from O’Reilly. I work at Google, as do the authors, but this review reflects my views only and not necessarily those of Google.

One thing I have learned over my three years of professional software development is that you really are writing code for other people to read, not for the compiler. This dual nature of programming, the precise, exacting specifications that run on the computer, and the imprecise, ambiguous human factor, is fascinating to me. Ben Collins-Sussman and Brian W. Fitzpatrick, two of the engineers behind the SVN version control system, currently working at Google, have written Team Geek, a book that aims to impart lessons learned in creating better software through better people skills and teamwork.

Programmers tend to lionize the lone programmer, like Linus Torvalds of Linux fame. In some rare cases, geniuses do manage to accomplish incredible things on their own. But in most cases, great software is a collaborative effort performed by a team of people of varying skills, backgrounds, and communication styles. There are many books which help improve your technical proficiency, but this is one of the few I’ve encountered that addresses the importance of working effectively with teammates.

I won’t reiterate all of the content of the book but there are a few themes that occur throughout that I’d like to touch on.

The first is that it is crucial to spread the knowledge throughout the team rather than keeping it siloed in the heads of a few people. They whimsically refer to this as the “bus factor” – how many people would it take to be hit by a bus (or be otherwise incapacitated) before the project would fall apart?

One way of increasing this shared knowledge is through the use of communication channels that are easily archivable and searchable rather than through point to point communication. For instance, it is better to ask questions of the team via an IRC channel or mailing list than to ask someone directly, because that exchange can be easily found in the future. It also gives other team members visibility and input into the decision making process.

The culture of the team is also frequently discussed. In the previous example, archiving technical discussions would do no good if no one bothers to search and try to find answers by themselves prior to asking someone for the answer. The shared values of the team are crucial to its effectiveness.

Another main theme of the book is focus, or “saying no to all the distractions.” Part of an effective team, the authors say, is a manager who can shield engineers from the chaos inherent in the organization. This is a form of avoiding distractions at a high level – working on things which do not actually matter for your project. One relevant quote I’ve found in this regard is

There is nothing so useless as doing efficiently that which should not be done at all — Peter Drucker

One way the authors suggest to maintain focus is to decide on a mission statement. It might sound cheesy, but they offer a compelling argument as to its efficacy. They relate an example of how they used this technique on one of their projects and it became clear that many of the senior engineers had very different goals and ideas of what the product should do. Had they not forced the team to clearly specify what they were trying to accomplish and what the non-goals of the project were, there would have been significant wasted effort by people working at cross purposes. They use the analogy of a cart being pulled by different team members in different directions – by not working towards one goal, the cart will not move forward as quickly as it would if all were pulling together.

At a lower level, distractions abound as well. While programming, it takes significant concentration and effort to get engrossed in the task at hand and to ‘load’ the program structure into one’s head. Context switching is very bad for productivity because the cost of reloading this state is so high. Sometimes these context-switching distractions come from other team members, such as when someone interrupts to ask a question. The authors suggest that the team come up with a strategy for minimizing these disruptions, both to increase productivity and decrease frustration. For instance, in one team the authors led, any time Alice needs something from Bob, Alice would make her presence known, Bob would verbally acknowledge Bob but not stop what he was doing, finish what he was doing, and only then stop and talk to B.

While much of the book is generalizable to any sort of team environment, the authors do give some coding specific advice. There are discussions on handling code reviews effectively, dealing with people who constantly dig their heels in and criticize others’ technical solutions, and ways to avoid ego while coding.

Conclusion

I thoroughly enjoyed this book, reading it cover to cover over two legs of an international flight. Much of the advice in the book is common sense but there are also many specific, concrete ideas that I had never considered before. I would recommend this book without reservation to anyone working on a team that writes software.

Simplifying Isosurfaces (Part 2)

Reblogged from 0 FPS:

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

To briefly recap, our goal is to render large volumetric environments.  For the sake of both efficiency and image quality, we want to introduce some form of level of detail simplification for distant geometry.  Last time, we discussed two general approaches to level of detail -- surface and volumetric -- focusing primarily on the former.  Though volumetric terrain is not exactly the same as height-map based terrain, we can draw an imperfect analogy between these two problems and the two most popular techniques for 2D terrain rendering: ROAM and geometry clipmaps.

Read more… 3,566 more words

Very interesting article on techniques for simplifying 3d surfaces, including an interactive WebGL demo comparing the various techniques. Simplifying 3d surfaces is important for maintaining frame rate in interactive applications when objects are far away; it is a way of managing level of detail in an automated fashion.