Things the “T” does not stand for, part 1. Made with Inkpad for iOS.
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.
I attended a Triangle UXPA meeting where we were able to watch the virtual seminar Designing Touch-Friendly Interfaces by Josh Clark. I’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):
So, thumb use accounts for about 64% of usage in this sample. This informs the heuristics below.
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:
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.
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."
TL;DR: grab a bookmarklet that adds “download video” links to Sakai videos.
In several of my classes at UNC, we use an education CMS called Sakai. For one of my online courses, lectures are posted as videos in Sakai, which is really convenient. However, the screen size options are “really tiny video” or “full screen”.
I wanted to download the videos to watch them in an external video player so that I could watch the video on half my screen and take notes on the other half. After digging through the page source, I finally found the actual video URLs. I don’t want to have to do that every time, though, so I created a bookmarklet that adds links after each video that link directly to the video for downloading.
I’ve only tested this in Chrome, but it works fairly well so far. The videos before:
The videos after running the bookmarklet:
The bookmarklet is in a gist on GitHub (link at the top of this post).
On my winter break after my first semester of graduate school, I did a little personal research project. The project’s goals were:
And, here are the results: Web Assets & Benford’s Law. It was fun, and I enjoyed it so much more than those assignments that are required in a classroom. :)
As defined in my previous post, Gray Plating is the overuse of gray in a user interface when it is detrimental to the user experience. Today, while reading about an app on the iTunes store, I found a good example of this problem on apple.com.
Reading the body text that describes the app Comic Zeal, I found the text to be a little hard to read in my living room, with natural light in the environment. Here is a screenshot of the body text:
If we plug the foreground text color (#898989) and background color (#ffffff) into Lea Verou’s awesome WCAG 2.0 Color Contrast calculator, then we get a result of 3.5, which partially explains the problem with the contrast. A 3.5, as the tooltip help text states, means this contrast “passes AA for large text (above 18pt or bold above 14pt)”. The website’s body text is 12px, or roughly 9pt, on my 1680x1050 resolution MacBook Pro screen.
At a font-size equivalent to 9pt, the iTunes app store body content fails to meet the WCAG 2.0 guideline 1.4.3 on minimum contrast, unless users resize the text themselves. It’s a good thing I’m nearsighted at this age, but for 80 year old me, and for others that currently don’t have as good of vision, this kind of Gray Plating is a real problem.
Despite the fact that responsive images may one day fix the bandwidth problem for images, I still think it is worthwhile to explore a simple alternative for certain types of sites. On mobile devices with slow network connections, images can take up a huge amount of the page weight for a single web page. I started discussing in my previous post a simple idea: just link to the images by default and let the user click the link to show the image. The user’s click could send a normal HTTP request, or an AJAX request to fetch the image and put it in some sort of modal dialog.
In practice, it might work for something like this ArsTechnica article from last year.
With images, this page is 14 HTTP requests and it has 896KB worth of images in the page.
In a user-activated version, with the images as links, it would look like the following image.
This version contains 11 HTTP requests, with only 8.6KB worth of images for decoration.
The first example is 1.1MB and the second example is 221KB. That is an 80% reduction in total page weight by just making the body images links. I think this kind of page weight reduction would be worthwhile for blogs and news sites where the main draw of the site is the written content, not the images. An option not to show these large images could be saved in a cookie, much like the option to “view mobile” or “view desktop” is saved on these kinds of sites currently. This is a really simple idea, and users may not find it worth the bandwidth savings having to click for their images, but I think it may be worth it in some contexts.
I’m not sure when car manufacturers started making seat belts in the backseats of cars not interchangeable, but it has to stop. If you’re not familiar with this, find a car built in the past few years and see if the passenger side seat belt buckle can fit in the receptacle on the driver’s side. Most likely, it can’t. I assume this is some sort of affordance that car designers have put in place to “help” passengers figure out which seat belt buckle fits with which receptacle. Googling hasn’t returned any decent results as to why this design decision was made.
My gripe is that the safety gains from enforcing one buckle to one receptacle do not outweigh the inconvenience of trial and error when trying to buckle up in the back seat. Beyond just inconvenience, though, bigger individuals can’t use two seats this way, because the middle receptacle won’t accept a side seat belt buckle.
Obviously, this is a minor thing and definitely a first world problem, but being related to design and engineering I felt like it was appropriate material to cover.
Idea: Coffee stirrers made of metal that change color based on drinkability of the coffee.
The new iOS 7 fade-in animation that occurs when turning on the device seemed slow to me, or at least slower than in iOS 6. So, I wanted to run a pseudo-scientific experiment to see if my perception was correct (“pseudo-scientific” due to the small sample size). I compared my iPhone 4S with iOS 7 to my wife’s iPhone 4S with iOS 6 in terms of “time to home screen”, which I defined as the time between pressing the power button, unlocking the screen, and waiting for the icons to come into place on the home screen.
For iOS 6, 5 runs: 2.11, 2.2, 2.07, 2.12, 2.06 (measured in seconds), with an average of 2.11 seconds.
For iOS 7, 5 runs: 2.3, 2.33, 2.51, 2.54, 2.47 (measured in seconds), with an average of 2.43 seconds.
The difference comes out to .32 seconds of extra time waiting on animations before getting to the home screen in iOS 7. Now, that’s not a whole lot of time; it’s not even a full second. However, this is a task that users will do several times a day, perhaps even several times an hour, and that means extra fractions of a second wasted over millions of people. When a user interface has a major update, it should take less of our time to use it, not more.