(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:

1. Export menu items over D-Bus (doesn't have to be for all applications).
2. For non-CSD apps, allow buttons and menus to be placed in the server-side window decorations, Gnome-style.
3. These buttons will send D-Bus calls to the decorated application (or even run external applications/scripts).
4. 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
5. These buttons and menus can trivially configured by the user or the developer (just like a toolbar).
6. 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.
7. 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.

1. The HUD is locally integrated (displayed wherever the app window is located).
2. The HUD allows the user to search the menu items (or other stuff, if applicable). Like Unity 7.
3. 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.

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.

@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.

@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.

PS: probably more relevant to tablet interfaces than phones. This will still be useless for phones. But someone here might be interested.

(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:

1. Export menu items over D-Bus (doesn't have to be for all applications).
2. For non-CSD apps, allow buttons and menus to be placed in the server-side window decorations, Gnome-style.
3. These buttons will send D-Bus calls to the decorated application (or even run external applications/scripts).
4. 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
5. These buttons and menus can trivially configured by the user or the developer (just like a toolbar).
6. 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.
7. 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.

1. The HUD is locally integrated (displayed wherever the app window is located).
2. The HUD allows the user to search the menu items (or other stuff, if applicable). Like Unity 7.
3. 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.