In LN 018, we explored how the OS of the future can have services which bring additional items into our system — things like emails, podcast episodes, calendar event invites, and so forth. We can use these items as freely as the ones we create ourselves, as seen in many of the earlier Lab Notes (e.g. LN 002, LN 004, LN 015).
Services that provide items to our system may also provide actions that can be taken on items of a specific type. For example, a service that brings calendar event invite items into our system may provide an action to RSVP.
So far in these Lab Notes, we’ve seen how the separation of the services which bring items into our system from the views we use to render and interact with those items has allowed us tremendous flexibility in creating the personal computing environments that best suit our lives and life’s work. Items become the fundamental unit with which we can more flexibly do our personal computing.
Similarly, actions are provided as-is by the system and services, and can be used any way we see fit. For example, views can render more than just item data; they can also take advantage of the actions related to an item being rendered.
In fact, when services make actions available along with items, we can make use of the functionality provided by a service through any means of interaction we would like (including many that the service vendor may never have thought to support — via new technologies, assistive devices, and so forth).
At the most basic, it’s straightforward to imagine menus that make actions available for a selected item. These menus could be customized by the user, who can prioritize favorite actions or customize specific actions (such as setting commonly-used parameters in advance). Alternatively, the system could automatically customize this menu, prioritizing frequently-used actions.
Extending into further use cases:
A command palette, seen increasingly in applications today, could allow use of the keyboard to quickly drill down to desired actions.
Users could assign hotkeys to specific actions.
Programmable devices (e.g. Stream Deck) could make use of favorite actions.
Extending into more advanced uses:
Using actions in new kinds of environments or with new technologies would not require new development from the service vendor. This is a compelling deviation from the way software is often built today, which would require each vendor to adopt support for a new class of device.
Users could set up automations that make use of available actions. For example, the arrival of a new email could trigger an automation that checks if it is from a specific sender, and if so, it could take some specific action on the email server in response (more on this in the next lab note).
Creating a shortcut that runs multiple actions would be simple as well. For example, you could add a button to your email item view that both (1) attempts to unsubscribe and (2) archives the email. Users would be able to add such buttons themselves, as seen in LN 009.
Users could choose favorite actions to appear on notifictions. For example, you could add “archive” and “remind in 1 day” buttons to notifications about new, important emails (see more on notifications in LN 019).
And of course there are system-level item actions that can be used in these same controls too: things like adding references (LN 012), opening associated items (LN 005), switching views (LN 006), assigning dates (LN 016), or opening a new browsing path (LN 004).
Something spark a thought? Email me, or come chat on Mastodon or on Twitter.