Using server-side headerbars, HUD and menu export to create a consistent, space-saving, touch-friendly and customizable UI for most applications.
-
(two articles with extensive mockups are linked at the bottom)
Example Headerbars:
Example HUD Overlay (could be made touch-friendly, see other mockups):
Summary
What if Unity 8 brought back the features of Unity 7 but in slightly different (more modern and robust) form? The idea is inspired by Gnome headerbars, KDE DWD protocol and (obviously) Unity 7 locally integrated menus and HUD. It borrows concept from all three. It can be used to create touch interfaces for apps that don't have them.
It also creates an extremely consistent consistent UI. Right now Gnome headerbars are wildly inconsistent with the UI of traditional applications. In general, no application rewrites will be required for this to work.
The idea is basically the following...
First the server-side headerbar. It's a very simplified version of KDE's DWD:
- Export menu items over D-Bus (doesn't have to be for all applications).
- For non-CSD apps, allow buttons and menus to be placed in the server-side window decorations, Gnome-style.
- These buttons will send D-Bus calls to the decorated application (or even run external applications/scripts).
- You can have hamburger menu(s) give the user actions that you can't fit into the decoration. So you can, for example, replace the menubar with
- These buttons and menus can trivially configured by the user or the developer (just like a toolbar).
- Many applications allow you to hide toolbars that you don't need. If the functionality of the toolbar has been transferred to the headerbar, the toolbar can now be hidden, giving much more room for content, which is important on smaller screens.
- Bonus: Would be nice to be able to have different colors for the server-side decorations, to match window chrome.
This way, app developers can deliver consistent native "headerbar" functionality to users with virtually no effort. And users can customize them to their needs. Nobody is locked into anything. Compare this with Gnome's approach of rewriting the entire UI for every app, a UI can't be customized by the user and won't work well anywhere outside of Gnome.
However, headerbars are very limiting. So one would have add HUD.
- The HUD is locally integrated (displayed wherever the app window is located).
- The HUD allows the user to search the menu items (or other stuff, if applicable). Like Unity 7.
- The HUD can also contain buttons and menus. You can use that to graft a touch interface on virtually any app. You can display the menu-bar as a big touch friendly sidebar, for example.
All of this stuff can be done with nothing more than menu export over D-Bus and a couple config files, but the possibilities are basically endless with further developer effort. One could integrate help documentation into the HUD, for example.
The gains in screen space, efficiency and UI consistency are potentially enormous. The HUD/Headerbar interface stays out of your way, unless you need it and is more discoverable and quick than using traditional menus and toolbars.
I wrote two articles with lots of mockups, one for the Headerbar and one for the HUD. Please take a look.
-
PS: probably more relevant to tablet interfaces than phones. This will still be useless for phones. But someone here might be interested.
-
Well, I have to say I cannot agree with the concepts. These things tend to exist as a matter of aesthetic, rather than for usability. They can actually make applications less usable, because their goal is to hide interface components in legacy applications. While some certain support may be useful in a transitional context, the idea of just shoving everything under a single menu button or hiding UI behind magic gestures or such, especially when such features are not a given on all platforms, is quite harmful to users.
Such features to help "integrate" legacy applications better, also increases maintenance burden and provides multiple additional points of failure. I think it would be far better to spend time moving away from legacy applications, and building fully converged and cross-platform apps that better serve user needs, with modern designed UI and smart interfaces.
Also, the latest version of unity8 already has support for the global menus feature.
And I guess you haven't actually looked at any applications which are designed for Unity 8 using the UITK, because the typical mobile "header bar" design is exactly what they use already.
-
@dobey Take a look at the latest Gnome Builder. It uses exactly the same HUD+Headerbar model, but it's a little crippled compared to this. Menubars, toolbars and Ribbons are IMO far less discoverable and far more limiting than a large HUD palette. And many apps use now use crippled hamburger menus, which are far worse than anything else.
Plus, today you have GTK+ headerbars, menubars, toolbars, ribbons, hamburgers, CSD, SSD which means zero consistency on the desktop. So even if these UI models were in theory good to use (which IMO they are not), they can't deliver anything approaching discoverablity or ease of use because there zero consistency on Linux now.
Note that the large "Menu" button would bring up a large search-HUD, much more discoverable than Gnome or Chrome's tiny hamburgers. The HUD exposes all the functionality that is not exposed in the main window, meaning you can still the main tools in the main window.
You are right that for true convergent apps that can run on phones you need to new apps entirely. But there are also tablets, convertibles and laptops where users will find the selection of UITK apps limiting. And Linux mobile is now going through the same fragmentation on phones that it did on desktops, with KDE, Gnome and UB developing their own separate ecosystems.
I'd like to see Linux UI become unified some day. Unity 7 was an attempt at delivering some consistency and lots of people would like to see something like that emerge again. But I don't think Unity's global menus or LIM can deliver a flexible and consistent UI anymore, for a whole host of reasons, so that's why I proposed this idea.
Headerbars and HUD can't be that bad, can they? They seem to be the future these days, but if you require developers to rewrite their apps, these features will be implemented on very few apps (and they won't be implemented with any consistency).
Such features to help "integrate" legacy applications better, also increases maintenance burden and provides multiple additional points of failure.
Correct. But global menus introduce the same points of failure, while CSD (and any other client side feature) introduces many more points of failure multiplied by the number of apps. There are so many bugs and quirks related to CSD that it's hard to know where to begin. Centralization would reduce the points of failure, especially in the long run.
are not a given on all platforms, is quite harmful to users.
Maybe collaborate with KDE and Mate? They are both interested in this server-side direction, particularly KDE with DWD. Gnome would be interested too if they saw other platforms adopting it.
-
@leftcrane I understand your opinion, but I cannot share it. The HUD is not discoverable because you cannot browse it. You must already know what it is you need to find, to be able to find it. Menus and toolbars may have become overgrown over the years, but one can always simply browse through them to discover what functions are available, and try them out. Calling it a HUD is also disingenuous, as it's a search, not a display to notify the user of important information. Notifications are far more "HUD" like than the so-called HUD is.
Correct. But global menus introduce the same points of failure, while CSD (and any other client side feature) introduces many more points of failure multiplied by the number of apps. There are so many bugs and quirks related to CSD that it's hard to know where to begin. Centralization would reduce the points of failure, especially in the long run.
Global menus only move the main menubar to the window title or top panel, and as I said, is a decent means of transition, but anything related is by no means "the future of UX." I understand you may have had some bad experience with CSD, or have some personal feelings about it, but I must disagree with your claims. CSD is perfectly fine, and apps have been doing it for decades by simply telling the WM to not display any borders, and providing their own close/minimize/etc… functionality integrated into the app. Maybe not a majority, but plenty have.
Maybe collaborate with KDE and Mate? They are both interested in this server-side direction, particularly KDE with DWD. Gnome would be interested too if they saw other platforms adopting it.
I don't understand why you're making the assumption that Unity8 is tied to this legacy idea of server-side decorations versus client-side. It's also not clear what your goal is here. You keep talking about "consistency" but the mock-ups you are presenting lack it, and as long as third party developers build apps, there will always be some level of inconsistency. Even on iOS where Apple is much more strict about app presentation, there is inconsistency across applications.
From this end of the ether, it looks to me like there isn't a clearly and well defined goal here, but you are just upset about GNOME and CSD, and are making a lot of assumptions about how things work, or what users expect or want.
-
@dobey If every application has a HUD a Headerbar, that's consistency to me. The HUDs and headerbar mockups are all different because I am trying to illustrate what's possible. Gnome CSD already has headerbars, so they'll just get the HUD. Other apps will get the HUD and headerbars. Of course it's optional and per-app.
I don't see how Gnome's headerbars and HUD are any better than what I am proposing, they are just more locked-down and require entire apps to be rewritten. The UI concept is basically the same. Gnome's
CSD is perfectly fine, and apps have been doing it for decades by simply telling the WM to not display any borders
I think the results on a legacy platform that's not tightly controlled are bad. On platforms like Windows and Linux, CSD guarantees terrible inconsistency and duplication of effort. It took Firefox a year to get normal looking CSD just on Gnome. And their CSD won't on KWIN. If they could use a DWD standard (which would be the logical extension of the above proposal), it would have taken them an hour to get native headerbars in most Linux DEs.
Even on iOS where Apple is much more strict about app presentation, there is inconsistency across applications.
Some inconsistency is fine. Don't let the perfect be the enemy of the good, imo. Mac OS X has reasonable consistency. Linux is in a very bad state.
but you are just upset about GNOME and CSD
Oh no, I actually like Gnome's design, A LOT. But I think KDE was right on DWD years ago and they are right now. If Gnome monopolized Linux, CSD wouldn't cause inconsistency in the long run. But they are just a small part of the ecosytem. I want other apps to be reasonably consistent with Gnome apps.
-
If every application has a HUD a Headerbar, that's consistency to me.
It's fine you might think that, but how does that help?
Gnome CSD already has headerbars, so they'll just get the HUD.
What will provide this "HUD" exactly? Will it function when running these apps on other platforms, or under other environments? What problem is it actually solving? How does it help people use the system?
Other apps will get the HUD and headerbars. Of course it's optional and per-app.
How will they get these things, without changes to said apps? Of course it's optional, because apps will have to be changed to use some new API, and most will simply not use it.
I don't see how Gnome's headerbars and HUD are any better than what I am proposing, they are just more locked-down and require entire apps to be rewritten. The UI concept is basically the same. Gnome's
I didn't say GNOME's system was "better" nor did I say yours was "worse," however I must say you have failed to explain how yours is better (assuming that is in fact the position you're working from). You are making some exceptional claims, and not providing any evidence. I think you also perhaps maybe cut this bit short, ending with just
Gnome'shere.Mac OS X has reasonable consistency. Linux is in a very bad state.
This is a very inappropriate claim. The only difference is you are choosing not to run apps built to other design guidelines on MacOS, and you are falling prey to the fallacy that "Linux" is on the whole equivalent to being a single operating system/environment, when it is many. It's not Windows/Mac/Linux. It's Windows/Mac/Ubuntu/RedHat/SUSE/GNOME/KDE/i3wm/etc… and this extends to include all the BSDs and other free operating systems with multiple distributions, as well. You cannot view all Linux distributions as a single OS. They are all competing systems with disparate goals in design, function, and architecture. The only reason MacOS might seem more "consistent" to you in terms of UI/UX, is due to subconsciously choosing to only use apps which follow that consistency. In fact, MacOS is no better or worse at consistent UI than any variation of Linux is.
I think you need to work on stating what exactly the problem is which you're trying to solve, and perhaps scale back a bit. Whether decorations are client side or server side is irrelevant. You've also been making the assumption that everyone knows what every piece you're talking about, is. I had to go search for DWD to find out what it is, only to find 3 year old posts about "where is this DWD design at?" It seems to not be implemented in KDE, despite your claims of greatness. It was an experimental design, and personally I don't think it's feasible.
-
What will provide this "HUD" exactly? Will it function when running these apps on other platforms, or under other environments?
Menu export over D-Bus, mainly, or anything exported over D-Bus, plus any external scripts or programs relevant to the app.
A robust API (like KDE's DWD) would of course not be supported by most applications, but neither is any particular CSD implementation, and that's OK. But at least applications with different tool-kits could use such an API, unlike Gnome CSD which is just for Gnome apps.
Will it function when running these apps on other platforms, or under other environments?
Yes, HUD implementations are completely independent of the WM under X and relatively independent under Wayland. Gnome menu-less CSDs aren't supported on KDE, not to mention other operating systems.
What problem is it actually solving?
Same problems Gnome's HIG is solving, and many more. The "more" includes consistency, flexibility, discovery etc.
I think I may need to clarify the benefits a little better, but I think it ultimately boils down to some people thinking it would be valuable and other people thinking it's not worth it.
