Suggestion: unique desktop interface

[roracle]

If you wish, I could give some mockups of what I believe to be a more unique desktop interface. As it stands, it looks WAY too much like macOS, and not enough like something new.

I actually enjoy the top bar, but the bottom shouldn't be a dock, you're just wasting space that could have other utility.

[probonopd]

Hello @roracle, thanks for reaching out.

It is explicitly not an objective of helloSystem to look like macOS or "modern" (as in: like iOS or Android), but it is an objective to feel Mac-like and to look slick but not distracting.

Our starting point are the concepts behind the early GUIs of the 80s.

Please check out the following resources prior to starting any work:

• Apple Computer, Inc., 1992, Macintosh Human Interface Guidelines, First Printing, November 1992. Addison-Wesley Publishing Company. ISBN 0-201-62216-5

Quote:

If you are a designer, a human interface professional, or an engineer, this book contains information you can use to design and create products that fit the Macintosh model. It provides background information that can help you plan and make decisions about your product design. Even if you don’t design and develop products for the Macintosh, reading this book will help you to understand the Macintosh interface.

• https://github.com/probonopd/hello/wiki (also the links at the right-hand side)
• My six-part series on #LinuxUsability
• The desktop metaphor must be saved article
  We'd welcome thoughts and scribbles/mockups of UX ideas. The chance that they will be considered for inclusion in helloSystem increases if they reflect the above. Indeed it would be welcome if our system could get a more distincive look, while still maintaining (or taking to the next level) the spirit of the early GUIs of the 80s and the look of (toned-down) mid-00s skeuomorphism (for example, a button should look like a button and not just be some text which may or may not be clickable).

In case you want to experiment with the style sheet, it can be edited and tested at runtime (just launch a new application and it will take effect): /usr/local/etc/xdg/stylesheet.qss.

[roracle]

Awesome! We're dealing with weather and power outages as it were, but I'll check all that out when the local infrastructure is stable again.

[ghost]

As an ex-Amiga user (and current Linux user), I really miss some key aspects of the spatial desktop paradigm that were common to AmigaOS and Mac system 1-9. Most of these you have captured in your posts so far @probonopd but one key tiny thing is missing:

The close button should never have been moved next to the other window controls.

If there's anything I would like to suggest you could change, it would be to reinstate the idea that close is on the left and minimise and expand are on the right (like Haiku).

This is one of the usability guidelines I think that came out of Fitts's law? That controls that are destructive should not be grouped with the non-destructive controls.

Amazing work so far, BTW :)

[ghost]

Something like this? Squarified a little for a hint of the older styles.

[probonopd]

Good points @moochris.

I really miss some key aspects of the spatial desktop paradigm

Me too: #79

Controls that are destructive should not be grouped with the non-destructive controls

Interesting point. I am not sure that the traffic light colors are still recognizable if the "traffic light" is not in one piece. Possibly we should use icons e.g.,

(x) ==== Title === (-)(+)

instead, which would also work better for the colorblind. Wdyt?

[ghost]

A spatial desktop/file manager would be great - I guess some thought about how exactly the metadata would be stored (as extended attributes like Haiku or through some other mechanism?)

Yes, agreed that the symbolic icons would be better 🙂

[probonopd]

Possibly using extended attributes.

[roracle]

Good points @moochris.

I really miss some key aspects of the spatial desktop paradigm

Me too: #79

Controls that are destructive should not be grouped with the non-destructive controls

Interesting point. I am not sure that the traffic light colors are still recognizable if the "traffic light" is not in one piece. Possibly we should use icons e.g.,

(x) ==== Title === (-)(+)

instead, which would also work better for the colorblind. Wdyt?

Perhaps it should be the traffic light colors with the icons? This would be familiar to those who are used to the colors while maintaining a default option for colorblind people. And keeping this in mind, color blindness isn't the absence of color but varies in shade and hue depending on the person. As a result, the traffic colors should be muted enough to not interfere with the icon visibility, but not so washed they are unattractive.

[roracle]

I might also suggest this behavior with the icons (respectively with position, not exact as in the video) when a window is maximized. Reminder: this lasts only a few seconds, but also in the second video, this might be a more reasonable way of handling the desktop interface to keep it "kind of mac-ish, but unique and attractive". Again the window control buttons would be part of the top bar on maximize.

https://youtu.be/aH5VhJphTH8?t=43
https://youtu.be/Q571XWR9vas?t=43

[probonopd]

Thanks @roracle - interesting, I have never seen this before. However, I don't think window controls have any business in the global menu bar because:

• They belong to the window
• The global menu bar is not shown when an application enters fullscreen (not: maximized) mode
• When the window is maximized (rather than the application is in fullscreen mode) then we want the normal window title bar to show, so that one can see the window title and window controls

[roracle]

@probonopd if an application is full screen, window controls are often hidden anyway. At least I've never seen window controls on a full screen application. If you're in Firefox right now, hit F11 and you'll see.

This method I suggest saves screen real estate when there's a top panel and bottom dock. It brings the entirety of the application into focus. Again, this is for maximized windows, not full screen.

Another reason this would be neat is it gives a unique quality to the interface that no one else does, except people like myself customizing KDE. And I've never seen anyone do it except me, and possibly the guy who created the widget.

I am going to champion this here because there's no way anyone could hate it. And it could always be turned off or on.

But even more important is WHY I use this method: it's a usability issue. When I want to close a window, I don't have to target my cursor over the control. I can simply move to the top right corner of the screen and click, and it's done.

I can see this being useful for people with tremors and other afflictions that cause the hands to shake.

[probonopd]

In Falkon, which is our default browser, the menu bar is not shown in full screen either, so putting the window controls into the menu bar would not have any advantage for fullscren mode.

For the maximized window, we want to have a proper title bar with the title of the window visible, hence we also can put the window controls into the same window title bar as usual.

When I want to close a window, I don't have to target my cursor over the control. I can simply move to the top right corner of the screen and click, and it's done.

Indeed this is a valid argument. But then, pressing Command-Q ("Quit") should do the same job.

Besides, I would not even know how to implement this technically and it would add a lot of overhead for sure. helloSystem needs to say "no" to many ideas if it wants to stay lean and consistent.

[roracle]

For the maximized window, we want to have a proper title bar with the title of the window visible, hence we also can put the window controls into the same window title bar as usual.

This always confused me. There are guidelines, but it's those who break the rules that make the biggest splash.

I believe wholeheartedly in a new method of using computers while keeping the desktop metaphor intact. If you're going to have a menu across the top, why not just throw the window title into the top menu like macOS does, and that would eliminate the need for the top of the window border completely when maximized, especially if all it contains is the app name and buttons?

If you wouldn't know how this would be done, here's a link to the widget's project page. Maybe it could give some insight.
https://github.com/psifidotos/applet-window-buttons

I have full faith in your abilities, not so much in mine, for programming a desktop system. I think what helps here is that you have the opportunity to not have that overhead because you're going to have tighter control over the desktop itself instead of having to pull the KDE "everything can do anything anywhere" which is one of the things that causes too much overhead in the first place. But the tight control over it could reduce that greatly, bake it into the cake as it were.

[probonopd]

Thanks for sharing. I will think more about it.

In the meantime, I wholeheartedly recommend you to read

Apple Computer, Inc., 1992, Macintosh Human Interface Guidelines, First Printing, November 1992. Addison-Wesley Publishing Company. ISBN 0-201-62216-5

In fact, as they say in the preface to this book,

If you are a designer, a human interface professional, or an engineer, this book contains information you can use to design and create products that fit the Macintosh model. It provides background information that can help you plan and make decisions about your product design. Even if you don’t design and develop products for the Macintosh, reading this book will help you to understand the Macintosh interface.

[roracle]

@probonopd is there a free digital copy of this book to look through?

[schusz]

@roracle https://dl.acm.org/doi/book/10.5555/573097

[probonopd]

Word has it that the leading mastermind behind the early editions of the book was Bruce "Tog" Tognazzini.

[Lestibournes]

As an ex-Amiga user (and current Linux user), I really miss some key aspects of the spatial desktop paradigm that were common to AmigaOS and Mac system 1-9. Most of these you have captured in your posts so far @probonopd but one key tiny thing is missing:

The close button should never have been moved next to the other window controls.

If there's anything I would like to suggest you could change, it would be to reinstate the idea that close is on the left and minimise and expand are on the right (like Haiku).

This is one of the usability guidelines I think that came out of Fitts's law? That controls that are destructive should not be grouped with the non-destructive controls.

Amazing work so far, BTW :)

Perhaps the same principle could be applied to keyboard shortcuts: don't put close window next to open new tab, for example.

[probonopd]

We have since moved away from "stoplight" window buttons, and have put close to the left hand side and the other controls to the right hand side, functionally more like the Classic Mac before X.