Mea Vita: Carpe Diem

That arrow is the mouse pointer making the entire area clickable.

Background

Paul Fitts was an Air Force officer who, during the 1950s, developed models of human movements that are now primarily used in human-computer interactions and aviation.

This is CNN

This morning, I was on CNN.com looking at a photo gallery when I noticed that my mouse pointer had changed from its typical pointer to a thin arrow. Depending on which half of the screen I moused over, the arrow either pointed to the right (indicating that I could click to go to the next photo) or left (previous). 

I haven't seen a lot of good use cases for changing the mouse pointer icon via CSS (HTML). Up until now, the best one I've seen is of a hand "grabbing" to indicate that a UI element is draggable.

The beauty of CNN changing the mouse pointer is it makes the entire image, and the area around it, a target without adding a new UI element. A large target, nearby, is one key to good UX. It's what makes the corner pixels on macOS such a great target since the corner pixels effectively have dimensions that are infinite in length. This is why the screen corners are commonly used as a quick way to invoke the screen saver and lock your computer.

The MacBook Pro's new Touch Bar is intriguing. It's a contextual software menu integrated into the keyboard's hardware. The best of smartphone UI elements brought to a laptop. That's the key to a good UX: UI elements that move out of the way when they're not needed.

Less is more at Apple. When I worked there, we joked that Microsoft believed perfection was achieved when there's nothing more to add. At Apple, we believed that perfection was achieved when there's nothing more to take away.

Elegantly simple Bumpies

When I bought the first iPhone, in 2007, I also purchased a third party acrylic case and soon after that I bought a screen protector. I quickly learned I didn't care for either one. In addition to adding weight, the phone case allowed debris from my pocket to get between the case and back of my iPhone, resulting in scratches on the phone. The screen protector didn't offer too much protection that wasn't already there since the iPhone screen is glass, which does not scratch, easily.

I went caseless until the iPhone 4 and Antennagate, when holding the phone the wrong way would drop calls. To solve this issue, Apple gave away beautifully minimalistic bumpers which I happily used.

I tried to go caseless with my iPhone 6, but that only lasted two days. This work of art was simply too slippery to pickup and hold. Also, the camera on the back of the iPhone 6 sticks out such that it supports the phone when laid down making the lens prone to scratching. So, off to the Apple Store I went to buy Apple's leather iPhone 6 case. The case I bought definitely makes the phone easy to grip, plus it doesn't block any of the ports, speakers, or mic. However, it does add a bit of bulk and it makes it difficult to press the volume buttons.

Bumpies, For the Win

Fast forward to last night's Kickstarter meetup when an entrepreneur gave me the fruits of his Kickstarter campaign to try out: Bumpies. This minimalistic iPhone "case" is less intrusive than Apple's bumpers from the iPhone 4 days gone by. These Bumpies are small plastic nobs that attach to the corners of the iPhone using a non-damaging adhesive. The slick packaging includes an alcohol wipe to clean the corner before attaching the Bumpies. What's more is that the packaging is also functional. To install the Bumpies, I slid my iPhone into the packaging, which fit inside it like a Hershey's chocolate bar fits into its wrapper. The corners of the cardboard packaging exposes the corners of the iPhone to make it easy to properly align the Bumpies. The process couldn't be simpler. Another benefit of the Bumpies, besides a lighter phone, is that they slightly raise the phone, when it's laid down, making it easier to pick up and they also keep the phone from resting on its camera lens. Simplicity is the ultimate sophistication.

Everything is broken. I said that in September and Dave Winer said it yesterday.

Ok, it's not quite everything, but it sure feels like it when your simple workflow comes screeching to a halt.

Software engineering is about managing complexity. It seems the level of personal technology has exceeded our ability to reliably manage it.
I'm typing this on my two-year-old iPad with Apple's Bluetooth keyboard. Normally, I use my MacBook Air, but today I wanted to focus on writing. It's too easy to go down a rabbit hole on my laptop. With just my iPad and keyboard, it's as close as I can be to being offline while being online. It minimizes my distractions.

Unfortunately, my afternoon is failing miserably. I can't get my iPad to keep its Bluethooth connection with my keyboard. On top of that, I can't respond to an incoming text message even when the keyboard is connected. One could make the case that it's a dying battery in the keyboard. (How would I know if the battery is dying? There's no way to check on the iPad.) But that doesn't explain why, when the keyboard is connected, it doesn't allow me to respond to pop-up text messages.

That frustration, added to the fact that Apple's Continuity fails me 50% of the time, is too aggravating. I hear my iPhone ringing, just a few feet away, but I can't answer it on my Mac half of the time. Oh, have I mentioned that the "Check Spelling While Typing" sometimes flags misspelled words now, and sometimes, at an arbitrary point in the future, it will suddenly flag a word that's been misspelled for hours? And don't get me started on the OS X dictation feature which is sometimes unavailable for no discernible reason.

So, I gave up trying to write in Pages on my iPad, this afternoon, and decided to blog here for a few minutes. Prose will have to wait.

And this isn't a case that all new technology has bugs. It's that the level of complexity is getting more than can be managed. My keyboard used to connect to my iPad, and stay connected; and my mouse used to do the same with my Mac. Now, both are hit-or-miss. Trust me, I clearly remember how elegant and bug-free the first iPhone was, yet how bad OS X 1.0 was.

Could it be turnover at Apple? I wonder if the lessons learned, from 15 years ago, are being repeated by the new software engineers at Apple?

Technology is suppose to move out of the way to enable productivity, not hinder it. But, I guess that's my problem to deal with. Perhaps I should focus on the positive, like the fact that I can count on one hand the number of times I've had a kernel panic over the last few years.

Happy Thanksgiving.

There are two types of lazy programming, good and bad.

Good Lazy

Lazily instantiating and populating data structures is a perfect example of a good design pattern. This technique is also how CDNs populate their edge servers. Don't create or store anything until the last possible moment.

When implementing this technique, I use accessors that have the same name as my instance variables (ivars). Below, my _employees ivar is set to null when a class is instantiated and it's not populated until the first time it's touched (accessed). This is the beauty of key-value coding accessor methods.

private NSMutableArray _employees = null;

public NSMutableArray employees()
{
    if (_employees == null)
    {
        this.setEmployees(new NSMutableArray());
    }
    return _employees;
}

public void setEmployees(NSMutableArray newEmployees)
{
    _employees = newEmployees;
}

Depending on my performance requirements, this design pattern would work if I needed to save memory. However, if memory isn't an issue, but, rather speed, this might not be an ideal solution since each time the employees() method is called there's a an O(1) test performed to see if the private ivar is null. In cases where speed needs to be optimized then it's best to pre-populate the data structures (caches) before the web app begins accepting requests. At the Apple Online Store, we pre-populated only when necessary. In every case, though, the key is to avoid premature optimization.

Bad Lazy

The goal of a software engineer is to provide the best possible user experience (BPUX).

As a programmer, I'm not shooting for perfection but I know when something can be done better. (If I went to sleep last night then I had time.)

If I have to code something that's singular or plural I'll go out of my way so it doesn't read:
You have 1 item(s) in your cart.

It's not very hard to code:
You have 0 items in your cart.
There is no shortage of websites where I've entered my phone number (760.444.4721) or credit card number (4111-1111-1111-1111) only to hit enter and been told I made a mistake and my digits need to be reentered with only numeric characters.

Some programmer had to go out of their way to search the string I entered, confirm there was a non-numeric character, and then return an error message to me. This is my big pet peeve – it's too in-your-face. I entered all the information the programmer needed and they could have parsed out the digits. When I'm coding, I simply write a cover method to return only the numeric digits.

Software engineers aren't sales people, so they don't live the ABCs.

In the past, I've written about creating the best possible user experience (BPUX) and it's worth revisiting. Simply put, the basic metric for BPUX is how many clicks and how long it takes to accomplish a task. While you may be able to accomplish a task faster in ten clicks that takes me longer in three clicks, that's still not the BPUX. The reason you're so much faster is probably due to the fact you've memorized the click path and it's become second nature to you.

As Steve says below (52:14)...

You've got to start with the customer [user] experience and work backwards to the technology. You can't start with the technology and try to figure out where you're going to try to sell it. And I've made this mistake probably more than anyone else in this room and I've got the scar tissue to prove it.

I recently befriended a guy who used to work in the mayor's office. During his tenure he oversaw several key transportation initiatives related to making the city more green and efficient. After speaking with him an idea came to mind regarding the importance of opening up government data to third parties via APIs. This is, by no means, a new idea, but it became obvious to me what can be gained once that happens.

Currently, if I want to access my DMV information, I have to visit a website developed by the government. Government websites are notorious for their poor design. Yesterday, I visited an FAA website to make an affirmation and this is what I saw...

Click to enlarge

I spent a couple minutes looking up and down the webpage wondering where to click to register my affirmation. I finally discovered that the entire green shaded area was a "button" to click on for affirmation. Although spelling out "click here" is usually a poor design choice, this is clearly a case where that would have been helpful. Even better would have been a simple button reading "I Affirm." If you look closer at the screen shot, you'll see there's actually a second button (the mauve shaded area) below the green one.

Data Wants to be Free

The reason I harp on poorly designed government websites is it would be simpler for governments to mind the data and let third parties design the websites and apps to disseminate it. Much of this data should be in the public domain, such as where a bus, train, or letter carrier is at any given time. Private government data, like my DMV information, can just as easily be accessed without compromise in much the same way that third parties access your Facebook or Twitter account.

The private company, Car2Go, does a great job at sharing data. Car2Go has their own free app and they publish their car data APIs for third parties to access and develop against. Car2Go doesn't make any more or less money if a customer uses their app or a third party app. Third parties are incentivized since they can sell their apps. Car2Go makes their money on the car rentals while third parties make their money selling their own apps.

The next time you find yourself on a marginal government website think about how great it would be if a professional web design firm got a hold of it.

I love iBooks but nothing beats the durability of a real book. As great as it is to carry around my e-book library on my iPad, it can never compare to the feel of picking up a real book and flipping through it. That's a physical experience sorely lacking on all e-book readers.

So, can the real world feel of a book be duplicated electronically?

Perhaps.. one day... probably. The key is that a digital book would have to feel like a real book. One way to do this is with a digital book made of pages where each is a thin, flexible film, like e-paper, that feel like real pages.

Imagine an e-book full of a couple hundred blank pages made of thin, bendable computer displays. You'd select which book to load and each e-page would display a page of your book. You'd be reading e-ink text on real pages that you could flip through, highlight, take notes, etc.; much like iBooks or Kindle. Just don't dog-ear a page. For books longer than 200 pages, you could just cycle back – page 201 would appear on page one and so on. Now that would be best of both worlds.

At Microsoft, perfection is achieved when there's nothing more to add; while Apple believes that perfection is achieved when there's nothing more to take away.

Two completely different philosophies held by two highly respected and industry dominating competitors. Microsoft is a marketing company (you don't get 90+% of the desktop market without marketing your way there) while Apple is a product company (build great products and profit will ensue).

It's not having a great idea that will make a great company; rather it's having great execution.

At Apple, the engineers are the talent and "This doesn't suck too bad," was high praise when I worked there.

Update, May 22, 2012: CNN published an article about this blog post. 

Sometimes, even the science and studies can be wrong. Not because of an error, but because you didn't dig deep enough.

About a dozen years ago we had some discussions at Apple about the placement of the logo on the back of Apple's laptops. As you can see in this Sex and the City scene, the Apple logo is upside down when the lid is opened.

Apple has an internal system called Can We Talk? where any employee can raise questions on most any subject. So we asked, "Why is the Apple logo upside down on laptops when the lid is open?"

We were told by the Apple design group, which takes human interface issues very seriously, that they had studied the placement of the logo and discovered a problem. If the Apple logo was placed such that it was right side up when the lid was opened then it ended up being upside down when the lid was closed, from the point of view of the user. (If you're currently using an Apple laptop made in the past eight years then close the lid and you'll see that the Apple logo will be upside down from your point of view, but right side up when opened)

Why was upside down from the user's perspective an issue? Because the design group noticed that users constantly tried to open the laptop from the wrong end. Steve Jobs always focused on providing the best possible user experience and believed that it was more important to satisfy the user than the onlooker.

Obviously, after a few years, Steve reversed his decision.

Opening a laptop from the wrong end is a self-correcting problem that only lasts a few seconds. However, viewing the upside logo is a problem that lasts indefinitely.

Q: What does computer user-interface (UI) design have in common with aviation safety?
A: Paul Fitts.

I was at Apple's World Wide Developer's Conference (WWDC), in 2004, when Apple announced a subtle change to their UIs. Specifically, Apple announced that they were going to begin branding search fields with rounded corners, instead of square corners found on regular text fields.


This change is not a big deal and it works well since people are already familiar with text fields. Also, most people won't even notice the difference between square and rounded corners. More importantly is the fact that Apple announces and documents their UI design changes.

Human Interface Guidelines
It's been ten years since Apple launched Mac OS X. A key philosophy that's kept the Macintosh user experience consistent, regardless if was developed by Apple or a third party, is their Human Interface Guidelines (HIG).

A quick glance of the HIG shows how Apple explains each detail of UI design. Of course, developers are free to deviate from the HIG. But, since most developers tend to create things that are "engineer ugly", they're usually more than happy to follow these guidelines.