Ideal UX is my (creatively named) personal project to design my ideal cross-form-factor system UX. It came out of inspiration from and frustrations with various system environments I have used over the years and ones I sought to explore further while designing this, including Android, Chrome OS, Windows, i(Pad)OS, MacOS, WebOS, BlackBerry OS, Sailfish OS, Gnome, KDE, and others.
One core goal was a unified set of gestures across smaller- and larger-screen devices. I had been frustrated by existing inconsistencies in gesture interactions and system UI element placement across desktop/tablet/phone versions of some interfaces, as well as approaches that dropped to the lowest common denominator (e.g., Android 4.2+, early iPadOS, and short-lived tablet WebOS treating tablets more like big phones) or offered confusing compromises (e.g., Chrome OS tablets attempting to support a Windows-like top swipe and iPadOS-like bottom swipe to grab the current app).
My earlier drafts attempted to combine familiar parts of the Windows taskbar, Android navigation bar, and Chrome OS shelf, with a bottom bar that had back and launcher buttons on the left and system and notification icons on the right. Similarly, the mobile experience would also gain the Windows gesture of swiping down from the top of the screen to grab the current app/window, and optionally dragging it to the bottom to close it.
After further exprimentation and consideration, I decided to literally flip that design on its head. I realized I had been holding on to the familiarity of the Windows taskbar, Chrome OS shelf, Android 3.x system bar, and Gnome 2/KDE/Cinnamon/etc. equivalents always being on the bottom. At the same time, there was a reason app window gestures were bottom swipes on more recent mobile devices—you generally perform those gestures more frequently than opening the launcher, notifications, or quick settings, so it makes sense to have those gestures most conveniently close to your thumb. That extended to laptops and “2-in-1”s with touch screens as well—window gestures starting from the bottom puts them in easier reach of hands resting on a keyboard.
Microsoft and Mozilla had already shipped tablet browsers with tabs and address bars at the bottom of the screen for that reason, but once I started thinking about it, window controls at the bottom of apps made sense across the board. Many apps have been adding more components to the title bar (menus, search boxes, account switchers, and more), reducing the available area for dragging. Additionally, many apps already have a status bar at the bottom that shows read-only status information. It would disrupt the typical experience very little for that bottom bar to become a draggable region, and apps could also follow the Windows Aero pattern of the bottom (“glass”, in that case) layer being draggable places other than the top of the window to still allow it to be grabbed by the empty space on the top bar. And for the Windows and Chrome OS pattern of putting the back button in the title bar, it would line up with the bottom bar position on mobile (when not using gesture back).
Another aspect of the mobile system experience I wanted to address was the home screen. And by “address”, I mean I wanted to eliminate it.
More precisely, I wanted to give mobile devices a “Start menu”-like experience, where the launcher is a panel that opens and closes over whatever you are doing rather than being an app of its own to spend time in. The most obvious advantage that could offer over the home screen pattern is allowing you to peek at widgets without closing out of your current task. It could also help prevent getting distracted from a multi-app task to have your current app open under the launcher
The possibly even more beneficial effect would be, if you closed all apps, you would be left at a blank desktop instead of your screen of apps and widgets, making it easier to choose to step away from your phone (as is currently the out-of-box experience on most desktop OSes, especially Chrome OS). You could choose to open the launcher to check widgets or open another app, but the choice would no longer be made for you by the system.
In the actual appearance of the launcher, I clearly took a lot from the Windows 10 refinement of the tile UI, combined with a healthy amount of Android and Linux launcher UX. Fitting app tiles and widgets to the same grid helped alleviate the cluttered feeling many Android home screens can have while still letting widgets be more functional than Windows live tiles. The app list could default to alphabetical sorting, like Windows and Android, but also have an option for category grouping, a common useful feature of many Linux launchers.
Notifications being on the same side of the top bar as system icons had the potential to be very cluttered if I took Android's historical approach of showing as many icons as will fit. I definitely did not want to take Apple's (and others') approach of giving no indication of notifications or the Windows/Chrome OS (again, among others) approach of generally just showing a count. I could take Android 9+'s approach of only showing the first 4 notification icons, but that still has the issue of hiding the total count.
The problem with all those approaches was not all notifications are equal. For instance, if I have social media notifications in the middle of my day, I frequently mentally filter them into a blob of lower priority notifications to check later. Ditto for things like non-priority personal emails, app updates, or notifications from my photos app. On the other hand, while Android prioritizes conversations automatically, I also definitely want things like event reminders to grab my attention.
The compromise I liked most took the best of several approaches: Silent (lowest priority) notifications would not show up at all; non-silent lower priority notifications would increment a counter; conversations and high priority notifications would show the app icon, but only once, regardless of the number of notifications from that app; high priority conversations would show the sender's profile picture (exactly like Android 11+); and ongoing activities (e.g., timers, map navigation, or calls) would be shown first with an optional chip to show a tiny bit of status information (e.g., time remaining or next turn direction, and getting collapsed down to a regular notification in the infrequent case there are too many ongoing activity chips). A high-/low priority system would be simple enough to be user-friendly, but combined with the special treatment of conversations and ongoing activites, it can allow the system to more intelligently unclutter the space.
My primary changes to notifications themselves were focused on reducing the clutter that gets in the way of the notification content. Android 12 was the most notorious offender, not leaving enough room to see even a full sentence between the app icon, profile picture, expander arrow, and extra padding. While better, Android 7-11, Windows 10+ and some versions of iOS still dedicate(d) a lot of space to the app that generated the notification and other metadata.
Following the examples of Android 3-5, earlier Chrome OS, and Android 11 conversation notfications, I brought the sender profile picture or attachment thumbnail back to the left side of the notification, and then placed the app icon in a cutout in the corner of it. To save more space, I moved the timestamp into the column of padding below the icon/thumbnail (an idea I associate with Rizzoma, though I am sure I encountered it elsewhere before that).
I made a separate webpage to show off the current state of my Ideal UX mock-ups. They are far from final or comprehensive, but I am happy they give a more polished visual example of what I am going for. I hope to iterate and expand on them further in the future, and also finish an interactive demo.
I would love to someday have a fully usable version of this experience (or the most important parts of it) on top of Android, but that is unfortunately beyond my current skills. I am considering someday recreating pieces of it on Windows, but that is far down the road.