jtaby.com

Conquering Defeat

2012-06-28T00:00:00-07:00

introspection |ˌintrəˈspekSHən|: the examination or observation of one’s own mental and emotional processes.

Sometimes I feel like I need to limit my time interacting with technology to just the times I need to get my job done. I go through this phase every now and then where I realize that my dependency on technology may not be as strictly beneficial for me as I make myself believe.

I’ve long held the belief that any technology is good technology. Technology is inherently good, even if it’s used for bad purposes.

Every now and then though, something happens that triggers a realization that life extends past the computer. It’s almost sad to need to realize that, but such is the reality of dedicating your life to your work and passion. Such is also the blessing and the curse of what we do. It’s kind of an ironic cycle: I am passionate about my work, so I spend a lot of time doing it, which makes me less passionate about it in the long run (burn out). For me to avoid the burn out, which is the worst outcome of passion, I have to remind myself explicitly to step aside and metaphorically (sometimes literally), and smell the roses.

It might be a trip home to see your family, your parents coming to visit you, some personal issues, or some external issues. It can be a combination of those, but the end result is introspection. Introspection can be a scary and frightening thing. A lot of people spend a lot of time running away from introspection. I can relate to this comic and have referenced it a lot since first seeing it (in my work’s bathroom stall):

I think that comic captures something essential about our use of technology. Whenever technology becomes not a tool to get a job done, not a toy to play with, and not a passion to feed, but an excuse to run away from introspection, then it’s time to re-evaluate it. Taking a long walk at night alone, sitting along on the beach, going on a solo bike ride. Solitude does not imply loneliness nor boredom. Solitude can be a time of reflection. Running away from hard decisions and tough problems doesn’t solve them. In fact, it can worsen them.

Part of me wants to turn this into one of my month-long goals: No Twitter or non-work-Facebook for a month. No internet for a month, etc. But I don’t think that’s the problem nor do I think I would get anything from it. The problem isn’t technology, the problem is using technology to run away from thought.

Flow (this is the third time I reference that book now) describes this in the second half of the book. People who conquer solitude, emotion, and thought are the proverbial “Masters of their domain”. I’m only 24, I’m a baby in the grand scheme of things, but I’m old enough now to draw conclusions from my experiences, and one of those conclusions is: The brain can be either your biggest liability or your biggest asset. It can bring you down, and it can lift you up. The difference in my opinion is introspection. Being able to understand that what you’re feeling is not reasonable. that you’re emotion is unjustifiable, that you’re confusion is incomprehensible is actually a really powerful concept.

One of the other conclusions I’ve reached is not to dwell. The instant a negative outcome is irreversible, any mental capacity spent not deconstructing it and learning from it is a wasted brain cycle. Nothing is sadder than a wasted brain cycle. This has been my indispensable tool for dealing with negative outcomes: Not getting into a college I wanted, not getting a job offer I wanted, not getting a raise I wanted, or any other life circumstance.

Once you truly isolate yourself from your reality and can look at it objectively and from a third person perspective, things click and become clearer. Think about all the situations where a friend has been able to help you figure out something hard. The difference is they’re isolated from the incident. Being able to do it on your own means you can do it for all the situations that are too personal to share, and at your own pace.

You obviously can’t control your emotions. You can’t stop yourself from being happy, sad, angry, or bored. What you control is your reaction to that scenario. If you learn to tame and control your emotion, you become in control of your happiness.

A Tale of Ten Hobbies

2012-05-02T00:00:00-07:00

The Problem

Over the past two years, I’ve been picking up hobbies left and right. I decide I want to “Get into X”, then buy all the gear necessary to exercise that hobby. Six weeks later, I move on and the hobby becomes a memory. Sometimes I cycle back to old hobbies, hoping to pick up a forgotten skill. As of today, the cycle includes: Figure Drawing, Cartooning, Watercoloring, Tailoring, Piano, Writing, Running, Cycling, Reading, Cooking, and Photography.

When I first noticed this tendency to drop hobbies shortly after picking them up, I dismissed it as a natural consequence of my desire to diversify my life’s experiences, and thus wasn’t something worth fixing. The point was to keep my mind sharp and active, not to get good at a certain hobby.

As I’ve matured though, I’ve realized that that line of logic was a cop-out I used to justify giving up. I never started a hobby expecting to drop it soon afterwards. When I do drop it, I usually do it out of boredom or frustration. Why is that? Why can’t I pick something up and stick to it long-term? Is that even feasible? How would I even fit time into my day for all these hobbies? How good do I really want to get?

After mulling those questions over in my head, I decided that the next time a cycle came about naturally, I’ll ride it through, and I’ll try to take note of what was going through my mind.

Soon after, I picked up photography: Bought the camera and a lens, started shooting, and sure enough 6 weeks later, it hasn’t left my desk in a week. I think I’ve figured out why I drop hobbies, and I have a hunch on how to fix it.

The Realization

Given a creative activity where the output is subjective, judging progress is difficult. Compared to a non-creative activity where the result is clear and progress is obvious, it becomes much harder to find motivation to continue investing time and effort when you don’t see that effort rewarded. For example, you either finish a 50 mile bike ride or you don’t, you either win a game of basketball or you don’t. Contrast that with judging a painting: When are you “finished”? How do you judge its quality?

“Beauty is in the eye of the beholder” is another way of saying that creative works are judged against a personal criteria of taste, quality, and style. As your skill and your exposure to a domain grow, your expectations grow and your tastes develop, but your skill may not grow at the same rate. That’s the case with me. Inevitably, I compare myself to the professionals who have had years of practice, and judge my amateur work against theirs.

Therein lies the problem. When I started photography, merely using a high quality camera with a shallow depth-of-field was enough to meet my expectation of a “good photograph”. However, as I interacted with more photographers, read about photo techniques, had my work critiqued, and refined my taste in photography, I realized that my ability to execute had lagged far behind my expectation. Every photograph became a failure, every photo walk a chore.

Every hobby I’ve picked up has a similar story, except for reading, writing and cycling. I think the feedback loop is so tight in those activities, that any input of effort, has a clear and obvious impact on the output.

This concept isn’t new. In fact, the realization came mostly from reading “Flow”, which I already wrote about in A Moment of Clarity in the Pursuit of Happiness.

The question remains though, what can be done to fix it?

The Solution

I don’t think I can reduce my expectations. I can’t unlearn what makes a good photo, painting, garment, or meal. What I can do however, is set quantifiable and achievable goals. I love cycling because I can measure my performance and compare it against my peers. The competitive challenge drives me and the data-tracking gives me feedback on my progress. Feedback is essential since it justifies my investment of time. Without the feedback, frustration and boredom kick in and I move on

I can set personal challenges that let me operate at the limits of my skill for any of my hobbies. For example, instead of trying to “make a good photo”, I can take an existing photo that I like, and reproduce it. I can set myself a goal of reading a certain number of “favorites” on Flickr. I can decide that I want to make some money from my tailoring.

Those are clear goals that I can work towards. Achieving a goal gives me the positive feedback I need, and increasing the challenge as my skill grow will close off the loop. Eventually, the skill will grow enough with practice to close the gap with my expectations. Until then, I need to put my expectations aside and work towards an achievable goal.

If you’ve ever struggled with the same problem, I hope this works for you, it’s certainly working for me.

Modern Web Development

2012-04-23T00:00:00-07:00

The blog post is the first in a series of posts that attempts to outline what a modern web development toolchain looks like and how to use the best-of-breed tools for efficient, effective development. Part two will outline how to use to set up your Terminal, zsh, and vim

The mobile landscape today is all but monopolized by WebKit, as a result, most of the tooling and infrastructure to support mobile web development on the frontend is taking place in the WebKit Inspector, so I’ll focus on it, and take a deep dive into its entire feature-set and how and when to use it.

Google and the Chrome team have been pumping a ton of resources into the WebKit Inspector. The changes have enabled a whole new class of complex and ambitious applications that would have otherwise collapsed on their own weight. This is great news, of course, but as I talk to more and more web developers about their process and tooling, it became clear to me that many of them haven’t caught up with the changes or aren’t making effective use of the tooling available. This blog post attempts to remedy that, not only by walking you through the inspector’s feature set, but also highlighting certain techniques for bug hunting and feature development that I’ve found to be indispensable. The post is meant to be scannable and shareable. You can click on any header to share a URL to a specific tip/technique or feature to your friends.

Before We Start

Before we start, I want to make it clear that I don’t claim to have infallible knowledge on tooling and process. If you find any of this information to be incorrect, out-of-date, or inefficient, please reach out to me and let me know, I’d love to hear your thoughts.

If you’re new to the inspector or have a passing knowledge of it, do me a favor and play with it as you read this post. Trying things out are the best ways to learn it! “But Majd, I don’t want to keep creating new files and loading them and editing them to test these things out! I have kids to feed!” I hear you, and I agree with you, that’s where the data: URL scheme comes in!
Try it out: Open a new tab of Chrome, and paste this into the address bar and hit enter:

data:text/html,<b>ZOMG I AM BOLD!?!!?</b>

This is one of the easiest ways to get some HTML into the page and start inspecting it and playing around/investing ideas. Anything after the comma is interpreted as html and once loaded, you can open up the inspector and start playing with it!

One Inspector to Rule Them All

There isn’t a single WebKit Inspector. In fact, there are 5 at any given time that you can use:

Safari Stable
Chrome Stable
WebKit Nightlies
Chromium
Chrome Canary

I’ve tried to sort them from oldest to newest. Chrome Canary gets updated with new features all the time. After they bake for a while with the early adopters, they make their way slowly to Chromium, WebKit Nightlies, Chrome, then Safari. At any given time, Safari’s Inspector is about a year’s worth of development behind Chrome Canary. That is to say, use Chrome Canary for your development.

Getting Set Up

Awesomesauce. You’ve downloaded Chrome Canary, you have it open, you have your site up, you’ve cracked your knuckles and rolled up your sleeves. Hit CMD+J to open up the Inspector or right click on a specific element and click “Inspect Element”.

Now let’s set up the environment so you’re comfortable. The first thing to do is familiarize yourself with the UI. Take a minute to click on every button you see, hover over it to see the tooltip, and find out what everything does.

Dock to Right

The first thing you’ll want to do is click on the gear icon in the bottom right to bring up the settings. Ignoring the horrendously ugly HUD display, I highly recommend checking the “Dock to Right” setting. What this does is stick the inspector to the right side of your window, but keeps it attached. If you decide to pop it out into its own window, then opening multiple inspectors at the same time can become confusing. If you dock it to the bottom, you get a lot of horizontal space, but vertically you’re very constricted. Docking to the right is the best of both worlds. Here’s what it should look like:

Emulate Touch Events

If you’re working on a mobile application, this setting (in the settings HUD) is essential.

Google, if you’re listening: Default the docked setting to “Dock to Right”.

Keyboard Shortcuts

Another quick tip to help speed up your work with the inspector is to get very familiar with the keyboard shortcuts. Go to the Elements Panel (some of the other panels eat the keystroke), and type “?”. This should bring up another horrendously ugly HUD display that contains a list of keyboard shortcuts. The most helpful shortcuts are the ones to navigate the Scripts panel, which we’ll talk about in a bit.

Google, if you’re listening: Make the keyboard shortcuts accessible from the settings panel. Most people don’t know the secret key. While we’re on the topic, why does the HUD have a different light source than the rest of the UI? Why is the border radius so big? Why is the “X” button not vertically centered in the header? Why are some of the shortcuts so small you can’t see them?

Inspecting an iFrame

Debugging iFrames has long eluded web developers. NO MORE! You can now set which iframe the inspector is inspecting through the popup in the bottom center of the inspector that says “”. This panel is interestingly only visible when you have the console expanded (hit escape from any panel).

Google, if you’re listening: Make the iframe drop down accessible everywhere.

The Console

Sweetums. You’re all set up, you’ve cranked up your music, and you’re hacking your heart away. Now you need to actually do something: Run a command, check the output of a function, check for the existence of a method, or see any logs/errors/warnings. This is where console comes in to help. The console is such a badass, in fact, it not only gets its own panel, it’s also accessible from any other panel by hitting the “>=” icon in the bottom left, or by hitting the Escape key.

It also happens to be one of the more intuitive features: Type something, hit enter, see the output of the expression. Any logs are visible chronologically, click the file name on the right and get taken there in the Scripts panel. What you may not have known though, is that you can type multi-line expressions in the console by hitting “shift + enter”. This is really helpful for writing out long commands that involve anonymous functions or complex statements. You can also type “ctrl + L” to clear the console when the logs get overwhelming.

From a DOM-debugging perspective, one of the cooler features of the console is its integration with the Elements panel (which we’ll discuss in the next section). Any element that’s selected in the Elements panel can be quickly accessed using “$0”. That will reference the element and allow you to interact with it. Inversely, whenever you see a DOM node printed in the console, you can right click on it and click “Reveal in Elements Panel” to quickly find it in the DOM.

Google, if you’re listening: Add syntax highlighting to the console command, it’ll help simple parse errors. It wouldn’t hurt to auto-insert braces and parenthesis and quotes, too.

The Elements Panel

So you got you’re all set up and ready to start building your application. The first step is to get your HTML and your CSS looking right (Or JavaScript, depending on your workflow). That’s where the Elements Panel comes in.

DOM Manipulation

The Elements Panel comes into play whenever you are modifying/debugging CSS or the DOM. The main area of the Elements panel is your live DOM hierarchy. As you make changes through JavaScript, you see them reflected live in the Elements Panel. You can use the arrow keys to navigate the hierarchy, and double click on any attribute to edit either the name or the value. You can also click-drag any node in the DOM to reorder it and change its position.

Because its live, I find myself doing a lot of experimentation in this panel. Drag this node here, does it fix that z-index ordering issue? That div is invisible, is it being hidden by another layer?

At the bottom of the inspector, you’ll find a magnifying glass. When you click [that, you can hover over your application itself and it will highlight the node you have selected. This comes in handy when you need a quick way to go to a deeply-nested element.

While you’re playing around with the Elements panel, try right clicking on one of the nodes and see the options that come up. One of these of note, is the “Break on Subtree Modifications” option. When you enable that, any changes that you make to the DOM hierarchy under that node, it will automatically pause, and let you debug it.

CSS Editing

Moving on to the right, the CSS editor is up-there in the list of most-helpful features of the inspector. Superficially, it allows you to live-edit your CSS. However, it reduces the barrier to experimentation so much, I find myself moving things around and playing around with ideas I normally would’ve dismissed as stupid, which is a good thing, as Bret Victor says.

The first thing in the list you see is the “Computed Style” section. Check the “Show inherited” checkbox, and you will see a list of every single style property and its corresponding value that’s applied to the selected node. Even if you didn’t explicitly set a property, it will show you the inherited default. This helps you not only understand what is making up the styling of the node, but it also helps you find out what properties you can set yourself to modify it. Take a quick look at it and see if there are any CSS properties you didn’t know about, then try them out and see what they do!

Next in the list is the “Styles” section. This shows you the list of properties, grouped by selector, that have been applied to the node. The first sub-section here says “element.style”. This shows the properties set through the style="" attribute in the HTML. The next section titled “Matched CSS Rules” shows you the selectors that matched the selected node, their properties, and their values, along with the file name and the line number on the right.

To add a new selector, click the “+” button to the right of the “Styles” header, here you can define the selector, hit tab, then start writing properties and values. You’ll notice Chrome offer auto-complete suggestions (this is another great way to investigate which properties you can set). The version of Canary as of this writing requires you to hit the right arrow key to fill in the autocompletion, then you can hit tab to set the value. Hitting tab again will let you set the next property. If you wanted to set a new property to an existing selector, click once on the closing bracket. Clicking on the button to the right of the “+” new selector button will allow you to specify a pseudo selector. Handy!

Colors behave slightly differently. Clicking once on a color value will toggle through a list of representations (hex, rgb, rgba, etc), and clicking on the little colored square will open up the color picker.

All this is great, but let’s say you’ve just spent 10 minutes editing CSS. Now what? How do you save those changes? To do that, click on the file name of the selector (or go to the file yourself in the Resources panel), then right click on the file (which will be updated to reflect those changes), and you can right click to “Save As” and overwrite your existing files. Personally, I find selecting the text and pasting it into my editor to be faster and less error-prone.

One final node on CSS Editing: If you write a new selector (by hitting the “+” key), it won’t persist into a file because it doesn’t know which CSS file to put the selector in.

Google, if you’re listening: Prompt me which file to put a new selector in when I create one. Also, make “tab” fill in the selected auto-completion. Finally, find a way to make persisting changes in CSS to my code easier. This last one is more of a high-level wish, I don’t really know whether or not it’s possible nor how it would work, I just want the process streamlined :P.

Metrics

Phew, that was a handful! Take a minute to play with all this. When you’re done, let’s move down to the next item in the list: Metrics. If you’re not familiar with the CSS Box Model, take a minute to read this awesome guide.

The Metrics section basically shows you how the browser is rendering a node from the perspective of content size, padding, border, and margin. Use this tool to debug positioning/dimension problems.

A nice companion tip to the Metrics panel, is that the semi-transparent blue box that overlays the selected node will actually show you the padding and the margin, so you can understand how a box is affecting the flow

Blue is for content, green is for padding, and orange is for margin.

Event Listeners

We’ll skip Properties and DOM Breakpoints for now. I haven’t found a use for the Properties section yet, and DOM Breakpoints shows you any “Break on …” actions you’ve taken by right clicking on a node. The last section we’ll talk about in the Elements panel is the Event Listeners section.

If you’ve attached any event listeners on your node (either using JavaScript or using the attribute in HTML), you’ll find those listeners listed here. This comes in handy when you want to debug whether or not a listener has been properly attached to a node, and what will happen when it gets invoked.

Clicking on the little funnel icon on the right allows you to see either the listeners on the selected node or in the document. This comes in handy if you have listeners attached on things you can’t select in the main list (like window, document, etc).

The Resources Panel

Your HTML and CSS are looking good, and you’ve got a fair bit of JavaScript written to use either the FileSystem API, IndexedDB, LocalStorage, App Cache, or Cookies. The Resources panel is where you go to inspect and debug all these storage resources. Most of them do more or less the the same thing and are pretty self-explanatory: Click a resources, see a list of items, and dig through to navigate your data.

Of note is the first item in the list called “Frames”. It includes a sub-item for every frame in your application, and groups resources such as Images, Scripts, and Stylesheets. Really the only reasons I’ve found to dig through this list is to find a Stylesheet file I edited so I can copy its content and paste it into my editor to save.

The Network Panel

The Network Panel comes in handy when you’re debugging, well, network issues. Is your image asset not updating? The network panel will tell you whether or not it’s being served from a cache. Is your XHR not responding? The network panel will tell you if it’s stuck or error-ing out.

Clicking the “Record” button (the black circle) will maintain a Network session across reloads, handy if you want to see how a change in your codebase affects the network performance.

If you find yourself debugging performance issues, the Network Panel is also very helpful. On the right, you see a “cascading waterfall” of your network requests. If your page is taking a really long time to load, your first step in debugging it would be to look at the waterfall. The blue and red vertical lines show you when the DOMContentLoaded event fired, which means that before then, your use is sitting around waiting for something to happen. You want to reduce that time as much as you can.

The Waterfall

Why do I keep calling it a waterfall, you ask? Well, it looks like one, but more importantly, the reason it looks like a waterfall is because every network interaction takes time both in network latency, and in download time, and the browser can parallelize only so many of them. If your waterfall is wide, you need to go out of your way to cut HTTP requests.

By the way, you can click on the “Timeline” header and you get a drop down (!) to change the sort order. Particularly interesting is the “Latency” sorting, which shows you which of your requests took the longest to establish.

The half-transparent left-side of the capsule shows the latency, and the dark part on the right shows the download time.

The Request Details

On the bottom of the Network panel, click “XHR” to filter the network connections just to XMLHttpRequests. Then click one of them. You see that the right side now changes to show details of that specific request. The first tab shows you all the HTTP Headers sent with the request, and those of the response. This helps when debugging server bugs or CORS bugs.

Preview is a pretty-formatted version of Response. If you’re getting back a lot of JSON, the Preview tab will format it into a collapsable list for you, whereas the Response tab will show it in plain text.

Cookies show you the cookies that were sent as part of the request, and Timing shows more details regarding the time profile of the request. Again, helpful if you have requests taking a long time.

The Scripts Panel

I’m a full-time JavaScript developer, which implies that I spend most of my day in the Scripts Panel. It has also seen some of the biggest changes recently.

Looking around, two buttons worth mentioning are the “Pretty Print” button (looks like a pair of curly braces), which will properly format a minified file. This comes in handy if you get a bug in a third-party minified package and you want to have an even remote chance of figuring out what is going on.

The other button worth mentioning is the “Break on Exception” button (Looks like a pause button). When gray, it’s disabled. Clicking it once will cause your script to pause if it hits any thrown exception. Clicking it again puts it in the “Break on Uncaught Exception” mode, which only pauses your script if you (or something else you use), throw an exception that doesn’t get caught. This is indispensable when you want to track an exception that’s being thrown, since it preserves the call stack and the current state of the application.

File navigation

The addition of tabs in the main workspace and a full file browser, scoped by origin has dramatically improved the efficiency of moving around your project.

To open the file browser, click the weird icon in the top left (it looks like two folders with a right angle between them). By default, the file browser will “float” on top of your workspace, so click the weird icon on the top right of the browser (it looks like a half-white, half-black rectangle) to dock it. Try typing while you’re in the file inspector, it will do a fuzzy-match of the files in your project!

While we’re on the topic of moving around your project, try hitting “CMD+O”, this will open up a TextMate-style “Go-to-File” popover that lets you quickly jump to a file. “CMD + Shift+ O” will open up a “Go-to-Symbol” popover that lets you quickly jump to a symbol in the current file, and “CMD + L” will let you jump to a specific line.

Google, if you’re listening: Add the path to the file in the Go-to-File popover, in case there are duplicates.

Breakpoints

Clicking on a line number in the gutter will insert a breakpoint. If your application hits that line during execution, it’ll pause, bring up the Scripts panel, and highlight that line. Then you can inspect the call stack, the scope variables, and inspect/modify your objects. This is the main workflow when debugging issues with your JavaScript.

Occasionally, you’ll want to debug a problem in hot code (code that gets run over and over). Putting a breakpoint here becomes tedious, since you’d have to hit “Continue” over and over. What I usually do in that situation is wrap the function call I want to debug with “window.foo = true” and “window.foo = false”, then right click on the breakpoint, click on “Edit Breakpoint”, then in the textfield I type “window.foo”. What this tells the inspector is that unless window.foo evaluates to true, don’t stop.

So, you’ve added a breakpoint, you refreshed the page, and now your script is paused. Now, the fun begins.

The first thing of interest in the sidebar is “Watched Expressions”. If you care about the value of some expression (Say “MyApp.someController.property === ‘some value’”), then adding that as a watch expression will let you keep an eye on it without having to type it over and over in the console.

Below that, the “Call Stack” section shows you every function call that the system went through to end up where it did. You can navigate this list using “CTRL + .” to go down and “CTRL + ,” to go up in the stack. I usually navigate this list when I care about how a variable came to have its value and how it traveled through the system.

Next, “Scope Variables” lists the local variables and their variables. If you’re using closures to close over variables, then those will be grouped together. The “Global” group shows you every variable on the “window” object (a huge list). As you move through a function, this list gets updated automatically.

Now that you’ve inspected the state of the app on a breakpoint, you’ll probably want to move around. “Continue”, “Step Over”, “Step Into”, and “Step Out” are your friends here. In fact, you’ll be using them so frequently, it’s worth bringing up the keyboard shortcut list again and learning the shortcuts for them. It’s much more efficient to navigate through the list with the keyboard than the mouse. If you’ve used a debugger before, these terms are already familiar to you. For the web developer though, these are new concepts that we didn’t have before.

Continue resumes the execution of the program. If execution hits the same breakpoint again, it’ll pause again. Step over will skip function invocations and stay within the current function. Step into will enter the new function if it’s being called. If you’re calling multiple functions in the same line, you can step into, and out of each one in order. Step Out will leave the current function and go back up one level in the call stack.

These tools are essential in walking through your code and pin-pointing a bug, or finding out which path through your codebase is being followed.

Another handy tool lives under the “XHR Breakpoints” section. As the name suggests, it sets up breakpoints related to XMLHttpRequest objects. The way you specify the breakpoint, is by typing in a substring of the URL you want to inspect. Handy!

By the way, in the “Scope Variables” section, you can right click on a function and choose “Jump to Definition” to jump to the part of the file that defines that function.

The Timeline Panel

Next in the list is the Timeline Panel. As you might have observed, each panel is designed to help debug a certain class of problems: Elements Panel for DOM and CSS, Resources for local storage and assets, Network for HTTP requests, Scripts for Javascript, and Timeline is for browser performance.

What do I mean by “browser performance”? I’m referring to things that are generally out of your control, but which affect the performance of your application. Understanding what’s happening under the hood is essential to supporting the growing complexity of an application.

Timelines

The first section of interest is the Timelines section. To activate it, hit the Record button (the black circle in the bottom left of the panel). When it’s glowing red, perform a task in your application you like to inspect. If you’re wondering why your scrolling performance is slow, you would try a short scroll. If you’re wondering why loading a modal panel is slow, you would do that. Don’t worry about doing too much and getting overloaded by data in the panel, there are tools to help!

So, you’ve managed to get a nice little timeline of what’s happening, but you’re only interested in a little section of the data. To “Zoom in”, you can click and drag on the timeline graph. You’ll see a couple of draggable thumbs so you can adjust the visible section. Moving down into the waterfall graph, you’ll notice little arrows next to some of the orange capsules. Expand those, and what you’ll see is the function invocation that triggered the browser to do work. In the example below, we can see that a scroll event had fired, invoked a handler, which caused a “Recalculate Style” to fire. If you hover over the item in the sidebar, you see even more detail.

You may be wondering at this point “What are these purple events that are taking up time? Repaint, Recalculate Style, and Layout?”. These are browser-events that are usually invoked by in response to visual changes. For example, If your resize or scroll, the browser needs to do a bunch of work to make sure everything looks as you’d expect it to. You could also invoke these events yourself, so it’s worth understanding what the inspector is telling you and not taking DOM changes for granted.

Recalculate Style

This occurs when you modify CSS properties. In the above screenshot, you see I’m running the same command twice, but seeing different results. The first time I run it, the browser has to Recalculate Style, Layout, and Paint. The next time, it just has to Recalculate style. What’s happening?

Because this is on a fresh page load with nothing visible, giving an unstyle div a height causes its contents to change layout (Layout), causes the visual display to change (Paint), and invalidates the styles (Recalculate Style). The next time I run the same command with the same value, it gets to skip the Paint and the Layout, since they didn’t change. Notice the order: Recalculate Style informs the later processes whether or not they need to get triggered.

Repaint

Back to our empty page, let’s give our div a width, height, and background color so it actually changes visibly on the screen:

Now, it has to repaint both times, but it only needs to calculate layout once. That’s because the Recalculate Style step found that the positioning/dimensions haven’t changed, but the background has, so it skipped that step. Anything that cause a visual change, causes a repaint.

Layout

Often referred to as “Reflows”, a Layout event causes the browser to recalculate the position of elements. For example, say you have a picture that’s floated, so the text wraps around it. If you remove the float, the browser has to “re-flow” the text around it. Paul Irish has a great video where he describes reflows and how to avoid them.

Google, if you’re listening: Please fix the resize behavior. On small Macbook Air screen, it’s common to hit multiple UI bugs when you arrange the inspector/application side by side.

For more detail on how this works under the hood, refer to this blog post.

Memory

Now we’ve looked at the timeline, optimized it, but the application is still crashing every now and then after you use it for a while, sometimes it slows down, and it stutters a lot. You’ve seen a few “GC” (Stands for Garbage Collection, which runs every now and then to clean up unused objects) events in your timeline, the Memory tool helps you debug those issues.

Tony Gentilcore has a great writeup on finding and fixing memory leaks, you should definitely give it a read. I’ll give you a quick overview here.

Click on Memory in the sidebar, then click record. Perform a task in your app, and observe the memory profile. Here’s the memory profile for an app that simply creates an object and throws it away every mousemove event:

A typical javascript memory graph looks like a sawtooth function: You keep accumulating memory until the garbage collector runs and cleans up unused memory. A few cycles through GC runs, and your memory profile should be flat. If it’s constantly going up in between GC cycles, then you have a memory leak. As your application gobbles up memory, the app will slow down, and certain browsers (MobileSafari) will actually kill it.

Below the graph you’ll see some more useful metrics to track the number of DOM nodes, and event listeners, they’re pretty self-explanatory.

Finally, let’s say you deployed your app in production, you found a bug in production, located it in the inspector. How do you tell your coworker/developer? Well, instead of taking a static screenshot, you can actually right click on “Timelines” and “Memory”, and save your session so that you can share the actual debug data! Handy when you’re working as part of a team.

The Profiles Panel

So, you’re now at a point in your application’s development where it looks the way you want it to look, HTTP requests are minimized, and you’re causing the browser to do more work than it needs to. Something’s not right though. Everything seems to be snappy, except for one small part. You’ve tried debugging it with the Timeline panel, but it doesn’t give you enough depth and detail. It’s not the browser that’s slow, it’s your own code.

That’s where the Profiles panel comes in.

JavaScript CPU Profiler

The first type of profiling you can do is JS CPU profile. The description outlines at a high level what it measures: What functions your app spends the most time in.

Select it, then click “Start”. Every action you take now, will be logged until you hit the glowing red “Record” button to stop recording (Or click on the “Stop” button). Once stopped, the profiler will show you an ordered list of all the functions that had executed, and the time it spent in each. You’ll probably see something like “(program)” at the top of your list. That’s webkit taking time to do stuff. You can’t inspect it, and you can’t do much about it (but the Timelines tab should help locate some of those bugs!). Apart from that, here’s what a typical profile looks like:

This is the profile for my blog when I open the photo portfolio and open/close a photo a few times. Looks like the most expensive part of that interaction is setting the curtain’s opacity and retrieving the bounding client rect. Just the info I needed to optimize that part of my app.

Google, if you’re listening: There’s a lot of work you can do here to surface useful information and hide useless information. I often get stuck in infinitely-deep lists, or 99.99% of my time spent in (Program), distorting everything else.

CSS Selector Profiler

CSS doesn’t come for free. Complex stylesheets take time to parse, calculate, and apply. The CSS Selector profiler shows you how many times each selector was matched to a DOM node, and how long the browser spends applying those selectors. In a complex application with many divs of the same type, applying styles to them might take a substantial amount of your app’s startup time.

Heap Snapshot

This is one of the most obtuse views in the inspector. So much so, I haven’t actually found it useful. Take this for example:

The amount of useful information there as far as I can discern is zero. I’ll defer once more to Tony Gentilcore’s writeup, may he light your way.

The Audits Panel

We’re almost there! The last panel is the Audits Panel, and it’s basically the last sanity-check of performance you do before going to production. Essentially, it will inspect the resources and the HTTP requests and suggests improvements based on current industry best practices. For example, while writing this, running the Audits panel told me that I should specify the image dimensions in the HTML to make layout faster. Good to know!

All the tips here are well-documented, and you should at least take a quick look through them.

Conclusion

I hope you’ve found at least some of this information useful. I’ve been writing complex web applications on the desktop and mobile for 2 years now, and I’ve had to use each of these panels to solve a different class of problems.

If I’ve mis-interpreted something, missed something, or made any errors, please let me know.

Perfect

2012-04-21T00:00:00-07:00

I’ve been having a recurring thought recently.

The first time was while I was watching A Clockwork Orange when this panning shot came up:

The music, visuals, the characters and storyline came together so well, and everything in the storyline was working together so well, it gave me goosebumps.

The next time that happened was while watching 2001: A Space Odyssey. This shot captured the same feeling:

More recently, a string quartet was playing in the lobby at work. Four musicians moving in perfect synchronicity playing the same thing. It was beautiful.

Above the individual performance though, whether it was a piece of art, a movie, or a musical performance, I realized that what I was admiring wasn’t the piece itself, but everything that must have gone on behind the scenes to bring it all together. Everything complementing everything else, and everything working together. Nothing is superfluous, and everything is there to serve a purpose.

It’s beautiful, and it’s what I try to do with my work.

It’s not easy though, it takes a ton of hard work and practice. It takes patience and perseverance and a self-critical eye to judge your work as you would just other people’s work. To those who have achieved that kind of refinement in their work, I applaud you, and hope to meet you there at some point.

A Moment of Clarity in the Pursuit of Happiness

2012-02-02T00:00:00-08:00

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?

How Much Skill Can I Gain in 20 Hours?

2012-01-19T00:00:00-08:00

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:

And here’s the fabric I will use for the shorts:

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:

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?

Please comment on the Hacker News thread.

Confidence of the Mobile Web

2012-01-04T00:00:00-08:00

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:

I’m not on my own phone, and I’m using a friends’ phone
I tapped on a link in an app
I don’t want to download your app and have it take up a spot on my phone
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.

John Siracusa on Hypercriticism

2012-01-03T00:00:00-08:00

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:

It is sad that hyper-criticism passes for attention to detail and hyper-cynicism for wisdom.
— Can Duruk (@can) December 7, 2011

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.

From the Junk Drawer: The Broken Pixel Theory

2011-12-25T00:00:00-08:00

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’ve decided to practice practice practice, and this is the first in a series of posts titled “From The Junk Drawer”.

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

Reflexions on my 24th Year

2011-12-10T00:00:00-08:00

This post is written by me, to my future me, in a public way. Hopefully I won’t regret this decision. This will include an unhealthy amount of self-praise and recollection/introspection. Feel free to ignore at will.

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 few open 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.

Eulogy for Steve Jobs

2011-10-05T00:00:00-07:00

I was screaming in the car. I was ecstatic; it was the one thing in the world that I wanted more than anything. I had just come home, my brother had gotten it for me, it was waiting for me on the dinner table. In the packaging, and on the side, it said in a big Myriad Set font: iPhone.

Steve Jobs is more than just a visionary. He is an idea, a philosophy, a way of thinking about life and technology that transcends the technical, and ventures into the creative. He gave a voice to those of us who were voiceless. We all knew things sucked; everything sucked. People hated using technology and we didn’t really know why. Hindsight is 20/20 and we can now clearly see what was wrong and laugh about it, but physical keyboards were cool, and styluses were in, cartoons were for kids, and computers were for scientists, but all that has changed.

Steve Jobs was my first boss, he created a company that I admired and tried hard to work for. I tried to get an internship at Apple three times, and I failed twice. Failure was never an option for Steve, and I never let it be a failure. Coming in second is reason to try harder, reason to improve, it’s a great motivator.

Steve knew early on what it takes to make a good product, he assembled a team to work with him that understood that. The team extended beyond just the senior vice presidency. All the employees who work at Apple understand the Jobsian ethos, if not explicitly, then implicitly. Before the first iPod was sold, Jony Ive knew that they were designing an icon.

The closest I ever came to talking to Steve Jobs was brushing shoulders with him at the cafeteria, but his presense was always felt, was a visionary, a legend, and a thought leader. You will be missed Steve, you meant the world to us.

Thoughts on the Kindle Fire

2011-09-28T00:00:00-07:00

Update: Added section headers

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.

Web or Native? A SXSW Panel Proposal

2011-08-16T00:00:00-07:00

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!

Design for the Mobile Web's Ubiquity

2011-08-11T00:00:00-07:00

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?

Image courtesy of pcadvisor.co.uk

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.

A screenshot of the mobile Twitter app, running inside of Campfire.

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. ¹ 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.

The Fallacy of Modern Web Development

2011-08-01T00:00:00-07:00

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 MVC frameworks, 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.

Building the Next Generation of Mobile Web Applications

2011-07-01T00:00:00-07:00

All mobile web apps today suck. Some mobile web apps come close to being good, like Gmail and Twitter, while some come really close, like The Financial Times and Basecamp. But all the examples fall short one way or another: Gmail’s scrolling is unnatural, Twitter hides the browser’s location bar, Financial Times is riddled with flashing/jittering/scrolling bugs, and Basecamp jumps when you tap on an item. For every one of these examples, there are 10 worse offenders I can point to, but they all share the same essential mistake: They all use the browser as an emulator of native apps. Trying to replicate the native experience on the web is a fool’s errand, and leaves users confused. To move ahead, the web needs to play to its strengths.

First, I’ll highlight the overarching problems with the current fleet of mobile web apps, then I’ll lay a framework for building the next generation of amazing mobile web applications.

Problem: Double-chrome

Consider that screenshot from Google+: There are three back buttons. What do you think will happen if I click the browser’s back button? Will it take me “Home”? or will it take me to the previous app? What will happen if I click the “Nearby” button? What about the “Home” button? Now let’s say I clicked on the “Incoming” link at the top right. What do the buttons do now? The answer is, the browser’s Back button will take me to the previous website, while the “Home” back button will take me to the main Google+ page, and the “Nearby” button will take you nearby. Once you click on a post, the browser’s back button and the button that will replace the “Home” button will do the same thing, but the “Nearby” button won’t. This lack of consistency and predictability is endemic of mobile web apps. This is a problem that native applications don’t usually have to deal with.

The counter-argument goes: If you make the user believe they’re in a native application, they will expect to have a back button in the top-left. Most of the time, this means having a navigation bar that is fixed to the top of the viewport. In reality, that argument makes the assumption that people are using the web app on iOS (navigation bars don’t exist on Android), and that they forget they’re in a web browser. Even assuming the argument is correct, it implies that the cost of learning the back gesture the first time outweighs the cost of having to make a decision on which back button to tap on every single subsequent page.

Solution: Browsers provide a persistent back button at all times that is impossible to get rid of. They also provide a title bar – which admittedly, isn’t persistent – but also provides a reliable way of telling your users where they are. Mobile web apps today suffer from platform-specific, ambiguous elements. Give the user their 50 pixels back.

Problem: Chasing your own tail

iOS has not had support for overflow-auto nor position:fixed until iOS 5. Instead, people resort to elaborate hacks to achieve the same fixed-bar-at-the-top UI of navigation controllers and tab controllers on native iOS apps described in the earlier section. If you’re ever used a web app that used that UI, you’ve probably noticed very quickly how unusual and weird the scrolling behavior is.

Scrollability is the best of the bunch, but it’s still not perfect, and it never will be perfect. The proper solution is the browser’s solution. You obviously couldn’t have used that feature before iOS 5, but my point is that web applications shouldn’t have a fixed bar along the top anyway, obviating the need for a scrolling hack (except on iPad for multi-pane UIs. That’s a technical limitation Scrollability is a good solution for). Moreover, for the scrolling hack to work, the scrollable area had to capture touches, which means when user scrolls to the top of the page, they get the scroll-bounce instead of getting access the address bar. For example, if you go to twitter’s mobile web app, you have to know to tap the title bar to scroll to the top of the page and reveal the address bar. ¹ My uncle Bob doesn’t know that tapping on the title bar scrolls his view to the top, so he’s essentially stuck in the app.

The fundamental problem is that people are trying to emulate as best they can what a bunch of engineers did at Apple 4 years ago. Apple can change interactions, behavior, and widgets between versions, and everyone who’s trying to emulate them, has to continue playing an endless game of catch-up.

Solution: Once you eliminate the double-chrome problem and the fixed-navigation-bar problem, you eliminate a lot of the issues that make mobile web apps terrible.

Problem: Forgetting what the web is about

Mobile web app developers seem to have forgotten that the web is inherently cross-platform. That’s the whole point of the web: Ubiquitous access to information. What’s the point of building a mobile web app if you’re only targeting iOS users? If you are targeting multiple platforms, why are you forcing the iOS UI on non iOS users? The navigation bar with a back button does not exist on Android, users won’t be expecting it, so save yourself the 50 pixels of screen real estate.

Solution: Build a UI and UX that is platform-agnostic.

Now that we’ve outlined some of the problems of the existing fleet of mobile web apps, let’s analyze how to build the next generation.

Build a mobile web app when it makes sense

Not every app is a suitable candidate for the mobile web. It’s important to analyze the strengths of the web and see if your application stands to benefit from them:

No installation: The barrier to entry for a new user to your app is essentially zero. As soon as a user has expressed interest (by clicking on a link), they have instant access to it. This quality is essential for certain classes of applications that require either an impulsive action, or a trial. If your app needs to get viral, it needs to be a mobile web app. There are counter examples: Instagram, Angry Birds, etc. However, instagram still needs to build a scaled back web page to share with people, and in the case of Angry Birds, they had to build different versions for every platform (and ultimately, the web). I’m using Angry Birds here as an example for the virality argument, clearly, I don’t think Angry Birds should ship as a mobile web app today.

URLs: This one goes hand-in-hand with the previous benefit. The fact that you have a URL to an application means you can a) encode the current state in the URL, and b) send that application in its current state to anyone in the world, on any device or platform. If your app stands to benefit from share-ability, it needs to be a mobile web app.

Auto update: Mobile web app users are always using the latest version of your application. You can ensure 100% penetration of new features and bug fixes almost instantly (allowing time for caches to expire). If your application needs timely security fixes or a/b testing or iterative user feedback, it needs to be a mobile web app.

Cross-Platform: Most people aren’t on iOS. Nor are they on a Mac. Those users represent real people, with real jobs, real bank accounts, and real user needs. The web is the only example of a wildly successful, healthy cross device and form-factor platform. If you app needs to reach a wide audience, it needs to be a mobile web app.

Notice how I didn’t mention performance. Performance on the web needs to only be good enough to deliver a great UX, it doesn’t need to be infinite. If you were instead building an oscilloscope app for the iPhone that needs to analyze large amounts of data quickly, please don’t build it as a mobile web app.

Uncanny Valley

Bill Higgins wrote in May 2007:

So I’d recommend that if you’re considering or actively building Ajax/RIA applications, you should consider the Uncanny Valley of user interface design and recognize that when you build a “desktop in the web browser”-style application, you’re violating users’ unwritten expectations of how a web application should look and behave. This choice may have significant negative impact on learnability, pleasantness of use, and adoption. The fact that you can create web applications that resemble desktop applications does not imply that you should; it only means that you have one more option and subsequent set of trade-offs to consider when making design decisions.

Rasmus Lerdorf, the creator of PHP, once gave a talk to us at The University of Michigan where he was talking about performance. He gave us an anecdote from his time at Yahoo! where they asked users to use Yahoo! Mail and Gmail and asked them to rate which one was faster and which was slower. Although Yahoo! Mail was faster at a technical level, the users said Gmail was faster. His hypothesis was that users compared gmail’s performance to Hotmail, but Yahoo Mail’s performance to Outlook/Mail.app. The takeaway is, by copying a different platform’s UX, the users had a mental model that did not match what they were using. I don’t know the accuracy of the anecdote (I’m recalling it from two years ago), but I think the point holds true today.

Web developers today use iOS as a starting point for every mobile web initiative. It’s a great platform, I don’t blame them, but iOS is only one of the platforms the web supports. On Android/WebOS, most of iOS’s interactions don’t make sense, on iOS, if they’re slightly off, they’ll break the illusion to the user. It’s a no-win situation. The Web has achieved cross-platform dominance by not imposing a platform-specific UI on multiple platforms.

The Financial Times web app does a very good job of this. It doesn’t feel like an iOS-specific app, and scales well to multiple platforms.

Image courtesy of macrumors.com

This view may seem contradictory to you if you’re familiar with my work. I’ve been involved with the SproutCore project for some time now first building desktop-like web apps, and now building a new UI layer for mobile devices. SproutCore’s mission has been (until the recent 2.0 release) to build desktop-like applications on the web. That argument makes a bit more sense on the desktop: Most desktop computers share a keyboard, mouse, and across the different operating systems, most interactions will map from one to another. On mobile platforms, that’s not the case, the variety between platforms is huge, and sometimes, input devices exist that don’t on other platforms (trackball, physical keyboard, hardware-based gestures, etc.) Furthermore, desktop browsers are much, much more capable than their mobile counterparts. That’s not to say that in a couple of years when mobile browsers get fast, that uncanny valley will no longer be an issue. After all, although SproutCore (and Cappuccino) delivered very strong solutions, neither nor developers flocked to use them.

Conclusion

The web platform on the desktop is much more capable than its mobile counterpart. For a while now, we’ve been able to build incredibly complex, compelling UIs on the web with no compromises. Desktop browsers are much better today at compatibility than they were before, and we have much better debugging tools.

On the other hand, developing mobile web applications today is akin to developing a web application on the desktop in 2004. The saving grace is that the pace of progress on today’s mobile devices is far, far faster than it was on the desktop. iOS 5 on an iPad 2/iPhone 4 is ready for the mobile web, Android isn’t (but that’s a topic for another post). The next generation of mobile devices (and worst-case scenario, the one after) will catch up to iPad 2/iPhone 4 and the mobile web will be ready to kick some ass.

¹ position:fixed in iOS 5 behaves correctly: When you reach the top of the scrollable area, the fixed bar moves down to reveal the address bar

Why I joined Strobe

2011-06-16T00:00:00-07:00

“One should not pursue goals that are easily achieved. One must develop an instinct for what one can just barely achieve through one’s greatest efforts.”
- Einstein

Three weeks ago I quit my job at Apple and joined Strobe Inc. as a full-time engineer. My job is to start work on a new project under the SproutCore 2.0 umbrella called SproutCore UI. The goal of the project is to provide a UI layer for building complex, app-like experiences on the web.

When I was trying to decide which company to join, I had the mother of all first-world-problems: I had to choose between multiple amazing offers from amazing companies with amazing people. During the process of deciding where to go, Einstein’s quote played a part in shaping my decision. Of all the choices, I decided to join Strobe for its combination of ambition, people, and focus. All qualities I think are essential for a company’s success.

Ambition

Strobe is attempting to provide a platform for web developers to build, deploy, and maintain amazing web apps. It’s no small task and involves multiple moving parts coming together, but the promise is great. If Strobe succeeds, the web will be a better place. The task isn’t simply to build the “Heroku for ____”, rather, it’s to change the way people think about architecting and building applications, and to set the tone for how the mobile web will evolve.

I never want to question the impact of what I’m working on. I never want to feel like I’ve settled for something, nor that I’m content with my current situation. I found a company trying to achieve the improbable in Strobe. When I told people about what Strobe was trying to do, I was faced with skepticism regarding the challenges it faced. That skepticism served as a validation to me: Don’t try to do the doable, try do the impossible.

People

I work with some brilliant people at Strobe. Not only is everyone accomplished, but they are also humble, approachable, and friendly. I knew most of the people in the engineering team before I joined, so I knew what I was getting myself into. Regardless, it’s much different in the trenches. Nobody at Strobe eats lunch alone. No uncertainties go unquestioned, no statements go unheard, and no ideas go un-vetted.

There are a few reasons why that played a role in my decision to join Strobe: Firstly, it allows me to absorb an immense amount of technical knowledge from people much smarter than I am. Secondly, it provides me with unprecedented access to the web community. To affect change at scale, I believe you need to not only have the will, but also the means. At Strobe, I believe that we have the means to change things for the better. Finally, I believe that the type of people you work with can have a dramatic effect on the happiness and the quality of work I produce, and I’m confident that my coworkers at Strobe will bring out the best in me.

Focus

The most important lesson I learned from my time at Apple is focus. I’ve seen large companies flail and waste their time and energy in vain, I’ve seen teams break apart because of a lack of direction, and I’ve seen driven people grow complacent because of a lack of vision.

Late last year, I got a chance to spend a day working at etsy’s offices in Brooklyn. I was taken aback by the focus of their team, and the do-or-die attitude that I sensed in their office. I had the same sense talking to the different people at Strobe, and it has turned out to be very true.

At Strobe, everyone knows what we’re building, why we’re building it, and who we’re building it for. This laser-like focus ensures that talent isn’t wasted, and resources are put to good use.

Conclusion

I’m writing this at 11 PM on a Thursday. The office is full, and everyone is excited. There’s a sense of urgency in the air, and everyone is working towards a single end-goal. I live for moments like this. Everyone on the engineering team understands what’s at stake, and believes that we are in a position to deliver the best solution.

I don’t know how everything will play out, but what I do know is that everyone involved will work their butts off and whatever we do produce will have an impact. There’s no way for it not to.

Gruber recently linked to a quote that rang very true to me:

“Make no little plans. They have no magic to stir men’s blood and probably themselves will not be realized. Make big plans; aim high in hope and work, remembering that a noble, logical diagram once recorded will never die, but long after we are gone will be a living thing, asserting itself with ever-growing insistency. Remember that our sons and grandsons are going to do things that would stagger us. Let your watchword be order and your beacon beauty. Think big.”
- Daniel Burnham

I can’t wait to come to work tomorrow.

Google Chrome - Epilogue and Reader Feedback

2011-06-07T00:00:00-07:00

I got a lot of great feedback from my previous post higlighting why I hated using Chrome yet continued doing so. The feedback ranged from the dismissive to the supportive. In the process, some readers highlighted good and bad things about Chrome I missed that I wanted to highlight in this follow-up post.

Before I get into the feedback though, there were a couple of points I wanted to expand on:

On the status bar

When I wrote the blog post, my complaint about the status bar mirrored that of the search bar: It overlayed the contents of the page. That presented other problems, which had to have their own solutions. When it comes to the status bar, my suggestion wasn’t to go the Safari route by making it a permanent bar (which in my opinion is inferior), but that the status bar as a whole is a useless relic from the olden browsers.

Having had a bit of time to think about it, I think a solution would be to remove the status bar altogether and instead place the hovered-url in the address bar itself. The address bar (or omnibox, as it’s called in Chrome parlance), provides the context of the current and future location of the page.

The assumption I’m making is that people use the status bubble to see what URL a link will take them to. By placing the hovered-url in the address bar, you also eliminate a mental step the user has to go through: Instead of hover, look at the bottom left, click, and then look up at the address bar, you just hover, look at the address bar, and click to commit the action. Moreover, you eliminate a confusing element from your browser!

On the search bar’s behavior

There seemed to be a bit of confusion regarding what I was suggesting when I complained about Chrome’s search bar. My complaint was that it overlays the contents of the website, not that it was inlined to the window. In contrast, Safari’s Search-in-Page UI is far superior in my opinion, since it is still inlined to the page, but it shifts the contents of the page down as it reveals itself. The separate window for searching the contents of a page was a terrible idea and I’m glad it’s largely history at this point.

On Chrome Develepor Tools’ non-native toolbar

Wes Campaigne wrote to highlight a bug he filed over a year ago

The reason I decided to include this comment here because it highlights an aspect of Chrome which I think is the root cause of a lot of issues. Specifically:

It is not as easy as it might seem – we are talking about dragging native window by the tabcontents content. I think in Safari, toolbar is transparent and we are dragging by the window itself.

Chrome is a cross-platform browser and shares a lot of code between its Windows, Linux, and Mac variants. To achieve that goal, they have to fake a lot of native behavior in their cross-platform components. What’s interesting about this though, is that I checked out the Chrome codebase and as far as I can tell, Chromium (the open-source codebase for Chrome) uses a shared component but the UI layer is built specifically for each platform.

Chrome’s open-tab behavior

Chris Karalus writes to highlight Chrome’s new-tab behavior. If you open a new tab, Chrome intelligently places that new tab adjacent to the current one. This creates a natural grouping of related tabs with no explicit user action. This is UX at its best: Interpret the user’s intent, and let the UI adapt to it.

On the download bar

callahad on Hacker News wrote :

Actually, in OS X, the Chrome icon in the dock has a small pie chart overlay during downloads that indicates both the number of pending downloads as well as the aggregate progress of all downloads. If your dock is hidden, you can quickly and easily check the progress by hitting Cmd-Tab. In Windows 7, the “tile” in the Windows “Dock” fills from left to right, like a progress bar, to show the aggregate status of downloads. You can also click on the in-progress download, dismiss the dialog, and the file will open once the download completes.

On the preferences pane

callahad again from Hacker News :

you can actually link to specific pages and panels. Though this doesn’t help you find a preference in the first place, it does make communicating the location of known preferences much simpler.

On integration with OS X

Kurt Landrus writes:

The one feature missing in Chrome and Firefox that keeps me in Safari, is the ability to drag or copy Rich Text from the browser to another app like text edit or MacJournal, Chrome and Firefox only copy plain text. I use this all the time for research.

Conclusion

The response I’ve received seems to suggest that a lot of people weren’t aware of any of these issues. The post also seems to have generated a healthy debate regarding the merits of my arguments and their objectivity. Whether you agree with my complaints or not, I think it’s important to take a critical look at the software we use every day.

On a separate note, it seems like the Chrome team has taken notice of the complaints and there are been bugs submitted to track those issues. Hopefully some good will come out of my ranting!

Google Chrome - Why I Hate It And Continue To Use It

2011-05-31T00:00:00-07:00

Update: striked-through a reference to the search bar overlapping search results. It doesn’t do that. (thanks to everyone who let me know).

This is the third time I have tried to use Chrome. The first two attempts lasted two days before I uninstalled it and went back to the comfort of Safari. Every time I use it, I end up venting my frustrations on twitter and face the inevitable backlash from my Chrome-loving followers. My problems with Chrome always revolved around its UI and UX, and this post will highlight the reasons I reached my conclusions.

First, I’ll highlight the things that Chrome gets right. Credit where credit’s due, and all that.

The Good

My current attempt to use Chrome as my default browser is much more successful than the previous ones. I’ve been using it for just over a week now and have finally gotten over the initial hump of disappointment. My hypothesis is that every time I try to use Chrome, I end up interacting with the browser itself for two days and not really using it to browse the internet. Once I got past the UI issues, I found Chrome to be a fine browser.

Unified search/location fields

By far, my favorite feature of Chrome is its unification of the search bar and the location bar:

This combination eliminates a decision every time I search/go somewhere. Not only that, sometimes I find myself switching between a search query and a URL mid-way through typing it!

Tab closing behavior

This one should already be familiar to you.

Tab exposé

This is an opt-in feature of the Canary builds which you can enable in about:flags

When I first found out about this feature, I thought it was a gimmicky but I found it works great especially with the trackpad (swipe three fingers down to activate).

Recently Closed / Restore session

These two go hand-in-hand, basically, being able to restore a session or re-open a recently-closed tab has saved my butt a few times and I appreciated the feature.

Developer Tools

The Chrome team has added some amazing debugging and inspecting tools to the webkit inspector (and they broke a bunch more, but we’ll get to that later). I find myself much more productive when debugging my web apps in Chrome vs. Safari.

The Update Process

…or lack thereof. The fact that Chrome sends you tiny diffs and updates its binary is amazing on a technical and UX level. It completely blurs the line between native and web app and I strong-heartedly stand behind this. More apps should do this and someone should release a framework that simplifies it.

The Bad

This is a list of what bugs me about Chrome. I will admit that on their own, a lot of these are tiny issues, but in aggregate, they form a sloppy browser. Death by a thousand cuts.

Lack of RGB Anti-Aliasing

Take a look at this zoomed-in screenshot of the New Tab page:

Notice how it’s using Black & White anti-aliasing? My guess is that they have
the text on a hardware-accelerated layer and not setting a background color on it, which causes the text to lose the anti-aliasing.

Look what happens when I give it a background-color: white;

Why this is something the Google engineers don’t do is beyond me. This happens in multiple places throughout the UI, not just the New Tab page.

Terrible PDF font-rendering

Chrome uses a non-native PDF viewer. That isn’t an inherently bad thing, you can be better than the native alternative, but this is anything but. Compare the text in the picture below between Safari’s PDF viewer and Chrome’s PDF viewer.

The Downloads Page

This one is a double-whammy. In Chrome, the downloads page opens in a separate tab, as opposed to a separate window (like Safari, Firefox, etc. all do).

Here’s my problem with this: Because the downloads window is a tab within the same Chrome window, they needed to add extra UI to show you the progress of your downloads are you browse. The way they do this is using the Downloads bar:

This bar eats up 43px of screen real-estate in the browser. If you wanted to reclaim your space, you can’t monitor the status of your downloads. If you don’t hide it, it stays visible long after all the downloads are done.

This is a solution to a problem that shouldn’t exist. By making the downloads manager a separate window, you can monitor it while you browse. Not only that, but you can view individual progress of your downloads vs. the aggregate.

You could tear-off the downloads tab and treat it as a separate window, but not only does that require user action, the UI isn’t designed to be compact, so you still can’t make the window small and get meaningful information.

The Title Bar

Because the tabs live in the title bar, and because the rest of the chrome (note the lowercase c) is not-draggable, the effective draggable area in Chrome is a thin 10px strip at the top of the window.

I’ve highlighted the section of the window which you can drag. It’s tiny!

The second problem with the tab bar being in the title bar is that when you have many tabs open, you have to rely on a tooltip to figure out what the title of the tab is.

Massive Preference List

When I first started using Chrome, I thought the preferences-as-a-tab was a heinous crime against humanity, however, after using it for a week, I’ve come to the conclusion that it doesn’t inherently present a UX problem. What does present a UX problem however, is the massive number of preferences Chrome exposes to the user:

I recognize that most people won’t peek “Under the Hood” but for most people, the large number of options makes finding what you want hard, even with the search feature.

Favicons Everywhere

I hesitated at first to list this, thinking it was too subjective. However, upon further consideration, I feel like I can lay out an argument for why it is actually bad.

Consider this site. I’ve put a lot of work into making sure that this website is as simple as possible, allowing you to, the reader, to focus as much as possible on the content without any distractions. However, in a typical session in Chrome, you’re innundated with favicons in the location bar, in the tab bar, and in the bookmarks bar. This not only clutters and cheapens the chrome of the browser itself, but it also distracts from the aesthetics of the article and impacts the motif I’ve built.

Another problem is that favicons are duplicated on the tab bar and on the bookmarks bar. However, the address bar doesn’t include them (just has that globe icon). This means that you end up seeing the same favicon multiple times unnecessarily, adding to the clutter.

While we’re on the topic of bookmarks. Notice that “Other Bookmarks” button? It’s empty. there’s the “»” button next to it, that shows me the “other bookmarks” which I can’t see because they don’t fit, but “Other Bookmarks” apparently means something else. I assume it means regular bookmarks (not on the bookmarks bar), but I couldn’t figure out how to add a page to that list.

Search Field

The search field covers the content of the site, if you ~~were searching and a match was under the field, or you~~ wanted to click a link/button under the search field, you’re out of luck.

In the case of a web app with a toolbar (This screenshot shows MobileMe, but the same UI model exists in most web apps), the search field actually covers the main parts of the UI, you have to dismiss it before you can use the app!

Status Bar

The status bar can be in one of three states: Bottom left, hanging off the window if it fits, or on the bottom-right. As you move your mouse in the bottom left corner, the status bar will move and jump around erratically.

This is a video showing the problem. (h.264 mov)

Your browser does not support the video tag. You should probably not be reading this blog post.

The New Tab Page

The list of tabs is horizontal, instead of vertical, there’s not enough space to read the title, and it’s hard to quickly and visually see what page is what.

Note: In the Canary builds, there’s an option in about:flags to enable an experimental Tab Page which is much better.

The Tab Bar

Again, because the tab bar is in the title bar, if you have a lot of tabs open, you end up having to hunt for the tab you want, and you can’t read the title of the tab you’re on.

Loading UI

When a new page/tab is loading, the only indication is a small spinner in the tab. I continuously find myself wondering whether or not Chrome is doing something or not.

Can you tell at a glance whether this site is loading or not? (By glancing at the chrome, most sites don’t have a giant “Loading” UI in the middle of the page.)

Lack of Attention-to-Detail throughout

Everywhere you look, things are mis-aligned, and broken. Here are a couple of examples:

Broken gradient in the toolbar of the Developer Tools

Not only is this using ugly and non-standard menus, but the first item remains curiously selected.

There is a highlighted item in this menu, can you find it? Neither can I.

I’ve counted three different menu styles in Chrome. The bookmark bar menu, the contextual menu in the bookmarks manager, and the customized native one in the Tools menu. This creates a confusion among users as the three menus behave slightly differently.

Notice how the error icon overlaps filter list in the Network tab of the inspector.

To change the sorting, you have to click on a header of a column (no indication that it’s clickable), and then select from a drop down. Who came up with this one?

When you open a new tab and go to a page with a scrollbar, it overlaps the resize handler.

The Network Tab

The Network Tab is an addition to the webkit inspector that still hasn’t made sense to me. Before it was introduced, The Resources tab was where you go to browse the…resources (js, css, html, xhr, etc) of your page and inspect the response/request headers. Now, you can access the same information in both the Resources tab and the Network tab in different UIs. The Resources tab doesn’t require a refresh, but the Network tab does.

The Network tab is also one of three ways you can view the contents of a file. Imagine an email app that has three different places to show you the list of emails in your inbox, in the same exact format, in three different places of the app.

To add insult to injury, the Network tab is the only place you can view the size/time statistics of your application, but you can’t view aggregate data. If someone could explain to me why the Network tab exists, I would be grateful.

Non-native behavior, Native look

Go to the developer tools, notice how it looks like it has a unified toolbar? Funny thing about that is, you can’t actually drag anywhere other than the title bar. Again, I’ve highlighted the area of the toolbar that’s clickable.

Conclusion

It’s been just over a week by now, and I continue to use Chrome. It may seem hypocritical, but the combination of search and address bar and the rate of iteration keep me hooked. I think it’s a bit like gambling, I keep using it with the hope that tomorrow all these problems will be fixed. As an anecdote, Google announces things like memory inspection that keep my interest in Chrome high. I feel like there’s a lesson here for other projects, maybe it deserves its own blog post.

As I said previously, a lot of these issues are small, but they add up to a broken experience and lots of little frustrations. I expect a lot of people to tell me that they don’t mind a lot of these problems, or that a lot of these problems are not in fact, problems. Finally, I also realize some of the problems tend to be subjective, but you came looking for my opinion, and I opined :)

What I Learned From Releasing My First Open Source Project

2011-05-30T00:00:00-07:00

Yesterday was a roller coaster ride. I woke up in the morning, fleshed out a quick README file, took a screenshot and a screencast, and launched my very first open source project. The project is called Waldo now, but it released under the name “VimAck”, and it was under that name that it hit the front page of Hacker News.

In the meantime, The repository has 105 watchers, I’ve merged three pull requests, I’ve implemented 2 new features, and also released two new versions. All in the span of 20 hours. Like I said, roller coaster ride.

I’ve had some time to think about my experience overnight, and I’ve already had to learn a bunch of lessons I thought I’d share with you.

Be your own QA department

When I released version 0.1, the search button was labeled “Button”. I had shown the app to 3 friends before releasing it, but everyone assumed I would change it before release. I even took a screenshot/cast with it and even published it live! I wouldn’t have even noticed had it not been for a friend on twitter. Basically, what happened was that I assumed it worked for the simple case I was developing it with and was so focused on getting it to work I forgot to actually change the label.

I’ve gotten better at with version 0.3. Before release, I go through both the installation, setup, and usage process, as well as the upgrade and usage process. The only person you can trust is yourself and that’s the only way you can ensure everything is running smoothly.

Something I do want to work on though, is automated testing. This is my first real Cocoa project and I’m not familiar with how testing is done, and it’s something I have to learn.

Takeaway: Rely on your own tests to ensure that things are running, and do it all before each release.

Choose a name wisely, and stick to it

VimAck, the name I released under, was chosen as a working title, and I was so involved in building the first version and caught up in the feedback it released, I forgot to change it.

It’s a terrible name. I couldn’t ever remember whether it was VimAck or AckVim, there was already a similar vim plugin called ack.vim, and it just sounded bad.

But here’s the problem with renaming a released project: People have already forked the old repository, links all over are pointing to the old repository, and Sparkle has problems updating to a different app name!

I’ve decided to take the hit early, after all, there were only 7 forker and 80 watchers at the time, and it’s better to do it soon rather than get stuck with a terrible name in the long run.

Takeaway: Changing the project’s name is costly, consider and reconsider your project’s name before launch.

Lower the barrier to contribution

In my opinion, one of the most rewarding aspects of open source software is receiving contributions from the community. A pull request is both a validation that you have created something of value to other people, and that you have created an ecosystem that encourages other developers to pitch in.

For example, zef came up with the great idea of auto-installing the vim plugin on launch. That was something I hadn’t thought of myself. ashchan did the work to make Waldo show up as a status menu item. That is something I had wanted to do, but didn’t know how.

However, you can’t expect people to come up with contribution ideas themselves, which is why I added a “Roadmap” section to the README on Waldo and outlined the upcoming features. I also commented the most code-heavy files in the project and outlined to people how they can contribute.

Takeaway: Do as much work as you can to streamline the contribution process to your users.

Your first release should be a full package

The first release was really only for me to show off my weekend project. What I didn’t anticipate was 100 people to watch it, and 120 people to download it. The problem with releasing what was essentially a demo, is that it wasn’t a full package. What I mean by package, is that it not only has support for the core set of features, but it also has a mechanism to update, an icon, a web presence, a way for people to contribute, and a way for people to file bugs.

Github takes care of most of those problems. Github is truly one of the best things to happen to open source software. I don’t think it’s hyperbolic to say that the world of open source would look a lot different without it. What I didn’t do, however, was include support for Sparkle.framework which meant that for people who wanted to upgrade to VimAck 0.2, they have to know that there’s a new version, and they have to manually download it.

To add insult to injury, the renaming of the project from VimAck to Waldo meant that the upgrade mechanism doesn’t work. Hopefully nobody will face these issues anymore and everything will be smooth sailing from here on forth.

It still doesn’t have an icon, but that’s because I haven’t come up with a good idea for one, but would love to have someone contribute one for me.

Takeaway: Provide a complete package to your users, not just a demo.

Be upfront with your users

The problems with Sparkle and with the renaming caused a lot of headache. For one, a pull requests was broken and was tough to merge, people who forked had bad remote URLs, and people had to upgrade manually from 0.1 to 0.2. As a user, this experience sucks, and there’s no way around it. As the care-taker of the repo, I felt like my trust with the contributors was broken. To amend it, I messaged everyone who submitted a pull request and told them what happened, and I also set up a placeholder README on the old VimAck repo with instructions to people who forked on how to update their repository.

I felt like the communication is especially important in the open source space and it helped people figure out what was happening with the project. Communication is essential since you have people in different parts of the world trying to touch the same codebase and having a clear narrative is essential.

Takeaway: When you make a mistake, ’fess up to it, and provide remedies.

Conclusion

The project is only a day old, and I continue to learn a lot about project management, community building, and communication in general. I hope you can take away a thing or two from my experience with open source. It is incredibly satisfying to see people appreciate and use your software and I thank everyone who helped fork/contribute and those who downloaded!

Reflexions on my 23rd Year

2010-12-10T00:00:00-08:00

This post is written by me, to my future me, in a public way. Hopefully I won’t regret this decision

Hey Majd, this is your 23 year old self. Let me tell you about this year just in case you need a refresher. Hopefully you’ll have done this every birthday and if you don’t, what the fuck is wrong with you? This shit will come in handy when you write an autobiography about yourself.

22 was a good year. Following up the best summer of my life (Apple class of 2009 representin’!), I crammed 3 semesters into 2 so I can get the fuck out of school, graduate, and start my life. Winter 2010 was a busy semester, but it was also the semester I started drawing again, founded the iPhone Developers Club, was president of CSE Scholars, and took some awesome courses. Mostly, I spent most of the semester waiting for graduation. May 1st came, Obama spoke, and I walked.

After graduation, I started waiting to start my job. The team was so much fun last summer and I learned so much, I couldn’t wait to start. May 18th came along, and I head off to Cupertino. Two days later, I found a room in a house in the Castro and decided to move into it. I wonder what this experience will seem like to you in hindsight.

I’m 7 months into my job now and it’s a blast. My coworkers are my best friends and my managers are incredible. The work is challenging, frustrating, fun, and unpredictable, just the way I like it. I’m half way through losing 80 pounds (at 45 right now), and it has already begun to change my life.

So to recap: When I was 22, I graduated, moved to San Francisco, lost 45 pounds, released some of my best code yet. Like I said, it was a good year.

Now that the “what” is covered, I’ll dig deeper. Here are things that I’m thinking about right now.

Wait, before I start. I want you to remember this:

Here’s to the crazy ones.
The misfits. The rebels. The troublemakers.
The round pegs in the square holes.
The ones who see things differently.
They’re not fond of rules.
And they have no respect for the status quo.
You can quote them, disagree with them, glorify or vilify them.
About the only thing you can’t do is ignore them.
Because they change things.
They push the human race forward.
And while some may see them as the crazy ones, we see genius.
Because the people who are crazy enough to think they can change the world,
are the ones who do.

School. What it meant, what came of it.

Was school a waste of time? I haven’t decided yet. On the one hand, I know for a fact that had I not gone to school, I would’ve accomplished a lot more professionally. On the other, I really value the friendships I built during school, and wouldn’t trade them for anything. Besides, I didn’t end up in a bad place, so maybe it all turned out for the better. The thought of having left Michigan 4 years earlier than I did sounds amazing though.

Current Thoughts

What is going through my mind right now? Work, weight-loss, and girls, in that order.

Professionally speaking, work is going great, but I’m trying to figure out what my next move is. I’m happy where I am right now, but I realize it’s not a permanent gig. The more time I spend in the industry, the more I realize how much shit there is out there. Not just that, but how much people don’t care. I’m not the most technically impressive engineer, nor do I claim to be. What I am (or, think I am), is a craftsman. In terms of money and success, I’m starting to realized that I’m not really after “the big exit”. I want to be successful, to be sure. I want my income to satisfy my ridiculous lifestyle and then some, but that doesn’t require a hundred-million dollar bank account. The reason I say that is because I feel like given a more bounded business, I can focus on making products in a life where money is not a limiting factor. I might be an idiot for thinking that, and I may change my opinion. I want to build products, and sell them.

When I’m not working, I’m primarily thinking about weight-loss. I’ve lost 45 pounds so far, and I want to lose 35 more. I just started reading The Hacker’s Diet and it seems to align itself perfectly with my approach to dieting. I’m thinking of starting some kind of blog where I keep track of my stats and write about how I’m doing, hoping to influence someone else.

Thanks to my coworkers who first got me running in the morning before work and biking with them after work, I unintentionally lost 20 pounds, and when I saw the improvements, I kept going. Now that I’ve gone from shirts XL to Medium, and pants from size 40 to 34, I see the profound ways in which being fit and healthy can affect my life. Biking down a mountain, hiking up a mountain, running in races, these are all new experiences for me. These are all things I couldn’t have done no matter how hard I tried 7 months ago. When I go shopping now, I don’t leave depressed, when I go to the gym, I don’t have to keep holding the towel up as I go to the shower. It’s the little things. Things that to other people seems completely benign, are completely new experiences for me. Majd, if you gained back the weight, then FUCK YOU! You should first be ashamed, then on a diet.

Girls. Girls girls girls….There aren’t a lot of Christian Arab girls around here, at least not that I can tell. I guess American girls are cool too, just not the crazy variety. Are you single still? lower your god damned standards! Right now I’m not “looking” to find someone. I’m waiting to lose the rest of my weight.

Attitude

Majd, you always look forward, never backwards. When you moved from Sayyidet Al-Farah to IISA, you learned to speak fluent English. When you moved from IISA to Livonia, you picked up web development. When you moved from Livonia to Ann Arbor, you got a job at Apple. When you moved to Apple…well I’m still here, I don’t know what you did but whatever it is, it better be a step up. Always look ahead.

Closing Quote

Heed these words, Majd.

There’s work, and there’s your life’s work.
The kind of work that has your fingerprints all over it.
The kind of work that you’d never compromise on.
That you’d sacrifice a weekend for.
You can do that work here.
People don’t come here to play it safe.
They come here to swim in the deep end.
They want their work to add up to something.
Something big. Something that couldn’t happen anywhere else.

Swim in the deep end. Always.