Posted 1 week ago

Automate the automatable for your users

In user experience design, we must automate the automatable for our users. Something may only take seconds for an individual user to do, which may seem like it’s a waste of time to automate. However, when something that can be automated isn’t automated, consider the wasted time as it multiplies across all of your users. 

For example, if I want to pay my water bill with the City of Durham website, I have to put in two different numbers to identify myself—an account number and a customer ID. These numbers, though, are actually just the last 6 digits of my account number on my paper bill and the first 6 digits of my account number on my paper bill, respectively.

As a users, splitting the numbers into two fields isn’t a challenge, but it’s annoying. It only takes seconds for me to split them up mentally, type one set into one field, and then type the other set into the other field. But why do I need to do that at all? Computers can split numbers in microseconds. I could be given a single input field to type the full number into and then the server can do the splitting. This would save me, a single user, seconds each time I want to pay my bill. Aggregated across all users, this would save hours per year, at least. 

So, when your programmer can spend a few extra minutes to save your entire user population hours per year, I think that’s worth the effort. Always automate the automatable for your users.

Posted 3 months ago

Sometimes the English language is inconsistent. 

Posted 3 months ago
Posted 3 months ago

Integer to Float coercion in PHP

I take for granted the coercing from integer to float in PHP when I work in that language. When I finally dived into Ruby to use it on a project recently, I discovered it does not do this coercing for you. Nor does Python.

This can be tricky to grasp at first—we learn for many years in math classes how to divide something like 100/33 into 3 and some remainder after the decimal. In math classrooms, there is no discussion of number “types” when doing this type of arithmetic. So, while Ruby and Python are very internally consistent with regard to their loose type systems (i.e. dividing integers gives an integer result), PHP’s coercing makes a bit more sense based on non-programming mathematics experience. 

Posted 3 months ago

DataMapper fails silently when strings are longer than schema property

When inserting content into your database using DataMapper’s create method, any String longer than the corresponding schema property will cause the create method to fail silently. For example, if your model has a property with a :length of 256 as below:

class Message
  include DataMapper::Resource
  property :id, Serial
  property :message, String, :length => 8

then doing the following will fail silently and not insert a row:

    Message.create(:message => "This message is more than 8 characters long")
Posted 3 months ago

Ignore CSS and JS files in Ruby Rerun

If you’re using the Rerun gem to watch for file changes in your Ruby web application, you may find it annoying that CSS and JS file changes cause the entire application to restart. Use the —ignore flag to ignore certain file types when calling Rerun. For example, below is a shell script I use to start a Sinatra application in my project:

#! /bin/bash
rerun --ignore "**/*.{js,css}" ruby app.rb
Posted 3 months ago

Animate the ZURB Foundation Progress Bar

After doing a search for animating the Foundation progress bar, I came across a ZURB forums post. However, I was trying to avoid using JavaScript to do the animation. So, if anyone out there is interested in a CSS-based method for animating the ZURB Foundation progress bar, just drop this CSS into your stylesheet:

.progress .meter {
    -webkit-transition:width 0.7s ease;
    -moz-transition:width 0.7s ease;
    transition:width 0.7s ease;

Adjust the transition properties as you see fit, but leave “width” in there, since that’s the property that changes on the .meter element.

Posted 5 months ago

Free Service Design Idea for an ISP

Imagine you own an ISP, such as Time Warner Cable, that occasionally has outages. Ideally, you’d never have outages, but since you might be Time Warner Cable, you have outages, like the one I experienced in my second week of living in my new place (where we don’t get AT&T Uverse, unfortunately). 

Now, you realize that if you have an outage that you are going to get bombarded with phone calls, emails (from mobile devices that still have service), and tweets about the problem. This costs money for customer service reps (not to mention stress) and frustrates customers because they will have even longer wait times than the normally frustrating wait times. 

So, what is one way to try to ease the frustration on both ends? Alert your customers that there is an outage—simply a text message to their phone number on file—and let them know there is a problem and that you’re trying to fix it. This differs from the current status quo because right now ISPs (at least TWC) expect the customer to check on the service status via an app or a website where they must be logged into their account.

Flip the communication stream and be proactive by alerting your customers. This will let some of them know not to worry about calling customer service because there is an obvious problem, it will relieve the call center of unnecessary calls, and it will save your site on bandwidth from a bunch of people checking service status. Then let them know the service is back up with another text message once service is restored. 

I’m borrowing the term “Service Design” from Patrick Quattlebaum and possibly abusing it here. Nonetheless, I think this simple idea is a great example of a small feature that can be added to improve a service’s customer experience. If you know anyone important an ISP (especially TWC)—pitch this idea to them!

Posted 7 months ago

Do unto others as they’d have done to them

I heard the Rod Stewart song Forever Young yesterday and the following lyrics reminded me of something I have thought about in the past:

And may you grow to be proud
Dignified and true
And do unto others
As you’d have done to you

I put emphasis on the lines that I am most interested in discussing. The phrase “do unto others as you’d have done to you” is sometimes called the Golden Rule in America. It’s a great rule because it works for a lot of situations where people interact. 

For example, would you prefer to cross the street or get hit by a car that didn’t stop for you? If you’re the driver of the car, treating the pedestrian as you’d like to be treated if you were the pedestrian in that situation is a pretty good idea. You wouldn’t want to get hit the next time you’re a pedestrian. 

However, what if the pedestrian wants to get hit? Perhaps he is mentally ill, depressed, suicidal, or looking to sue the first person he can find that hits him for medical benefits. In that case, he wants to get hit, but you still probably don’t want to get hit. So, the Golden Rule breaks down. 

The above example is somewhat contrived, so I can provide a slightly more innocuous, yet realistic, example. Over at GiantUX, Tom Greever writes about a time when arrogance got in the way of his design process. I think all designers and developers can relate to this experience. We think we know what’s best for our applications’ users. However, we are not our users. So, even with the Golden Rule, we may try to build something that’s wrong for our users because that’s what we would want to use (“done to you”). 

Fortunately, there is another, lesser known rule out there we can use: The Platinum Rule. The idea of the Platinum Rule has been around a while—see the criticisms section of the Wikipedia entry for the Golden Rule for a brief overview. Simply put, the Platinum Rule states “do unto others as they would have done to them.” The wording difference is small, while the implications are huge. 

I think the Platinum Rule is very important for user experience practitioners, especially. You must build applications that users want, not that you want. And it must work in a way they want it to work. If you like modals and carousels, that doesn’t matter. Find out what your customers really want and how they want to interact with your application.

On a more serious note, I think this goes far beyond user experience design. It’s a general principle to guide most of your interactions with others. 

Yesterday, TechCrunch published an article on a female designer leaving GitHub due to a hostile work environment. I think situations that involve sexism stem, partially, from the assumption that one sex (in this case, men) knows how the other sex (in this case, women) want to be treated because they know how they would like themselves to be treated. Again, the Golden rule breaks down. 

So, let’s focus on utilizing the Platinum Rule to build better software and to build better relationships with other people. 

Posted 7 months ago

Notes from Josh Clark’s Designing Touch-Friendly Interfaces

I attended a Triangle UXPA meeting where we were able to watch the virtual seminar Designing Touch-Friendly Interfaces by Josh ClarkI’m sharing my notes here as a service to myself in the future and as a reminder to others out there about how to design touch-friendly interfaces. 

Some interesting statistics on how people hold their phones “on the street”, from a field study by Steven Huber (n=~1300):

  • One handed, using the thumb on that hand: ~49%
  • Cradled in one hand, using pointer finger on the other: ~36%
  • Two handed with both thumbs: ~15%

So, thumb use accounts for about 64% of usage in this sample. This informs the heuristics below.

For apps:

  • Primary controls on the bottom
  • Right vs. left side less important than top or bottom
  • Data changing buttons at the top (“out of harm’s way”)
  • Content at top, controls on the bottom (similar to other devices, like a calculator)
  • Stacking controls is a bad idea (causes mis-taps)

These guidelines reflect an iOS-bias. For Android devices, usually controls go on top because the physical device buttons are at the bottom. 

For websites, browser chrome gets in the way, so having a sticky navigation at top or bottom eats up content area. Therefore, a good way to avoid this is to put a Menu link in the header that links to navigation in the footer, but the navigation is at the bottom of the page, not the screen.

Tablets are almost more desktop-like. Controls at the top are better than the bottom. Bottom nav makes more sense if the whole canvas will change (“coverflow style”). Favor the sides and corners of the screen for controls, since sometimes we hold larger devices in both hands due to their weight. 

Dimensions for controls:

  • ~7mm is the contact point for thumb on a flat screen
  • 44px maps to ~7mm and works well across devices
  • 2.75em on a default font size of 16px is 44px
  • 7mm has a 1 in 100 error rate on taps, 9mm is 1 in 200 (based on Microsoft study)
  • At least one dimension should be 44px; 29px minimum in other dimension
  • At least 2mm between controls; less than that requires increasing size of controls

Clarity trumps density: you may have click or tap more, but the clarity of what’s on the screen pays off. This is in contrast to previous fears on the web that too many clicks would increase bounce rate. 

General recommendations:

  • Get rid of select menus; replace with other controls
  • Get rid of extra fields (generally a good idea)
  • Get rid of confirmation dialogs (use gestures to confirm less than desirable actions)
  • Require less keyboard use
  • Eliminate detail screens (providing more information upfront makes secondary detail screens less necessary…AccuWeather example)
  • Eliminate carousels (seems everyone wants to do this)
  • Eliminate the long scroll (use off-canvas panels)

Great quotes (paraphrased): 
"People come to your site/app for the content, not the navigation."
"Navigation is often a last resort if the (navigation in the) content fails us."