My one resolution for 2010 is to only do things that feel good and right. Last night, as part of that resolution I deactivated my Facebook account. It wasn’t an action I took lightly, but it was something that I felt like I needed to do.

By the end of 2009, I was making several visits to Facebook a day. I’d have a moment of downtime during lunch, in between meetings, after dinner or before sleep, and Facebook was the first site that would come to mind. I’d hit the site, and of course I’d have to click through all of my notifications and see what comments people had left on my posts. Read, comment. And why not check the news feed? Read, comment, like In addition to the times I’d visit Facebook on my own, throughout the day I’d receive an occasional message or event invite via the site. Read, mark as attending, reply. And oh while I’m here, let’s check the news feed again. Read, comment, like.

(On Facebook, you can get notifications for a lot of things, but I didn’t really use Facebook apps, so I generally only received notifications when someone commented or liked one of my posts or when someone commented or liked a post that I also commented on. If you put a lot into it, you get a lot out of it. And me, I was putting a lot into it. Beyond simply commenting and liking news feed posts, I was posting updates and links almost daily. So the influx of notifications I received with every visit was mostly my own doing.)

I was probably spending at least an hour a day on Facebook. That’s 7 hours a week, 28 hours a month - and at least two weeks a year.** I’m not a terribly busy person but I personally find that to be a huge chunk of my time.

I realize that many people have no issues spending this amount of time browsing, commenting and liking on Facebook. While writing this entry, I asked a friend of mine how much time she spent on Facebook, and she answered “maybe an hour or two.” But she couldn’t use it at work.

I also realize that many people find Facebook entertaining, useful and/or valuable. I sometimes found it entertaining, useful and valuable as well. But many more things didn’t feel right: the compulsion to visit the site several times a day, the endless yammering, the “likes,” the dating ads, the distorted idea of “privacy” that Facebook promotes, the lack of control I felt when using the site.

I had a few options: I could post and comment on Facebook less, I could login less, or I could deactivate my account. Posting to Facebook less was easier. Restraining myself from commenting was hard. Logging in less was harder. In short, I couldn’t change my activity on my own, so I needed external moderation. Deactivating my account was really easy, and it would automatically keep me from logging in, posting and commenting. My plan is to keep my account deactivated for at least rest of January, watch how often I try to use Facebook (and for what reason), see if I miss it - or see if I forget about it - and then go from there.

Facebook isn’t just a website anymore. It’s become part of our lives. And like anything in our lives, especially something that we spend so much time using, it deserves a critical evaluation. I hope to reactivate my account someday, but next time I visit I want to feel better about my experience there. I want it to feel right.

** Some may be asking, “What about Twitter.” I feel like I have more control over my Twitter experience, mainly because Twitter only has a stream. It’s really just updates, mentions and an occasional direct message. No “friends,” no mysterious news feed, no notifications, no photos, and not a million other things have no need for. As a result, I spend much less time on Twitter, and the time I do spend there feels more valuable.

Reactivating Facebook

For folks who weren’t following along, I deactivated Facebook back in January because I felt like it was slowly taking over my life. Basically, I wanted to prevent myself from being able to immediately logging in and using the site. It worked, and I didn’t use Facebook at all for a little over three weeks.

I’m proud to say that I use Facebook significantly less now. Essentially, I only use it as an extended address book and to RSVP for events as it’s practically become the de facto standard for events and invites.

A few services I use (Tumblr, Netflix and YouTube to name a few) still automatically post to Facebook on my behalf, which I’m okay with because I don’t ever have to worry about comment notifications on these posts. In fact, I don’t ever have to worry about comment notifications on any post because I’ve turned off commenting. If you want to reduce the time you spend on Facebook without deactivating your account, turning off commenting on your posts is probably my top suggestion. (As a sidenote, I tried disabling my wall for a short period of time, but I felt like that was going a little too far. Visiting a profile without a wall feels like visiting a site without a home page; I re-enabled it shortly afterwards.)

It’s hard not to pass through Facebook without at least glancing at the News Feed, which I’ve done on several occasions. I think I’ve read a small handful of posts and have left two comments. Overall, my 1+ hours a day has been reduced to a few minutes a day at the most. I’d say that’s a very good thing.

I feel like I can say that it’s a good thing because I don’t miss it at all and the little interaction I have with the site feels much healthier. If you do miss Facebook when you don’t use it, and you enjoy the time you spend on there, that’s great. But I would ask you to take a more critical look at your experience on Facebook and ask yourself, despite how entertaining it might seem in the moment, does it truly feel good and right?

Deactivating Facebook and Reactivating Facebook were originally published in January 2010 and March 2010 on my tumblelog, also unraveled.

To switch the active application in 10.2, you hit Command-Tab and a highlighted dock icon told you which application was selected. It worked, but it had problems. The biggest of which occurred when open applications were separated by several unopened applications on the dock. When this happened, the highlight skipped across these unopened applications in a seemingly unpredictable manner because almost no one could remember exactly which applications were open and which applications where closed.

A Better Switcher

In 2001, a small software startup named Proteron announced LiteSwitch X, an OS X update to its popular OS 9 keyboard application switcher. LiteSwitch was essentially a Mac implementation of the Alt-Tab switcher found in Windows, but with an additional slew of features including drag and drop support, closing multiple applications and windows layering control. I was unsatisfied with the 10.2 application switcher and started using LiteSwitch X soon after buying my first Mac.

Apple caught up to Proteron in OS X 10.3 and introduced its own application switcher albeit with significantly less features than LiteSwitch X. Apple’s switcher has remained relatively unchanged since its original implementation.

Hit Command-Tab and you switch from the current app to the next most recently used app. If you hold Command, all running apps are displayed, and you can continue hitting tab to switch to another app. You can additionally hold down Shift and cycle in the opposite direction, and use the H and Q keys to hide and quit applications.

Apple slightly improved the switcher with 10.5, introducing drag and drop support and then again with 10.6, allowing you to trigger Exposé and show all windows of the selected application by hitting the up or down key.

Blinded by the Lite

Version 1.1 of LiteSwitch X introduced a preference for sending the reopen event to applications upon switching to them. This meant that LiteSwitch would force OS X to reopen the window if it had been closed, or restore the window if it had been minimized to the Dock. I enabled this preference soon after I started using LiteSwitch as it felt like the most natural way to switch to an application. With every OS X update, LiteSwitch X was one of the first add-ons that I installed. So when I switched to an application, I expected to it to be visible — the only exception being if it was a document-based application and there were no open documents.

In early 2009, I noticed that the Proteron website was down (The Wayback Machine records July 24, 2008 as the last date the website was reachable), and over the past year I was concerned about continuing to use software that was no longer supported. So near the end of December I begrudgingly tried to use the built-in OS X switcher.

Having been blinded by LiteSwitch for so many years, I was completely set back that the OS X switcher didn’t reopen closed or minimized application windows. For example, say iTunes was open but the main app window was closed. If I switched to iTunes, no window would appear. Switching to to Finder, Mail, Address Book, Safari, Tweetie, Adium and other apps also didn’t reopen application windows.

Shortcut Madness

Given that switching didn’t reopen application windows, I expected a common keyboard shortcut for accomplishing this. Unfortunately, shortcuts only complicated the situation. To show the iTunes main window, I needed to hit the keyboard shortcut for opening the window (Option-Command-1 in the case of iTunes) or click on the iTunes Dock icon. There’s no unified keyboard shortcut for reopening the main window - even among applications made by Apple. Here are the keyboard shortcuts for the apps I listed above:

• iTunes: Option-Command-1
• Finder: None
• Mail: Command-1
• Address Book: Command-0
• Safari: None
• Tweetie: Command-0
• Adium: Command-/

These are just the apps that have a shortcut. Many, like Evernote, don’t even have one.

After tweeting about the lack of a standard shortcut for reopening main windows, Martin Polley pointed out that the OS X application switcher actually can reopen windows with some additional shortcut trickery.

It goes like this: hit Command-Tab to switch as you would normally, then when the app you want to switch to/reopen is selected, hit Option while continuing to hold Command. Then release Command before you release Option. Go ahead and try it now. When you first start using it, it’s quite painful after the simplicity of Command-Tab, but it does get slightly easier over time.

Personally, I love controlling OS X via keyboard, and most of the time I welcome consistent and standard keyboard shortcuts for commands. However, I believe that adding a shortcut for reopening windows is the wrong solution because it defies traditional keyboard shortcut expectations. For nearly every keyboard shortcut I use in OS X, there is a perceived before state and an expected after state. For example, if I’m browsing a site in Safari and I want to jump to the search input, I hit Command-Option-F. In the before state, I perceive that the webpage has focus. The expected after state is that the search input will have focus. In the case of the OS X reopen shortcut, the before state is that the window is closed or minimized. The expected after state is that OS X will bring the selected application forward and reopen or restore the window. The issue is that it’s very difficult, and sometimes impossible, to know if the window is actually closed or minimized. So for the shortcut to be truly effective, the user needs to remember which windows are open and which windows are closed or minimized. This is unrealistic at best.

Switching 101

Out of the box, the Mac offers three key ways to switch applications, and each of them behaves differently.

• The Dock. Click the application icon in the Dock to switch to the application and bring all of its windows, including closed application windows or individual minimized windows (if the app has only one window and it’s minimized), to the front. Clicking on an application’s Dock icon to switch to that app is one of the first skills that a new Mac user will learn. So it makes sense that doing this brings that application’s windows to the front.
• Selecting the Window and Exposé. Click within an window to switch to the application and bring the selected, but not all of its application windows, to the front. Exposé is a different way to visualize windows but the same behavior applies. This is even more straightforward that clicking on a Dock icon; clicking on a window brings that window forward. For the new user, it seems okay that only a single application window comes to the front because the user clicked a single window. (As a historical note, in OS 9, clicking within a window actually brought all the application’s windows to the front.)
• Command-Tab. Hit Command-Tab and you switch from the current app to the next most recently used app and bring its open windows to the front. Let’s consider the new Mac user again. Clicking on an application’s Dock icon brought that app’s windows to the front, but using Command-Tab to switch to an app — which looks identical to the app icon in the Dock — only brings open windows to the front. It’s easy to assume that this isn’t going to make a lot of sense to the new user.

I believe that Command-Tab is the only way to switch applications without affecting windows because when Apple implemented the switcher in OS X 10.3, someone decided that it was the one true application switcher. And a true application switcher shouldn’t affect windows; a true application switcher only switches the application.

This is where Apple misstepped. Beyond being inconsistent with its closest switcher sibling the Dock, it doesn’t provide perhaps the most important thing that most users need upon switching: to see an application window.

Applications and Windows and Documents

Every application has at least one window. Some applications are document-based, meaning they allow the user to operate on multiple items at the same time. Mail, TextMate and Photoshop are all examples of document-based applications. Typically, document-based applications have one window per open document and often have multiple windows open at once. Other applications are non-document based; in these apps the user can only operate on one item at a time. As of this writing, iTunes, iCal and Address Book are all examples of non-document based applications. Typically, non-document based applications only have one window. For all practical purposes, that window is the application.

In the case of non-document based applications, the argument for always showing a window upon switching is easier. If you want to use iTunes, there’s practically nothing you can do without the application window. The same is true for iCal, Address Book and many other single window apps.

It’s a little trickier for document based applications. If the application has one document open, it makes sense to show that window — even if its minimized — because there’s a damn good chance that they’ll want to see that window. (People who keep their Dock hidden: have you ever switched to a document-based application and thought nothing was open because you didn’t see a window, later only to discover that you had a window minimized in the Dock?) If the application has two documents open, it makes sense to show the last document (window) the user interacted with.

Here’s the tricky part: what if a document-based application doesn’t have any documents open? Current apps handle this in different ways: some do nothing, some open a new untitled document automatically, some make it a user preference. Personally, I prefer apps to do nothing and not open any new windows, but ultimately I believe the window opening behavior should be based on the app. This, then, is the only exception to showing a window upon switching: if a document-based application doesn’t have any documents open, the developer should choose the window opening behavior and in some cases, allow the user to choose in the application preferences.

The Crux of the Switch

Switching should reopen closed and minimized application windows. It’s consistent with other ways to switch and therefore easy to understand. But most importantly, it’s what the user needs to use the app in most cases.

Given that Apple has released three versions of OS X since introducing the application switcher, I’m fairly certain that they would be extremely hard pressed to change its behavior at this point. The good news is that LiteSwitch X 2.6, despite being released previous to OS X 10.5, works perfectly in 10.6 Snow Leopard. There’s currently no official download site, but it’s still available on several software sites such as VersionTracker. Unregistered, it will work for 30 days.

If you end up liking LiteSwitch, you’ll probably want to use it longer than a month. While there’s currently no way to get a serial number, you shouldn’t panic. I’ve been in touch with Proteron developers, and we’re working on a plan for resurrecting an official download site for LiteSwitch in the near future.

The Crux of the Switch was originally published in January 2010 on my tumblelog, also unraveled.

One feature common to all Twitter clients is “reload,” allowing users to load the latest tweets. Tweetie handled this particular feature differently from the beginning. I talked to Tweetie’s creator, Loren Brichter, about how this feature evolved and his perspectives on designing gestural interfaces.

Joshua Kaufman: Tapping a button to reload was generally accepted as a standard within the iPhone interface. What made you explore the refresh interaction in Tweetie 1?

Loren Brichter: Necessity is the mother of all invention. Looking back to Tweetie 1, I was in this position where my navigation bar was already filled up. On the left side was the “Accounts” back button which would take you back to the accounts list (Tweetie 1 was the first app with a sensible multiple accounts implementation). On the right side was the compose button.

So where did the reload button go? Other apps of the day simply put the reload button in the upper right corner. This was acceptable for single-account apps, but for apps that handled multiple accounts, those apps had to go through some nasty contortions and shove the account switcher UI into some other non-optimal place. So I thought about it, and asked: what was “reload”… really? In the context of Twitter, it really meant “load newer”. And when you loaded newer tweets in your tweet stream, where did they go? At the top of your list.

So I put the reload button at the top of the list. As you scrolled up, reading newer tweets, eventually you’d get to the top of the list and bam… there’s a reload button, it just slid into view exactly when you needed it. You tap it and it’s replaced by the newer tweets. It’s intuitive and doesn’t waste prime screen real estate (corners of the screen) until you actually need it.

JK: How did you arrive at the pull down and release to refresh interaction in Tweetie 2?

LB: Tweetie 2 simply took this idea from Tweetie 1, that reloading was simply “loading newer”, and “loading newer” put new messages at the top of the list… and activated the action based on a finger motion that you were already doing. Why make the user stop scrolling, lift their finger, then tap a button? Why not have them continue the gesture that they are already in the process of making? When I want to see newer stuff, I scroll up. So I made scrolling itself the gesture.

The gesture is only half the battle though, you need appropriate feedback. Once the reload is activated, the scrollable area of the list actually changes to leave the feedback UI in-place (rather than bouncing offscreen). Without this part, the UI is unintuitive. And once the loading is complete, the UI makes itself disappear.

JK: Using this interaction in Tweetie 2 reminded me that gestural UI is still young and full of possibilities. Are there other common interactions that you see being improved by new gestures?

LB: Of course. But you need to be careful. The reason that I think the pull-down-to-refresh works so well in Tweetie 2 is because it’s discoverable and explanatory. It’s discoverable because you already know how to scroll a list, and as you scroll up, when you get to the top — bam — the UI reveals itself and you go “whoa, what’s that?”. It explanatory because once you start tugging down there is some great UI feedback, actual text that provides instructions as you interact. It’s not like it pops up some modal dialog with instructions on how to use it, the UI itself is the instruction. Once you learn it you simply ignore the text and can look at the graphical arrow which gives appropriate feedback on what you need to do.

Now, I think you can split gestures into two categories. One is of the pull-down-to-refresh kind. These are gestures that are discoverable and explanatory. The other kind of gestures are like tapping-the-status-bar-to-scroll-to-the-top, or swipe-to-delete (or swipe-to-reply in Tweetie). These gestures you won’t discover on your own except by accident. These are not discoverable, and they are not explanatory.

This second class of gestures can exist (in my opinion) because they are not the only way to accomplish a goal. In the case of tapping the status bar, users already know how to scroll to the top manually. It’s slower, but it’s possible. In the case of swipe to delete, users already know they can tap on a message and then tap the trash button. So knowing the gesture isn’t necessary.

So when you’re inventing new gestures, it’s important to think about whether the gesture is required to use the app. If it’s the only way to accomplish a goal, you better be sure it’s discoverable and explanatory without needing to read a manual. If it’s the other kind of gesture, go nuts!

Loren Brichter runs atebits — a devious scheme designed to take your money $2.99 at a time. Previously he worked for Apple on the original iPhone. Now he mostly answers email, and occasionally finds time to actually program.

A video of his entire presentation is unfortunately not available, but Josh Damon-Williams did manage to grab this clip.

After watching this clip it’s easy to understand why the audience became so excited about the possibilities of these tools. At the same time, I wondered what the chances were for something like fourbysix to be developed on a much larger scale. The fact is that we can drool over tools like this all we want, but unless a large group of designers starts supporting the work of people like Björn, we’re going to be stuck with the same tools we’ve been using for the past ten years for the foreseeable future. I wanted to know what it would take to make tools like this accessible to more designers.

When I met with Björn, he explained how he created the fourbysix table while at Microsoft. Not surprisingly, he used a lot of Microsoft technology including the Microsoft Surface SDK and proprietary source code only available within Microsoft’s walls. However, he also used a lot of non-proprietary technology, including tools that have been available since the late 90s. He also explained that, while he did use proprietary technology to build fourbysix, there are more open equivalents that could be used to build something very similar.

So with enough know-how, resources and materials, you could build something like the table in the clip above, but chances are that this is out of reach for most designers. So what’s the next option? According to Björn, the best chance for designers to make use of this technology is to collaborate with a research university on such a project. Fortunately, there may even be opportunities for this in the San Francisco area over the coming year.

If you’re interested in participating in something like this in the future, please get in touch with myself or Björn. In the meantime, I’ll definitely be following his work and helping out where I can.

Update (21/9/09)

Björn just let me know that videos are now available which feature the multitouch table he demonstrated at Interaction ‘09.

This is the fifth and final interview in the Design Inside Yahoo! series. I interviewed Greg Rosenberg, Principal Designer for Yahoo! Mail. I talked to Greg about where web email platforms are heading, the redesign of Yahoo! Mail’s and the recent addition of social features.

Joshua Kaufman: It’s been nearly three years since the launch of the redesigned Yahoo! Mail. How has the web-based email landscape changed in that time?

Greg Rosenberg: ‘04 to ‘06 was the big Web 2.0 Shuffle: “Hey, got AJAX?! FLASH?! Drag-n-Drop?!” That’s certainly leveled off, and rich web mailers are pretty much the norm now. Since then, I’ve seen two big things happen in the web-mail space. As industry leaders we all have this great technology in place in our products (Yahoo!, Google, et al.), but at the same time we continue to tweak our products to make sure they still address core needs, while we add new dynamic interactions and features. It’s a tough sweet spot to find: striking that balance between a cool, new feature and “why can’t I just check my mail?” This dilemma will always be there as long as we have expectations around what email is, and the massive population that’s grown up using it. We’ve continually tweaked the new Yahoo! Mail, and seen some the evolution of other e-mail services. Hey, even Gmail added a “Delete” button.

The second big thing is pretty obvious: the social media and social networking explosion. This has had a big impact on email as for some it has replaced traditional online communications (Email, IM), almost turning them into commodities. In social networking sites, once you and your friends join, you don’t need to remember an email address to contact someone: you only need to remember your username/password for that site. What constitutes “communication” has also evolved: a tweet, just updating your picture, posting a set of pictures, “liking” something, commenting on someone’s Facebook status, etc. In social networking, MySpace was the first to try and venture into e-mail (yes, there were predecessors, but not as mainstream and prevalent.) But, as we have seen, they suffer from a pretty big perception problem of only catering to tweens, a place for creepy stalkers, and bands trying to promote themselves. Facebook really deserves the credit for changing the social networking game here as they’ve zoomed past MySpace with finding a way to appeal to a wider demographic and have had explosive growth. However, an email address is still the starting point here, and hundreds of millions of people still heavily rely upon email. This is where I still think social networking sites still haven’t broken through a key barrier: the communications are so casual, the line between public/private so fine, that it’s not only a bit of an unorganized mess but there also seems to be a lack of etiquette in 1:1 private communications and incentive to engage in these types of communications. At Yahoo!, we recognize what’s happening in the industry and have been working hard to create a best-of-both worlds experience, reversing the flow and infusing social communications into an email environment. Not for the just for the hell of it, but to make email better and use connections (aka “friends”) and social features to power that. In your inbox, you can instantly weed out the noise to see messages from people most important to you. When you sign in, you’ll also see those messages highlighted with their pictures, along with updates about them (a news feed of sorts). The updates stream is not isolated to Yahoo!’s network, it aggregates Yahoo! and non-Yahoo! updates (Twitter, Yelp reviews/ratings, YouTube, etc.) all of which the user can control in their Yahoo! Profile page. We also have a whole new assortment of connection-related features in the pipeline. The core though, is still email, which draws more of a need to take real action, as opposed to social networking casual check-in behavior. This is where email is strong: you can still consume updates, traverse your network of connections, but the emphasis is on email functionality as the primary tool here. So, we retain the important and familiar user behaviors and give our users deeper confidence in knowing that the emails (and IMs) they send and receive are governed by the strongest and most robust security and privacy measures.

JK: After Google innovated with a conversation view, “archiving” and labels in Gmail, why did Yahoo! take a more traditional approach with folders and a standard column-sortable list of messages?

GR: Regarding Yahoo!’s approach, we have folders and not labels for a couple of reasons:. First, unlike Gmail which had no user base to migrate, we have millions of users worldwide of varying ages, experience levels, and usage behaviors, many of which using folders in the Classic version of Yahoo! Mail. Changing both the UI at a high-level and their method of organizing their messages at the same time would’ve been too much change at once. That’s the biggest reason we kept folders. Secondly, and equally important is that the concept of labeling can be confusing to some and thus has a bigger learning curve and ultimately doesn’t address what a lot of our users want to do: clean out their inbox. We know that users of folders use them to keep a tidy inbox, and like to file things away. It’s a natural behavior that’s been part of the digital world, based on the realities of the physical world. I’ve personally seen users in the lab, and during in-home research visits that end their daily mail experience with an empty inbox — as if an inbox that had any messages in it felt like a stack of late/unpaid bills. On the column sortable list: no need to reinvent the wheel here, this is just another example of something Yahoo! Mail users were already accustomed to using.

All that said, three years later, it doesn’t mean we’re not thinking about similar features :)

JK: What’s the story behind the general design approach, including the decision around using tabs?

GR: The early version of the new Yahoo! Mail (prior to the first beta phase) was actually very different from what you see today. The product more closely resembled its predecessor, Oddpost: it appeared as a traditional desktop application with “child” windows, primarily for composing and reading messages. It also launched into a chromeless browser window (that is, there was no toolbar) and hi-jacked the browser’s pull-down menu and shortcut key system. Essentially, it functioned identically to a desktop mail program, but ran inside a browser. For a variety of technical and usability reasons, we recognized that we had to change design direction.

Technical reasons:

• Proliferation of pop-up blockers (which became more extensive and built-in since Oddpost’s design framework was built) increased dramatically. Pushing past a blocked popup when launching the application, or composing a message, would be a difficult hurdle for the user to jump over.
• For security reasons, many browsers require a URL prefix to the title of any window that doesn’t contain an address bar. This means that as long as we opened all our windows into chromeless browser windows, the titlebar would have to be a random confusing mess of symbols, letters and numbers.
• The increase of tabbed browsers with enhanced control over clicked links would create unpredictable results when working within the application.

Usability Testing Feedback/User Perception reasons:

• There’s a growing user perception that a “window” and a “pop-up” are one and the same. If the user is using a web browser, and the page being viewed opens a new window (without the user specifically creating a new window), a significant percentage of the users will associate that window with an annoying ad.
• It felt heavy. We wanted to make the application light. As the earlier product mimicked a desktop application, it brought many of the expectations of such a product (required installation, full-OS specific shortcut keys, etc.)
• An inconsistent experience across all browsers and operating systems. The earlier version worked well on Windows (and Oddpost only worked on Windows), but we now had an odd experience for the Mac, which manages its menu system outside the browser’s application frame. On a Mac, the earlier version showed the Y! Mail native menu system and the browser’s menu system simultaneously - thus creating major confusion.

After the rough first set of usability tests, and peeling me off the observation room floor, our PM (Ethan Diamond) dropped me into a cave to come up with a new interaction model, and seven days later I crawled out with what you see today. We decided to have the product run in a Web-standard fashion: a single page in a chromed browser, without popping up windows for composing and reading. We also wanted to offer our own proprietary shortcut key system. How would we retain the same level of multi-tasking support that a windowed application affords the user, but do it in such a way that it’s dirt simple for the user? Out of the need to support this came the tabbed message system you see in the product today. In essence, native Yahoo! Mail tabs replace windows, but without all the mess of finding all the windows you have open. This is pain we’ve all felt with an OS, desktop program, and is worse with a stack of browser windows that can have confusing/unpredictable titles (that on Windows get grouped under one taskbar entity after a certain threshold has been reached). The tabs do a nice job of serving as an “index” of the user’s current open tasks: a message being written, an inbox to return to without losing the message being composed, to read the newest blurb in an IM tab with a friend, the social dashboard/updates tab, an application, etc.

JK: Calendar seems to be the only office app that hasn’t been fully integrated into Yahoo! Mail. Not to be rude, but what’s taken so long?

GR: Oh, I wish I had a good answer for this. While we have the calendar bar at the bottom of the Mail window supporting basic calendaring functionality available, we don’t have a Mail-integrated version of the rich calendar that’s currently in beta. Nothing new to report here.

JK: I noticed that RSS has been moved from Yahoo! Mail into My Yahoo!. The reasoning behind this is described in Yahoo! Mail help. I’m curious how much this decision was based on customer feedback. Do many people really want to read their RSS feeds from a start page?

GR: The decision wasn’t based on customer feedback. Most people don’t even know what feeds are, and an even smaller percentage know what RSS means. The RSS feature, inherited from Oddpost, was rarely used, took up valuable space in the folder list, and we just couldn’t give it more time & resources due to higher priorities. Given the small number of users of the feature, and that their feeds are mirrored in My Yahoo! (a more popular content consumption environment), it was a good move for us. As My Yahoo! is a popular starting page for many on the web, offers a robust built-in reader, and the content that appears on My Yahoo! is fairly similar, there are likely only a small number of users feeling much pain from this change.

JK: Meanwhile, on the way in are slew of social features based around connections. Is email the new newsfeed?

GR: It’s certainly moved more in this direction than it has in the past. You have to be careful though how far you take the news feed. The news feed is a strong way to passively consume what’s largely public content, see what friends are up to, casual commenting, etc. Blurring that too much with email is tricky business. Personal emails are private between the sender and the recipients, and there’s a different expectation put on the recipient of the message. For example, you’re more likely to hear “Why didn’t you reply to the email I sent to you four days ago?” as opposed to “Why didn’t you comment on my Facebook status from four days ago?”. So, baby steps. With the new social features we’re rolling out, we show updates from your connections, but above that in its own section are the email messages from your connections. In the context of Yahoo! Mail, emails are first and updates are second.

JK: What’s next for Yahoo! Mail?

GR: We’re gradually rolling out the social features and the open features (productivity apps integrated into the Mail environment). Outside of that, we’re always looking at every pixel, and every feature, always asking: does this make sense, does it belong, and does it make Yahoo! Mail better for our users?

Greg Rosenberg was Principal Designer on Yahoo! Mail for over four years and led the design of the new version. Currently, Greg is the Design Director for Community Products at Yahoo!, which includes Yahoo! Groups and Yahoo! Answers.

Readers may also be interested in my 2003 interview with Ethan Diamond, co-founder of Oddpost.