Don’t Always Be On

Humans operate in continuous time, where time is always passing for us. In the first chapter of Program or Be Programmed, Rushkoff discusses why computer systems are biased away from continuous time and towards asynchronsity. Instead of operating in time, they operate from one human decision to the next. Because computer code is biased away from continuous time, so too are the programs built on it, and the human behaviors those programs encourage.

As digital media becomes increasingly integrated with our lives, we are more likely to adopt an “always on” approach to media. We’re constantly trying to keep up with a never-ending flow of messages, updates and demands—so much so that it’s starting to become an addiction. It changes our ability to engage with the world around us and leaves us frazzled and exhausted on a regular basis. This forms the basis of his first principle: don’t always be on.

Turning Off

Digital media consumption is largely a choice. We can choose to get things done or we can choose to check our email, look at our phone and use Facebook. But as our digital services become more ubiquitous, consumption becomes less about choice and more about avoiding distractions.

As someone who’s easily distracted, I try to avoid distractions wherever possible. I check my email only a few times a day; I turn my phone over on my desk so I’m not distracted by new notifications, and I recently edited a system file that blocks Facebook on my computer. Each of these simple tricks helps me to avoid distraction and focus on getting things done.

The Google+ Juggernaut

Sometimes avoiding distraction is more difficult. For example, when services we regularly use are constantly nagging to show us something. This is the case with Google’s latest project, Google+. I’m specifically referring to the Google+ bar, which not only appears at the top of Google+ but also most other Google products.

The most noticeable feature of the Google+ bar is the well designed notification menu, activated by selecting the notification count—clearly highlighted in red—on the right side of the bar. Similar in concept to Facebook notifications, Google+ notifies you when someone adds you to a circle, comments on one of your posts or comments after you on a post that you’ve previously commented on.

Including the Google+ bar at the top of most Google products is an excellent product strategy as it wraps sharing, notifications and links to other popular Google products in a tidy package; it’s also a constant distraction. Like many others, I use Google services all day long: Search, Maps, Reader, Docs and others. So I was being distracted by notifications all day long.

Avoiding the distraction of Google+ notifications is not a simple choice. There is no way to disable notifications, and I couldn’t avoid the notifications from Google+ unless I didn’t use Google products. I realize there are many alternatives to Google products, but as a Google user for over ten years, it’s difficult for me to imagine life without them. How then was I to use Google products without the constant distraction of these notifications? The answer lies in the thesis of Rushkoff’s book.

Program or Be Programmed

In the final chapter of his book, Rushkoff says that because digital technology is programmed, it’s biased towards those with the ability to program: “in the digital age, we must learn how to make the software, or risk becoming the software.” With this, he describes the final and most important principle: program or be programmed.

He goes on to describe the consequences for those who don’t have a basic understanding of how digital technology works:

The less involved and aware we are of the way our technologies are programmed and program themselves, the more narrow our choices will become; the less we will be able to envision alternatives to the pathways described by our programs; and the more our lives and experiences will be dictated by their biases.

Applying this idea to the internet, those who understand how the web works will be able to envision and create alternatives to the sites and applications that we use everyday. Many of us realize this, but very few of us are empowered by it. We leave the creation of software to people who are smart enough or skilled enough to build it. What we don’t realize is that you don’t need a computer science degree to change the way the web works. You barely even need to read a book. The tools for creating and altering the web are readily available and easy to learn.

Restyling Google+ Notifications

One of the most simple tools for altering the web are user styles. These allow anyone to change way their browser displays websites by using Cascading Style Sheets, a language used to describe the presentation of web pages. All that’s required to create user styles is a basic understanding of HTML and CSS. User style configuration used to be buried within browser preferences, but now there are browser extensions for most major browsers. Stylish is an extension that’s available for both Firefox and Chrome. A similar extension is available for Safari called User CSS.

No matter what browser you’re using, you’ll need to create a user style for Google+ (be sure to include both http:// and https:// URLs) and include the following CSS rule. Yes, just one rule.

div#gbg span#gbi1a { background: none !important; }

If you did everything correctly, your Google+ bar should now be relatively distraction free. The functionality of the notification menu is unchanged. You can still see the number of notifications; it just won’t be nagging you every time you use a Google product. All it took was a little HTML and CSS knowledge.

We’re Just Getting Warmed Up

Managing digital distraction is just one of the many aspects of living with digital media. If we don’t understand the way digital media is created and programmed, our lives will be increasingly dictated by it. As with Google+ notifications, the choice of how we experience digital media will be made for us by the designers and engineers that created it.

As digital technology becomes further integrated with our lives, we must start to learn the basics of how programs work or we’ll be at the mercy of those who do the programming. This doesn’t mean that we need to understand exactly how programs work, but we need to understand the fundamentals of digital media if we want to regain control of our experiences with it. Often it only requires a little bit of knowledge and inclination. As the previous example shows, it may only require a single CSS rule. With powerful browser extensions like Stylish and the collections of user styles that are now available, anyone can can take more control over their experience.

Thanks to Kevin Cheng and Michael Burkett for their feedback on my draft.

My one resolution for 2010 is to only do things that feel good and right. Last night, as part of that resolution I deactivated my Facebook account. It wasn’t an action I took lightly, but it was something that I felt like I needed to do.

By the end of 2009, I was making several visits to Facebook a day. I’d have a moment of downtime during lunch, in between meetings, after dinner or before sleep, and Facebook was the first site that would come to mind. I’d hit the site, and of course I’d have to click through all of my notifications and see what comments people had left on my posts. Read, comment. And why not check the news feed? Read, comment, like In addition to the times I’d visit Facebook on my own, throughout the day I’d receive an occasional message or event invite via the site. Read, mark as attending, reply. And oh while I’m here, let’s check the news feed again. Read, comment, like.

(On Facebook, you can get notifications for a lot of things, but I didn’t really use Facebook apps, so I generally only received notifications when someone commented or liked one of my posts or when someone commented or liked a post that I also commented on. If you put a lot into it, you get a lot out of it. And me, I was putting a lot into it. Beyond simply commenting and liking news feed posts, I was posting updates and links almost daily. So the influx of notifications I received with every visit was mostly my own doing.)

I was probably spending at least an hour a day on Facebook. That’s 7 hours a week, 28 hours a month - and at least two weeks a year.** I’m not a terribly busy person but I personally find that to be a huge chunk of my time.

I realize that many people have no issues spending this amount of time browsing, commenting and liking on Facebook. While writing this entry, I asked a friend of mine how much time she spent on Facebook, and she answered “maybe an hour or two.” But she couldn’t use it at work.

I also realize that many people find Facebook entertaining, useful and/or valuable. I sometimes found it entertaining, useful and valuable as well. But many more things didn’t feel right: the compulsion to visit the site several times a day, the endless yammering, the “likes,” the dating ads, the distorted idea of “privacy” that Facebook promotes, the lack of control I felt when using the site.

I had a few options: I could post and comment on Facebook less, I could login less, or I could deactivate my account. Posting to Facebook less was easier. Restraining myself from commenting was hard. Logging in less was harder. In short, I couldn’t change my activity on my own, so I needed external moderation. Deactivating my account was really easy, and it would automatically keep me from logging in, posting and commenting. My plan is to keep my account deactivated for at least rest of January, watch how often I try to use Facebook (and for what reason), see if I miss it - or see if I forget about it - and then go from there.

Facebook isn’t just a website anymore. It’s become part of our lives. And like anything in our lives, especially something that we spend so much time using, it deserves a critical evaluation. I hope to reactivate my account someday, but next time I visit I want to feel better about my experience there. I want it to feel right.

** Some may be asking, “What about Twitter.” I feel like I have more control over my Twitter experience, mainly because Twitter only has a stream. It’s really just updates, mentions and an occasional direct message. No “friends,” no mysterious news feed, no notifications, no photos, and not a million other things have no need for. As a result, I spend much less time on Twitter, and the time I do spend there feels more valuable.

Reactivating Facebook

For folks who weren’t following along, I deactivated Facebook back in January because I felt like it was slowly taking over my life. Basically, I wanted to prevent myself from being able to immediately log in and using the site. It worked, and I didn’t use Facebook at all for a little over three weeks.

I’m proud to say that I use Facebook significantly less now. Essentially, I only use it as an extended address book and to RSVP for events as it’s practically become the de facto standard for events and invites.

A few services I use (Tumblr, Netflix and YouTube to name a few) still automatically post to Facebook on my behalf, which I’m okay with because I don’t ever have to worry about comment notifications on these posts. In fact, I don’t ever have to worry about comment notifications on any post because I’ve turned off commenting. If you want to reduce the time you spend on Facebook without deactivating your account, turning off commenting on your posts is probably my top suggestion. (As a sidenote, I tried disabling my wall for a short period of time, but I felt like that was going a little too far. Visiting a profile without a wall feels like visiting a site without a home page; I re-enabled it shortly afterwards.)

It’s hard not to pass through Facebook without at least glancing at the News Feed, which I’ve done on several occasions. I think I’ve read a small handful of posts and have left two comments. Overall, my 1+ hours a day has been reduced to a few minutes a day at the most. I’d say that’s a very good thing.

I feel like I can say that it’s a good thing because I don’t miss it at all and the little interaction I have with the site feels much healthier. If you do miss Facebook when you don’t use it, and you enjoy the time you spend on there, that’s great. But I would ask you to take a more critical look at your experience on Facebook and ask yourself, despite how entertaining it might seem in the moment, does it truly feel good and right?

Deactivating Facebook and Reactivating Facebook were originally published in January 2010 and March 2010 on my tumblelog, also unraveled.

To switch the active application in 10.2, you hit Command-Tab and a highlighted dock icon told you which application was selected. It worked, but it had problems. The biggest of which occurred when open applications were separated by several unopened applications on the dock. When this happened, the highlight skipped across these unopened applications in a seemingly unpredictable manner because almost no one could remember exactly which applications were open and which applications where closed.

A Better Switcher

In 2001, a small software startup named Proteron announced LiteSwitch X, an OS X update to its popular OS 9 keyboard application switcher. LiteSwitch was essentially a Mac implementation of the Alt-Tab switcher found in Windows, but with an additional slew of features including drag and drop support, closing multiple applications and windows layering control. I was unsatisfied with the 10.2 application switcher and started using LiteSwitch X soon after buying my first Mac.

Apple caught up to Proteron in OS X 10.3 and introduced its own application switcher albeit with significantly less features than LiteSwitch X. Apple’s switcher has remained relatively unchanged since its original implementation.

Hit Command-Tab and you switch from the current app to the next most recently used app. If you hold Command, all running apps are displayed, and you can continue hitting tab to switch to another app. You can additionally hold down Shift and cycle in the opposite direction, and use the H and Q keys to hide and quit applications.

Apple slightly improved the switcher with 10.5, introducing drag and drop support and then again with 10.6, allowing you to trigger Exposé and show all windows of the selected application by hitting the up or down key.

Blinded by the Lite

Version 1.1 of LiteSwitch X introduced a preference for sending the reopen event to applications upon switching to them. This meant that LiteSwitch would force OS X to reopen the window if it had been closed, or restore the window if it had been minimized to the Dock. I enabled this preference soon after I started using LiteSwitch as it felt like the most natural way to switch to an application. With every OS X update, LiteSwitch X was one of the first add-ons that I installed. So when I switched to an application, I expected to it to be visible — the only exception being if it was a document-based application and there were no open documents.

In early 2009, I noticed that the Proteron website was down (The Wayback Machine records July 24, 2008 as the last date the website was reachable), and over the past year I was concerned about continuing to use software that was no longer supported. So near the end of December I begrudgingly tried to use the built-in OS X switcher.

Having been blinded by LiteSwitch for so many years, I was completely set back that the OS X switcher didn’t reopen closed or minimized application windows. For example, say iTunes was open but the main app window was closed. If I switched to iTunes, no window would appear. Switching to Finder, Mail, Address Book, Safari, Tweetie, Adium and other apps also didn’t reopen application windows.

Shortcut Madness

Given that switching didn’t reopen application windows, I expected a common keyboard shortcut for accomplishing this. Unfortunately, shortcuts only complicated the situation. To show the iTunes main window, I needed to hit the keyboard shortcut for opening the window (Option-Command-1 in the case of iTunes) or click on the iTunes Dock icon. There’s no unified keyboard shortcut for reopening the main window - even among applications made by Apple. Here are the keyboard shortcuts for the apps I listed above:

• iTunes: Option-Command-1
• Finder: Command-N
• Mail: Command-1
• Address Book: Command-0
• Safari: Command-N
• Tweetie: Command-0
• Adium: Command-/

These are just the apps that have a shortcut. Many, like Evernote, don’t even have one.

After tweeting about the lack of a standard shortcut for reopening main windows, Martin Polley pointed out that the OS X application switcher actually can reopen windows with some additional shortcut trickery.

It goes like this: hit Command-Tab to switch as you would normally, then when the app you want to switch to/reopen is selected, hit Option while continuing to hold Command. Then release Command before you release Option. Go ahead and try it now. When you first start using it, it’s quite painful after the simplicity of Command-Tab, but it does get slightly easier over time.

Personally, I love controlling OS X via keyboard, and most of the time I welcome consistent and standard keyboard shortcuts for commands. However, I believe that adding a shortcut for reopening windows is the wrong solution because it defies traditional keyboard shortcut expectations. For nearly every keyboard shortcut I use in OS X, there is a perceived before state and an expected after state. For example, if I’m browsing a site in Safari and I want to jump to the search input, I hit Command-Option-F. In the before state, I perceive that the webpage has focus. The expected after state is that the search input will have focus. In the case of the OS X reopen shortcut, the before state is that the window is closed or minimized. The expected after state is that OS X will bring the selected application forward and reopen or restore the window. The issue is that it’s very difficult, and sometimes impossible, to know if the window is actually closed or minimized. So for the shortcut to be truly effective, the user needs to remember which windows are open and which windows are closed or minimized. This is unrealistic at best.

Switching 101

Out of the box, the Mac offers three key ways to switch applications, and each of them behaves differently.

• The Dock. Click the application icon in the Dock to switch to the application and bring all of its windows, including closed application windows or individual minimized windows (if the app has only one window and it’s minimized), to the front. Clicking on an application’s Dock icon to switch to that app is one of the first skills that a new Mac user will learn. So it makes sense that doing this brings that application’s windows to the front.
• Selecting the Window and Exposé (now part of Mission Control). Click within an window to switch to the application and bring the selected, but not all of its application windows, to the front. Exposé is a different way to visualize windows but the same behavior applies. This is even more straightforward that clicking on a Dock icon; clicking on a window brings that window forward. For the new user, it seems okay that only a single application window comes to the front because the user clicked a single window. (As a historical note, in OS 9, clicking within a window actually brought all the application’s windows to the front.)
• Command-Tab. Hit Command-Tab and you switch from the current app to the next most recently used app and bring its open windows to the front. Let’s consider the new Mac user again. Clicking on an application’s Dock icon brought that app’s windows to the front, but using Command-Tab to switch to an app — which looks identical to the app icon in the Dock — only brings open windows to the front. It’s easy to assume that this isn’t going to make a lot of sense to the new user.

I believe that Command-Tab is the only way to switch applications without affecting windows because when Apple implemented the switcher in OS X 10.3, someone decided that it was the one true application switcher. And a true application switcher shouldn’t affect windows; a true application switcher only switches the application.

This is where Apple misstepped. Beyond being inconsistent with its closest switcher sibling the Dock, it doesn’t provide perhaps the most important thing that most users need upon switching: to see an application window.

Applications and Windows and Documents

Every application has at least one window. Some applications are document-based, meaning they allow the user to operate on multiple items at the same time. Mail, TextMate and Photoshop are all examples of document-based applications. Typically, document-based applications have one window per open document and often have multiple windows open at once. Other applications are non-document based; in these apps the user can only operate on one item at a time. As of this writing, iTunes, iCal and Address Book are all examples of non-document based applications. Typically, non-document based applications only have one window. For all practical purposes, that window is the application.

In the case of non-document based applications, the argument for always showing a window upon switching is easier. If you want to use iTunes, there’s practically nothing you can do without the application window. The same is true for iCal, Address Book and many other single window apps.

It’s a little trickier for document based applications. If the application has one document open, it makes sense to show that window — even if its minimized — because there’s a damn good chance that they’ll want to see that window. (People who keep their Dock hidden: have you ever switched to a document-based application and thought nothing was open because you didn’t see a window, later only to discover that you had a window minimized in the Dock?) If the application has two documents open, it makes sense to show the last document (window) the user interacted with.

Here’s the tricky part: what if a document-based application doesn’t have any documents open? Current apps handle this in different ways: some do nothing, some open a new untitled document automatically, some make it a user preference. Personally, I prefer apps to do nothing and not open any new windows, but ultimately I believe the window opening behavior should be based on the app. This, then, is the only exception to showing a window upon switching: if a document-based application doesn’t have any documents open, the developer should choose the window opening behavior and in some cases, allow the user to choose in the application preferences.

The Crux of the Switch

Switching should reopen closed and minimized application windows. It’s consistent with other ways to switch and therefore easy to understand. But most importantly, it’s what the user needs to use the app in most cases.

Given that Apple has released three versions of OS X since introducing the application switcher, I’m fairly certain that they would be extremely hard pressed to change its behavior at this point. The good news is that LiteSwitch X 2.6, despite being released previous to OS X 10.5, works perfectly in 10.6 Snow Leopard. There’s currently no official download site, but it’s still available on several software sites such as MacUpdate.

The Crux of the Switch was originally published in January 2010 on my tumblelog, also unraveled.

One feature common to all Twitter clients is “reload,” allowing users to load the latest tweets. Tweetie handled this particular feature differently from the beginning. I talked to Tweetie’s creator, Loren Brichter, about how this feature evolved and his perspectives on designing gestural interfaces.

Joshua Kaufman: Tapping a button to reload was generally accepted as a standard within the iPhone interface. What made you explore the refresh interaction in Tweetie 1?

Loren Brichter: Necessity is the mother of all invention. Looking back to Tweetie 1, I was in this position where my navigation bar was already filled up. On the left side was the “Accounts” back button which would take you back to the accounts list (Tweetie 1 was the first app with a sensible multiple accounts implementation). On the right side was the compose button.

So where did the reload button go? Other apps of the day simply put the reload button in the upper right corner. This was acceptable for single-account apps, but for apps that handled multiple accounts, those apps had to go through some nasty contortions and shove the account switcher UI into some other non-optimal place. So I thought about it, and asked: what was “reload”… really? In the context of Twitter, it really meant “load newer”. And when you loaded newer tweets in your tweet stream, where did they go? At the top of your list.

So I put the reload button at the top of the list. As you scrolled up, reading newer tweets, eventually you’d get to the top of the list and bam… there’s a reload button, it just slid into view exactly when you needed it. You tap it and it’s replaced by the newer tweets. It’s intuitive and doesn’t waste prime screen real estate (corners of the screen) until you actually need it.

JK: How did you arrive at the pull down and release to refresh interaction in Tweetie 2?

LB: Tweetie 2 simply took this idea from Tweetie 1, that reloading was simply “loading newer”, and “loading newer” put new messages at the top of the list… and activated the action based on a finger motion that you were already doing. Why make the user stop scrolling, lift their finger, then tap a button? Why not have them continue the gesture that they are already in the process of making? When I want to see newer stuff, I scroll up. So I made scrolling itself the gesture.

The gesture is only half the battle though, you need appropriate feedback. Once the reload is activated, the scrollable area of the list actually changes to leave the feedback UI in-place (rather than bouncing offscreen). Without this part, the UI is unintuitive. And once the loading is complete, the UI makes itself disappear.

JK: Using this interaction in Tweetie 2 reminded me that gestural UI is still young and full of possibilities. Are there other common interactions that you see being improved by new gestures?

LB: Of course. But you need to be careful. The reason that I think the pull-down-to-refresh works so well in Tweetie 2 is because it’s discoverable and explanatory. It’s discoverable because you already know how to scroll a list, and as you scroll up, when you get to the top — bam — the UI reveals itself and you go “whoa, what’s that?”. It explanatory because once you start tugging down there is some great UI feedback, actual text that provides instructions as you interact. It’s not like it pops up some modal dialog with instructions on how to use it, the UI itself is the instruction. Once you learn it you simply ignore the text and can look at the graphical arrow which gives appropriate feedback on what you need to do.

Now, I think you can split gestures into two categories. One is of the pull-down-to-refresh kind. These are gestures that are discoverable and explanatory. The other kind of gestures are like tapping-the-status-bar-to-scroll-to-the-top, or swipe-to-delete (or swipe-to-reply in Tweetie). These gestures you won’t discover on your own except by accident. These are not discoverable, and they are not explanatory.

This second class of gestures can exist (in my opinion) because they are not the only way to accomplish a goal. In the case of tapping the status bar, users already know how to scroll to the top manually. It’s slower, but it’s possible. In the case of swipe to delete, users already know they can tap on a message and then tap the trash button. So knowing the gesture isn’t necessary.

So when you’re inventing new gestures, it’s important to think about whether the gesture is required to use the app. If it’s the only way to accomplish a goal, you better be sure it’s discoverable and explanatory without needing to read a manual. If it’s the other kind of gesture, go nuts!

Loren Brichter runs atebits — a devious scheme designed to take your money $2.99 at a time. Previously he worked for Apple on the original iPhone. Now he mostly answers email, and occasionally finds time to actually program.

A video of his entire presentation is unfortunately not available, but Josh Damon-Williams did manage to grab this clip.

After watching this clip it’s easy to understand why the audience became so excited about the possibilities of these tools. At the same time, I wondered what the chances were for something like fourbysix to be developed on a much larger scale. The fact is that we can drool over tools like this all we want, but unless a large group of designers starts supporting the work of people like Björn, we’re going to be stuck with the same tools we’ve been using for the past ten years for the foreseeable future. I wanted to know what it would take to make tools like this accessible to more designers.

When I met with Björn, he explained how he created the fourbysix table while at Microsoft. Not surprisingly, he used a lot of Microsoft technology including the Microsoft Surface SDK and proprietary source code only available within Microsoft’s walls. However, he also used a lot of non-proprietary technology, including tools that have been available since the late 90s. He also explained that, while he did use proprietary technology to build fourbysix, there are more open equivalents that could be used to build something very similar.

So with enough know-how, resources and materials, you could build something like the table in the clip above, but chances are that this is out of reach for most designers. So what’s the next option? According to Björn, the best chance for designers to make use of this technology is to collaborate with a research university on such a project. Fortunately, there may even be opportunities for this in the San Francisco area over the coming year.

If you’re interested in participating in something like this in the future, please get in touch with myself or Björn. In the meantime, I’ll definitely be following his work and helping out where I can.

Update (21/9/09)

Björn just let me know that videos are now available which feature the multitouch table he demonstrated at Interaction ‘09.