Column-based Layout

Moving to a columnar layout has a surprising number of implications. You might not guess that it would take much work to move a list of messages from appearing above the message preview to the side, but a lot of Mail’s previous functionality was based on having that wide, spreadsheet-style list of messages. For example, with the switch to a stack of messages on the side they’ve had to add a sort drop down (previously handled by clicking the column headers in the spreadsheet-like view).

With the old layout it was easy to add a column to the list view if you wanted to see, for example, the number of attachments. The new layout has a little less flexibility and looks a bit cramped with every option turned on.

The new layout has also prompted a change to the search filters bar. In Snow Leopard and earlier, when you started searching a bar would appear above the messages list allowing you to restrict search to a specific mailbox. In the earlier developer previews this was moved to a spot above the new message list, but in the most recent developer preview it has been integrated with the new “Favorites” bar.

Search mailbox filters in developer preview 3.

Search mailbox filters in developer preview 4.

Speaking of the favorites bar, it’s a list of mailboxes that you can customize. The thinking is that you can hide the mailbox sidebar most of the time and just use the favorites bar. If you need the full mailbox list there is an icon on the far left of the favorites bar to show and hide it. Or, if you don’t want to use the favorites bar, you can hide it (but if you do a search it slides down so you can still filter by mailbox).

And if you don’t like any of this new stuff you can still get the classic, messages-on-top layout. If you stick with the new layout, however, you can customize the message list a good bit, selecting how many lines (from none to 5) of each message to preview and whether to show a picture of each sender (based on pictures in your address book).

Search

As Phil Schiller demonstrated at the WWDC keynote, Lion has a new search method that’s used in Mail and the Finder. It provides an interface to the search functionality that was previously only available when creating a smart mailbox. When you start typing in the search field an autosuggest drop down will appear, offering various ways to apply that search term, i.e., find emails where it’s in the subject, or where an attachment matches it, or where it matches the sender, etc. It tries to be smart with its suggestions – for example, if you type “ash”, it won’t just offer to look for emails from “ash”, but will show names from your address book that match (“Ashley”).¹

If you select one of these suggestions then your search term will be replaced by what Schiller called a “token”, which work kind of like the blue oval around email addresses in mail. On the left side of the token is what you’re searching (“From”, “To”, “Subject”), and on the right is your search term. You can click on the left side to change what you’re searching, and you can double click to edit your search term. As Schiller demonstrated you can add multiple terms to create fairly complex searches directly from the search field. One quirk is that if you don’t select one of the suggestions and just hit enter after putting in a search term your term won’t get “tokenized”; it will work exactly like search worked in the past.

You can choose to save any of these searches, at which point you’ll get the smart mailbox dialog that you may be familiar with from earlier versions of Mail, which makes it clear that these search tokens are a new front end to functionality that already existed.

Conversations Threads

Conversation threads aren’t technically a new feature in Mail, it’s just that they were so poorly done previously that no one really knew they were there. Lion fixes that. The threading is smart and the presentation excellent. In previous versions of Mail the threading was based entirely on the subject line. Now, “Mail groups messages into conversations based on many factors, including the message headers, subject, sender, recipients, and date.” From what I’ve seen so far it works.

In addition quoted content is hidden by default, presenting a clean conversation. For those that hate top posting you can choose whether the most recent messages are at the top or bottom.

One other piece that makes the conversation view work is inline actions. Hover over one of the messages in the conversation and icons fade in to delete, reply, reply all, or forward the email. In true Apple style each of these actions animates. Reply, for example, fades in a new email window and a copy of the message jumps from the conversation into the new email window.

Everything Else

Gmail integration has improved, with a dedicated “Archive” button available for the toolbar. Unlike Mail on the iPhone and iPad, however, Lion Mail doesn’t have a single button that switches between deleting and archiving depending on what mailbox you are in. Archive is available for any mailbox; if you click it on a non-Gmail mailbox, it will just create a new folder called “Archive” and move the message there.

“Move” and “Copy” buttons have been added for quick filing of messages. This functionality was available in previous versions of Mail but was only accessible from the “Message” menu.

And last but certainly not least, we’ve finally been freed from the tyranny of the font inspector. Developer preview 4 revealed the addition of an optional formatting bar in the new message window. Hallelujah.

1In the most recent developer preview, however, it’s still a little flaky. Hopefully that is addressed before release.

What I’ve come to realize from all this “research” is that the “Back to the Mac” concept – bringing ideas and features of iOS to the Mac – that Apple revealed at WWDC is much wiser than it initially seemed.

I think the main thing everyone got out of the presentation at the time was “Oh, great, now my Mac is going to have a grid of icons instead of a desktop.” It seemed like Apple was intending to replicate the least liked parts of iOS or at least migrate the pieces that actually fit worst into the Mac paradigm. This impression led many people to think that future Macs might come with touch screens, a locked down App Store as the exclusive channel for software, and sandboxed apps.

Instead Apple is taking features that most people don’t even really think about as unique iOS features (though they are); features like seamless app resuming, app “multitasking” with full screen apps, invisible scroll bars, easy application launching, automatic saving, OS state restoration, and physics-based scrolling.

These are all improvements to OS X, some more meaningful than others, but all worthwhile. The common thread through them is allowing the user to think less – getting closer to the old tagline, “It just works.” With application resuming and auto-saving you don’t have to worry near as much about application crashes or restarts. With OS state restoration you can apply software updates that require restarting the computer without going through an hour long prep-for-shutdown process. With the spaces-based “multitasking” of full screen apps you can focus on one task when necessary but easily get back to the desktop (and your other applications) at any time. With invisible scroll bars that only show up when needed you maintain all the functionality of the current scroll bars but with less visual clutter.² And with Launchpad, the iOS-like application launcher, Apple has abstracted applications away from the file system.³

Apple didn’t go for the obvious features that define the iPad and iOS, the ones everyone thinks of first (like being touch-based), but instead they took everything they learned about making a computer even easier to use and applied those lessons to OS X.

Lion may not work like the iPad, but it feels like the iPad.

1 Seriously, if you’re going to make a screencast, maybe you should actually show interesting stuff on the screen rather than telling me what you could show me while showing me the desktop for 10 minutes.
2 As a web developer I love that these new scroll bars overlay the content such that the width of the content window is the same regardless of the need for scrolling.
3 At my all-Mac company I have seen many, many OS X users that are completely unaware that the Applications folder even exists. Here’s something to think about: Launchpad combined with the dock and the desktop mean that a user could theoretically never use the Finder.

Here’s an example: While watching Eminem’s performance at the Grammys I wanted to know the story behind the medallion he was wearing. I did a search on Twitter for “Eminem necklace” and learned that it was a symbol for Alcoholics Anonymous.

Another one: My power went out on a Saturday morning. I was worried that it might be a problem with just my house rather than some upstream issue. The first thing I did was check Twitter for any nearby tweets mentioning a power outage. (In this case I didn’t actually find any answers but the point is that I even thought to check Twitter). I’ve had good results with these cases in the past – why is there so much traffic right here? What are those sirens about? I’ve been able to get answers to those questions through Twitter. Twitter is a window into what’s happening not only right now, but right here.

I generally find that I could care less about the trends (worldwide, regional, it doesn’t matter), because they don’t matter to me. They don’t answer any of my questions and they rarely align with my interests. I think it would be a real missed opportunity if Twitter where to go in the direction of so many other aggregator services and focus on the global “what’s popular”. If there’s one thing I’ve seen from services that attempt to surface relevant information from aggregated community input, it’s that crap floats. The lowest common denominator stuff is what rises to the top.

Account options UI for the Contacts, Gallery, and iDisk sections

Account options UI for the Mail, Calendar, and Find My iPhone sections

Why are they different? Because Apple has updated Mail, Calendar, and Find My iPhone in the past year. They haven’t updated Contacts, Gallery, or iDisk. There is no way that Apple would let this discrepancy continue indefinitely; they are too obsessive about UI. The only reason they would allow this is because updates for the other sections are in the works.

The Bottom Line

The only way to achieve what Gawker’s new design does, cross-browser, is the way they’ve done it. There are ways to improve the design for newer browsers, but the foundation would still be what Gawker has implemented.

And despite what some are claiming, the design does more than just “look cool”; it actually enables behavior that many find useful and can be achieved no other way.

So why use a hash-bang?

Out of all the reasons, the strongest one is “Because it’s cool”. I said strongest not strong.

It’s an insult to the tech community that an article with this claim gained so much traction. Any web developer that truly knows his stuff will tell you what a hashbang-based, JavaScript-based site enables. In the case of Gawker’s two-pane design, it allows the reader to not lose his place in the article list as he reads through multiple posts. It also increases the perceived speed of the site, because jumping to a different article doesn’t refresh the whole page.

Let me give an example of a real world benefit. If you are anything like me, you visit the front page of a Gawker site (for me, it would be Kotaku) and you scroll through the list of articles, opening any you want to read in a new tab. Why? Because I don’t want to lose my place in the article list by clicking into the story, and I don’t want to have to hit the back button once I’m done reading that particular article. So after a few minutes I’ve got 10 tabs open, which starts to bog down my browser and eventually my whole computer. With Gawker’s new design I can scroll through the list, click on each article as I go, confident that I won’t lose my place in the article list. My tab bar stays sane and my computer’s fans stay off.

The Details

But what are the complaints of the web standardistas? Even if Gawker’s finds success with their “non-standard” redesign, should others avoid going down a similar path? Let’s evaluate.

• The site won’t work with JavaScript turned off.

Although it’s hard to find truly authoritative numbers, most reports indicate that over 98 percent of users have JavaScript enabled.

• The site won’t work if the JavaScript fails to load, or if there is a syntax error (such as an extra comma) in the code.

This is the biggest red herring of the bunch. Guess what? ANY website won’t work if parts that it relies on fail. Relying on the JavaScript to load is no more dangerous than relying on HTML to load. In writing about this, Mike and others make it sound like building a website that depends on JavaScript is akin to rubbing your lucky rabbit foot and putting on a blindfold before starting to code.

Every URL references the LifeHacker homepage. If you are lucky enough to have the JavaScript running successfully, the homepage then triggers off several Ajax requests to render the page, hopefully with the desired content showing up at some point.

He’s purposefully making it sound far brittler than it really is. This is like saying that when you visit a traditional URL, “If you are lucky enough that the server is running successfully, the request triggers several function calls, hopefully with the desired content being returned at some point.” The reality is that all web services are dependent on their constituent parts working.

I think part of the reason for this perception of JavaScript as brittle is that for a long time JavaScript was an “extra”, and so was coded by people who were not overly familiar with the language and was then either tested poorly or not tested at all, resulting in broken implementations. This led to the perception that the language itself was the problem.

• The URL looks ugly.

Here’s a Gawker URL under the new design:

http://gawker.com/#!5781440/the-latest-news-from-japan

And here is that same URL under the old design:

http://gawker.com/5781440/the-latest-news-from-japan

That’s all I have to say about that.

• HTTP/1.1 and RFC-2396 compliant crawlers now cannot see anything but an empty homepage shell.

This is a business concern. How important is it for your business to show up in search results? More specifically, how important is it for your business to show up in search results besides Google¹?

• Caching is now broken.

Another business concern. If your infrastructure can handle the requests without caching, then there is no issue. If it can’t and you want to have a more JavaScript-based approach, modify your infrastructure to support it.

• The potential use of Microformats (and upper-case Semantic Web tools) has now dropped substantially.

A real travesty.

• Facebook Like widgets that use page identifiers now need extra work to allow articles to be liked.

So you’re saying they still work? So what’s the issue here?

• Using cURL to retrieve one of the new Gawker URLs will not return the correct content.

Good thing I’ve got this here browser, then.

• The new URLs “don’t map to actual content”.

So, requesting the URL assigned to a piece of content doesn’t result in the requestor receiving that content

Actually, each URL does map to content. It just requires JavaScript to complete the mapping.

The Switch to Web Apps

Despite my flippant responses, the last two points bear further discussion. What’s happening here is that the web is evolving. Many sites are migrating towards a “web app” model, where the site operates like a self-contained application rather than a network of interrelated links. Along with that the browser and all its functionality, including JavaScript, are elevating from a GUI wrapper around cURL commands to an element of the web stack itself.

This change is making some developers uncomfortable. In their effort to explain their discomfort they are coming up with all sorts of rationales for sticking with older methods of web site design. Although there will surely be some bumps along the way, the reality is JavaScript is going to find its place as a standard, accepted part of the web stack. Other methods of retrieving web content will either have to adjust (such as Google’s efforts to index JavaScript-loaded content) or be relegated to secondary or special-purpose status, such as cURL.

Business on the Web

One last point I want to make. Even if Gawker’s new design truly was a catastrophe on the code side it could still be the right decision for them, because ultimately they are a business and their infrastructure and code choices should all be made in support of their business goals.

I think Gawker understands that they have to serve their users. From the user’s perspective a lot of these questions don’t matter. Who cares if the server parses the URL or the client does? Who cares if the parsing is done client side, or if the browser has to retrieve the content based on a URL fragment that it stored? That’s all implementation.

As much as web standardistas wish it wasn’t so, all these technical decisions (in a smart organization) are ultimately business decisions. Who cares if the design doesn’t conform to the W3C² URL standard? The real questions are: How is the end user affected? Does it deliver a superior experience? Does it work for the audience Gawker cares about? Does it increase engagement? And of course the only question that really matters – will the design lead to increased profits? I can easily imagine that Gawker did an analysis and came away with the conclusion that this change would deliver where it really mattered.

1. The “bang” part of the hashbang design is not technically necessary, but Google devised using an exclamation point after the pound symbol as a signal to its indexer. Using the hashbang allows Google to index the content despite it being loaded dynamically via JavaScript. More here.
2. The World Wide Web Consortium, responsible for the standards on which the web is built.

I wrote:

Twitter clients should add a tab on a user’s profile page for viewing tweets directed @ that person.

Well, most Twitter clients do that, including the official Twitter client. But that’s not exactly what I’m looking for. What I really want is way to quickly get to all the @ replies from the tweet itself without having to click through to a profile page and then a tab within the profile page.

At least one application does this. Twitteriffic has a “Replies to this author” action available from the detail view of any tweet.

Part of the reason I wasn’t aware of this is because I got rid of Twitteriffic on my iPhone after a while. I just couldn’t handle its confusing interface. Turns out that the guys at The Iconfactory realized they may have overengineered the app and dramatically overhauled the interface with version 3, released in June of last year. They really did a fantastic job of keeping a lot of functionality while streamlining the interface. It’s now my default Twitter app.

Despite Steve Jobs clever reveal of the iPhone as three separate but equal products in one package (an iPod, an “internet communication device”, and a phone), most consumers saw it as an evolution of the mobile phone. It was a phone, plus a bunch of other stuff.

But the iPhone is no longer a phone, it’s a mobile computer (a post-PC device, Jobs would say), and iOS needs to change to reflect that.

Phone calls are still given primacy in the OS. If I’m in an app and a call comes in, my entire screen is taken over by the incoming call UI. I have to either decline the call or wait for the call to end¹ to get back to what I was doing. If I choose to accept the call I’ll be dropped into the phone app when the call ends, not into the app I was using when the call came in. This was especially irritating before iOS 4 and multitasking. Similarly, if I’m in an app and I click on a phone number that initiates a phone call, I’m taken out of the app and into the phone app for the call.

Text messages are slightly better but not by much, the key difference being that an incoming text message does not take over the whole screen, instead displaying a notification. Otherwise text messages exhibit the same behavior as phone calls: answering and initiating a text message takes you out of your current app and into the messaging app.

Contrast these with the email interface of iOS. If I’m in an app and an email comes in my phone buzzes; that’s it. Besides the vibration and audio chime, I’m not interrupted in any way. If I’m in an app and I click on an email address to send an email, an email “sheet” slides up where I can type my email. Clicking “Send” sends the message and dismisses the email interface, leaving me exactly where I was before I clicked the email link.

The email interface of iOS used to work differently. Prior to iOS 3, clicking an email link in an app would switch you to the email app to compose and send your message. But Apple realized that this was not optimal (especially before multitasking) and so devised the email “sheet” method.

Apple should switch the phone and messaging interfaces to work like email.

Better yet, all three should be unified into a standard communication framework that third-party applications can also link into. If I’m going to get pie-in-the-sky here (if I’m not there already), this new framework would hook into a new notification system.

My dream is that I have the same options for each method of communication: I can choose whether I get a notification that interrupts to some degree (the current pop-up message or some future implementation), that alerts but does not interrupt (vibration or audio cue), or that neither interrupts nor alerts. And responding or initiating each method of communication would use the “sheet” method, allowing me to stay within any app I may be in.

Some may argue that the differences between the OS’s handling of phone calls, text messages, and email reflect an inherent difference in the nature of each type of communication. I disagree. Today an email may be more important than a phone call or a text message. For some people a Skype message or AOL IM could be more important than any of the natively supported methods of communication.

Apple loves to be the first company to drop old technology and old ways. Treating phone calls like they are more important than other communication methods is the old way.

1. Waiting being my preferred choice as declining a call sends the caller directly to voicemail, tipping them off that I chose not to answer.