[ERR:SIGNAL INTERRU...

by Thomas Brady in ,


So, uh, yeah...

I seem to have done that oh-so popular thing where you abandon your blog and only tweet from time to time instead of having fully-formed thoughts.

Well, this didn't fit into a tweet, so, I'm back! I hope.

If you ever, say, write a sketch to an Arduino Leonardo that randomly sends keyboard and mouse input to a host computer, for the purpose, let's say, of making that person think that their keyboard, mouse and/or computer are malfunctioning, you might later find out that if you didn't wrap the HID-mode stuff in your Arduino sketch in some sort of enable/disable functionality that it's now nearly impossible to write new sketches to the Leonardo.

If you do find yourself in such a pickle, and you happen to have an AVR Dragon (or similar), here's the way forward: install avrdude (brew install avrdude if you're on a real computer) if you haven't already and issue a commmand similar to this one (I leave it to your capable hands to change what needs to be changed):

avrdude -v -patmega32u4 -cdragon_isp -Pusb -Uflash:w:/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/bootloaders/caterina/Leonardo-prod-firmware-2012-12-10.hex:i -Ulock:w:0x2F:m

"Draw a sky blue brain exploding"

by Thomas Brady in ,


I just don't even know how to put words to this one...

Natural language... programming?

Somehwere, Bret Victor is either sitting back looking proudly at something he secretly worked on, or he's weeping at its beauty. I guess both could be true.

If this is half as good as this demo video, I can't see how this won't upend the world of programming, the world of education... hell... the world.


The Electric Imp-spacebrew-nod-uino

by Thomas Brady in , ,


I've been dying, ever since a couple of the core contributors visited frog Austin a little over a year ago, to play with Spacebrew, and in yet another skunkworks bit of hacking at work recently, I finally got to.

We, the secret snooping society, want to fill the Austin studio with sensors of varying type and scope, and we wanted it to be very easy for people, once they've found us out, to play along. This is a perfect fit for Spacebrew, which aims to make interactive spaces, exposing data via a simple API. One rig can be set up to be a data "publisher," and, without permission or help of any kind, anybody that can reach that server via a network/Internet connection can write a "subscriber" that can do whatever it likes with that data (usually, visualizing it).

As I was building this out (our project used a simple proximity sensor to track motion near the elevator, as a proxy to counting elevator trips), I realized that we also wanted historical data. Spacebrew is a super convenient way to provide real-time data, but it doesn't have any affordances for persisting data. So, I built a Node.js server that both acted as the Spacebrew publisher, via the javascript API, and write data to a mongoDB.

I also finally got to play with the Electric Imp, a nifty little WiFi-enabler.

You can read all about it, and get all the source code, on github, but here's a short walkthrough of how it works (from the "What does it do?" section of the project's README):

  1. Use an Arduino to power a proximity sensor as a motion detector, and, when it sees motion, send a command over serial to an
  2. Electric Imp, which throws an event over the Internet to
  3. Electric Imp's cloud service, which we've configured to exposes an API that rolls up and reports these events upon HTTP GET, which
  4. Our Node.js server polls, and upon finding new events, acts by both
  5. Writing a record to a mongoDB and
  6. Forwarding the event to
  7. Spacebrew

Up to this point we have built a Spacebrew publisher, that happens to also persist data (something not typically included in Spacebrew).

We have also included an example Spacebrew subscriber, in the form of a web app that uses the Spacebrew javascript API in order to increment a count of movements observed. Our web app first polls our Node app to get a historical count for the day, and the timestamp of that last movement. The real-time Spacebrew updates then increment this historical count, and reset the last-movement-seen clock.

IMG_2473.jpg
Source: https://github.com/thomasqbrady/TheElectri...

Øredev 2013

by Thomas Brady in , , ,


Update

I am mortified. My speaker notes included credits for Gloria Wu for visual design in the first application show in the video below (the TouchTunes SxSW visualization), and Michael McDaniel for visual design on the subsequent data visualization. I only realized after watching this video that I didn't actually mention those notes. Profuse apologies to you both.


A much longer post is due, and will come soon, but, hopefully suffice it to say for now that it's been an incredible honor and pleasure to have been invited to participate in Øredev 2013. I did two talks, one technical talk on Ember JS, which I think may be a little too technical to share here but was a sneak peek at the book Jesse Cravens and I are releasing soon with O'Reilly, and one personal talk on the power of story to unite designers and developers, which you can watch below. Thank you (Tack!) Øredev. Thank you Linda, my wife, for making this possible, for picking up all my slack all those nights while I worked on these talks, for being a single parent for a week so I could be in Sweden. For being excited for me, so selflessly, when it meant so much cost to you .

Thank you, thank you, thank you.


I've been busy...

by Thomas Brady in , , , ,


There's been a lot going on at home, at work and in my third place. I'm excited to finally get a chance, and in some cases the clearance, to talk about some of what I've been up to.

Wearables

A couple months ago I got really hot and bothered about wearable tech. I saw projects like the Pebble Watch and even got a Jawbone UP, but I didn't see the total package in any of these options. I wanted a watch that would vibrate to alert me that I was getting call or text message, and maybe show me caller ID information about the call. At the time, there wasn't a device for sale that I could find that did all—or in some cases just—those things.

So I decided to build my own.

I got an Arduino Fio, a replacement iPod battery (they didn't carry iPod mini replacement batteries at the time, but that looks like a better option), a BlueGiga WT32-based bluetooth module from an off-brand, much more affordable source and a real time clock module, which I had no idea I'd need at the start of the project. That last bit required different voltage than I was using everywhere else (needed 5V, but all I had was 3.3V), so my rigged setup required a AA battery, too, for a good-enough boost to 4.8-ishV (couldn't seem to find a voltage booster that would be small enough/cheap enough). I intended to fashion a bezel with this hand-moldable plastic from Inventables.

The best-laid plans...

Have nothing to do with this story. I spent hours. Hours. HOURS on this project. I don't regret it in the least. Every step was new information. I'd tinkered with Arduinos a bit, but I hadn't encountered one, yet, that required special hardware just to be able to connect to a computer to be programmed (it's called an FTDI adapter—something that can connect to your computer via USB and speak computer languages on one end, and connect via serial connection on the other end, and speak in micro-controller languages. They're built into the flagship Arduinos (Uno, Leonardo, etc.).

Oh, and a .96" OLED screen. It felt unreal the first time I got that thing going. Hours of soldering, writing code, watching video tutorials (available at that link for the screen itself) and testing, and it was just strange to see something I'd made rendered on that tiny little OLED screen. I've been writing software for most of my life, and every new platform is a bit of a thrill. This, for some strange reason, was one of the bigger thrills. I think it's because it felt like a realm in to which I shouldn't be able to reach—like I was manufacturing my own consumer electronics. This less-than-$100 pile of Radio Shack-available parts didn't exist in this form 10 years ago. This was a new frontier.

In the end I learned that it's not as easy as pulling a bunch of Radio Shack parts off the shelf and beating them up with your soldering iron. The package never got small enough that I would actually be willing to wear it. But it did work, which was a pretty satisfying end to what could have been a downer of a project. Here's the working code at Github. With compatible hardware, that'll get you a 5-minute-increments clock (if memory serves), and, when paired with a bluetooth phone, a vibrating alert when an incoming call is received, as well as caller ID info.

Sadly, I fried the Fio when trying to clean up my late-night soldering job, and I only just realized I never got photos or video of the working rig. : (

Research on Rails

After a few weeks of not having a side project, I got the bug to a) learn Ruby on Rails and b) build a research tool I'd been kicking around for a while. When you design products for clients, they get pretty picky about where you keep your notes. It's become a tradition at frog to build internal-use-only clones of services like Dropbox, Evernote and the like, because, well, we're jealous. We can't store our client's data outside our firewall, so we have to build our own toys.

For everything but client work, you can pry Evernote from my cold, dead hands, so I set out to build something similar for client work. I've long been interested in collaborative workspaces, so I also took more than a couple cues from Pinterest. I call it Catcher. It's my first Ruby on Rails app, and it's currently in use by a couple dozen frogs. I couldn't be happier. Here's a demo:

One feature not shown there is the ability to email items to an internal-only email address, which get scraped and added to your list, including attached or embedded images, URLS and keword tags that were in the subject line. I was trying to make sure that this was a tool that could serve alongside the ways that we frogs currently solve this problem, one of which is by sending emails. Of course, this is better than those emails, because in six months when you go looking for that thing you know you got from somebody on some project about something kinda like… Well, good luck searching your inbox. The email you're looking for probably has a ssubject line that reads something like, "Exactly like this:" and the body of the email is just an image or a URL. If you added it to Catcher, which you could do just by forwarding the email, you might have taken a moment to add some keyword tags. Even if you didn't do that—shame on you—you stand a better chance picking out the image or a big block quote on the infinitely scrolling "Home Plate."

At least that's the idea.

You might recognize a bit of Pinterest in there, too. At frog, and other agencies where I've worked, it's another common practice to have big pegboards up around team areas, where you can print and pin project-related artifacts. These are anything from wireframes to Gantt charts, but most of the time they're inspiration bits—mood-boards, funny pictures, mockups and just plain pretty pictures. I wanted that kind of content to have a home in Catcher, too. A forthcoming feature will add a filter that will let you see just "inspiration" items, or just "bookmarks," etc.

I spent hours on this project, too, enjoying every minute. The vast majority of them were outside work hours. Note to employers: I ended up building something very similar to this for a client in record time because I had just done it for this side project. And screen captures of the tool have ended up in some pitch decks, too. Free time, in the hands of the right people, can be a very powerful thing.

I'll spend a lot more, hours on this, too. Looks like someone in China just started using it, even though I've tried to keep it under wraps while it's in "beta."

SxSW 2013

frog Austin has been an integral part of SxSW for over a decade now, in that we have thrown the kickoff party for all but a couple years of the existence of the conference. Each year got a little crazier. Apparently the party was broken up by the fire department one year.

It's a chance for a bunch of frogs to get together in a warehouse with power tools, buckets of electronics parts, loud music and the goal of making crazy-cool attractions for a party full of thousands of geeks.

Sadly, I got tricked (I kid) into doing something for the party that didn't involve any of that. I ended up working a good number of hours alone at coffee shops and at my dining room table, at all hours of the night. It sure paid off, though. The attraction I got to work on was an experiment in crowdsourced DJing. We teamed up(again) with TouchTunes(again—we partnered with them to design their latest hardware and software), makers of touch-powered digital jukeboxes found in thousands of bars and restaurants. They brought 20 of their jukeboxes (an intimidating sight by daylight, and the closest thing I've experienced to being a moth near a fluorescent light at night) and added the event space as a venue in their smartphone app. This made it possible for any or all 6,000-ish party-goers we had that night to cast a vote for what would be played by walking up to the Tron-tastic jukeboxes or whipping out their smartphones. And they did. We had nearly 10,000 votes, playing over forty songs chosen by the crowd all night.

I got to build a very-large-screen experience that visualized all this activity real-time. A projected screen near the jukeboxes showed, on rotation, something akin to a slide presentation wherein the slide were alive with data. I got to do a lot of the design of the experience, as well, at the information architecture/wireframe stage. Thankfully I got to work with a visual designer to bring those to vivid, neon life—thanks, Gloria! I'm no data-viz-whiz, but I think it turned out all right. I tried to make sure to balance the exposure the votes got. If we only showed you which songs were in the top 5, for instance, those songs would be assured their top 5 spot. If you're standing there and you look up at that big screen and see a song title, you're likely to say, "Oh, I love that song!" and vote for it. So I tried to expose the underdogs. There was a screen that only showed songs that had recently (within the last 30 seconds) received their first vote. Another show every song that had received any votes at all as various sized squares—the more votes the bigger. At regular intervals a random song from that collection was chosen and spotlighted, showing you the artist's name and the song's title.

Lots of people, myself included, gamed the system. You could, if you so chose, stand at the jukebox and choose the same song again and again, if you didn't mind looking a little, obsessed. Early in the evening, this was fairly easy to do. Into the third hour, you'd have to vote hundreds of times this way to break the top 10. I single-handedly chose the second song of the night. I was determined to hear some Tom Waits, and we did. I was kind and played "Jockey Full of Bourbon" and not "Earth Died Screaming" or "Pony."

There was also a slide that showed a real-time 10-band EQ graph of the sound of the event. A mic was connected to the server running the event, which captured not only the music, but crowd noise.

Here's a video from our marketing department covering the event, with a section—starting at 2:06 on the crowdsourced DJ attraction, and some shots of the part I worked on starting at 2:22:

The Aftermath... math

I spent a lot of time building and testing and testing and rebuilding and testing and... You get the idea. The app was pulling voting data from Heroku, synchronizing that data with a local SQLite database, and then going through the same hoops to get song metadata. We had a test server and a production server. For some reason, every time we tested with the production server everything crapped out. Up to just a couple hours before the event. I was sitting in the rain at the outdoor venue re-writing whole chunks of the application. In the end, it worked. Perfectly. I started the app, and only watched—never had to touch—the admin console I'd built for it, except to call up the "Bar's closing/Last call" slide.

I was as tired as I've been in a long time that day after the event, having been up very late for a couple weeks working on this code, up early the day of the event rebuilding signage girders and setting up PA equipment, and up late again that night tearing things down. But I was sitting there the next afternoon with a database full of 10,000 votes cast by thousands of people, and 250,000 pixels worth of graphed waveforms recorded at the party. I had to see what was in there. I wanted everyone to see what was in there. So I set out to learn some more HTML5 and some d3, and the next thing I knew I had another side project. A couple weeks later, with some much-needed design help from fellow frogs Michael "Gondola" McDaniel and Mike Herdzina, this popped out:

 A screenshot of the SxSW Opening Party Data Visualization

A screenshot of the SxSW Opening Party Data Visualization

The coolest/craziest/scariest part is that this thing has been published. First by Core 77, in part three of their coverage of the crowdsourced DJ thing from SxSW itself (crazy just doubled, Inception-style), and soon, as I understand it, on Design Mind.

Until very recently, it had been about five or six years since the last time I had actually shipped an HTML application, one where cross-browser use actually had to be supported. The web has change so much, and so little in that time. There are myriad little pains in developing for the web, but the ubiquity of software that can make use of your work is intoxicating. And making use of a good web browser to lay out text or deliver content to a screen-reader is like riding downhill on a bicycle. Hardware-agnosticism in the form of Java and similar technologies is, to me, a myth. They try to tell you, "We can make it easy to write your software once, and run it anywhere." Web development sounds, on first blush, like it's making the same promise. The difference, though, is that no one ever said it would be easy. You'll be able to run your software in lots of places, but you're still on the line to support all the thousands of little differences between hardware, software and user needs your software will find itself surrounded by. To me that's a lot more realistic. Honest.

Thanks

I'm coming up on my first anniversary at frog. I had a great start in my technology career at a little eLearning house called Enspire Learning. I was hired as a technical writer, but they trusted me when I said I could learn to be a developer, and, what's more, they equipped me. They surrounded me with smart people who cared about their craft. They gave me time to learn on the job. They cultivated an environment where people shared their knowledge (with lunch-and-learns and even after-hours classes offered by colleagues). After lots of false-starts, Enspire was where I really became a developer. I outgrew the work in a few years, but for the next several years I felt like I would never find that environment again. I feel I've finally found it in frog. I'm very happy to be here.

Special thanks to Jared Ficklin, who owns the frog SxSW engagement, for involving me, and giving me such a fun bit of the work to tackle.


Karma - the "just works" pay-as-you-go mobile hotspot

by Thomas Brady in ,


My mom has one of those Clear hotspots. You know the one. It comes with any of a number of logos on it. Looks like a tiny Apple TV with three green lights on the front—if you're very lucky. It's usually on a table in front of someone who's doing the Jerry Seinfeld posture—the one that says "Who's the genius who…"—and cursing profusely.

Enter Karma. I heard about them when someone—sadly, I don't remember who—tweeted about having received there's around Christmas. I did a bunch of reading, and, despite being incredibly wary of the hardware, more on that in a second, I placed an order.

The Karma is the very same hardware, by the looks of it, as that nefarious Clear Spot, though in Storm Trooper white to the Clear/Sprint/et al's Darth Vader black. The big—no huge—difference is the software. You don't do any configuring with the Karma. With the spot, or similar, there are lots of hoops to jump through, typically, to secure the modem—setting your own encryptiong method, password, etc. With the Karma, you simply login with your Facebook credentials. As much as I dislike Facebook, this makes for a superbly easy, works-right-out-of-the-box experience. They're so sure of it, and so proud, that this is the instruction card that comes in the box:

 Karma instruction card

Karma instruction card

That's pretty much it. There's more on the back, but with just that, you'll suddenly see a WiFi hotspot in range called, "Thomas's Karma," if your Facebook account is for a person whose first name is Thomas. It's already secured. Much like a coffee shop WiFi setup, you are greeted by a web page when you attempt to connect to the Karma, where you are asked to log in via Facebook.

This is all just icing, though. Even if the zero-configuration experience weren't a part of this offering, I would have likely ordered the Karma anyway because of the business model/pricing structure. Your Karma serves up pay-as-you-go data. Fifteen dollars gets you a gigabyte of data. No expiration dates. Dead simple, and fairly priced.

If you're paying attention, you may be asking yourself, "Wait a minute… what happend if some freeloader with a Facebook account logs in to the modem?" That's another interesting thing about their pricing/model. If this happens, that person is invited to use or create their own account with Karma, and purchase their own data at $15/GB. They're using your infrastructure to get there, but they're not using your data plan. And for the effort of lugging around and charging the modem you're both connected by, you get 100 MB added to your account when they connect.

So far the Karma has performed beautifully. I get great speeds (usually around 8 Mb/second), the battery lasts longer than I've ever needed so far, and I'm quite happy with the pricing.


Orchestrating the sounds of your interface

by Thomas Brady in ,


I'm a sucker for big-picture pieces like this, solutions to the problem of creating consistent, yet distinct experiences across a platform. Here we have GE creating a "sound palette" from which to pluck bleeps, blorps and chimes for distinct interactions with microwaves, refrigerators, stovetops, etc. Via Small Surfaces.


Apparently Jony Ive isn't busy enough...

by Thomas Brady in , ,


This must be a first. PetaPixel reports that Ive will be designing a very limited edition Leica camera.

I don't recall Apple every loaning out key team-members like this. Ever.

This is for a charity event, and it does involve Bono, so all of the "just this one time" flags are flying, but, this is very unusual.

If I were paranoid, I'd say Ive was looking for greener pastures. There was kerfuffle last year that Ive really wanted to leave Apple and move back home to the UK, so that his children could go to school there. Of course, this May, when he was knighted, he said he's staying put.

Apple doesn't let stuff like this happen without thinking it through. Friends who work there have reported that they can't speak at any public event as an Apple employee without clearance from marketing. This is calculated. More than likely, this is Apple sacrificing a bit of Ive's time for a good cause, and a tax write-off.

Quite possibly, this is Apple and Ive saying to the rest of the industry, "well, we've lapped you enough times we're going to take a break now."


Apple and The CXO

by Thomas Brady in , , , , ,


Previously, on Bash Modern Quantity…

Coming up on a year ago, I asked the Internet "What's missing from Apple's Org Chart?". My premise went…

  1. Apple's biggest advantage over its competitors is its superior user experience,
  2. this superior user experience is the result of having a strong UX team at Apple and that
  3. a key to maintaining or growing this team and its strength would be strong, empowered leadership.

After lots of digging I could only find evidence of a director-level position within the UX discipline at Apple (also here). No vice presidents. No senior vice presidents. Nobody with a C in their title. It seemed obvious enough that Steve Jobs would have seen himself as the C-level representation of UX concerns at Apple, but it seemed equally obvious—to me, at least—that Tim Cook is not similarly capable of wearing that hat. It seemed to me it was time to appoint a high-level head of user experience design at Apple.

This week, on Twitter…

I read, via Crystal Ehrlich, Reuben Steiger's article, "Who's the Chief Experience Officer?", in which he described the need for such high-level representation thusly,

The crux of the problem is that building great experiences is everyone’s responsibility and nobody’s job.

If anyone was to have a CXO, wouldn't it be Apple?

Well, I think they do have a CXO, of sorts, and I'll tell you who it is. Well, actually, I'll let Steve Jobs tell you what he told Fast Company:

Think of it this way. If you look at your own body, your cells are specialized, but every single one of them has the master plan for the whole body. We think our company will be the best possible company if every single person working here understands the whole master plan and can use that as a yardstick to make decisions against. We think a lot of little and medium and big decisions will be made better if all our people know that.

John Siracusa, if he's reading this, just thought the phrase, "hippie-dippy," and who can blame him? This sounds like idealist, weirdo, airy Steve Jobs rambling, doesn't it? But here's the science behind it.

Business science.

James Allworth thinks "Steve Jobs Solved The Innovator's Dilemma." I think he's right. And I think this is a big part of how he did it.

In case you aren't familiar with The Innovator's Dilemma [yes, that's a dirty, dirty affiliate link], it was the 1997 Harvard Business School Publishing release by Clayton Christensen wherein he coined the term "disruptive innovation." Disruption theory is beyond[me and] the scope of this post, but it describes the vicious cycle in which what we would call a startup can become a big, slow-moving beast of a corporation, and can, therefore, stagnate, stop innovating, and fail to thrive while another startup comes along and steals its market. In short, it's not enough to come up with an incredible product. You have to keep coming up with incredible products, even if the new ones threaten sales of your old ones, or even your current, successful products. It means taking some risks, getting into markets you don't have any proven ground in and not holding onto anything too tightly. It's being able to change what your company is and does when the market changes, or, preferably, before the market changes. Like turning "Apple Computer," manufacturers of Macintosh personal computers into "Apple," the consumer electronics and media company.

I'll leave it to the Harvard guys'n'gals to go any further with that line of thought, but there's a nugget within there that's germane to our topic (no, I haven't forgotten what it was). How do you keep your finger so close to the pulse of the market that you know how and when to change what your company is and does? This is where the Venn diagram of "User Experience Design" and "Business Model Innovation" overlap, and I'm not the only one who thinks so.

In "The hiring and firing of milkshakes and candy bars," episode 19 of Horace Dediu and Dan Benjamin's "The Critical Path," Dediu describes his own independent arrival at Christensen's theoretical solution to the innovator's dilemma, while observing user experience researchers at work:

The idea is that rather than asking people what they want—showing them things and asking, 'What do you think of that?' you would observe them using the product… It was very useful in identifying why people were clicking in the wrong places. This was a process of cleaning up the interface and finding out where people might be led astray. And I remember trying to actually suggest that method—and I was learning about this at a time before I knew job-to-be-done theory at all, I mean, it was actually before the second book was published, which I think is where it was introduced, in The Innovator's Solution [TQB: yes, another affiliate link]—and so it sort of clicked in my mind… that observation of actual behavior is more important than asking wishes, or asking of people what they want."

This is job-to-be-done theory: the idea that you can predict a market's behavior by looking at why your customer wants your product—what your customer hires your product to do—and optimizing your product to do that job well. If you're really good at this, you can figure out that customers are hiring unlikely products to do certain jobs because there are no better options, in which case you've just found an invisible untapped market. Or you might figure out that a sizable portion of the market is hiring a particular product because it's the best suited to do the job for which they've hired it, but that it's not really getting the job done. It's a "successful" product in terms of metrics such as sales or brand recognition, but customers may ultimately be very frustrated with it, even if they aren't aware of their frustration. This is how RIM's wildly "popular" BlackBerry could be toppled, among several others, in such short order by such an inexperienced little company such as Apple.

And how do you find out what your customer has hired your product to do? As Dediu said, you do user research, in the tradition of the user experience designer.

Obviously, then, I'm all the more justified in my cry for a C-level representative of the UX discipline at Apple, right?

I don't think so.

I think I was right when I said, "Steve Jobs was the de facto [head] of UX at Apple," but I think I was only half right. Whereas Steiger put it so poignantly, as quoted earlier in this article, "building great experiences is everyone’s responsibility and nobody’s job," I think at Apple building great experiences is everyone’s responsibility and everyone's job, especially if you have a C in your title. I think this is what Steve Jobs was talking about with his each-cell-knowing-the-master-plan analogy.

The executive leadership at Apple has been in charge of this for years. Think about keynote events. Who does the demos? Sure, while he was alive, Steve Jobs did the lion's share (yes, an intentional pun), but come on. Steve Jobs doesn't sit on the bench. More and more, though, even while he was still doing the majority of demos, executives of the top several levels demoed their hardware and software. As far back as 2000 you'd see these guys in the promotional videos released alongside the G3 Cube or the first aluminum PowerBooks. Yes, I realize that even Microsoft executives demo their own software, but I challenge you to compare those demos favorably. On one side you'll get a lot of boilerplate, stiff, clearly-rehearsed deliveries of speeds and feeds. On the other you'll hear someone speak with obvious first-hand, deep knowledge of the practical benefits of what they're showing you—the improvements to the user experience.

Not enough to convince you that the executive leadership at Apple is the apparent co-CXO of the company? How about this one, quite possibly the most important UX design datail in the history of Apple, the feature that could be credited for bringing Apple back to life: the iPod's click wheel? It was invented by Sr. VP of World Marketing, Phil Schiller.

This is the body-and-cell analogy quoted above. I don't think Steve Jobs tried to hide his solution to the innovator's dilemma, I think he just phrased it in ways he knew his competitors would never even try to understand. Here he is spilling the beans in Steve Jobs, by Walter Isaacson,

My passion has been to build an enduring company where people were motivated to make great products. Everything else was secondary. Sure, it was great to make a profit, because that was what allowed you to make great products. But the products, not the profits, were the motivation. Sculley flipped these priorities to where the goal was to make money. It's a subtle difference, but it ends up meaning everything.

Sounds a lot like one of Steve Jobs's heroes, Walt Disney:

We don't make movies to make money. We make money to make more movies.

It also sounds a lot like something one of the other cells in the Apple body—Jon Ive—was quoted saying to Wired:

We are really pleased with our revenues, but our goal isn't to make money. It sounds a little flippant, but it's the truth. Our goal and what makes us excited is to make great products. If we are successful people will like them and if we are operationally competent, we will make money.

That's good user experience design summed up quite nicely by someone who neither came from a UX background nor occupies a UX role at Apple. People often credit Ive with all things design at Apple, but he and his team are industrial designers. To be sure, what he does is a major part of the experience in an Apple product, but he doesn't work alone, or even head the division. Ive doesn't likely call any shots when it comes to pixels.

At most places, a user experience designer, if that title even exists, works in the domain of pixels. If it's a really enlightened company, they might get to sit at the table when decisions about hardware or services are being made. At Apple, they don't stop at pixels, they don't stop at power buttons and they don't stop at unibody construction. They don't stop at the packaging, and they don't even stop at the store display. They keep going. It's why you can buy most items in an Apple store right from your phone, without having to stop and wait in a checkout line. It's why you can get first-class support in person at the Genius Bar. It's why I haven't had to call them more than once in a decade, and why I never heard hold music that one time I did.

TLDR;

It's way too late for that header, isn't it?

This seemingly fussy little organizational detail may hold half of the secrets to Apple's wild success. They don't have a CXO because they don't need one. They don't need one because they've infused their very business model with the concerns, the metrics and even the techniques of user experience design.

UPDATES

Horace Dediu, responding via Twitter:

@thomasqbrady That's right. The CXO's job description is a "value" or priority that should be embedded in every employee.


Why we shouldn't be calling it App.net, nor comparing it to Twitter

by Thomas Brady in ,


As much as Twitter's recent API "warnings" have made us want it to be so, App.net is not, according to this excellent essay by Orian Marx, "How App.net Can Change Everything", just another Twitter alternative.

It's a platform. It's very close to what I was just begging new Yahoo! CEO Marissa Mayer for, when I said,

Whereas a Twitter client is the current Hello World2, give us a platform that makes a Twitter-like service the "MyFirstWebApp.html" experience. Do for web application development what Blogger and Wordpress did for content development.

Along those lines, Marx suggests we call the social application currently featured at alpha.app.net "Alpha," to distinguish it from the infrastrcture?the platform?on which it was built, which is App.net. If this truly is the direction in which Dalton, et al are headed, I think good things are in store.


Real artists

by Thomas Brady in , , ,


So if you're any kind of Mac nerd you've by now seen numerous photos of early iPhone prototypes now made public domain by inclusion as evidence in the ongoing Apple v. Samsung case.

The Verge featured write-ups, with galleries, on the 26th and the 30th and NetworkWorld today posts a deposition from Douglas Satzger, an industrial design lead who worked at Apple at the time the iPhone was being developed.

There are a few interesting things to me about all this. On the snarky end, the inexcusably poor coverage has been a bit of a surprise. The number of headlines and even whole articles accusing Apple of ripping off Sony design, having clearly not read any of the words in the source materials that weren't in one of the pictures of the prototypes is appalling. It's pretty clear, if you bother to read any of this, that a designer (or some designers) was (were) asked to design something in Sony's style.

The most striking thing of all, to me, is the design itself. This composition from The Verge tells the story best:

It's clear, looking at that 2005 design, that Apple envisioned the iPhone as we know it now—the iPhone 4 and 4s industrial design—before they designed the original iPhone and the 3G/3GS.

I'm very impressed by a company that can not only devise what is, in their estimation, the perfect design and eventually realize it in a shipping product, but can also ship iterative, real-world-constraints-compatible versions on the way there—iterative, real-world versions, by the way, that disrupt entire industries, several at a time. The iPhone was clear two steps forward for Apple, despite the one-step back design and capabilities of the first generation.

Apple had to make some compromises to get that design to market. They had to choose: do we make something that is as powerful as we want, but is maybe a tad way-too-gigantic, or do we sacrifice some power to get the right size? What can we ship now that will be a good jumping off point for the next version, which can be another step toward the product we dream of shipping?

Two of my favorite Steve Jobs quotes come to mind.

"I'm as proud of what we don't do as I am of what we do"

And, of course, "Real artists ship."


How Yahoo! can get an app (or five) on the homescreen of every smartphone

by Thomas Brady in ,


The latest episode of the Talk Show, “The Next Big Thing (feat. MG Siegler)” got me thinking about Yahoo!, and what Marissa Mayer could do to make it a great company again.

I’m sure Ms. Mayer is full of great ideas for what to do with Yahoo!. I’m sure, too, that she’s receiving far more suggestions than she requires. But I haven’t seen anyone suggesting this one.

In case you need/want it, here’s a TL;DR jump.

From my woefully under-informed position, it seems that Yahoo! is currently crammed into a corner while Google, Microsoft, Amazon and maybe even the likes of Apple and Thompson Reuters take up most of the dance floor. Trying to displace Google in the search market seems a tall order. Yahoo! is currently partnered with Microsoft for search capabilities, which makes competing with them on any of their other hobbies awkward. As John Gruber points out in this episode, Yahoo!’s content generation/syndication causes seem to have given up to Google News and real players like Thompson Reuters. A mobile play—at the top of anyone’s list these days—seems crazy, too, as that club has a line wrapping around the corner. Only one of the companies in that list above doesn’t have a mobile platform/device.

What does Yahoo! do really well? What could they do even better? What could they do better than anybody else?

Before I let loose this cerebral flatulence, let me point out the obvious flaw in my idea: I don’t know how to monetize it. That’s your job. I’m just an idea guy. The only dollar signs in any of the textbooks involved in my higher education were either in variable names or world problems having to do with the cost of a ticket for a train leaving Chicago at 7:20 AM, whilst another train left Philadelphia at 7:35 AM.

The Challenge

John Gruber and MG Siegler set a goal for Yahoo! in that episode(paraphrased):

Get an app on the home screen of every mobile device.

I have no idea what app Yahoo! could create that would achieve that goal. I do have an idea that could easily, though, net them several apps on that home screen.

Yahoo! and The Web

For the past few years, if you were learning to write software for just about any platform, the second application you’d write, after a “Hello World” is a Twitter client. For many years before that, it was a Flickr client. Yahoo! has always been one of the companies that best understood how the Web really needed to work—that you didn’t really have a service until you had an API.

Far as I can tell, Yahoo! has a nigh unchallenged stronghold on API-enabled online content platforms. If you’re Apple, apparently, and you want stock market data, or weather data, or sports scores and news, you turn to Yahoo!. That’s a ringing endorsement. What I definitely don’t understand is how this part of your business works. At Polycom I worked with a team of lawyers and outreach people to try to contact someone at Yahoo! to negotiate a similar contract to embed Yahoo! data in Polycom products. I scoured the Yahoo! site for contact information. There’s a single, unpromising form. I found phone numbers on message boards and called them all. Our lawyers called people. One of our outreach people tried to call in a favor from a college friend. We could never get a return call from Yahoo!. Apparently Yahoo! doesn’t make money from this, or they really like exclusivity.

Yahoo! Technology

Yahoo! has an oddly quiet, but impressive technology story. Someone lured Douglas Crockford there in 2005, though he left for PayPal this May. While there, Crockford worked on YUI!, one of the web’s first big UI kits. These days you can choose from a few dozen: jQuery UI, Twitter Bootstrap, Zurb Foundation, a couple from Sencha, etc. Not only was YUI! one of the first sets of interface elements, it was one of the very first libraries to include highly interactive, animated, AJAX-powered interface elements in a web UI library.

There are lots of labs-type projects at Yahoo! that seem to be waiting to be discovered. Yahoo! Pipes is something I can’t believe hasn’t taken off. This is another great example of Yahoo! understanding the true nature of the web: a network of semantically rich objects with APIs to connect them.

And Yahoo!’s still hard at work on this stuff. The more recent announcements around the Cocktails—a suite of technologies using HTML, CSS, Javascript and Node.js to enable web application development for server and client side in one go and a platform for hosting such apps—shows that they’re out there on the cutting edge.

Peanut Butter, Meet Jelly

If you’re building a web app right now, one of the most difficult stages is the one in which you pick your technology stack. There’s always the big ugly framework shoot-out chart, wherein you narrow down your giant list of of frameworks to the few that really have all the features you’re excited about, to the two that actually support all your requirements (including accessibility, localizability, etc.).

Then you get to go figure out where you’re going to get your data. Licensing said data is often a headache.

Next you get to constantly deal with the, “Shouldn’t we just make a native application?” question, that no one with a trustworthy opinion can answer in any final way, yet. We are at a crossroads. This may lead you down the path of tools such as PhoneGap to achieve “native” installation as an app.

In far more cases than one would hope this lands you with:

  1. A web application
  2. A framework like jQuery
  3. A framework like jQuery UI
  4. Possibly another framework for mobile, like jQuery Mobile
  5. A “native” app built with something like PhoneGap, which requires
  6. A fork of your web application to make use of device features

While we’re on the topic, let’s get something out of the way. I don’t think anyone denies that an application built with native application frameworks—whether we’re talking about an application binary written for OS X, iOS, Android, Windows, or whatever you’re using—will outperform a web application running as though native, at least not yet. The reality for many of us, though, is that supporting the repository of codebases necessary to produce native applications for two, three, four or eight native platforms is just not an option. Leveraging web technologies as cross-platform development tools might lead to less-than-the-absolute-best performance and user experience, but that’s a trade-off many people are willing to live with in order to reach 2x, 3x and larger audiences.

TL;DR

Here it is, my complementary billion-dollar idea.

Become the platform for web application development.

A plan so simple as to sound ridiculous. If we were talking about just about any other company, it would be ridiculous. I think Yahoo!, though, is uniquely equipped to do this.

Give us a one-stop-shop for web application development. You already have most of what we need. Make each of the tools best-of-breed, stack them up and get a PhoneGap-like tool online. Keep offering YUI!, Mojito, Manhattan and the like, but also market an integrated toolset that looks like a single all-encompassing toolset that includes a license to integrate Yahoo! data services like Yahoo! Finance, Yahoo! Weather, Fantasy Sports and the rest. Give us the promise of tools like Sencha Touch and PhoneGap, but deliver what they haven't so far: a dependable release schedule that's in lock-step with the platforms we're targeting, giving us new features as they're available, not tens of months later. Give us a development platform in the sky—perhaps another Cocktail—that makes it feasible to share a core library of web application logic across instances tailored for use as a web app, as a native app and as a service for someone else to integrate with Pipes. A one-click build server that spits out web apps, native binaries and SaaS servers. Whereas a Twitter client is the current Hello World2, give us a platform that makes a Twitter-like service the "MyFirstWebApp.html" experience. Do for web application development what Blogger and Wordpress did for content development.

I know I can’t be the first person to come up with that idea. And, Yahoo!, while you may not be the first company to attempt to do such a thing, you’re uniqely positioned to do it.