Dashboard and iOS

Posted by liviupt on May 3, 2012 08:35 pm 8

I know, I know there are several dozens of posts on here about widgets and implementing them but bear with me. I am going to waste a few minutes of your time and probably half an hour of mine as I seriously analyse the relationship between Dashboard and iOS.

I don't know about you but I am fed up with the reproach that Android (and as of late Windows Phone) always brings to the table in comparisons: 5 years of consecutive iterations and iOS doesn't have widgets. There is a reason for that and I'll explain in a second. First I'd like to focus your attention to the MacWorld 2005 Dashboard introduction. I quote from Steve Jobs' keynote:

"But there's a lot of times when you need to do a quick calculation, or find out the weather or a new piece of information you need now and get back to what you're working on quickly. Get in, find something, get out. And that's what Dashboard does... Dashboard is a place for widgets to live and a mechanism to get in, get your stuff and get out."

Get in, find something, get out. Does that remind you of something? In case you haven't figured it out by now, that is the basic UX philosophy of an app. Launch the app, get in, do something/find something, get out, repeat. What I am suggesting is that the reason why iOS hasn't taken the idea of widgets seriously by now is the fact that the entire springboard and indeed the iPhone itself IS A HANDHELD DASHBOARD. The widget is partially responsible for the concept of the app. Even the original iPhone OS 1.1.x dock resembled the Dashboard dock. The form of app icons, same inspiration: widget icons (check it out right now if you don't believe me...). Even the styling of the apps: Calculator, Weather, Stocks (last two are pretty much pixel-perfect ports) etc. is nearly identical to that of widgets.

What I am suggesting is this (and I bet someone else has thought about it by now, I haven't had the time to research this): in between the first iPhone and the iPhone 3G, the way Apple treated the iPhone was as a simple widget launcher that supplemented its basic functions. If you remember the 2007 introduction, Jobs defined the iPhone as a phone/an iPod and an Internet communication device. What it became, with the addition of the App Store, was a handheld computer. And with that, new problems arose. For instance multitasking, which was tackled with great difficulty. The way multitasking worked with widgets was, you had a ton of them on hand on the somewhat large Mac screen. The way app worked was, you launched one, you did your business and then you closed it, repeating the process when necessary. Beefed up widgets that produced a system where one was confined to one module at a time.

So we've dealt so far with the origin of the Dashboard and how it influenced the philosophy behind mobile apps. One conclusion to bear in mind is that the iPhone was a beefed up widget launcher. At least this, I believe, is the way Apple envisioned the iPhone and treated it for a very long time. It wasn't in the roadmap to make it a computer, they realised this only when the jailbreak community started developing programs like Apollo IM and everyday users demanded more power. With time, this need for complexity resulted in apps like iPhoto and Pages for iOS, very powerful and flexible, a far cry from the original widget-apps of the first iPhone. This is why Apple did not introduce widgets: because you've been holding a widget engine in your hand since 2007.

Now let's move on. IF Apple was to introduce widgets in iOS 6 or iOS 7 what would this implementation even look like? Do we even need them anymore? I think the answer to the latter is yes and not because other platforms like Android has them and is pressuring competition but because of the continuous shift towards more efficient multitasking and the current focus of integrating and consolidating UI/UX across iOS and OS X. After all, widgets are bits of HTML, CSS and JavaScript with a dash of Cocoa. This guy ported them perfectly. He even got down the process of adding widgets just as on the Mac. A page opens and you download them. As simple as that! But the problem remains, where do you put them? Here, two design philosophies will duel and even though I'd like to think that the first will win, the second is probably how Apple will implement it.

Their successful implementation depends on the concept of glanceability. To be able to see some bit of information really quick and use it somewhere where you are working at. The great advantage that widgets bring is that they deal with auxiliary sources of information and processes brilliantly. Think of the Dashnote widget. It syncs with Simplenote on the iPhone and is basically a note taking tool that works perfectly with Dashboard as a layer. You research something important, bring the layer with the note taking tool, take a quick note while you can still see the underneath information. See why it is so amazing? This is the first implementation, Dashboard as a layer. Keeps the glance intact (here is mine, excuse the girl, she likes to pose lol):

The second implementation is Dashboard as a space. It's what they are going with in Lion/Mountain Lion. Here is why I think it sucks: basically any other way of adding widgets to your workflow other than as an overlay is wrong. It has to to with the glance again, the gaze, the way we are wired to get information quickly, "jump in, jump out". There's a reason why Dashboard worked so well before. Now it's broken. They even demoted the widgets to an obscure part of their website, not worthy of the Mac App Store. And in Lion, you swipe to Dashboard like any other space with four fingers. Like multitasking on the iPad. So I go to my note taking utility, I write three words then jump back to remember what the hell idea I started with and go back to Dashnote again? It's stupid, less elegant and broken for some widget scenarios like Dashnote. Sadly, if they ever introduce widgets on the iPhone, this is how I believe they will do it. I'll give you another example for why I think it won't work. Another company tried to add widgets to their operating system. Maybe you've heard of them... they're called Microsoft and they produced a pretty shitty piece of software called Vista. In Windows Vista, gadgets resided in the Sidebar. You could hide the sidebar but then again you needed the widgets and having it permanently on the screen reduced screen estate for programs. This is what happens when you take widgets out of their overlay. You leave them homeless. They tried to fix that in Windows 7 and added them on the desktop. But then again how would you see them with programs on top? Well they added a button to give you the ability to gaze at them. Like this:

But then again how you interact with them? If you only want to gaze at them, you need extra button clicks to actually modify information in them. The class of widgets in which Dashnote falls would simple not populate this widget ecosystem. It would be jobless. This is why Dashboard is efficient. Precisely because it is an overlay.

The notion of Dashboard as a layer is also pretty consistent with the UI philosophy of iOS. iOS uses tons of layer metaphors: multitasking has a layer "underneath" the apps, like a mechanical linen-woven underpinning, folders employ the same layer and let's not forget about Notification Center where the only actual widgets of iOS reside (they kind of kept this idea of glancing at an overlay quickly for a bit of information). It would not work with lots of widgets because you would have to scroll endlessly to get to your notifications or information. It would stack widgets upon widgets and be very hard to work with. Widgets have no place in Notification Center. Same goes for putting them like Android along with app icons. If widgets are read-only, then maybe. But if you have to input info or copy info to input somewhere else, then it would be the same scenario as with Windows 7. Why exit an app to get info and jump back in when I have another app to provide that info for me. Putting them in the Lockscreen is not an option because that would generate security concerns limiting the classes of widgets allowed there (nothing with access to your personal info) etc.

So the ideal implementation of widgets on iOS is this: just like the original Dashboard, an overlay with small applets that provide auxiliary info or processes and are made out of the same things WebKit can handle on the desktop: cross-platform iOS/OS X (you could even use it as a marketing scheme: "the new iPhone, now with Mac Dashboard"). The only problem is that certain widgets would have to be reworked to fit into the limited screen of the iPhone (on the iPad that would not be a problem). But that would be an issue with developers not Apple. Some have even started to iOS-ify their widgets: check out the gorgeous Loremify for instance. Widgets built for both touch and cursor interaction. Isn't that the dream of OS X anyway, iOS-ifying everything?

Overall, this man's vision of what Dashboard would look like on iOS was the most accurate:

What if iPhone had... Dashboard Widgets (via oceanobservations)

Thank you for your patience and please excuse this massive post. I needed to outsource some ideas and could not find a better community to receive them. I hope you'll add to mine your own thoughts. And for the love of God Apple don't mess this up and put Dashboard to the left of Spotlight. Overlay, or don't even bother.