Second Gear T-Shirt Sale

As I mentioned previously, I am heading to Australia next month to speak at the One More Thing Conference. I decided that after a few years or wearing the same style Second Gear shirts on stage, it was time to do a bit of a fashion refresh. I casually mentioned I was having these designed and people expressed interest in being able to purchase their own shirts.

Running a clothing store on the side isn’t something I want to do long-term, but I decided to open up the Second Gear Shirt Store for a week. If you’re interested in adding another black t-shirt to your collection, you’ve got until Sunday to get your order in.

Buy a Second Gear Shirt

Posted on April 18, 2012

A Review of the Das Keyboard For Mac

I have never really had a problem typing on the Apple Bluetooth Keyboard or my MacBook Air. The scissor key style that Apple offers across its line these days is nice because it’s relatively quiet, comfortable and attractive. If I generally enjoy the typing experience of Apple’s keyboard offerings, you’re likely wondering why exactly then did I drop $114 on the new Mac friendly Das Keyboard.

Das Keyboard has been available for a while with Windows keys, but this is the first version that is designed with key caps for OS X. After hearing Gruber consistently talk about his love affair with the Apple Extended Keyboard II I figured I’d give a new keyboard a shot. This may be the most conflicted I think I have ever felt about a new product.

The Das Keyboard is a throwback to the days of loud, mechanical keys that came with the computers you used in previous decades. Mechanical keys give this feeling of satisfaction as you’re typing. The keyboard itself is insanely large and has a substantial weight to it. It feels really well built and worth the amount of money I spent on it. It’s got a full keyboard, number pad and even two full-powered USB ports on the side. The only thing missing from this throwback is the PS/2 or ADB cable at the end.

So…how does it type?

Amazingly.

Every key press is substantial and satisfying. The keys have a slight inset to them that allows your finger tips to rest comfortable in them. As you push down on the keys, you are greeted with the classic “click-clack” noise of the keyboards of yesteryear. At first the amount of noise coming from my keyboard was incredibly distracting. Working around others it also made me a bit self conscious about my typing. As the week progressed, though, I started to notice the noise less and less. Das Keyboard does make a quieter version of their Windows keyboard. I wouldn’t be surprised if a similar Mac variant made its way to market someday.

The distance you have to go to press a key is much greater than that of Apple’s keyboard, but it’s by no means uncomfortable. It did take a couple of hours and a lot of typos to get used to changing keyboard styles. One thing I also found to be curious in the transition was how often I kept trying to reach for the Control key rather than the Command/Apple key as my modifier as if I was back on my old IBM desktop PCs of the late 90’s. Muscle memory never leaves you I suppose.

One of the odd choices made by the Das Keyboard folks is the location of the Function (Fn) key. On Apple keyboards the function key is in the lower-left corner. On Das Keyboard, it’s in the lower-right and nestled between the right side option and control keys. I rarely, if ever, have actually used the Fn key on my Mac keyboard, but with Das Keyboard it is essential if you want to work with the music or brightness keys.

On an Apple Keyboard pressing F1-F3 defaults to adjusting brightness, F7-F9 the currently playing music and F10-F12 the audio levels. To actually perform the action that a function key may be mapped to, you need to press the Fn key to override those built-in controls. On the Das Keyboard, it’s the inverse. Adjusting audio or brightness requires pressing the oddly placed Fn key and then the function key you want to work with.

Since the Das Keyboard is a wired keyboard, it is capable of supporting USB on the keyboard like classic Apple keyboards from the late 90’s and early 2000’s. Unlike those Apple keyboards, however, Das Keyboard takes up two USB ports on your Mac to use those ports. The reason is that these are both full-powered ports whereas Apple’s old keyboards only offered one full-powered and the other with just enough power to handle your evil hockey puck mouse. Giving up two USB ports in the back of my display wasn’t a big deal as I was using two ports for 30-pin cables. I’m not just running those cables through the keyboard itself.

So if I like how Das Keyboard types so much and the USB ports on it why am I conflicted about it? This thing is large, unattractive and a bit taller than I had hoped.

Aesthetics don’t matter when it comes to getting your work done, but it is hard to not notice the large keyboard that dwarfs my MacBook Air, Cinema Display and Magic Trackpad. It feels incredibly out of place on a modern Mac desktop. If all you care about is aesthetics, don’t even bother trying to use one of these things. You’ll hate it. If you are consistently dressing up as Darth Vader, Das Keyboard will make a lovely addition to your attire.

The size of it is a bit troubling if you have a smaller desk. I have a San Francisco sized apartment and an equally sized desk (aka: tiny). The Das Keyboard takes up most of the desk space, leaving a little bit of room for my Magic Trackpad and not much else. If you have a bigger desk this probably won’t be an issue for you.

Finally, the biggest frustration with Das Keyboard is the lip at the base of it. The keyboard makes it incredibly easy to rest your wrists on the base of it right below the space bar, which becomes painful after extended use. With the Apple Bluetooth Keyboard, the angle, bottom lip and key sizes are so small that my wrists are straight and not resting on anything. Das Keyboard requires a substantial amount of retraining to prevent myself from a lifetime of carpal tunnel trouble.

So in conclusion:

Will Das Keyboard make you a better programmer? My sources say no.

Will Das Keyboard annoy your coworkers? Most likely.

Will I still be using Das Keyboard a month from now? Reply hazy, try again.

Posted on April 15, 2012

One More Thing Conference 2012

If you have been looking for a good reason to make a trip to Australia, the One More Thing Conference happening next month may be it. A sigle day conference with 20-minute talks by developers and designers from around the world. I have been making an effort to cut down the amount of speaking engagements I am doing this year, but the premise of this event was hard to pass up. It being in Australia certainly didn’t hurt either.

Posted on April 02, 2012

Cancel Or Allow Overload

Unless you’ve been living under a rock, you’ve heard that Path was uploading your entire address book to their servers to use as part of a friend matching service. They have since apologized and removed all the data in favor of an opt-in approach to sharing that data, but it has sparked a debate on how Apple should handle this sort of data access going forward. The rest of the Internet has chimed in, and I don’t like feeling left out.

iOS’s existing method for determining access to important data is via alert views.

When you first launch Tweetbot for iPad, you’re prompted by iOS to allow or deny it access to your device’s Twitter accounts.

When you first launch über, you’re prompted to allow or deny access to your location via GPS.

When you first launch Facebook, your prompted to allow or deny push notifications to your device.

It seems logical then that Apple’s solution to further securing access to your contact data would be to bombard you with another alert dialog the first time an app tries to query it.

In fact that is what Path does now in their latest release. When you tap the “Add Friends” button in their app, you are asked if you want to upload the contact data to their servers to enable the friend matching feature. The feature is still the same as before, but now it’s opt-in.

Tossing up another dialog asking for user confirmation doesn’t solve the problem users are faced with. It just puts a band-aid on it. At the core is a more fundamental problem in how iOS handles permissions and access to data. Basically, I have no idea what sort of permissions or access an app wants until I download it and launch it the first time. Moreover, I really don’t to see another dialog pop up in my face as I’m using an app.

Apple takes this approach to securing user data because it’s the most direct way to force the user to express their intentions. There’s no “I was never prompted” or “I didn’t know” excuses allowed when you are shown a dialog asking if you want to give each application access to specific device services.

Both Android and Windows Phone take a different approach and inform the user of what permissions an app will be granted prior to download as part of their respective market places. From that screen a user can then determine whether they want to continue with the download or move along because the app is a bit too loose with its access demands.

Neither the iOS or Android/Windows Phone solutions are perfect. On the iOS side I’m able to allow access to some services, while denying others. As far as I can tell on Android, it’s an all-or-nothing proposition. You either choose to give an app full access, or you just don’t use it.

Meeting In The Middle

A hybrid solution that takes the best parts of iOS’s one-by-one acceptance and Android’s expressed and obvious intents seems like a proper model here. In fact, Apple has many of the pieces in place elsewhere.

On Mac OS X, Apple adopted a new sandbox permission system where developers are required to specifically define what parts of the system they need access to as part of the development process. That information is then transmitted as part of the app’s binary to iTunes Connect for approval as part of the app review process. If Apple doesn’t think your app needs access to a user’s location or photo library, they will reject the binary and request more information as to why you need that access.

Even though Mac developers are required to express these predefined intents, users still aren’t aware of what sort of access an app wants until they reach a point where an alert dialog pops up asking for permission.

This is the sort of information that I would want to be presented with as part of the app details in both the Mac and iOS App stores. Even better, the ability to adjust what permissions I want to allow as part of the download process.

Presently, when you want to download an app on the App Store, it goes like so:

  1. Tap the price
  2. Tap Install
  3. Enter your Apple ID’s password if required.

It’s definitely possible to adjust the process between steps 1 and 2 to show a list of permissions the app will request and allow the user to toggle them based on their predefined preferences. For example, I may want to prevent all apps from having access to my address book and Twitter accounts by default, but have no problem with them using the GPS. If I was downloading an app like Tweetbot, however, I’d want to give it Twitter account access just by toggling the access permission prior to or during the actual app download.

No longer would I then be prompted on first launch to handle a plethora of permissions dialogs related to different types of access the app may want. Users would know what information they are sharing or giving access to prior to even downloading the product.

The Case Against Intents

If this all sounds familiar, it’s similar to what Facebook does with their Facebook Connect functionality. If you ever link your Facebook account with another web service or application, the Facebook dialog will show you what information the requesting product would like. You then have the opportunity to adjust it to prevent certain access, or just move on without approving the app at all.

No one in the history of computing has ever said Facebook was easy to use and understand. In fact, if you ask most people about privacy settings or data access in regard to Facebook, you won’t get back much more than a blank stare.

Placing that amount of information in front of a user as a barrier to entry causes two things: confusion and disregard. If you prompt me to allow or deny location services the first time I launch an app, I only have to think about a single permission at that one moment in time. If, however, you prompt me with half a dozen different permissions at once, it is overwhelming and possibly confusing.

When we are overwhelmed or confused, we either leave the situation or just blindly access whatever it is. Do you ever read the end user license agreement for iTunes before you click the “Agree” button? Probably not, because it’s an overwhelming amount of tiny text. The same can be said for complex permissions and access dialogs. If you put too much in the face of the user, they will likely disregard it and say yes to get into the product itself.

Technology no longer requires a computer science degree and it shouldn’t. I’d love to see Apple adopt a more Android or Windows Phone-style permissions system for iOS, but those are models that are still holding onto a bit of the past. iOS is about breaking computing paradigms, even if it means a lot more tapping is involved.

Posted on February 11, 2012

Birds, Ducks and Robots

When Apple shipped the original iPhone back in 2007, Steve Jobs famously said the company was offering a “sweet” solution for developers: web apps. The original iPhone didn’t have the App Store, but instead a web page on Apple.com that listed the most popular web apps tailored for the iPhone.

Being an Apple platform developer, I spent time with my friend and designer Robert Andersen to build PocketTweets, one of the original (and popular) Twitter clients for the iPhone.

When Apple announced and delivered the AppStore, it was obvious to us that PocketTweets as a web app was no longer a viable solution for iPhone users. Even we no longer wanted to use it when there were native clients coming that performed better and integrated deeper into the platform. That’s when I switched to Twitterrific.

Twitterrific was an amazing demo of what was possible with the original iPhone SDK. It was one of the first apps that had all the fit and polish of an app out of Cupertino, but built by people I knew and respected on the outside. Unfortunately, I have never been a fan of Twitterrific’s unified timeline that mixes your timeline, mentions and direct messages all into a single stream.

Personally, the unified timeline wasn’t feasible for me with a common Twitter name of @justin as I was inundated with hundreds of misfired tweets a day. Professionally, I have always found the experience of having your direct messages integrated into the main timeline to be disorienting and confusing. I was always gun-shy sending and replying to direct messages in Twitterrific because I was always had that moment of panic where I wondered whether the message sent publicly or privately. When Buzz Andersen released Birdfeed, I instantly switched.

Birdfeed was the first, and only, Twitter client that truly clicked with how my brain works. It wasn’t the most feature packed client on the market, but it had a thoughtful interface, a navigation hierarchy that made sense, and (most importantly) I never noticed I was using it.

When Birdfeed was sold to Brizzly and subsequently murdered I was sad and again without a client that I could call my own. Luckily, Tweetie was there to be my rebound.

Whereas Birdfeed was the Pulp or Velvet Underground of iPhone Twitter clients, Tweetie was the Rolling Stones. It had the most users, was insanely popular and did a lot of great things. I never loved Tweetie like I loved Birdfeed, but I didn’t mind using it and came to mostly enjoy it.

After Tweetie was acquired by Twitter Inc. and rebranded as Twitter for iPhone I slowly stopped enjoying the app. First it was small things like removing power user things such as TextExpander touch support. Next it was putting more focus on things relevant to Twitter’s bottom line more than my use of the service: trending topics and top tweets. Next, the infamous #dickbar.

The final straw with Twitter for iPhone was the newly released redesign that doesn’t look or feel much like the Tweetie product that it started its life as. The new version of the Twitter app isn’t a terrible app, but it’s neither a great app, nor one that is designed with me in mind. The de-emphasis on direct messages and lists in favor of “Discovery” is a sure sign that the app isn’t for me. I visit Twitter to catch up on the news and happenings that are relevant to my friends I follow. Discover has never shown me anything I would consider relevant to my personal interests.

I tried to put aside my frustration with the changes in Twitter for iPhone and give it the benefit of the doubt, but I became more frustrated with the app as I continued using it over subsequent weeks. That’s when I finally relented and switched to Tweetbot.

Tweetbot is probably the most interesting of the Twitter clients on the market today. In terms of functionality, ease of use and thoughtfulness to the experience there isn’t a better offering. Where the app stirs controversy is with its heavy handed user interface design. Tapbots is known for having a unique design styling that spreads across all of their apps. In fact, it is a major part of their branding and signature.

Many people love the aesthetic stylings of Tweetbot. I am not one of them. I consider Tweetbot to be the best designed Android app available for iOS. The robotic theme feels heavy, animations feel off compared to the standard iOS provides ones and the experience just doesn’t disappear in your hands. I can never use Tweetbot without realizing that I am using Tweetbot, which is bad.

Whereas Tapbots’s signature style may work in smaller utility apps that are used quickly and infrequently such as a calculator or a global clipboard, it is incredibly hard to work with in such a text-heavy and long-term use app such as Twitter client.

I don’t dislike using Tweetbot, but I certainly don’t enjoy using it either. And that’s where the problem lies. I no longer feel like there is a perfect Twitter client available for me. Instead I feel like I am now using my Twitter client of choice solely for utility rather than enjoyment, which leads me to enjoy the overall Twitter experience much less than before. This is a prime example of the first world problems that haunt my daily life, friends.

Executing Perfection

There is a running gag in the Apple development community that a Twitter app is the new “Hello World”. For the non-programmers, “Hello World” is usually the first project you do as you are learning a new programming language. The goal is essentially to print out that specific phrase to your screen. I’m sure more than a handful of people have picked up an iOS development book solely to build something around Twitter’s API.

As a joke, the Hello World analogy holds true. In reality, however, building a 1.0 Twitter client is an incredibly hard task to undertake for even the most seasoned developers. When you start to break down all the different aspects of what is involved in order to compete it becomes even more daunting. Want to give it a shot? Here’s what you need:

  1. A great posting interface that supports photo and video uploading and location publishing at a minimum. Bonus points if you support username autocompletions and points of interests in your locations.
  2. A good looking profile view for each user account that also has information about their followers, who they follow, and specific timelines for their tweets, mentions, and favorites. Don’t forget you need to deal with caching and checking to see if they have an updated avatar periodically. Oh, and how about dealing with following and unfollowing that account.
  3. Every good Twitter client has a great timeline reading experience. It’s usually more than just parsing JSON into instances of UITableViewCell. You’ve got to handle refreshing and adding new tweets. What about instances when the network connection is wonky? There’s also all sorts of interaction design work and development around how to easily handle a user’s actions on a tweet (reply, favorite, retweet, etc).
  4. Each tweet needs a single tweet view with a variety of actions and metadata associated with it. Don’t forget you need to integrate maps here so you can view the location appended to the tweet and a photo/video viewer for any media.
  5. Mentions are their own separate timeline. Gotta have it.
  6. Favorites need a timeline too. This is a big 1.0, huh?
  7. Search is a major part of the Twitter experience. You’ll need a good interface to allow your user to search for both people and tweets with specific words and phrases.

I’m leaving out other aspects of the Twitter experience, but I think you get the point. This is a hard problem to solve and an even harder problem to solve in a way that provides an incredibly polished user experience. That’s why you’ve seen quite a few smaller clients come out with decent 1.0 starts, but missing key features and floundering shortly thereafter. Getting all the aspects of a Twitter app’s experience in sync is a full-time job and not an easy one.

Development difficulty aside, Twitter didn’t help the situation when they advised platform enthusiasts to no longer compete with them in the client space. It’s hard enough to be successful in a saturated market without having to compete against the platform provider who has posted a sign on the front door claiming you’re no longer welcome.

I firmly believe if Twitter had handled that situation with a bit more grace and tact, we’d still see more developers taking a swing at building quality clients for all the mobile platforms. Instead, those that were around or in development before Twitter’s client acquisitions remain while the rest of the development community focuses on building Dropbox syncing text editors.

Open Source

In the early days of Mac OS X there were quite a few different AOL Instant Messenger clients available. AOL of course had their official client, but others were out there such as Proteus, Fire, and of course Adium.

When Apple released iChat as part of Mac OS X Jaguar, they killed the third-party AIM client market for all intents and purposes. It’s incredibly difficult to compete with something that is free, bundled with every new Mac and is good enough for the majority of users.

While Proteus and Fire faded away, however, Adium remained. I have never been a regular Adium user, but I have an immense amount of respect for what it signifies. It is the power-users instant messaging client that not only goes beyond the service offerings iChat affords, but also the features.

Adium is software developed out of love and desire, more than solely for profit. What iOS needs is the Twitter equivalent to Adium: a well maintained, open source Twitter client that is targeted at the most hardcore and passionate users of both Twitter and the iOS platform.

That, of course, is easier typed than done. Many open source projects fail because of lack of vision or direction. Others fail because they are just badly engineered software that aims to shove every pet feature into a unified product. Projects like Adium succeed because there is an established hierarchy of managers, developers and contributors. Each release has a focus and direction much like a commercially produced project.

I would love to see the Adium model apply to a great Twitter app, but I remain pessimistic.

Next?

Where does that leave us? For many of you, you’re doing great. You have found a client for your device that works exactly how you want it to. Others like myself, however, will keep searching and hoping that someday someone will come forward and build that mythical perfect client.

Maybe someone else will build it. Maybe I will. Maybe we all will.

Whose up?

Posted on January 18, 2012