Tails

#2 Updated by intrigeri 2016-04-05 10:47:33

> It could be argued that this should be fixed in upstream (GNOME), but I think many of our users are in another position than most other GNOME users. We should aim to make Tails as usable as possible for users who mainly use other operating systems.

FWIW, I agree.

> And both Windows and OS X have a minimize and maximize button in the title bar.

Wrt. the maximize button: why not, I don’t care much.

Wrt. the minimize one: why not, but I’m slightly concerned that this (+ the habits that go with it) relies upon the windows list (“task bar”), that we currently have since we run GNOME Shell in Classic mode, but it’s not obvious that we’ll have it forever (e.g. we may decide to move to the regular GNOME Shell for Tails 3.x or earlier, and GNOME Classic might become less well supported if enterprise desktop distros move to the regular Shell experience). So, in a sense, not making it obvious how to minimize windows is a nice first step towards 1. shipping something closer to regular GNOME SHell; 2. training users to interact with windows with other means than the “minimize” feature. And on the contrary, re-introducing the minimize button 3 months after we released Tails 2.0 would feel like a step backwards, and some debt we might have to deal with later (as any delta we decide to create).

I have a few more arguments in favour of keeping things as-is:

• this can be changed in GNOME Tweak Tools;
• adding widgets makes UX worse for everyone who doesn’t need them; this problem was not raised during the 2.0 testing phase (beta, RC), and it was just filed a couple weeks ago, so I doubt many users have problems with the current situation; with this in mind, I’m not convinced the pros/cons ratio of the proposed change is favorable.

Now, I’m not sure myself what’s best, I won’t research the subject further, and I could live with re-adding those buttons. This is just additional points I feel should be taken into account before we make this change in a hurry :)

#3 Updated by sajolida 2016-04-15 08:15:29

I’m also not sure what to do… I acknowledge the inconsistency but I also know that GNOME’s native applications are the ones in which more UX and design is put on by GNOME, so they are most likely more aligned with “the way forward” in GNOME.

But then we have an option to add the buttons when missing but not to remove them in non-native applications, so I tend to be more aligned with intrigeri’s position (= status quo), as I would otherwise propose to consistently remove them.

Still I’m not convinced by intrigeri’s arguments as:

• We’re considering removing Tweak Tool (Feature #11237).
• I don’t expect people annoyed by this to scream and shout on our user channel whn discovering 2.0. Having the issues raised only weeks after 2.0 doesn’t mean that it’s not affecting many people; for me it just means that it’s not affecting them badly.

Also, GNOME 3 is relatively new and things are still moving quite a bit regarding core elements, so I’d be curious about looking out for discussion or design documents in the GNOME sphere about these elements. The issue is affecting them as well and I would be surprised if we couldn’t find past discussions about this elsewhere.

Anyway, I know that polishing UI and consistency is important but here the problem might be common but I don’t think it’s that serious and the solution is not clear. So don’t expect me to spend a lot of time on this myself but I’m happy to follow up and I won’t block decisions that are properly justified.

#4 Updated by segfault 2016-04-20 09:36:26

I forgot to add myself as a watcher, so I only saw your replies just now.

> Wrt. the minimize one: why not, but I’m slightly concerned that this (+ the habits that go with it) relies upon the windows list (“task bar”), that we currently have since we run GNOME Shell in Classic mode, but it’s not obvious that we’ll have it forever (e.g. we may decide to move to the regular GNOME Shell for Tails 3.x or earlier, and GNOME Classic might become less well supported if enterprise desktop distros move to the regular Shell experience)
I think we should not move to regular GNOME Shell, even if enterprise distros move. My argument is the same as above: GNOME 3 might bring some nice UX once users get used to it. But most Tails users only use Tails occasionally and thus will have a hard time getting used to new desktop concepts. IMO users expect something like a taskbar and if at some point we feel that GNOME Classic is not well supported anymore, I think we should consider switching to one of the many other desktop environments which still offer taskbars: KDE, xfce, LXDE, Cinnamon, Mate

> this can be changed in GNOME Tweak Tools;
But we don’t support storing these changes persistently. So users would have to do this everytime they boot Tails and want to minimize a window.

> adding widgets makes UX worse for everyone who doesn’t need them
I think the UX regression of having another button next to the existing close-button is far less than the annoyance of not knowing how to minimize this one window, while you can minimize all the other windows. Also, because the buttons are present on other windows, I think even the UI inconsistency outweights this point.

> this problem was not raised during the 2.0 testing phase (beta, RC), and it was just filed a couple weeks ago, so I doubt many users have problems with the current situation; with this in mind, I’m not convinced the pros/cons ratio of the proposed change is favorable.
I think many users have this problem many very few users will make the unproportional effort to complain about this. Especially because there are other ways to minimize the windows which users might figure out after some time (right clicking the window’s menu bar and choosing “Minimize” or clicking the corresponding item in the taskbar).

> GNOME’s native applications are the ones in which more UX and design is put on by GNOME, so they are most likely more aligned with “the way forward” in GNOME
Like I said above, I don’t think we should follow GNOME’s way forward but keep to what users know and expect.

#7 Updated by intrigeri 2016-04-26 02:58:44

> If anonym has a strong opinion on this I’ll let him merge or reject.

Works for me, with the additional note that if it’s decided that we add these buttons, I personally won’t feel committed to maintain that piece of delta e.g. on our way to Debian Stretch and newer.

I’ll refrain from arguing more here on the general / strategic topic of “following GNOME’s lead”, what desktop interface users are expecting (or not expecting anymore) in 2016, etc. But if this pops up again in some other specific situation, I think we’ll need to have this conversation e.g. on tails-dev@, before we establish too many precedents in one way or the other.

#8 Updated by sajolida 2016-04-26 09:42:27

I played with Ubuntu 16.04 today, and there gedit, Files and the others all have the three buttons consistently.

#10 Updated by sajolida 2016-04-27 05:20:19

But thanks for raising this point as I finally agree with the initial proposal :)

#11 Updated by segfault 2016-04-27 12:36:54

> So I search a bit for discussions within GNOME about this topic and found this:
>
> https://afaikblog.wordpress.com/2011/03/01/where-did-the-buttons-go/
> https://mail.gnome.org/archives/gnome-shell-list/2011-February/msg00192.html
>
> With quotes like:
>
> « They don’t make sense within the current shell design. There’s nothing to minimize to, like a dock or window list, and it’s potentially confusing, since users will not know where their windows have gone. »
> « The minimize icon is a remnant of the GNOME 2 taskbar and has nothing to do with the GNOME 3 experience. (Really, we don’t have minimization at all, we have “hiding”) »
>
> My conclusion is that minimize should go along the windows list that we have in the bottom. Since we decided to have the windows list we should have minimize. The day we decide to remove the windows list we should remove minimize.

Great! Thanks a lot for the research!

> Meta: I had a good time doing this research this time, but as a general dynamics, I’d really prefer if the people proposing a diversion from upstream backed it up with data gathered upstream as well about the reasons behind a given behavior. This shouldn’t be the job of people initially resisting a diversion from upstream.

I agree. I should have done this research. I didn’t think about it. I guess it’s because I didn’t expect to find arguments in my favor in upstream discussions. And I thought my arguments might be convincing on its own, but I see that it helps to understand the decisions of upstream and that their reasons actually don’t apply to our situation :)

#12 Updated by intrigeri 2016-04-27 14:07:11

> My conclusion is that minimize should go along the windows list that we have in the bottom. Since we decided to have the windows list we should have minimize. The day we decide to remove the windows list we should remove minimize.

Makes sense, thanks for doing the research!

#13 Updated by elouann 2016-04-29 06:51:35

> My conclusion is that minimize should go along the windows list that we have in the bottom. Since we decided to have the windows list we should have minimize. The day we decide to remove the windows list we should remove minimize.

+1, and thanks for the researches
Tails also differs from upstream by adding links on the desktop: minimizing windows is usefull to access the Tails offline documentation, for example

#20 Updated by intrigeri 2017-09-07 17:11:40

(From a rabbit hole that lead me from Bug #13461 to Feature #11717 and this ticket..)

From what I’ve heard in a GUADEC talk, a careful design decision resulted in dropping the “minimize” button. The idea is that the user should not have no mentally/internally manage themselves the list of currently running apps: hiding windows forces them to do that. This approach is consistent with displaying one single icon in the dash for an app, regardless of whether it’s started or not, and with the lack of a task bar: if I want to use a given app, I’ll click its launcher, and I don’t need to know if it’s already started (=> go to task bar) or not (=> go to apps menu); if I don’t want to use it anymore, I can simply close it (and next startup will be fast because it’s in the disk cach); and if I want to keep tons of apps running at the same time (my use case!), then I can use virtual desktops. I found this explanation convincing, but I’m aware I’m very easy to convince that GNOME decisions are good ;)

All this confirms the results of the research sajolida did earlier on this ticket: having a minimize (sic; it should be called “hide”) button is consistent with displaying a taskbar. They go together, and if we ever want to drop one of them, the other should go away as well.