After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 696351 - Dash behaviour with lots of open apps [!]
Dash behaviour with lots of open apps [!]
Status: RESOLVED DUPLICATE of bug 701387
Product: gnome-shell
Classification: Core
Component: overview
3.6.x
Other Linux
: Normal major
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-03-21 23:14 UTC by betdomagoj
Modified: 2015-02-27 13:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of the overview (426.10 KB, image/png)
2013-03-21 23:14 UTC, betdomagoj
Details
5 apps (736.71 KB, image/png)
2013-03-25 19:35 UTC, betdomagoj
Details
ext (700.68 KB, image/png)
2013-03-25 19:36 UTC, betdomagoj
Details
size (617.31 KB, image/png)
2013-03-25 19:36 UTC, betdomagoj
Details

Description betdomagoj 2013-03-21 23:14:06 UTC
Created attachment 239504 [details]
Screenshot of the overview

The overview has a SERIOUS problem in regards to the dash.

The problem is existent in these two use cases:
1. when a user decides to put a lot of apps in his dash e.g. make a lot of apps favourites 

2.when a user launches a lot of apps

The problem is this: First, with the increasing number of apps the dash starts to shrink - the more the apps, the more it shrinks. It starts to shrink too much; the app icons become far, far to small. Finally, as if the smallness problem wasn't enough, the dash overloads so to speak,the number of apps in it becomes to great, as you add more those before disappear and some overlap with the "show applications" icon.

This suggests that there is a limited number of not just apps that can be favourites (which is a lesser problem) but that there also is a limited number of apps open whose icon can be shown on the dash.

In my experiment, I managed to overload the dash with only 18 icons. With the 18th icon it started to over lap the "show applications" icon so I couldn't use it anymore.
Also, my exp. involved making the apps favourites, but this also applies to simply - running the apps - WHICH IS A PRETTY BIG ISSUE!

This is a MAJOR FLAW in the design of shell which needs to be fixed! 

I hope you do not expect people to use a maximum of 17 apps?! 

So, you should change the way the dash works. Maybe instead of shrinking it you could make it scrollable? 

Whatever works. But this nneds to get solved.
Comment 1 Matthias Clasen 2013-03-22 13:21:27 UTC
I don't agree with your shouting. And using 17 apps productively at the same time seems like a pretty tall order, even for a good multitasker. But obviously, the dash shouldn't visibly break in that case, we need to handle it somehow.
Comment 2 Florian Müllner 2013-03-22 17:56:44 UTC
I know making the dash strictly about favorites (e.g. no running apps) is discussed by the design team. If we do that, we could just disallow adding favorites once we can't fit any more items.
Comment 3 betdomagoj 2013-03-22 19:01:16 UTC
(In reply to comment #1)
> I don't agree with your shouting. And using 17 apps productively at the same
> time seems like a pretty tall order, even for a good multitasker. But
> obviously, the dash shouldn't visibly break in that case, we need to handle it
> somehow.

I don't bloody care if agree with my shouting. That's not the point.

I am pointing out a quite ridiculous problem that any design team that's been working on their DE should have noticed and solved it.
Comment 4 betdomagoj 2013-03-22 19:01:49 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > I don't agree with your shouting. And using 17 apps productively at the same
> > time seems like a pretty tall order, even for a good multitasker. But
> > obviously, the dash shouldn't visibly break in that case, we need to handle it
> > somehow.
> 
> I don't bloody care if agree with my shouting. That's not the point.
> 
> I am pointing out a quite ridiculous problem that any design team that's been
> working on their DE should have noticed and solved it.

And working on it for several years.
Comment 5 André Klapper 2013-03-23 11:28:26 UTC
betdomagoj: Change your tone and read https://live.gnome.org/CodeOfConduct , and read for your expectations I recommend the "No obligations" section of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Comment 6 betdomagoj 2013-03-23 18:15:03 UTC
(In reply to comment #5)
> betdomagoj: Change your tone and read https://live.gnome.org/CodeOfConduct ,
> and read for your expectations I recommend the "No obligations" section of
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

I sincerely apologise for my tone. I just got upset because I usually run a lot of apps and this became a bit of a problem for me.

I didn't mean anything bad and I hope you manage to solve the problem so as to make GNOME even better.

My only motiv is to better the gnome experience.

With sincere apologies and good wishes, Domagoj.
Comment 7 William Jon McCann 2013-03-25 16:33:41 UTC
My view is that we should not be using the dash for running applications. We should fix the number of favorites - perhaps based on the screen size.
Comment 8 betdomagoj 2013-03-25 19:35:41 UTC
Created attachment 239819 [details]
5 apps
Comment 9 betdomagoj 2013-03-25 19:36:01 UTC
Created attachment 239820 [details]
ext
Comment 10 betdomagoj 2013-03-25 19:36:29 UTC
Created attachment 239821 [details]
size
Comment 11 betdomagoj 2013-03-25 19:39:25 UTC
The problem is though, that when you have a bit more apps running it is sometimes hard to see in the overview just the app you want to use, especially when you have a smaller screen; the images/snapshots of apps become blurry, grainy and small so it's kind of slow to switch between them.

That's why it's sometimes easier to switch apps from the dash because you have clear, big icons that you instantly recognize.

To me this problem becomes evident when there are 5 apps open for example on my 1366*768 screen. Switching becomes slow in the overview because the pictures are all similarly sized, small, blurry and unclear so I have to sort of actually look for the windows that I want to use. Picture "5 apps" shows this.

This remides me of another thing - the snapshots are for my taste too similar in size; the ratio of their proportions should be more similar to how they relate on the desktop. I've provided an example with picture "size". On the desktop the chrome window is maximized and the contacts window is not, yet, when you go in the overview the contacts window seems bigger. That makes quickly recognizing apps visually hard.

That's in contrast with the dash where I actually just instantly recongize the app by its icon and click swiftly.

Extensions always do come in handy, so I use the "Window overlay icons" ext for example. Picture  ext I've provided shows this.

With best regards, Domagoj. :)
Comment 12 roman.yagodin 2013-04-27 20:22:38 UTC
So if dash is only about favorites, it would be right(?) to disable icons of running apps to address buggy shrinking. But, in other hand, not having icons of running apps in dash is limiting users to Alt+Tab and windows in the overview and completely missing taskbar-like functionality in dash (liked by most users). This is the first limiting idea.

The second limiting idea is about fixing the number of icons in dash. I think, no one could answer a simple question: which number of icons would satisfy 99,9% or at least 90% of users? So personally I vote for 6+1/2 icons in a dash :)

Setting and enforcing incomprehensible limits is not a way of achieving good user experience, IMHO. And the only thing that could pull of the question (at least partially) is more room for icons in the dash.

It could be done by scrolling (like in Unity), more columns in dash (e.g. one for favorites and one - for running apps), multiple dashes (left, right, top, bottom), or by something else - but it definitely must be done. More room for icons! No excuses.
Comment 13 Florian Müllner 2015-02-27 13:49:51 UTC
Marking as duplicate of bug 701387 which implements the behavior mentioned in comment #2 and comment #7.

*** This bug has been marked as a duplicate of bug 701387 ***