Principle of Least Astonishment

The Principle of Least Astonishment is well put by Wikipedia: “People are part of the system … the principle aims to exploit users’ pre-existing knowledge as a way to minimize the learning curve.” This principle is often demonstrated with UI design, but equally applies to API’s and programming models.

Let’s look at this principle in action for programming models.

Let’s get some Context

In Android, there’s a way to bind a click listener in the UI xml to a method in the code. This is the same functionality provided by HTML elements and Javascript, by the way, so this is a pretty normal paradigm that pre-dates Android. You can see from the Android documentation:

“you can assign a method to your button in the XML layout, using the android:onClick attribute. For example:”

 <Button
     android:layout_height="wrap_content"
     android:layout_width="wrap_content"
     android:text="@string/self_destruct"
     android:onClick="selfDestruct" />

“Now, when a user clicks the button, the Android system calls the activity’s selfDestruct(View) method. In order for this to work, the method must be public and accept a View as its only parameter. For example:”

 public void selfDestruct(View view) {
     // Kabloey
 }

So far, so good, right?

Android Fragmentation (No, Not That Fragmentation)

Recently I was converting some of my Android Activity code to use Fragments. I had a number of elements in the UI bound to methods in my Activity via “onClick”, so needed to copy those over into my new Fragment classes.

Let’s play fill in the blank:
The onClick in the layout bound to an Activity calls a method in that Activity.
The onClick in the layout bound to a Fragment calls a method in that ________.

What should we put in the blank here? If you are a new Android developer (like me), you might say “Fragment”. That’s what I thought, and I was wrong. If you are an experienced Android developer, you might say “… Fragment’s containing Activity” which would in fact be the correct answer.

Surprise, Surprise

I’m not the only person who got that fill-in-the-blank wrong. This scenario comes up from time to time.

Now, the solutions are easy to understand and implement. And I’m sure the Android development team had good reasons for this particular programming model. But I would argue that whatever those reasons were, the tradeoff was a violation of the Principle of Least Astonishment.

We were surprised that the first approach we thought of didn’t work and instead blew up with an Exception.

We were surprised to discover that the structures that apply to programming Activities did not apply to programming Fragments (which share many similarities with Activities).

We were surprised that the correct approach was a different programming model: programmatically assigning click listeners instead of using the onclick attribute.

Conclusion

Keep the Principle of Least Astonishment in mind as you design user interfaces, API’s, or programming models. An unsurprising piece of software saves your users time and frustration, which in turn saves the software company time and frustration (and money). This makes everybody happy!

Advertisements

Leave a comment

Filed under Android, Software Engineering

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s