David Barnard

Testing App Store Promo Codes

Mon, 03 Oct 2011 09:55:04 -0500

I’m launching Tweet Speaker on Thursday and have begun sending promo codes out to friends and acquaintances in the press. With the avalanche of pitches, press releases, and SPAM flooding their inboxes, I sometimes don’t hear back and wonder if they even saw my email or had time to redeem the promo code I sent. Apple doesn’t provide a direct method of checking the validity of promo codes, so I searched google looking for some sort of hack to see which promo codes I’ve sent out have been redeemed.

One of the first posts I came across was written back in June by my friend, Dave Caolo, who writes for TUAW and 52Tiger: How to check if an Apple promo code has been used or not

Unfortunately, the steps outlined in that post didn’t work, but after thinking about it for a few minutes, I realized that Dave’s tipster left out one very important step. Most heavy App Store users, especially developers, end up checking the “Don’t warn me about purchases” box at some point. For Dave’s tip to work, you have to go into the iTunes Account account and reset all warnings.

So, here’s how to check if an App Store (or other iTunes) promo code has been used or not:

1. Launch iTunes and log out

2. Log back in and go the the Account view

3. Look for “Reset all warnings for buying and downloading” and click the “Reset” button

4. Quit and relaunch iTunes [I’m not 100% sure this is necessary, but I didn’t want to risk a promo code to find out]

5. Follow this link to the promo code redemption page: https://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/redeemLandingPage

6. Enter a code and click “Redeem”

If the promo code has been used you’ll see a warning stating: “This code has already been used. Each promo code may only be used once.”

If the promo code is still valid, you’ll be prompted to enter your password. Click cancel and the promo code will remain unused.

Great Developers Steal Ideas, Not Products

Mon, 19 Sep 2011 06:43:50 -0500

Over the past few months, I’ve been thinking a lot about intellectual property and the underlying moral and legal issues. In blogging and tweeting about these thoughts, I’ve tended to use the word “borrow”, but at times I’ve used the word “steal” to assert the implicit moral judgment.

As I thought more about and researched these ideas today, I came across this excerpt of an essay by T. S. Elliot:

One of the surest tests [of the superiority or inferiority of a poet] is the way in which a poet borrows. Immature poets imitate; mature poets steal; bad poets deface what they take, and good poets make it into something better, or at least something different. The good poet welds his theft into a whole of feeling which is unique, utterly different than that from which it is torn; the bad poet throws it into something which has no cohesion. A good poet will usually borrow from authors remote in time, or alien in language, or diverse in interest.

In dancing around the moral and semantic differences between borrowing and stealing, I’ve been missing the greater point. Elliot used the word steal, not for its immoral connotation, but to suggest ownership. To steal something is to take possession of it.

When you steal an idea and have the time and good taste to make it your own, it grows into something different, hopefully something greater. But as you borrow more and more from other products, there’s less and less of you in the result. Less to be proud of, less to own.

On User Interface Chrome

Fri, 16 Sep 2011 13:03:00 -0500

While watching Microsoft’s overview of Metro, its new user interface paradigm, it struck me as somewhat odd how much emphasis was placed on the removal and abstraction of user interface chrome.

Though we act directly on many objects in our day to day existence, many of those objects are themselves tools for acting on other objects. We are, in fact, completely surrounded by object interface chrome.

We don’t carry water around in our hands, we carry it in a some sort of cup. The cup is a tool we use to more effectively carry, store, and drink water. Our food is cultivated, transported, prepared, and eaten with tools.

History was not “recorded” until we imprinted it on rock, clay, and paper–using tools. Most great works of art are created with brushes, chisels, and other tools—music with drumsticks, guitar picks, and piano keys.

The iPhone, iPad, and other touchscreen devices are the meta-tools that enable the primary tools of computing—apps. And apps themselves are a collection of software tools that ultimately become, as Steve Jobs said, “a bicycle for our minds”. Tools to enhance and enable our cognitive endeavors.

Apps completely take over the touchscreen experience. The device becomes a book, a calculator, a map, a stopwatch, a sketchpad, and even a musical instrument. We shouldn’t view apps and the devices they run on merely as portals to content, but as tools for learning, sharing, and creating.

To that end, the ultimate goal of user interface design isn’t to minimize chrome, the goal is to build the right tool for the right job.

The El Camino of Computing

Tue, 13 Sep 2011 15:58:00 -0500

I have to admit I was rather charmed watching a demo of Microsoft’s Windows 8 tablet. I bounce back and forth between my iPad and MacBook Pro quite often during the day, so merging the two into a single device looked appealing. After a few minutes daydreaming about the unification of iOS and OSX, it struck me that I don’t want an El Camino.

My wife, Liz, and I share a 2001 Honda Accord for a reason—it’s an incredibly practical vehicle that handles 99% of our transportation needs. Every once in a while we need a truck to haul a large piece of furniture, or handle some other cargo that just wont fit in our Accord. Fortunately, we have quite a few friends who own trucks we can borrow, but even if we didn’t, renting a truck once in a while is significantly more cost effective than buying a truck just to have one around. And buying an El Camino would be absurd. It compromises the functionality of each vehicle class such that it would be completely impractical for us.

Liz and I also happen to share my MacBook Pro. It’s the only non-iOS computing device in our home. Sharing the computer was a minor source of contention until recently when I bought Liz a keyboard for her iPad. She still uses my computer on occasion, but it’s mostly for things like buying plane tickets or ordering flowers, which should be much easier on iOS.

Some people still have a hard time believing this, but I have no doubt that the future of computing—especially casual computing—is iOS, not OSX. And I’m starting to doubt the viability or necessity of a hybrid. The car vs. truck analogy will become less applicable over time. iOS isn’t bound by physicality as is a car. Through speech-to-text, gestures, software innovation, and even hardware accessories, Apple can empower more and more iOS users to make a complete break from OSX. And iCloud is a big step in that direction.

Microsoft’s El Camino approach to computing may ultimately be saved by Moore’s Law if hardware can catch up fast enough to adequately and cost effectively run the behemoth they’re building. But Apple already has an 18 month head start on the future of computing and Windows 8 wont launch until Fall 2012 at the earliest. While the hybrid approach looks attractive today, it will look less and less attractive over time, and will likely look like a complete kludge by the time Microsoft is able to ship it.

App Producer

Thu, 01 Sep 2011 14:08:31 -0500

Upon making an acquaintance…

HIM: So, what do you do?
ME: I develop software.
HIM: Software?
ME: iPhone apps.
HIM: Oh! I’ve got this great idea…
ME: [listens patiently]
HIM: So, you’re a programmer?
ME: No.
THEM: So, you’re a designer?
ME: No.
THEM: What do you do then?
ME: A lot, actually.

It’s difficult to succinctly communicate what it is I do, I wear many hats. My role goes far beyond what would traditionally be described as product management, though I do manage the development process. I’m not a programmer, though I do work in Xcode and even tweak isolated bits of code. I’m not a designer, though I do spend quite a bit of time in Photoshop. I work on marketing, writing, networking, tech support, business development, brainstorming, quality assurance, usability testing, user interface drafting, etc.

Trying to describe what I do has, over time, helped me better understand it and focus on getting better. Focus doesn’t seem an apt word in the context of the many hats I wear, but I do have focus, I just haven’t had a great way to describe what it is I focus on. After a compelling conversation about it on Twitter, it finally dawned on me—I’m an app producer.

At some point in junior high school I decided I wanted to be a record producer. I enjoyed performing and composing music, but what really fascinated me was the process of capturing that talent and creativity. Capture. As if music is some wild animal roaming the wilderness, and the recording studio is just an elaborate trapping mechanism.

After reading MIX Magazine for years, obtaining a degree in Sound Recording Technology, interning at a big studio in Nashville, and even spending a couple years as a freelance recording engineer, I still essentially viewed the studio as an elaborate system for capturing the talent and creativity of musicians. Then I got the opportunity to work on an album with a great producer. It changed my life.

Over the course of a few weeks I saw the producer craft the album. It’s a sort of meta-creativity, working iteratively with talented musicians to create something that’s greater than the sum of the parts.

There’s a reason George Martin was sometimes called “the fifth Beatle”, and why the Red Hot Chili Peppers have worked with Rick Rubin on every single studio album since the break through Blood Sugar Sex Magik. A great producer sees the forest for the trees and thoughtfully guides the recording process.

That’s what I do, except with apps. I was pretty bad at it when I founded App Cubby back in 2008, but it’s my art and I’m constantly striving to be a better app producer.

The Fair Use of Ideas

Mon, 08 Aug 2011 14:00:00 -0500

I’ve tried my best, but just can’t reconcile the complete abolishment of software patents with my innate sense of justice. The patent system is an utter mess, but let’s not be so quick to throw out the baby with the bathwater.

Among the friends I’ve made in the indie iOS development community, there is a sort of unwritten honor code related to software innovation. If someone comes up with a great implementation idea we either ask for permission to use that specific implementation, or we iterate on that idea such that it has recognizable bits of the original implementation, but is clearly different—preferably improved. We borrow from each other constantly, but we do so respectfully.

That works well for a relatively small community of thoughtful, creative folks, but obviously doesn’t scale. As the App Store has grown, so to has all forms of blatant IP theft and attempts to profit on the ideas of others with little or no innovation. In the App Store this happens on a relatively small scale and the knockoffs don’t often gain traction.

Then there’s Google. Their knockoffs aren’t confined to the App Store, and with a huge pile of cash funding the efforts many have gained significant traction. As I said in a previous post, they have been “borrowing” at an alarming rate and seem to care less and less about their own innovation as they seek to capitalize on their ability to monetize software through advertising.

I don’t think Google set out to become the Chinese knockoff shop of the software industry, but the erosion of intellectual property rights is a slippery slope. It seems to have started with a disdain for the blatant abuses of software patents and dissolved into a sense of entitlement. Whether or not specific patents are valid, Google doesn’t have the right to trample on any and all software related intellectual property rights. “Making enemies along the way” might seem like an appropriate way to create shareholder value, but it often comes back to bite you in the ass. And even when it’s not illegal, it’s disrespectful—both to the innovator(s) whose ideas were stolen and to the entire industry.

How then do we effectively protect the intellectual property rights of software developers while also spurring innovation. Fair use. Copyright law is another mess of good intentions and imperfect execution, but the concept of fair use has made copyright law, well, more fair.

Here’s an overview of the fair use provision in copyright law from the U.S. Copyright Office:

Section 107 contains a list of the various purposes for which the reproduction of a particular work may be considered fair, such as criticism, comment, news reporting, teaching, scholarship, and research. Section 107 also sets out four factors to be considered in determining whether or not a particular use is fair:
The purpose and character of the use, including whether such use is of commercial nature or is for nonprofit educational purposes

The nature of the copyrighted work

The amount and substantiality of the portion used in relation to the copyrighted work as a whole

The effect of the use upon the potential market for, or value of, the copyrighted work

Those four factors have obvious application in the realm of software patents.

Even in copyright law, fair use is confusing and far from perfect—and there’s still the threat of a lawsuit that one can’t afford to fight—but taking some of the teeth out of software patents with concepts similar to fair use could move us a long way toward a more balanced, productive approach protecting the intellectual property rights of software developers. Other ideas such as a non-practicing entity clause would also help.

Unfortunately, adjusting patent law and interpreting it through the legal process will take years. And the legislation currently pending makes things worse, more than better. In the mean time I propose a stopgap. Software developers should treat each other, and the entire industry, with respect. And when we fail to do so, we should expect public shaming by our peers and industry journalists.

Stealing ideas for profit is shameful. Borrowing from the ideas of others and innovating on them is commendable. These two seemingly contradictory concepts are at opposite ends of a vast sea of grey, but some shades of grey are dark enough to be called black.

Everyone Borrows, Google Flaunts It

Tue, 19 Jul 2011 22:33:00 -0500

In “Everything is a Remix” Kirby Ferguson makes a compelling and fascinating case that innovation and creativity lean heavily on prior art. That’s always been the case in technology, especially software, but I can’t recall a single company going so far in “borrowing” from product after product as Google has done recently.

I can, however, recall various groups that unabashedly borrow from other software products. Gimp, Open Office, and many other open source projects don’t just lean heavily on the work of Adobe, Microsoft, and others, they directly copy key features, often while adding little or no additional value. Because most such projects have yet to successfully disrupt the status quo and do actually contribute to the “greater good” in various ways, the tech community has excused and at times even celebrated the borrowing.

Google’s use of “open” as a marketing term often seems to be a naive misappropriation of the concept, but more and more I think it’s a brilliant misdirection. Though many, if not all, software products borrow from existing ideas, we’re more likely to give Google a pass on excessive borrowing because of their perceived openness. In thinking about this post, I had to google whether or not Google Docs is open source. Even though it’s not, it has the feel of open source software since it can be used for free or on the cheap and is an attempt to disrupt the stranglehold of Microsoft Office.

Google has innovated in real-time collaboration and other areas, but the core concepts and even most of the features borrow heavily from Microsoft Office and other similar productivity suites. Shame on Goog… oh, wait… Apple did the same thing with iWork. And Microsoft is the one looking over Google’s shoulder in building Office 365. Everyone borrows.

Productivity suites are an easy target since many of the foundational concepts have been around for decades now, but I think it hints at a greater point—the borrowing of software features and other implementation concepts is so easy and so prevalent it’s almost impossible to prevent or even stop. Apple, Microsoft, and other’s are trying, but enforcing software patents in court is a costly fight that can drag on for years.

Meanwhile Google is flaunting its ability to monetize through advertising by unabashedly borrowing from and commoditizing the world’s most used software. People spend a lot of time reading and replying to email—enter Gmail. People spend a lot of time working on documents, spreadsheets, and presentations—enter Google Docs. People spend lots of time in a browser—enter Chrome. People are spending more and more time on mobile devices—enter Android. People are spending an inordinate amount of time on social networks—enter Google+.

In most of its products Google innovates enough that we view any similarities to prior art as borrowing, but Google+ is the most flagrant product ripoff I’ve seen from such a large corporation (Android being a close second). The similarities between Google+ and Facebook were obvious when Google+ first launched. The UI is cleaner in various ways, and Google has innovated a bit with Circles, Huddles, and other features, but fundamentally Google+ is an unabashed ripoff of Facebook. And if you’re not convinced of that, take a look at the Google+ iOS app that just launched today:

Apps and the Apple TV

Thu, 07 Jul 2011 16:26:00 -0500

The speculation surrounding Apple’s fall announcements has been focused on new versions of the iPhone and iPad, but we’ll undoubtedly see additional “Apple TV will get apps” speculation as the event nears. Developers, the tech press, and even tech savvy users have been fascinated by the possibility of running iOS apps on the Apple TV. And that fascination reached a fever pitch last fall when Apple launched the iOS based Apple TV 2.

This fall Apple may or may not announce a beefed up Apple TV with the ability to download and run apps directly, but even if they do it wont be quite as ground breaking as many assume. The ground has already been broken with AirPlay and AirPlay mirroring in iOS 5.

There remains a fundamental misunderstanding of the difference between mouse-like pointing devices and touch screen interaction. I’ve written about this before, but I’ll do so again—direct manipulation of objects on a touch screen device is a fundamental change in human-computer interaction and is undoubtedly the future of most, if not all, consumer computing devices. The age of the mouse is ending, but the implications are still unclear to most.

When the Magic Trackpad launched, quite a few posts were written about the death of the mouse. The problem with most of those posts is that they conflated the Magic Trackpad with touch screens. The mouse as an object that physically moves around your desk is dead, but fundamentally the Magic Trackpad is just a better mouse-like pointing device. The Magic Trackpad is not the future, it’s just one of the last great pointing devices.

I think the best way to illustrate what I’m trying to say is to tell the story of my 2 year old son, Luke, trying out AirPlay mirroring for the first time…

The other day I was watching the Tour de France on my TV using AirPlay mirroring of NBC’s TDF app running on my iPad 2. When Luke saw the iPad sitting there seemingly unused, he asked if he could play games on it. I did my best to explain to him that the iPad was busy sending video to our TV and was completely blow away by his response. In essence, he asked if he could play his games on the TV. He’s just a few months past his 2nd birthday, but he instantly grokked that the iPad was able to send video to the TV. Why not, he’s growing up surrounded by magic.

What’s interesting, though, is what happened next. When handed the iPad, he looked down at it and launched this week’s favorite app, The Monster at the End of This Book. He looked up at the screen and was excited to see Grover on TV. Then he looked down at the book and flipped the page. Then he looked up and was again excited to see Grover on TV. Then he looked down and turned the page. After just 60 seconds the thrill was gone and he was mostly just playing with the iPad, only intermittently looking up to confirm that Grover was still on TV.

After a few minutes he exited the app and looked up to see the icons of all his favorite apps on the TV. He immediately set down the iPad, walked up to the TV, and tried launching an app by touching the TV screen. My wife and I instinctually told him not to touch the TV, but he looked back at us quite puzzled. The thing is, Luke has never used a mouse-like pointing device. Other than using the TV remote to turn the TV on and off, or turning a light switch on and off, he’s never used one object to remotely manipulate another.

I can’t overstate what a fundamental shift this is. In the entire history of computers we have used a keyboard, keypad, mouse, mouse-like pointers and other similar devices to manipulate objects on a remote screen. [The Palm Pilot and other devices that used a stylus for input did foreshadow the iPhone, but I’d still lump a stylus with mouse-like pointing devices, though I’ll save that argument for another time.] The iPhone changed all that.

As my son so clearly demonstrated, a remote screen is much less interesting when you can directly manipulate objects on a touch screen. The two most obvious conclusions to draw from that statement are: 1. All screens should be touch screens 2. Remote screens will go away because direct manipulation is more compelling. But I think there’s a third, more likely conclusion: TVs and other remote screens will be limited-use extensions of our mobile touch screen devices.

In thinking about how TVs and other remote screens will be used in the future, I think we need to consider how the user interacts with objects on the remote screen and what use-cases are truly more compelling with a remote screen. As my son demonstrated, interacting with the iPad while looking back and forth from the iPad to the TV is onerous and seeing Grover on the TV was fun, but not ultimately compelling.

The current Apple TV user interface isn’t much different from the mouse-like pointing paradigm we’ve grown accustomed to since the introduction of the Macintosh in 1984. The only difference is that you navigate a selected state among objects instead of navigating a pointer over those objects. We can only visually focus on one thing at a time, so when two devices are involved one of them has to be operated without looking, or the user has to look back and forth between the two objects. Someone who doesn’t know how to touch-type is constantly looking down at the keyboard then back at the screen. The mouse doesn’t require us to look at it, but it is a learned skill. Most of us don’t remember, but using a mouse for the first time is disorienting and takes time to master.

Even break-through technologies like Microsoft’s Kinect require remnants of the pointing device paradigm. There is a very physical disconnect between what the user is doing in front of the TV and what is happening on-screen. That disconnect must be somehow mitigated. In most situations, Microsoft has chosen to use ghosted body parts to help connect the user to the on-screen action. The body then becomes just another pointing device with a pointer visible on-screen.

In discussing the iPad, Steve Jobs famously said “If you see a stylus, they blew it.” Similarly, if you see a pointer on-screen, you’re still using a mouse-like device, even if it’s your body that has become the mouse. If the iPad is just a big trackpad that moves a pointer on a remote screen, we’re in for a very boring future. But that’s where things get quite interesting, the touch screen is the iPad’s primary input method in normal use, but the accelerometer, gyroscope, compass, gps, proximity sensor, light sensor, camera, and even the microphone provide options for input that don’t require looking down. With Airplay maturing this fall in iOS 5 and Microsoft officially allowing developers to tinker with Kinect, we’re just now starting to explore the ways in which a remote screen can be used in compelling ways apart from the human-computer interaction paradigms of the past.

The Social Implications of Circles

Wed, 29 Jun 2011 17:39:21 -0500

Circles within Google+ look really interesting, but I wonder if they’ll lead us further down the rabbit hole of multiple online personas. I’ve often thought that I’d rather not hear about a person’s dog/kid/food/fun/etc on Twitter. I mostly follow people in the iOS/tech space and it’s often time consuming to wade through the noise looking for the information that’s applicable to running App Cubby. But the more I think along those lines, the more I appreciate how Twitter seems to encourage people to be themselves.

I mean we all put our best foot forward to a certain extent, but I feel like I’ve really gotten to know the people I follow on Twitter. When I bump into them in real life I can ask how their kid if fairing at that new school or their thoughts on french press vs. siphon coffee.

I wonder if creating a bunch of circles and overthinking which circles get to see what bits of information will end up making us less social rather than more. Though a certain level of control seems beneficial, that control might be an overly logical approach to the very human matter of self-disclosure.

Facebook started very private and is pushing users more public. Though Twitter does allow private accounts, it’s primarily been a public platform since its inception and most use it that way. Google is giving us what looks to be the best of both worlds, but I’m not sure that’s a good thing. Time will tell… I haven’t even gotten to use Google+.

iUnicorns

Tue, 28 Jun 2011 15:30:00 -0500

Yesterday I wrote a rather speculative post about something Apple probably won’t do. This morning I woke up and thought for a few minutes about what I’d written. At first I felt a bit embarrassed. Sure I made a half decent case, but seeing Apple release a $49 Thunderbolt cable kind of put their MO into perspective. Apple may release a cheaper Apple TV, but the odds are definitely against it.

After re-reading my post and seeing some of the headlines this morning, I’m actually quite proud of what I wrote. For a post wildly speculating about Apple, I did a great job making it clear that it was just speculation. Even the last sentence of my post clarifies that I’m not suggesting Apple will actually release a cheaper Apple TV: “…but I’m more and more convinced that a cheap Apple TV would be a boon to the entire iOS ecosystem.” I’m not more and more convinced that Apple is going to do it, I’m more and more convinced that it would be a boon to the entire iOS ecosystem. Those a two very distinct assertions.

Maybe it’s always been this way, but it seems as though the tech press has been getting worse and worse at presenting speculation as fact. Headlines like “iPhone 3GS Will Still Be The [sic] Low-End iPhone Even After iPhone 5” and a million more like it that I won’t even waste my time looking up, have been driving me nuts lately.

In yesterday’s press frenzy about the possibility of Apple introducing a second, brand new iPhone model—or some other sort of stratification—one tweet stood out as a perfect example of restraint and careful wording. “We keep hearing it’s done and just waiting on Apple to pull the trigger. Really solid source.” Rene does have great sources, but he hardly ever publishes information he’s been given. The thing is, if the information is correct it may cost someone their job, and if the information ends up being false, it may still cost someone their job and Rene looks like a tool.

Apple often leaks false information to rat out sources. So, even if you hear something from a solid source who has been right in the past, there’s still no way to guarantee when or if that thing will happen. Hence Rene saying that Apple does have some sort of cheaper iPhone waiting in the wings, but Apple may or may not pull the trigger. At the end of the day, writing a story about this mythical device just doesn’t make sense for someone who respects their readers and sources.

I will say, however, that there are certain writers to whom Apple PR purposely leaks information that they want public, but don’t want to directly confirm. If you go back and look at articles written as fact by respected members of the Apple press, you may find some patterns of accuracy that weren’t obvious amid all the speculation.

Anyhow, I wont beleaguer the point further… Rumors and speculation can be interesting, but please stop reporting them as fact, it’s insulting to readers and ultimately embarrassing to sites that peddle in those link-bait tactics.

The Case for a $49 Apple TV

Mon, 27 Jun 2011 19:13:00 -0500

Rumors of Apple releasing a TV have surfaced once again… it’s apparently the new Verizon iPhone. I bet they have a few prototype TVs hidden somewhere in Cupertino, but I wonder if their short-term strategy is something much less sexy—a dirt cheap Apple TV.

As many have pointed out, the TV industry is a mess of commoditization. Apple could be working toward a hardware/software differentiation strategy similar to what’s driving their industry leading profits in computers and mobile devices, but the logistics of bringing a TV to market just don’t seem to make sense for Apple. They do, however, have this amazing technology called AirPlay that makes the TV somewhat irrelevant once the user plugs in the tiny Apple TV.

The current Apple TV sells for $100, which is actually pretty cheap for such an amazing piece of technology. But $100 is still too high to be an impulse purchase, even for the throngs of iOS users who pay $200+ for an iPhone and thousands of dollars to connect that device to the rest of the world. More so for those who buy an iPod Touch or iPad expecting it to be a one-time purchase.

Apple, under the leadership of Tim Cook, has done an amazing job leveraging pre-purchase contracts and economies of scale to drive down the cost of hardware. According to iSuppli the Apple TV cost Apple around $60 to manufacture when it first launched last year. iSuppli is having to guess as to what exactly Apple paid for components, but they do attempt to account for the special pricing Apple is able to negotiate. Though not accurate, it at least gives us a ball park number to work with.

Looking at the bill-of-materials there isn’t a lot of room for Apple to dramatically drop the cost, but most of the big ticket items on that list are the sorts of components that drop in price over time. And keeping the hardware exactly the same means the manufacturing partners and component suppliers don’t have to ramp up new processes. It might be a stretch, but after a year on the production line, I bet Apple could make a small profit selling the current A4 based Apple TV for just $49. But why would they?

Jobs stated rather plainly at D8 that set-top-boxes don’t have a viable go-to-market strategy. They are given away for free or rented at a nominal cost by cable and satellite TV companies. Nobody wants to buy a set-top-box. Apple could drop in an A5 processor, lots of RAM, 16+GB of storage and market it as some sort of gaming console meets set-top-box, but with AirPlay you don’t really need beefy hardware constantly hooked up to the TV.

I’ve been thinking quite a bit lately about the concept of a “thick client.” Over the past few decades as Moore’s Law has been pushing hardware improvements logarithmically, the gatekeepers of the Internet have been thwarting and throttling networks. And now we’re increasingly moving toward ubiquitous internet connectivity, but the mobile web is being built by many of the same gatekeepers and faces even greater tech challenges. I hope to write more about this soon, but the bottom line is that the idea of a true thin client makes less and less sense. Why offload all the work to the server when we all carry incredibly powerful computing devices in our pockets? Similarly, why do we need a beefy Apple TV when the iPad 2—and soon the next iPhone—are quite capable on their own.

A few days after returning from WWDC, I loaded the iOS 5 beta onto my iPad 2 and Apple TV. The experience of playing RealRacing 2 HD over AirPlay completely blew my mind. The iPad acted as the controller and the graphics I saw on my 1080p TV looked as good or better than what we saw early in the current generation of dedicated gaming consoles.

With iOS eating its lunch in mobile gaming, Nintendo recently showed off the successor to the amazingly successful Wii, the Wii U. Guess what? iOS 5, AirPlay, and the Apple TV will combine to give a Wii U like experience when iOS 5 launches this fall. The Wii U isn’t expected to ship until mid 2012. Throw in a few more iPhones or other iOS devices and you have the full on party mode Nintendo was proposing as the future of gaming. The iOS platform already has quite a few AirPlay enabled apps and that number will grow quickly as developers see the full potential of iOS 5.

But the bigger question remains—why would Apple sell a device on such a thin margin? I think the answer is two-fold. First, a $49 Apple TV would be an incredible, no-brainer accessory to devices running iOS 5. And though margins would be thin on the device itself I think it would help drive sales of iOS devices and propagate iOS platform lock-in. Second, I think the low price would give Apple momentum in the living room. Without a clear strategy for selling billions of dollars in high-margin set-top-boxes, why not grease the wheels a bit with a trojan horse that may help create an opportunity while at the same time pushing sales of their ridiculously profitable mobile devices?

I have no idea what the long-term living room play is for Apple, and I’m not sure it’s clear to them either, but I’m more and more convinced that a cheap Apple TV would be a boon to the entire iOS ecosystem.

The Eleventh App

Fri, 24 Jun 2011 08:05:04 -0500

In his post on the 37signals blog, David Heinemeier Hansson makes a very good point about the small number of mobile apps most people actually use regularly. If most of us use just ten or so apps on a daily basis, do we really need hundreds of thousands of apps? His answer is a rather emphatic no, but I think he’s having trouble seeing the forest for the trees.

As an iOS developer I’ve spent an inordinate amount of time thinking about the market for apps. When the App Store first launched in July of 2008 I was absolutely blown away by the hundreds of apps available on day one—as was Apple, from what I’ve heard. Then a month later when my first app launched I was dumfounded to see the total number of apps already pushing into 5-figures. And a few months after that, 6-figures. And before the platform is even 5 years old that number will surge past 7-figures!

We’re obviously in the middle of a boom, and in any boom there’s going to be excess and redundancy, but are 499,999 of the 500k apps available on the App Store excessive and/or redundant? Obviously not. Can other mobile platforms be competitive without 500k apps? Absolutely! But here’s the really interesting question to ask: what specific apps does a mobile platform need to be competitive?

I think it’s telling that David says he only uses/needs ten solid apps on a daily basis, then goes on to list nine apps Apple baked into iOS (Safari, Camera, iPod, Clock, Weather, Photos, Messages, Mail, and Maps) and two apps from the App Store (Echofon and Bloomberg). So, he’s actually at eleven apps, but then backs off saying that he’d be fine reading Bloomberg in a browser. That leaves Echofon, a Twitter client, as the one 3rd party app David just can’t live without.

Well, WebOS, Windows Phone 7, Blackberry OS, Android, and even Meego all have the core apps covered as well as some sort or Twitter client. So, what is it that’s so magical about the iOS App Store? It’s that eleventh app.

Like David and many other iOS users, my tenth app is a Twitter client, Tweetbot, but just a few weeks ago that tenth app was Twitterrific and I’m actually hoping that with improved support for lists, Twitterrific will soon be my tenth app again. I do, however, have an eleventh app—Reeder. I could probably use Google Reader in a browser if I absolutely had to, but I REALLY don’t want to. Oh, and Black Pixel recently acquired Net News Wire, so my eleventh app might even be changing in the near future.

Nine core apps, a Twitter client, and a Google Reader client, surely that’s all a mobile platform needs to be competitive? Hardly. I shouldn’t have even conceded that a Twitter client is the tenth essential app for mobile platform success, many would argue it’s a Facebook client or something else entirely. But saying that a Google Reader client is essential to mobile platform success is laughable. To me, however, that eleventh app really is essential. I’d never switch to a mobile platform that didn’t have a fast, rock-solid Google Reader client.

Like most iOS users I could rattle off another 5-10 apps I use on a weekly, if not daily, basis and even that list is constantly changing as new apps come along and developers iterate on existing apps. Are those additional 5-10 apps essential and irreplaceable? Probably not, but my mobile computing experience would undoubtedly suffer without them.

If we took a poll of all iOS users and asked for a list of the eleven absolutely essential, can’t live without apps I bet we’d end up with at least a thousand different types of apps. A doctor might include a medical imaging app, a musician would likely include a multi-track recorder or some other musical sketch pad, an artist would include an actual sketch pad app, a builder might list an estimating app, a freelancer a time-tracking and invoicing app, and so on.

And that’s just app types. If the poll asked for the names of specific apps, I bet the list would head well into 5-figures and might even break 6-figures. That “builder” I mention above is a generalization of an entire category of professional iOS users and each individual in that group has different needs and expectations. The estimation app that’s essential to a residential builder might be completely useless to a commercial builder.

We can each argue convincingly that the apps we use daily are the essential apps that make a platform, but the truth is, each app is just a tree and the magic is in the forest.

Winning the Mobile Platform Race

Tue, 21 Jun 2011 12:36:00 -0500

I’m not much of a racing fan, so forgive me if the analogy breaks down rather quickly, but it struck me today that Apple’s disciplined approach to building its mobile platform looks somewhat like a well managed racing team. While competitors have been taking risks and cutting corners in an attempt to catch up, Apple has been meticulously preparing for the race ahead.

RIM bolted a spoiler and painted some racing stripes on a dated car with a winning pedigree. Without a major overhaul in recent memory, the car’s age and sustained abuse have become more and more apparent as competitors shift into second gear. What was a very strong lead early in the mobile platform race has been completely squandered. They did go out and buy another car, but it also needed an overhaul and they didn’t have the patience to finish before tossing it into the race. After an embarrassing crash and burn they’re still pushing ahead, but RIM needs much more than a quick pit stop at this point.

At just the right time, Palm abandoned its old, crufty car and built a new one from the ground up. The car looks amazing on the outside, but their new engine just hasn’t delivered. With time and lots of tweaks the engine should perform well, but Palm didn’t have the cash to stay in the race long enough to get the car firing on all cylinders. Just when things were looking most dire, HP swooped in and bought the car—racing team and all. HP’s cash, branding, distribution, and other strengths may well keep the car in the race, but it will likely take another year or two for the car itself to perform optimally and by then who know where the competition will be.

Microsoft initially didn’t understand that the rules of the race had fundamentally changed and expected the new competition to crash and burn. As others picked up speed Microsoft tried the racing stripes and spoiler approach but soon had the good sense to scrap their old clunker. The new car shows lots of promise, but started so far behind it’s going to take a herculean effort to catch up. With deep pockets, determination, and decades of platform building experience, Microsoft is just the sort of company able to mount a herculean effort, but I’m still not convinced they fully understand the race they’re now in.

Google looks to have a great car in the race, but they’re forgoing tire changes, routine maintenance, and timely fill ups to try and catch Apple. They’re making up ground and things look great from the grandstands, but it’s only a matter of time before a long pit stop or two kills their momentum.

The other analogies are a bit of a stretch, but I really do think we’re in the midst of Google’s first major pit stop. They admittedly rushed Honeycomb to market and are now having to fix things that would have best been done right the first time. They have a strong, well funded pit crew and may be able to get back in the race quickly, but the floundering of Honeycomb based tablets and slow growth in 3rd party tablet apps don’t bode well.

The next major pit stop for Android may be the elimination of physical buttons. Rumors have been floating around that the next Google phone (Nexus 4G?) wont have Android’s current physical buttons. If true, I’m very curious to see how the buttons are emulated and/or eliminated in software. Will all existing apps need to be updated? Will Ice Cream Sandwich automagically work on devices that have buttons just as well as those without? Will the transition confuse and frustrate users?

The Android team has proven itself able to iterate on features like Cut/Copy/Paste on the fly, but something as fundamental as removing the physical buttons may prove to be a slow, painful pitstop. And if not the physical buttons, who knows what other legacy implementation or hastily coded API may send the pit crew scrambling.

Google may well mitigate any major technical hurdles, but there’s still the threat that other corners they cut along the way will come back to haunt them. Oracle has presented a very strong case that Google “knowingly, directly and repeatedly infringed Oracle’s Java-related intellectual property”. It’s rather ironic that a dispute over “open” technologies may be Android’s biggest challenge.

Apple, on the other hand, had the luxury of defining this entire category and many of its fundamental concepts years before some other platforms had a single line of code written. Apple’s car then is a stripped down, painstakingly rebuilt piece of engineering art based on decades of hard-won race experience. They didn’t start with a clunker in OSX, but they still had enough of a lead on the competition to carefully consider the strengths and weaknesses of OSX and build iOS on a solid foundation.

iOS is by no means perfect, and Apple has and will continue to make pit stops along the way, but that’s actually my point—Apple’s disciplined approach to iterating on iOS and its OSX underpinnings allows them to take productive, well-timed pit stops while the competition continues to scramble and take on undue risk. As John Gruber put it: “This is how Apple rolls — steady, relentless, incremental progress.”

Twitter's Unfortunate PR #Fail

Tue, 14 Jun 2011 12:46:00 -0500

In light of Twitter’s amazing integration in iOS 5 and conversations I had with Twitter employees after their developer meetup, I’d like to present a “glass half full” reinterpretation of recent events.

“…developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.” -Ryan Sarver on Twitter Development Talk

Reinterpretation: We’re about to show you some really great stuff at WWDC, please don’t all go out and create new client apps just because we’ve made it easier to do so.

That’s oversimplifying the point, but I think that the forthcoming iOS integration may have played a part in the timing and tone of Ryan’s post. Twitter’s deep integration into iOS 5 is a game-changer. As MG Siegler put it in a post on TechCrunch: “Apple Just Handed Twitter The Keys To The iOS Kingdom.”

What most people took away from Ryan’s post was that Twitter was trying to take over the Twitter experience for monetization purposes and would be actively pushing 3rd party client developers away. In person, however, Ryan was rather effusive about TweetBot and other client apps. I may have been reading too much into things, but my takeaway was that Twitter has no intention of squashing existing Twitter apps built by lifestyle businesses (Twitterrific, TweetBot, etc).

Those who read the post as a threat to Uber Media and other VC backed startups were probably much closer to the mark. When Twitter bought Tweetie and released the official Twitter app in 2010 it was clear they intend to own the primary experience of Twitter. Even more so this year with the purchase of TweetDeck. Whether this is part of their long-term monetization strategy, or a just another way to “optimize for user benefit and create an awesome experience,” it’s clear that they have been and will continue to invest heavily in their own web and native apps.

I honestly think Twitter did developers a favor by laying things out so clearly. Building a Twitter client has been a sort of “hello world” project for many developers. But competing with existing apps, especially Twitter’s, is going to be a losing proposition for most. Much more so for those who take on debt or funding to do so.

I do, however, think the post came off rather aggressive and Twitter didn’t do a very good job taking back control of the message as the press and developers had a field day with the possible ramifications. Then this:

“Apps that you use to access your direct messages will ask for your permission again. By the middle of June, applications that do not need access to your direct messages will no longer have it, and you can continue to use these apps as usual.” -Twitter blog

Reinterpretation: We have lawyers now, and those lawyers are telling us direct messages will be a huge bag of legal hurt unless we deeply change our approach.

From congressmen to Twitter’s own employees, DM Fail has been an issue for Twitter since it’s inception. However, I don’t think the legal liability of direct messages (now apparently just messages) fully set in until the trickle of subpoenas turned into a flood in 2011. For legal reasons Twitter hasn’t been very open about the frequency and source of message subpoenas, but we all heard about the Wikileaks Subpoena and I get the impression new ones are coming in on a weekly, if not daily, basis.

Though many developers, myself included, took this as evidence that Twitter would be actively pushing away existing client apps, I now think this was a legal maneuver more than anything. Even the timing of it smacks of fear. Twitter initially gave developers just a few weeks to adapt their apps to the new authentication guidelines. By publicly acknowledging the fact that messages aren’t as private as most users assume, Twitter had to quickly close the window before a rogue app took advantage of the situation.

From the aforementioned TechCrunch article: “But Sarver says this is not about screwing over those apps. ‘It honestly has nothing to do with making it harder for them,’ he said. Instead, this authentication change is about protecting users.” If he were being completely honest, I think he’d have to mention something about protecting Twitter as well, but his point stands that the decision wasn’t made with the explicit intention of pushing away existing client apps.

“But now literally every iOS developer can be a Twitter developer. We think every app is going to benefit from instant personalization from this social layer, from gaming to utilities to enterprise apps.” -Ryan Sarver in an interview with All Things D

What’s unfortunate about Apple’s unveiling of Twitter integration at WWDC is that it came at a time when most developers in the iOS ecosystem were questioning Twitter’s relationship with developers. I’m not sure Twitter fully understood the backlash to their two major API related announcements in the Spring. iOS developers talk, and even if we didn’t, John Gruber and other members of the tech press made it clear what we should think about the situation.

So, the announcement at WWDC hit many of us like a big wet kiss from an estranged lover. What the hell? Is this for real? Can I trust you or will I just get burned again?

Some of us are trying to take a more optimistic view of things while others have been so badly burned it’s hard to give Twitter another chance. My hope is that in the months preceding the launch of iOS 5, Twitter will do a better job communicating with developers and better explain some of its prior comments. This is a huge opportunity for both Twitter and the iOS ecosystem, I’d hate to see bad PR stifle excitement and innovation.

Orchestrating Magic

Thu, 19 May 2011 17:19:00 -0500

I’ve really tried to like The Daily. I want ambitious projects to succeed on iOS. I want to see the delivery and consumption of news reinvented on the iPad. But I just don’t look forward to launching The Daily. It hasn’t become part of my daily reading routine.

A distaste for the editorial voice may be part of my hang-up, but I do actually enjoy many of the stories when I take the time to launch the app. However, that’s where I frequently get hung-up… taking the time to launch the app.

I’ve been hesitant to speak my mind on the app because I know what it feels like to work incredibly hard on something only to have it torn apart by armchair quarterbacks. But I just can’t hold back any longer.

Instead of ripping apart the hard work of my friends and colleagues, I’m going to offer a very specific solution for solving one of the biggest complaints about the app. I know a lot has been written about this, and I’m likely repeating things that were said months ago, but the app has now seen several updates that failed to properly address the issue, so I think it’s time to bring it up again.

When I launch an app on any computing platform, I do so with very specific intent—to read, to catch up on Twitter, to edit a photo, etc. Anything that comes between me and that intent quickly becomes frustrating, especially when I launch the app often. This has always been the case with computers, but it’s especially apparent on mobile devices such as the iPhone and iPad. I don’t want to wait for things to load, I don’t want to navigate through a messy jungle of options, I want to get right to doing whatever it is this particular app does well enough that I bother launching it in the first place (further reading on that subject: Tapworthy).

And guess what? Many iOS developers have gone to great lengths to satisfy that expectation. I remember launching Reeder for the first time on my iPhone and being absolutely shocked at how quickly my feeds loaded. My expectation had been set by other slow RSS apps which discouraged me from spending much time with them on my iPhone. Reeder changed that.

Now, you could argue that The Daily is a different type of app—people launch The Daily with the expectation of spending some serious time in the app. That may be true (though I doubt it is), but that intent doesn’t change the expectation set by the launch speed of most well built apps on the platform. The launch experience of The Daily is about as far as I’ve seen an app stray from that expectation.

I could go on and on about why this is bad and why it’s not acceptable even for a “newspaper app,” but I’ll cut right to the case and offer my thoughts on a potential solution. You may want to download and experience the app yourself if you haven’t already, or just read this: The Daily Wait.

Though many would argue with me here, I don’t think the launch animation is necessarily a bad thing. It’s a pleasant animation with a nice branded look and sound. Like the Twitterrific chirp, the sound will cue most people in the room as to what you’re up to, and I’d argue there’s even a pleasant psychological cue, kind of like the crinkle of a physical newspaper. There’s a certain sense of comfort in those subtle aspects of a routine. The key is to use that sequence as a kind of slight of hand, or “magic” if you will. The user gets a little brain treat while the app is racing to deliver content in the background.

When the app launches, the first process that should spin up isn’t the launch animation, but a request to deliver the current day’s front page and table of contents. Then, in a separate thread start the animation sequence. I’m not sure this is technically feasible, but if it is, here’s why I’d do it that way…

The carousel is a fun bit of UI (at least in theory, it’s still a bit laggy and jittery for my taste), but there’s just no way to quickly deliver enough content to make the carousel usable. The front page and table of contents, on the other hand, could likely be fully delivered in the 4-5 seconds from the launch of the app to the end of the launch animation. Sending users directly to the front page (or potentially a redesigned table of contents, but I wont get into that) will make it feel as though the app has been magically filled with content.

The user can start reading the front page and even swipe to the table of contents instantly. To make this work, the left to right swipe to go to the back of the issue should be permanently disabled. Just after launch it’s unlikely that the last page of the issue will have been delivered, and even if that could be prioritized, I’m just not sure swiping from the front cover to the back of the issue is the best interaction.

Next is the prioritization of content delivery. I have no idea if the backend of The Daily currently allows individual stories to be delivered out of order, but if not, I think re-working the backend to enable this should be a top priority. The millions of dollars spent on development and content creation has been significantly tarnished by the UX. Fixing it would likely be cost effective as evidenced by Flipboard: Flipboard Triples Daily Usage in Two Months After Speed Improvements

Anyhow, back to content delivery. The first stories that should be delivered are the ones highlighted on the front page. It’s likely that users will be taken by a headline and jump right to one of those stories. In the few seconds it takes to read the headlines the full content of those stories could likely be delivered (though large files like video and 360º images should probably be separated from the main text/photo content so as not to slow that process). If the user does tap on one of those headlines, BAM, they’re reading the story, no loading spinner, no delay, just carefully orchestrated magic.

If the user doesn’t tap on one of the main stories, there are a limited number of possible interactions, so the next step is to prioritize those options. If the user swipes left to right, the page moves with their finger, but bounces back when let go—indicating that they are at the beginning of the issue. If the user swipes right to left, they are taken to the table of contents which has already been delivered.

Another option is for the user to tap on one of the section headings. I’d guess that most people are at least somewhat habitual in their reading and will either go directly to the table of contents (which is already accounted for) or jump to their favorite section. It would be trivial for The Daily to start logging which section shortcut, if any, is tapped most often on a particular device. After launching the app a few times, it should be able to reasonably predict which direction the user will head and prioritize the delivery of that content.

If the user typically swipes to the table of contents then just keeps swiping into the stories as if they were reading a magazine cover to cover, just deliver the content linearly. If the user always jumps directly to the sports section, it’d be best to start delivering the sports section right after the front page and table of contents have been delivered (even before the stories on the main page). The prioritization of delivery will be slightly different for each user, but will feel like magic to them all.

There will be times when the user inevitably strays from their typical patterns or are on a slow connection that delays the delivery of their favorite content. In this case some sort of loading screen will be inevitable, but the app better damn sure drop everything it’s doing and load that particular page as quickly as possible.

I’ll bite my tongue on further critique of the carousel view as the intended primary mode of navigation, but I will say that the app should only prioritize the loading of those assets if the individual user actually navigates to it frequently. Either way, it just too data intensive to be the spot where people land when the app first loads.

I know first hand how hard it is to build great iOS apps and I hope I haven’t been overly negative in this critique. The Daily is one of the most ambitious apps to have been created on this platform and though I’m quibbling about a few things I see as flaws, shipping such a complex app was, I’m sure, a superhuman feat. I’d love to see it reach its full potential.

Bass Ackwards

Tue, 28 Sep 2010 00:42:31 -0500

The knee jerk reactions of our government in the wake of the 2008 “mortagage meltdown” have screwed me over in just about every way possible.

They start a first time home buyer tax credit, but I don’t qualify because I responsibly bought a condo that I could afford in 2006 (a year before Liz and I got married). Then they start a program for move-up buyers, exactly what Liz and I were hoping to do, but the condo purchase was too recent for us to qualify.

Fine, we don’t need a damned government handout (even though it’s been artificially propping up the market), I bought a great condo in thriving San Marcos (a college town with a growing student body and low vacancy rates) and poured my blood, sweat, and tears (and $10k) into remodeling it. Surely we had built some good equity and could use it as a downpayment on a home for our growing family.

So, we tried to sell the condo. We received several offers before the condo was even listed in the local MLS and accepted a full price offer within days. Awesome, we’d have more than enough money for a downpayment to build a home on an amazing infill lot we found just 1.5 miles from downtown.

Just kidding… the condo didn’t appraise and the sale fell apart just days AFTER we had moved into a temporary apartment.

Turns out, appraisers are scared. In the wake of the mortgage meltdown, appraisers were one of the groups [rightly] singled out for being willing co-conspriators in the whole mess. So they’ve been handed all sorts of new, hastily drafted regulations and live in fear of loosing their license and therefore their livelihood.

But at the end of the day, the job of an appraiser is to determine fair market value for a property. And what’s the most definitive measure of the market value of something? Multiple willing and able buyers, which we had! But by the time everything was sorted out, the buyers had moved on. The parents and investors who buy condos in San Marcos want to have everything lined up with ample time for students to move in before school starts in late August.

OK, fine… we don’t need to sell the damned condo, we’ll become landlords and scrape together the downpayment on our own. Well, it took us 2 months of paying rent at the apartment and mortgage on the vacant condo before we found a tenant. With the bleeding stopped and the condo now generating a positive cash flow, we turned our focus back on building a home.

Guess what? It didn’t appraise.

So, you know how our government is throwing all sorts of money at energy efficiency, alternative energy, and the like, while also trying to stimulate the housing market through giveaways and ridiculously low interest rates? Well, it’s all bass ackwards—as are most things in Washington. Turns out, the same scared appraisers who couldn’t appropriately appraise my condo also can’t (or maybe just don’t) give much value to improvements in energy efficiency and quality of construction.

In the several month process of working with our builder to plan the home, we did tons of research and made most decisions based on value and long term durability. That meant we chose mid grade (not luxury brands like Viking and Kohler) fixtures, appliances, and things like strand woven bamboo flooring that were well regarded by Consumer Reports and the like.

We also decided that increasing the energy efficiency of our home was the most responsible and long term cost effective thing we could do (and would be cost prohibitively expensive to change after the home was built). So, we went with self sealing Zip System sheathing (with built in radiant barrier), hardie board siding, foam insulation in the attic, Optima blown-in insulation in the exterior walls, a 16 SEER AC (2 stage, zoned system with variable speed fan), low-e vinyl windows, etc.

But, the appraiser compared our construction plans with existing, poorly constructed tract homes that cost their owners twice as much to heat and cool while falling apart before their very eyes.

So, what have I learned through all of this?

1. Don’t buy anything of consequence unless the government is handing out money to do so, or somehow subsidizes the construction, manufacturing, or other aspect of the cost (like a subsidy in the cost of borrowing money). Depending on what you plan to buy, this will likely happen in 10-20 year cycles, but for many things it’s perpetual.

2. Don’t count your chickens before they hatch. You just never know when some random government regulation will wipe out those nest eggs, artificially depress the market for chickens, or tax the sale of chickens such that you no longer profit from the chickens having hatched.

3. Don’t bother doing anything of consequence if there are government regulations involved. If you build it, they will come and tear it down for not meeting some obscure regulation written by some random lobbyist.

So, instead of working on my business today as I should have been (you know, creating value and helping to grow the economy), I spent most of the day writing a letter to an appraiser practically begging him (while also providing as much solid documentation as possible) to increase the appraised value so that we can build our home.

Wish me luck, I’m gonna need it.

The App State of Mind

Sat, 28 Aug 2010 16:25:00 -0500

The other day I was chatting with my brothers about travel plans and trying to figure out if I could plan my trip to visit them around the opening of football season. To figure that out, we needed to know the fall schedule of the Cowboys and the University of Texas. Rather than launching Safari and Googling “Cowboys 2010 schedule” my first impulse was to go to the App Store and search for schedule apps.

I didn’t even think to download a general sports app like SportsTap, my first impulse was to search for an individual schedule app for each team. And guess what? I found them almost instantly and they now live in a “Sports” folder on the Home Screen of my iPhone.

Now, every time I want to schedule a trip to the Tap Room with friends, or let my wife know whether I’ll be available a particular Sunday afternoon, I’ll launch a single app and instantly find the content I need. And at the end of the football season I’ll just delete them.

Sure I could bookmark the schedules in Mobile Safari, or favorite the teams in an app like SportsTap, but doing so not only takes a lot more work to setup, it adds several mental and physical steps to accessing the content I want.

My Mobile Safari bookmarks are hopelessly cluttered. Depending on the most recent state, I might have to traverse up then back down several levels of folders to find the bookmark. Doing a new Google search each time would probably be faster than tracking down the bookmark (and that’s undoubtedly a factor in Google’s current and future mobile strategies. See: Mobile Apps: The Ultimate Threat to Search Engines?).

SportsTap could provide better UI for quickly viewing team schedules, but it’s optimized for what’s currently happening throughout the sports world, not looking weeks ahead. And that’s the thing about apps, each one went through some sort of design process that defined what content was relevant to the app and how users might want to view and interact with that content on a mobile device.

A web browser provides the opportunity for anyone to find just about any content ever created by man. Apps provide me an immediate and customized view of the content I care about on the web.

Desktop web browsers have and will continue to offer better and better ways to find, view, and act on content via bookmarks, keyboard shortcuts, plugins, and interesting new features like Panorama in Firefox 4, but trying to shoehorn the complexity and extensibility of a modern desktop web browser into a mobile platform would be challenging. And even if it were possible, UX would undoubtedly suffer.

It will be interesting to see user reaction to and adoption of Goole’s Chrome OS when it launches later this year. But Chrome OS isn’t a mobile browser, it’s a mobile OS build around a browser. “The user interface is minimal to stay out of your way, and most of the user experience takes place on the web.” Notice the use of the word “most”.

Now don’t get me wrong, the mobile browser and other apps that offer broad access to web content obviously serve a purpose in the mobile app ecosystem, but I’ve found myself using Mobile Safari less and less as I find apps that curate the bits of the web I care to access. And I’m not the only one.

iPhone 4 Antenna WIN!

Mon, 16 Aug 2010 19:47:04 -0500

My wife and I were out in the boondocks picking up my mother-in-law from a local day spa. I called my mother-in-law with my iPhone 4 (to her iPhone 4) to let her know we had arrived. The call went through, but we could hardly hear each other. With all the hoopla surrounding the iPhone 4 antenna, I decided to take a look at my wife’s iPhone 3GS. Sure enough, no signal at all. The spa staff were surprised that my mother-in-law was able to even make a call.

I go back and forth defending AT&T at times, cursing them others. Their coverage is great in my area and I sympathize with challenges they’ve faced maintaining and expanding their network, but at the end of the day AT&T is the real reason for “antennagate.” Under the scrutiny of experts, and in my own personal experience, the iPhone 4 antenna is one of the best ever built. If people weren’t already having so many issues with AT&T coverage, they wouldn’t have been scrutinizing the reception of the iPhone 4 and a bit of attenuation certainly wouldn’t have made the news.

Below is my wife’s iPhone 3GS (on the right) and my mother-in-law’s iPhone 4 (on the left). Taken with my iPhone 4.

Sparkle for iOS Beta Testing?

Tue, 10 Aug 2010 17:11:00 -0500

I’m not sure this would even work, but I wanted to post the idea incase anyone smarter than me (and with actual coding experience) wants to run with it.

After reading this post (by @iamamused via @chockenberry) yesterday, I was brainstorming ways to further streamline beta distribution.

Here’s the basic concept from Jeffrey’s post:

With the new iPhone iOS 4, you can distribute apps wirelessly without iTunes intervention. You still need to collect the appropriate devices id’s and create the appropriate provisioning profiles but if you already have those sending out files is easy.

…

Along with the generated .plist and the .ipa files, you’ll need the provisioning profile and a simple index file…

With these all uploaded to your server all you need to do is point people at the index file and they can select the links to install the provisioning profile and app directly from mobile safari on their iOS devices. A much nicer experience compared to installing through the iTunes sync process.

Using that workflow will make distributing beta’s much easier, but you still have to email beta testers every time there’s a new build and they have to follow the link on their device or bookmark the address and remember to check periodically.

What would be even better is if users were notified of an update via a push notification that would launch Safari (or Webkit within the app) and automatically initiate the download of the new version.

Seems as though Apple would be the perfect one to pull this off, but that’s a bit unlikely (enhancement request for Xcode 5?). UrbanAirship or another similar existing service would be the next best host (since they already have push notification servers and an API for setting up push notifications within an app) and could charge a nominal fee or even host it for free to promote their services to the iOS developer community. This could also be tackled by a group of developers and open sourced, but then each developer would have to set up their own server. A community server could be created, but that would involve a lot of trust and/or cost sharing.

There’s also the matter of security. It would be easiest to post the downloads to obfuscated URLs, but some projects might require something a bit more secure. A password could be set up for the initial download then some sort of app/server handshake for updates, but that seems like a lot more work. In practice, the only real risk is that a competitor or other random developer would download and re-sign the app. They could then run it and even try to reverse engineer some great new feature, but they couldn’t submit it to the app store or anything like that. If a download URL was made public, random users wouldn’t be able to install the app since their UDID wouldn’t be in the provisioning profile.

There may be some huge caveats I’m missing, but I thought the idea was worth sharing. Beta testing iOS apps is definitely a hassle for both developer and testers. Anything that can be done to smooth the process would be time well spent.

I don’t have the time or expertise to head this up, but if anyone is interested let me know and I’ll update this post and tweet about it.

The Magic Trackpad is Just a Better Mouse

Thu, 29 Jul 2010 09:54:00 -0500

For all the hyperbole about the mouse being dead, no one has called out the Magic Trackpad for being what it really is—just a better mouse. Though it is touch based and enables certain gestures, the power of a real touch based OS like iOS is in direct manipulation via a touch screen. Here’s how I put it in my chapter on iOS UI in iPhone User Interface Design Projects:

“One of the keys to creating great UI on the iPhone is taking a step back and thinking a bit about how users actually interact with the iPhone—with their fingers. Yes, that’s incredibly obvious, but something so obvious generally caries significance that few people take the time to explore.

The finger is an incredibly efficient pointing device, far more efficient than the mouse. When the mouse was first introduced, it revolutionized human interaction with computers. I would argue that Apple’s multitouch interface [on a touch screen] will, in time, prove to be even more revolutionary.

A mouse [and the mouse-like Magic Trackpad] manifests an unnatural disconnect between the motion of the user’s hand and the action on screen. Most people these days have used a computer enough to be somewhat accustomed to the mouse, but if you watch someone use a computer for the first time, you’ll see a definite learning curve to using a mouse! I’ve even noticed a bit of a learning curve when using a new mouse or tracking settings with which I’m unfamiliar.

But the human finger, that’s something just about every human is quite accustomed to using. We’ve learned since birth how to control our fingers with an amazing level of precision and speed. Imagine if you were to attempt playing the piano with a mouse. Your tune would be choppy and unmusical at best. A touch-screen piano, however, would be playable, even if it didn’t match a real piano for feel and accuracy. The more I thought about the finger as a means of interaction the more intrigued I was by how drastic the shift was from the mouse to multitouch [on a touch screen]. That’s when it finally hit me. Taps are cheap!

If the appropriate action is obvious to the user, the time actually required for that user to tap the proper spot on the screen is miniscule. Confusion about where to tap wastes far more time than an extra tap.

Again, this conclusion may seem quite obvious. After all, ambiguity has been a challenge in all human computer interfaces, and reducing ambiguity has been one of the pillars of good interface design. But the iPhone is the first graphical computer interface where the speed and precision of the pointing device makes the physical action of pointing almost irrelevant when considering the time it takes to accomplish a specific result. Let that sink in for a minute—taps are cheap.”

Using a mouse (and mouse-like Magic Trackpad) is expensive. Moving the cursor around a screen and precisely aligning it with buttons and performing other actions takes significant time and skill compared to direct manipulation with fingers on a touch screen. The gestures of the Magic Trackpad do make certain actions faster and more natural, but it’s still just indirect manipulation of objects on a remote screen.

To better understand what I’m saying, think about a Magic Trackpad piano where different parts of the trackpad triggered different keys. Sure you could use more fingers and eventually do better than a mouse based piano, but there would be a HUGE learning curve as you memorized the position and spacing of the keys on the blank surface. And if the piano keys were just buttons on a computer screen, the Magic Trackpad gives no advantage over a traditional mouse, you’d still be moving a single cursor around a remote screen.

The Magic Trackpad is a small evolutionary step in human computer interaction, touch screen multitouch is revolutionary and will live on long after the mouse really dies.