In a recent post, Apple Should Bring Back Dashboard, Stephen Hackett expresses his wish for Dashboard to make a reappearance in Mac OS:

Apple killed off Dashboard at exactly the wrong time. Just one year after Catalina killed Dashboard, Apple started allowing developers to bring their iOS widgets over to the Mac in macOS Big Sur. Sadly, they all got stuffed into the slide-out Notification Center user interface[.]

Notification Center is a real mess. Even on a Pro Display XDR, you get three visible notifications. That’s it. Anything older is hidden behind a button, regardless of how many widgets you may have in the lower section of the Notification Center column[.]

Apple needs to rethink this and let this new class of widgets breathe, being able to use the entire screen like the widgets of yore could. Bringing back Dashboard is an obvious solution here, and I’d love to see it make a return.

I remember being excited and fascinated by Dashboard when it made its debut back then with Mac OS X 10.4 Tiger. I remember spending quite a lot of time perusing the Dashboard widgets page on Apple’s website to look for more widgets to add to my collection. I used Dashboard and its widgets quite a lot in the Tiger-Leopard era. In a sense, when the iPhone’s user interface was demoed in January 2007, one of the things that made me instantly love it is that certain apps and interactions fondly reminded me of Dashboard widgets. The Dock in iPhone OS was basically the Dashboard ‘dock’ in its first iterations.

The usefulness of Dashboard and the concept of the ‘desk accessory’ or widget started waning for me as soon as I got my first iPhone in 2008. Ironically enough, for many quick tasks and quick information retrieval, the iPhone has become the tangible desk accessory. In a way, fetching the smartphone to check things like the weather forecast, the status of a package that I should receive soon, or to make a calculation or unit conversion, is less disruptive of the workflow I’m having on the Mac than having an overlay or a dedicated space within the Mac UI itself.

But putting my habits aside for the moment, let’s focus on how widget management could work on the Mac, as it’s a good UI exercise. The crucial aspect to consider, then, is this: where to place widgets? How to handle them is important, too, but the ‘how to handle them’ aspect is intrinsically tied to where they should appear and be placed.

Before Dashboard, there was Konfabulator (those who didn’t know now understand the strange wording of this piece’s title). Konfabulator was an application that, once executed, remained accessible from the menu bar as a menu extra. Its initial offering of a handful of default widgets could be extended by downloading third-party ones created with the same engine.

Konfabulator 1.8 for Mac — Onboarding

Here’s a screenshot of the Widgets folder created by Konfabulator 1.8 with the default widgets that came with it:

Konfabulator Widgets folder

And here’s how some of them look on my iBook G3’s desktop:

The Konfabulator menu extra is that icon with the gears.

Konfabulator’s approach was to embed the widgets in the desktop itself, where they remained, beneath all open windows and apps, always ready to be glanced at when needed, and existing rather unobtrusively when not. If you needed to customise them, you could do so by using the Konfabulator menu extra or by right-clicking on them directly.

I liked them. They looked great. And some were indeed useful. But as you can see from the screenshot above, if you had a Mac laptop at the time, with relatively limited screen real estate, your desktop would get crowded very soon. That may not be a problem in itself, but it’s cumulative when you also have a lot of applications and windows open, and you also like to keep all the important stuff (files, folders, aliases) on your desktop.

Also: widgets don’t all work the same way. There are widgets that display information you want to constantly keep an eye on (such as a CPU/RAM monitor or a network monitor); widgets that serve as controllers for certain apps (like the iTunes mini-player); and widgets you only need to consult occasionally (say, a calculator, dictionary, or weather widget). So, you’ll probably want to keep some widgets permanently visible, while some other widgets you’d like to be easily invoked on demand.

An approach like Konfabulator’s favours the placement of static widgets. While adding/removing widgets isn’t cumbersome in itself, the operation of adding a widget to just glance at its information for 5 seconds to then put it away becomes clunky quickly.

A similar approach can also be seen in Panic’s Stattoo, an app developed in 2004–2006 that certainly didn’t want to replace Konfabulator or Dashboard, but whose idea was to offer a limited selection of widgets that could be placed on your desktop and display useful information like weather, date/time, battery status, song playing in iTunes, email headers, even RSS feeds.

Panic’s Stattoo — widget setup

Like Konfabulator, the selected widgets stayed on the desktop, always visible but in background, of course, so as not to interfere with other apps, windows, and items on the desktop.

Dashboard’s UI when it debuted in Mac OS X 10.4 Tiger. (Image source: Ars Technica)

Dashboard’s approach was different. The widgets you chose were placed on a transparent layer which — when invoked via a keyboard shortcut — would appear as an overlay on the desktop. This kind of approach tends to favour the use of those widgets you need to just glance at every now and then, over the widgets you’d like to monitor more frequently, but it’s overall more versatile. Given how quickly you could jump in and out of Dashboard, it was easy to keep an eye on things with CPU or Network monitor widgets by frequently tapping F12 (the default shortcut for Dashboard) or the dedicated Dashboard key on certain Apple keyboards. And if you really needed a Dashboard widget to be permanently visible even outside Dashboard, you could use this tip from Mac OS X Hints to do exactly that. This bit from Rob Griffiths’ additional note is worth quoting:

[…] I find it extremely useful — there are certain widgets that you’d just rather see and use all the time, instead of only in Dashboard mode. Note that the widgets float above all windows, so this trick is most useful if you have some spare desktop space.

Another bit that’s worth quoting is this one, by John Siracusa, from his review/essay on Mac OS X Tiger at Ars Technica:

I have one big complaint. Apple has unnecessarily linked two good ideas in Dashboard: the widgets themselves, and the Exposé-style layer where they live. While I really love the idea of a separate window layer for infrequently used items, I’m extremely disappointed that only Dashboard widgets can live there. To a lesser extent, I’m also disappointed that Dashboard widgets can’t be interleaved with regular windows, float on top of all windows, or be embedded in the desktop like Konfabulator widgets can.

I’d like to be able to put any application in the Dashboard layer, and I’d like to be able to pull widgets out of it and place them anywhere I want. This would require rethinking the Dashboard UI a bit (e.g., providing an active menu bar in the Dashboard layer) but I think the benefits would be well worth it.

Observations like these really make you wonder about what would be the best widget placement/interaction model. My impression is that the one that could meet the most disparate user needs would be tricky to design, UI-wise. Imagine an overlay implementation like Apple’s Dashboard, but with widgets that can be freely detached from such overlay and placed on the desktop with the flexibility proposed by Siracusa. How to make all the necessary interactions intuitively discoverable by the user? Tooltips that appear on first use and that can be subsequently toggled or dismissed? These are tricky little details to implement. Even Control Centre on iOS can only be customised by accessing the Settings app instead of via direct manipulation of the controls on the pane itself.

One thing is certain: the current implementation of widgets on the Mac is just poor. It’s bare-bones, it’s stiff, severely limited, and the idea to make them appear in the same interface as Notification Centre (to mimic the behaviour on iOS) is simply misguided. Whatever your Mac’s screen size, you get an unnecessarily cramped interface that feels like the worst of both worlds (Notifications and Widgets), as there is insufficient breathing room for each, and one seems to constantly get in the way of the other.

The original Apple’s Dashboard seems to have the most versatile of all these approaches, if you count the little ‘hack’ suggested in that old Mac OS X Hints entry. By the way, starting with Mac OS X 10.7 Lion, Dashboard could also be configured as a space instead of a transparent overlay, but I never found this option to be particularly appealing or effective. Mind you, this is a wholly subjective remark; I’m sure having Dashboard widgets on a dedicated space worked for some people. It didn’t work for me because I’ve always wanted widgets to come to me instead of having to go to them by jumping to their space. It’s subtle, but a single shortcut key (F12) is quicker than hitting Ctrl+(space number); more importantly, by having widgets appear on a transparent overlay you can still keep an eye on what’s going on underneath, or even reference it when you’re interacting with a widget. Simple example: you’re looking at an email attachment of a detailed invoice and you want to verify whether the total amount is correct. You invoke Dashboard and use the Calculator widget, and you can input the figures you’re still able to see underneath the overlay.

To conclude, would I want to see a return of Dashboard as it was before being removed by Apple? I’d certainly want an updated solution for widget management, because the current one is inadequate. As a recap, I think it should have the following characteristics:

• It should be utterly separated from Notification Centre. Widgets and Notifications are entities that need screen real estate to be really effective, and both demand complex interactions. Having them share the same (meagre) space, and having them appear simultaneously when you need to consult either is just poor UI design.
• It should work as an overlay or super-space, like the original Dashboard, more than a separate space you ‘visit’. Let the user control the opacity of the overlay, in case they don’t like transparency.
• It should handle widgets in the flexible way John Siracusa wished Dashboard could handle them. Have them appear on their overlay by default, but make them detachable and let users place them at whatever level they want: desktop level, Finder window level, application window level, or constantly in the foreground above all other windows. You may find this flexibility to be a bit excessive, but again, depending on what kind of information a widget displays or what kind of user interactions it entails, the user could prefer a specific placement for such widget. This could also inspire the creation of widgets with very specific uses: imagine a widget you can attach to a Finder window, and it tells you how many JPG files are contained in the currently open folder. (It could be JPGs or whatever kind of file you’re interested in). It’s a basic example, but such flexibility could inspire so many cool, useful widgets.
• It should have its own pane in System Preferences. Here, users could be reminded of the necessary gestures to handle widgets, customise shortcuts, and even customise the appearance of this ‘Widget Manager’.

Now, am I optimistic about something like this coming to a future Mac OS release? Of course I’m not. Just look at how Notifications management has visually regressed from Big Sur onward. Just look at how Apple appears to be hell-bent on making certain parts of the user interface work in the same way across operating systems, even when this forced consistency makes little sense. Just look at how brittle and disjointed the user interface flow is becoming especially in Mac OS. Designing a better Notifications interface and a better Widgets interface requires a meaningful rethinking and a commitment to good-design-that-works which Apple doesn’t seem particularly interested in, when you consider the direction Mac OS user interface has been taking after Mac OS 10.15 Catalina.