My eyes squinted, my lips puckered. My palms sweaty and my heartbeat faster. The adrenaline started in my back, tingled my brain, then tickled my toes. It was a moment of clarity: A moment where something obscure suddenly made sense, a moment where the future was laid out for me, waiting for me to realize it. The most recent moment of clarity triggered this blog post.

The realization is that my happiness is something that is in my control to create control, something that I can create for myself and manage. What it means and how it works, are still a little hazy for me, but the idea is there, I feel it in my bones.

I’ve recently started reading Flow by Mihaly Csikszentmihalyi, a book which analyzes years of research into happiness. Here’s the quote that captures the thesis:

What I “discovered” was that happiness is not something that happens. It is not the result of good fortune or random chance. It is not something that money can buy or power command. It does not depend on outside events, but, rather, on how we interpret them. Happiness, in fact, is a condition that must be prepared for, cultivated, and defended privately by each person. People who learn to control inner experience will be able to determine the quality of their lives, which is as close as any of us can come to being happy.

The implication being, the quality of your live (and thus, your happiness), is a choice. It’s something that you decide you want, and something you create for yourself.

Here’s another quote from an article I just recently read called Top five regrets of the dying that supported the same argument:

Many did not realise until the end that happiness is a choice. They had stayed stuck in old patterns and habits. The so-called ‘comfort’ of familiarity overflowed into their emotions, as well as their physical lives. Fear of change had them pretending to others, and to their selves, that they were content, when deep within, they longed to laugh properly and have silliness in their life again.

Steve Jobs also shared a similar sentiment during his famed Stanford speech:

And since then, for the past 33 years, I have looked in the mirror every morning and asked myself, if today were the last day of my life, would I want to do what I am about to do today?

I’m trying to internalize this concept and make it a part of who I am. My identity and my thoughts are my own to have, control, and share. Happiness is a mindset for me to create. I find this newfound control over my life comforting since it means I can stop passing the buck and sulking in any form of unhappiness.

A final thought: On average, you have 78 years total to live. The first 18-20 are spent learning, which leaves 58. Spending 2 years doing something you don’t enjoy is a full 3.4% of your life. What are you getting back for that investment? Money? What are you going to do with that money that will be worth the non-refundable 3.4% of your life? An extra room in your house?

There seems to be a seeping Napoleon Complex among mobile web devs, it’s almost like they don’t want me to use their web app. I’m sure a lot of developer effort went into building these comfortable, mobile-friendly alternatives to the full desktop experience, so why ruin it by putting up speed bumps between me and the content? (I’ve put example of this below the text.)

If I’m using your mobile web app, it’s because:

1. I’m not on my own phone, and I’m using a friends’ phone
2. I tapped on a link in an app
3. I don’t want to download your app and have it take up a spot on my phone
4. I didn’t know you had an app and I went to your website by default

The first three use-cases imply that I don’t have an interest in your native app, and the last use-case doesn’t justify trampling on the other three. A simple banner would do. Even better, wait until a user takes an action that’s only available on the native app (like uploading a photo), and then prompt them to download the native app. All around, I see examples of this:

As an alternative, I really like what Instagram does: A simple link that takes you to the App Store. Simple, effective, and unobtrusive.

I came across a 2009 post by John Siracusa called Hypercritical and it inspired me to share some thoughts on the subject. I, like Siracusa, live in perpetual displeasure with my work. I’ve come to attribute this displeasure to the disparity between what my brain wants to create and what my hands can output. I’ve heard Ira Glass tell us that the antidote is practice, so practice I do.

There is a flip side of course, and it was recently summarized by @can:

https://twitter.com/can/status/144331530779635712

Seems to me, the only bad criticism is one that is personal and inflammatory. Hyper-criticism is an unapologetic quality, and has a tangible impact on the final product, when channeled properly.

I don’t know how justifiable my criticism is. Is there a threshold of external validation one must meet before their opinion matters? I don’t think so, and I think the more I can constructively criticize – that is, back my criticism with logical analysis – the better I become at judging my own work.

I’m not about to compare my criticism to Steve Jobs’ secret-sauce of sucess (much to my ego’s dismay), but I think the general idea that the key to success is being critical of one’s own work and ” being in a position to demand that it be fixed before a product sees the light of day” is, in fact, a key to Apple’s success and an indication of the failure of many competitors.

Choice quotes from the Siracusa article:

This touches on the idea of practicing even in the face of self-doubt.

But much worse than that, it means that everything you ever create appears to you as an accumulation of defeats. “Here’s where I gave up trying to get that part right and moved on to the next part.” Because at every turn, it’s apparent to you exactly how poorly executed your work-in-progress is, and how far short it will inevitably fall when completed. But surrender you must, at each step of the process, because the alternative is to never complete anything—or to never start at all.

I like what this quote has to say about using criticism to understand not just what sucks, but why it sucks.

And true to form, there was plenty of recursive self-analysis. Do I dislike these new tabs only because they’re different? Are my old habits blinding me to the benefits of this new design? People really dove deep on this thing: generalizing, trying to find the underlying patterns, and changing their positions based on new analyses.

Prologue

Over the past few months, I’ve started writing blog posts and stopped half-way through, or even worse, I finished them, but thought they weren’t good enough to be posted. Sometimes it’s because I felt like there wasn’t a real call-to-action to the post, other times it’s because I didn’t think the point was well-made. Recently though, I realized that this was causing a writer’s block and the way to unblock myself was to keep writing, regardless of my perception of its quality. “Done is Better than Perfect” and all that. So in the spirit of Ira Glass (See video above), I will practice, practice, practice.

The Broken Pixel Theory

The Broken Window Theory is a fairly well-known criminology theory that correlates the well-maintenance of neighborhoods with lower crime rates. The idea is that a building with a broken window will lower the guilt barrier of breaking another window, which snowballs into a higher crime rate. I stipulate that the theory applies both to application UIs, as well as the code that runs them. A UI with a broken pixel will lower the guilt barrier of breaking another pixel. If unchecked, these broken pixels can snowball to a culture of qualitative indifference.

There are many examples of The Broken Window Theory in daily life. For example, a clean desk tends to stay clean until a piece of paper stays on it for a couple of days. Similarly, I’m much less likely to care about a 2-3 pixel UI bug when the whole UI is a mess. Nobody would care about my bug, and even if they did, they probably won’t notice my bug among the swarm of other bugs.

Sweating the details is important not only from an aesthetic perspective, but also from a cultural perspective. A company’s culture is one of its greatest assets, and its products are a reflexion of it. Apple’s products are polished and smooth, Google’s products are fast and technical, Amazon’s products are simple and frugal. The Broken Window Theory applies not just to the user facing products, but everything internal as well, from the letter head to the internal websites, and all the energy put into maintaining a high level of polish is a worthy investment.

If you thought this blog post was interesting, you may also enjoy Braden Kowitz’s Why you should move that button 3px to the left

tl;dr: Try doing something you’ve always wanted to do for a month. If you like it, you’ll keep doing it, if not, you don’t have to do it for very long.

Play a song, Tailor a pair or shorts

Starting Monday, January 23rd, and until February 24th, I will spend one hour each day either learning to play a piano piece or working on constructing a pair of shorts. I’m thinking three nights on Piano, two on Tailoring.

Here’s the song I will try to learn to play:

Note: The song was “Children Arrive” from the Finding Neverland Soundtrack. It’s been removed from YouTube

I took some piano lessons when I was 10, but I forgot most of what I learned. I still know the very basics of reading music, but I don’t know how to apply them. I know the basics of garment construction, but I still can’t put them together all the way to a final piece. I don’t know if I’ll be able to hit my goal, but it doesn’t matter quite as much as the act of practicing something outside my core competency. If I find that I’m improving, I don’t have to stop in a month. A month is the minimum, not the maximum.

Why?

I’ve worked in tech in Silicon Valley for one-and-a-half years. The work is hard, the deadlines are aggressive, and the days are long. I love the challenge, I love the work, and I love the culture, but after a while, I started feeling like parts of my brain were going dormant.

I’m surrounded by people who excel at everything in life from unicycling to writing novels. I draw inspiration from these individuals, and I have a laundry list of activities and hobbies that I would like to be good at, but never found the time or motivation to actually follow through.

The Book

I’m reading The Talent Code Where the author describes the conditions and type of intentional, “deep practice” that breeds greatness. Here are a couple of quotes from the book:

“The trick is to choose a goal just beyond your present abilities; to target the struggle. Thrashing blindly doesn’t help. Reaching does.”

“People at most of the hotbeds [of talent] I visited practiced less than three hours a day. The younger Spartak kids (ages six to eight) practiced a mere three to five hours each week.”

5 hours a week, one hour each weekday, for a month. The experiment is to find out whether one hour a day is enough to meaningfully gain knowledge and skill in an area of interest.

The book has jolted me into a state of restlessness and I want to capitalize on it. I’ll try to describe this “Do something for 30 days” idea, how it has worked for me, and why you should do it as well.

The Epiphany

When I came out to San Francisco in June of 2010, I weighed 240 pounds, and lived a sedentary lifestyle. One of my coworkers convinced me to go running with him one morning. Then he got my ass out of bed early to go for another run later that week, and a couple of weeks later, I found myself looking forward for that morning run. A short conversation and a $50 wager later, I decided to commit to running 2 miles in the morning before work every day for a month.

Here’s the Nike+ graph of that month:

I skipped a few days to rest, and I missed a 5 day stretch because of a trip to NYC.

The epiphany came after the month was done: I kept on running, increased my mileage and eventually participated in a 10 mile run during which I weighed 185 pounds.

I did a similar thing a few months later: I really wanted to read. I felt like there was a lot of knowledge buried in books that I was not exposed to because of my aversion to reading. By the time 2011 was done, I had read 11 books. As I continued reading, my speed got faster, and my vocabulary grew (and I learned a lot!).

The reason I’m recounting this isn’t to pat myself on the back, it’s to highlight the fact that people are in control of their lifestyle and it’s in their power and capability to completely change it. The key is to truly want to do it for yourself. If you decide to do it out of peer pressure, you’re almost certain to fail. I was haggled to lose weight by my family for years, and it wasn’t until I personally wanted to do it, that it happened.

Why a Month is the Perfect Amount of Time

This idea isn’t unique, I can’t remember hearing about it before I did it, but since then, I’ve come across a bunch of people advocating the same thing. Here’s Matt Cutts talking about the exact same idea:

http://embed.ted.com/talks/matt_cutts_try_something_new_for_30_days.html

He approached it from a therapeutic perspective. In hindsight, when I started my month challenges, I had just moved to a new city, was still trying to build a social circle, and was feeling a little detached. These challenges fill up your free time, give you a purpose and a goal.

A month is the perfect amount of time for a couple of reasons: First, it’s short enough that if you decide the challenge you embarked on is not fun, you don’t have to do it for long. Secondly, it’s long enough, that if you stick to it, it would form a habit.

If you’re thinking about doing this, the rules are: It has to be something you genuinely want for yourself, and it has to be something sustainable

What do you think? Has there been something you’ve always wanted to do and be good at? What is it? What are you waiting for? Why aren’t you doing it today?

Recap

Last year I wrote one of these and in retrospect, it was too personal. I think at the time, I didn’t expect more than 10 people max to read it. Even though the post makes me feel a bit exposed, it has had a positive effect on me that encouraged me to keep it posted and write another one.

It was around June when I started thinking about where my career was heading and where I was going. I felt like 2010 was such a crazy year, with so much personal and career development, that had I left 2011 as I entered it, I would have wasted a year. I seriously considered what this blog post would say had I stayed where I was. I thought the blog post would be boring and uneventfull, a reflection of what my life would have been. This idea scared me, and made me itch for change.

Coincidentally, a couple of opportunities presented themselves to me at that time, and I considered both heavily. Finally, I decided to join Strobe Inc.. This was my second job out of college, and the freedom that came with working in a startup amazed me, in stark contrast to Apple. On my first day at the job, I was linked to by Gruber (A bucket-list item of mine). Later, five of my blogs posts would make it to the front page of Hacker News (Another bucket-list item), and within 4 months, I released a fewopen source projects. The rush of seeing people use my software and the rush of public-speaking was addictive.

I recommend working at an early-stage startup to any engineer without hesitation. The breadth of knowledge you need to have and the intensity of the work is intoxication. You become a master of your own destiny, your peers become your family. and your work becomes your best friend. Moreover, you end up learning about a topics you wouldn’t otherwise explore: Financing, business developement, operations, etc. – All essential lesson to learn, and all lessons I’m glad I learned.

Fast forward a few months, and I’m now at Facebook. Truth be told, had I been in the open recruiting market, Facebook wouldn’t be the first company I’d reach out to. In hindsight though, I’m etremely grateful for the chance to work here. Regardless of the work itself, I’ve learned a lot about how a large company can operate and how teams can be managed. Again, invaluable life lessons I am grateful to learn.

I now sit in a room with some of the brightest and most accomplished names in Web Development, working on the most popular web destination, on tough problems. My old goal of always being the stupidest person in the room has been handsomely fullfilled.

Life Lessons

Shifting gears to big life lessons learnt, I’d say the biggest lesson is to slow down. I’ve been operating under the time pressure of a race. I felt like every day that didn’t mark a notable improvement in my career was a wasted day. I’ve always been a futurist. I dream about the future, I talk about the future, and I build the future. I couldn’t justify a lack of change, so I enduced change. I’ve come to decide that that was a terrible way to live, and the lesson is that building the future takes time, adjustments, perseverence, and hard work.

Another main lesson I learned it: Fixing what’s broken can be as rewarding as starting over. I’ve always beena “grass is greener on the other side” sort of person, and treat obstacles with dread.

As I enter my mid-20s, I think I’m going to slow down. I want to have a few, but deep and impactful outcomes this year, not a lot of smaller ones. It’s time for me to stop being a student and a consumer and start creating my own world and future.

Socially

I’ve met most my SF friends for over two-and-a-half years now. These people have been with me through my weight loss, my job transitions, and my growth over the past couple of years, and they’ve handled all my whining and bad jokes, and I love them for it.

I now live with two of my best friends, in an amazing how in an amazing neighborhood in an amazing city with an amazing job, and an amazing life. I’m extremely grateful and take none of it for granted. As I grow, I want what I have to work for me more than I’ve given it a chance to do in the past. This year will have fewer changes, but bigger outcomes.

I’m excited.

I love Amazon, they’re one of the few companies who like Apple, understand that for a consumer product like a phone/tablet to succeed, it needs an ecosystem to back it, not just the hardware/software to run it. Amazon is also in a unique position of being in charge of one of the biggest ecosystems for media on the planet.

The Good

The focus of the Fire on media consumption through Amazon’s ecosystem is brilliant. The price point (my wild guess is that they’re selling it at a $1-200 loss per sale) is the razor-blade/printer equivalent of tablets. My assumption is that the play that Amazon is trying to earn most of the money on content sales rather than hardware. Assuming a 2 year lifetime, $1-200 is easy to spend on content (especially $10 books and $3-4 movie rentals).

They also cleverly designed the UI to play to the strengths of the Fire. As opposed to the iPad (whose strength is the Apple store) which features apps on the home screen, the Fire features content on the home screen. These sorts of UI decisions influence how people use and perceive the product, and Amazon wants people to know that this is a media consumption device.

The iPad 2 weighs 21.28 ounces, the Kindle Fire weighs 14.6 ounces, this will make a big difference when holding it up for elongated periods of time for reading. I just bought one of the new Kindles (the most basic one) for the sole intended purpose of reading. I’ve never been able to read books on my iPad. The combination of a backlight, the weight, and the screen resolution is a deal-breaker for me. I haven’t played with a Fire, so I don’t know whether or not it suffers from the same resolution/backlighting problems of the iPad for reading, but the weight will help a lot.

The Bad

The 7″ form-factor is an aspect which doesn’t sit well with me. One of the pleasures of using an iPad is the size of the display. Multi-touch gestures are extremely natural and comfortable on the iPad, web content designed for large computer displays feels natural at 10″. The Galaxy Tab 7″ is the only 7 inch tablet I’ve played with, and it felt smack-dab in the middle of being big enough to be comfortable, and small enough to be portable. The difference between the Tab and the Fire though is the same as the difference between the iPad and the Fire: The Fire is intended for serving a smaller subset of use-cases which are less interactive: Reading books, watching movies, listening to music, etc. so it may be less of an issue.

Overall, I think it is a well-rounded product with a string backing ecosystem, I can’t see why this product won’t be a runaway hit. However, I don’t think anyone seriously considering an iPad would opt for a Kindle Fire instead. My hypothesis is that people who were on the edge about spending $500 on a tablet will be much more inclined to buy a Kindle Tablet, which will increase the size of the market, but won’t cannibalize the sales of the iPad.

If you’ve taken interest in this blog, chances are you’re at least intrigued by the mobile web and its possibilities and how it fits into our ecosystem. We’re still in the nascent days of the mobile web, and it’s still establishing itself as a powerful application development environment. As a result, a lot of companies and developers find themselves wondering whether a new project they’re starting ought to be built on top of ubiquitous web platform, or the performant native one.

In order to answer some of these questions, and to engage in a level-headed conversation, Tom Dale, Buzz Anderson, Neven Mrgan, Lia Napolitano and I have submitted a SXSW panel proposal trying to address the “Web or Native?” question from a UI, UX, and engineering perspective.

Some of the questions we will answer:

• What advantages do native apps have over web apps, and vice versa?
• How does good mobile web design differ from good native app design?
• How does the native development process differ from the web?
• Which kinds of applications are best suited to mobile web, and which are best suited to native?
• Can both mobile web and native apps have a place in your mobile product strategy?

Please vote for our panel proposal here.

We hope to see you in Austin!

A Lengthy Introduction

I was casually browsing my Twitter stream the other day, and someone posted a link to a blog post on doctyper.com which when loaded, made me realize another downside to imitate native UIs in the mobile web.

I should make it clear first, that I don’t intend to pick on doctyper or its developer, it just happens to be popular enough that I stumbled upon it. Everything I say here is general enough to apply to almost all native-imitation-style mobile web apps.

Here’s what I saw when the page finished loading:

My first problem with this came up when the content started rendering and I tried to scroll. Because doctyper uses custom, Javascript-based scrolling (A topic I discuss in more detail here) and because the javascript hadn’t finished parsing and executing, my touches weren’t captured. Instead, the page scrolled as-is and the top and bottom black site bars along with the content all static and moving together. I released my finger, tried again, and it finally kicked in.

Not a problem native developers have to deal with.

The second problem came up when I started scrolling. I don’t know about you, but I don’t like small, confined spaces. And on this site, I felt very claustrophobic. To see what I mean, let’s deconstruct the screenshot into its various elements. Labels on the left represent the component that drew them, and the labels on the right show their pixel height:

Of the 960 pixels of real estate, 520 were used for content. In other words, 46% of the space was information and visual clutter that had nothing to do with the content.

Sometimes web developers seem to be more concerned with the frame than the painting. Haven’t we learned anything from Microsoft?

The Assumption

My assumption is that people who design and develop these native-imitation style mobile web apps are doing so in the void of MobileSafari, ignoring the ubiquity of the web. The whole point of building a web app is to leverage its strengths. One the main strengths is the web’s ubiquity.

The ubiquity of the web means you can’t guess where and how people will be using your web app. The best you can do is come up with a flexible design language that will adapt to screen sizes, form factors, and input mechanisms. Unless you’re building a hybrid app – combining web views within native wrappers – where you can presume the dimensions and access points, designing for a specific form-factor/use-case will indubitably lead to situations like the one discussed earlier.

The Addendum

Having said all that, some of you may be wondering why you would build an app-like experience on the mobile web at all. I did just spend 400 words telling you why it was a bad idea afterall. Well, let me tell you about another experience I recently had with the mobile web.

John Gruber, being the fan of @counternotions that he is, linked to one of his tweets recently. As I was browsing the feed, the mobile Twitter app loaded and I was pleasantly surprised. 1 I was expecting the basic HTML page to load that showed the tweet, the person’s avatar, and a couple of buttons. Instead, a rich UI was loaded which let me fave the tweet, see the conversation leading to it, and quickly switch over to my main timeline. 15 minutes later, I realized that I was still in the embedded web view of Reeder, lost in a sea of poop jokes and kittens.

The takeaway is, I was under-promised and over-delivered, and that’s what we ought to aim for. Mobile web apps should delight our users, not frustrate them.

Please note that I’m writing this without any proof-reading. This is pure stream-of-consciousness.

iCloud.com was just announced. That’s pretty awesome: iCloud’s web apps include some pretty amazing interactions. If you haven’t seen them, get a developer account and log in. You should do that now, the rest of this blog post assumes you’ve seen them. iCloud is pretty fuckin’ amazing: The animations are incredible, the interactions are buttery, and the UI is polished as possibly could be. Having praised the iCloud suite of applications, one thing worth noting is: They prove that a buttery-smooth UI is not impossible to build on the web.

iCloud is tangential the the point of this blog, but it highlights a point I want to make: People are surprised and impressed that the web stack is capable of implementing the interactions which iCloud implements. We as web developers ought to be embarrassed about that. It shouldn’t be a magical surprised that a good, no-compromise UX is possible on the web.

Everyone expects Apple to release software that is far and beyond the level of sophistication and polish that we are accustomed to, but we shouldn’t be surprised that a technical achievement is possible which we previously thought wasn’t. My hypothesis is that we as web developers are so entrenched in our trees, we can’t see the forest. Every javascript developer is developing their own hot little javascript micro-framework or even fully-developer mature framework to one part of the web development story or another. I call bullshit. As far as I’m concerned, we’re all chasing our tails trying to solve the same damned problem over and over again. People are somehow susceptible to false benefits which are easy to preach, but hard to verify. I say: Stop worrying about kilobytes, and start worrying about web developers being oblivious to the capabilities of the web.

I could spend an entire blog post outlining the fallacies of micro-frameworks and niche solutions, but I feel like Apple has already proven many of my points: Take a look at the iPod. Not only has the iPod achieved market dominance in its segment, it has also maintained that dominance long enough for the entire market segment to become irrelevant. There are many reasons for the iPod’s success, but the one I think is worth highlighting in this conversation is its ecosystem. An iPod without iTunes is like a human body without blood. Why don’t we Web Developers learn this lesson?

There are more MVC based frameworks than I can count. Since SproutCore 2.0 has started establishing its namesake with bindings support and the observer layer, it seems like every single new javascript framework ships with the same live-updating support. This isn’t an apologetic SproutCore blog post though, I could spend an entire blog post telling you why all these framework developers are wasting their time and chasing their own tails, but the point is: The people developing these clones are really smart, but they’re not building anything worthwhile.

It shouldn’t be a surprise to people what you can do with CSS 3D Transformations. At this point, that’s well understood and well documented. It’s like somebody being surprised that mixing peanut-butter and jelly with some bread creates a tasty combination. What should be a surprise is what happens when you build a fully-integrated solution on top of it. Instead of developing more redundant MVCframeworks, we need to coalesce our energy on a few proven solutions.

Native developers don’t have this problem. You never hear of widespread news when a native developer finds out that if you call methods on UIImagePickerController then you magically get access to the device’s camera, but it’s common-place to find out that people exposing and using the intricacies of CSS3 transforms are creating incredible feats of UX.

We need to cut this shit out. I don’t care how small your microframework is. Bandwidth isn’t the problem. If you think a 5kb framework is preferable to a 7kb framework, your are bat-shit insane and patently wrong. There is no “maybe he has a point”. No, it’s black-and-white. File size isn’t the problem, code-size is. If you string-wrap your code, your OK. Don’t listen to people who tell you otherwise, they’re lying to you (though probably not intentionally).

A JavaScript-based MVC framework is only a small part of the solution, the same way an iPod is a small part of the digital music solution. A proper, scalable backend along with all the services and add-ons that make up a server stack are required to create an ecosystem. But that still doesn’t quite cover the whole story: The stack not only has to exist (Nokia, RIM, Microsoft), but it also has to be tightly integrated and seamless (Apple).

Partly as a disclaimer, and partly as supporting evidence, I should make it clear that I work at Strobe Inc. We’re the first people to really build an end-to-end solution for web development. Lots of other developers are working on solving certain problems in the domain, but none are providing a full-stack, integrated solution like we are. Strobe is sponsoring projects like bpm, sproutcore, and the strobe platform to once-and-for-all solve the problem of developing web application from the ground up. I strongly believe in what we’re doing, which is why I’m spending time to make sure we do it, but the point is that the rest of us should stop wasting time and start moving our platform together.

We have a gem on our hands: Let’s stop arguing about who has the better hammer and let’s start chiseling it into a beautiful piece of jewelry.