UIFe: Launcher - update launcher reveal interaction to make it more accessible to first time users

Reported by John Lea on 2011-04-08
64
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Critical
John Lea
Unity
Medium
Unassigned
unity-2d
High
Unassigned
gnome-control-center (Ubuntu)
Undecided
Unassigned
unity-2d (Ubuntu)
Undecided
Unassigned
unity (Ubuntu)
Undecided
Unassigned

Bug Description

Update the Launcher reveal interaction to make it more intuitive to new users.

This update involves a number of changes. These individual setting tweaks and changes are all tracked in a single bug because they all need to land to deliver a coherent UX (we can't pick and choose to do some of the items listed here and not others).

--------------------------------------------------------
SYSTEM SETTINGS

- Introduce a applet to the Gnome Control Center called 'Unity Launcher'

- This applet includes a single control that allows the user to select between "Show Launcher with mouse [ On left of screen | In top left corner ]

- 'On left of screen' becomes the default option

---------------------------------------------------------
'LEFT OF SCREEN' REVEAL

- When a user pushes the cursor *past* the edge of the screen the Launcher is revealed. To make this interaction insensitive and minimise false positives, the user must apply sustained pressure against the edge of the screen for a set length of time in order to reveal the launcher. Brushing on the side of the screen, or placing the cursor against the side of the screen should not reveal the Launcher.

- The 'top left' Launcher reveal stays (it does not conflict with the 'left of screen' Launcher reveal and is a complementary interaction).

- When the Launcher is hidden and a App issues an alert, the App icon should pop out and wobble from it's position in the Launcher. With the 'left of screen' Launcher reveal enabled, when the user moves their cursor to the position where the App icon pop'ed out, the Launcher will reveal giving the user direct access to the app.

(Note: this interaction was previously removed because it didn't work with the 'top left' reveal. When the user went back to where the icon had popped out of the Launcher, the Launcher didn't slide out leaving the user confused. With the change to the 'left of screen' Launcher reveal this app alert interaction can return. )

- When a application alert is outstanding, a blue triangle appears in the top left of the screen. The BFB no longer changes color. See attached design.

----------------------------------------------------------------
'ONLY TOP LEFT CORNER' REVEAL

If the user changes the Launcher reveal setting to 'only top left corner' in appearance properties, the following changes happen:

- 'left of screen' Launcher reveal is disabled.

- The alert 'app icon pop out' behavior is disabled.

John Lea (johnlea) wrote :
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
importance: Undecided → Critical
status: New → Fix Committed
Neil J. Patel (njpatel) on 2011-04-08
Changed in unity:
milestone: none → 3.8.6
status: New → Triaged
John Lea (johnlea) on 2011-04-08
description: updated
description: updated
Didier Roche (didrocks) on 2011-04-08
Changed in gnome-control-center (Ubuntu):
status: New → Triaged
Changed in unity (Ubuntu):
status: New → Triaged
John Lea (johnlea) on 2011-04-08
Changed in ayatana-design:
status: Fix Committed → Fix Released

Is there code available for review?

Changed in unity (Ubuntu):
status: Triaged → Incomplete

The launcher is already revealed with an empty desktop, or when windows don't cover the launcher area, so people should know that it's there already? FWIW, I don't consider this important enough to change the general behaviour at this late point, but I don't veto it as long as it really doesn't trigger unexpectedly (bugs like bug 754690 are really quite unexpected and annoying). What is the timeout you had in mind?

NACK from my side about changing gnome-appearance-properties:
 * It's a very intrusive patch to maintain (due to changing the GtkBuilder file), and won't port well/at all to GNOME 3 next cycle.
 * It introduces several new strings which need to be translated (we'll only get poor coverage in the remaining two weeks)
 * It introduces new variables and options which make it once again harder to test.
 * I question the value of providing the option in the first place: If this launcher activation gets too much in the way, the screen side reveal should be disabled or be made more resistant. If it's not getting in the way, we shouldn't have the option.
 * We don't provide options for other Unity behaviour which are _far_ more important, such as reenabling the system tray, or making the Launcher appear when you move the mouse anywhere in the left panel area with the Ubuntu icon. Especially the latter behaviour is so confusing, perhaps this would be a better thing to address first?

Changed in gnome-control-center (Ubuntu):
status: Triaged → Won't Fix
summary: - Launcher - update launcher reveal interaction to make it more accessible
- to first time users
+ UIFe: Launcher - update launcher reveal interaction to make it more
+ accessible to first time users
Conscious User (conscioususer) wrote :

In my opinion, using only this pressure policy will introduce a constant unwanted delay. I suggest adding to that a momentum-based approach that recognizes whether the mouse was placed or thrown by analysing its speed and acceleration.

I'm aware that this does not cover the case where the mouse is already close to the side, as the momentum will be low regardless of what the user does. That's why I'm suggesting using this in *addition* to the pressure policy instead of replacing it.

We are doing user testing of the existing code, and this is one of the
key issues. So we are getting this bug discussed and some code written
in anticipation of a final report on that testing.

The challenge is that prior testing showed worse problems in the long
term with edge activation. I am reluctant to make this change so late,
especially since we don't actually have the opportunity to do long term
testing on the edge option either. I thought we could work up the
change, test it, and drop it in later BUT seb correctly points out we
have translation issues etc.

We know that long term muscle memory for corner activation is just as
good as the edge approach.

I think we can move forward based on previous testing, and address this
in Oneiric if needed.

Mark

manny (estelar57) wrote :

For the: "The 'TOP left' Launcher reveal"

I've found that the way its done in unity2d (current version as of date; natty) feels easier than on unity 3d/compiz.

The goal of the launcher is to switch between opened or pinned apps easier and quicker, so IMHO unity 2d has the lead here.

as for "'LEFT OF SCREEN' reveal", this could open some possibilities.

@John Lea,
apart from the mockup of the "blue triangle at the top" and with the new launcher default behavior of being invoked from the sides, shouldn't the app icons also pop out for attention for a second or two like they used to?

That seemed to had worked well IMO, and probably more so with this new reveal behavior.

example:
User sees Icon pop and knows immediately which app is it. If interested, then places mouse on the side to reveal the launcher.

The blue triangle at the top alone doesn't really give much info from multiple apps that may require attention.

Another problem i noticed is that once launcher is invoked, Is pretty hard to notice which app is the one requesting attention because those little blue indicator arrows are too subtle. I believe the entire icon should glow.

John Lea (johnlea) on 2011-04-08
description: updated
Jeremy Bicha (jbicha) wrote :

John I don't think that little blue triangle will be noticed by most users. In fact it may even be less visible than the current aqua BFB indicator thing.

John T. Folden (john-t-folden) wrote :

I think 'LEFT OF SCREEN' REVEAL is a boost to efficiency and will greatly improve the desktop experience. If a user wants to open an app via the launcher, they can aim directly for where that icon will be when the launcher slides into view.

As it is now, a user must move the cursor to the top left of the screen and then down to the desired icon. This requires unnecessary mouse travel, particularly when the icon they're aiming for could be at the other end of the screen.

Allowing app icons to 'pop out' when attention is needed is, also, a big improvement over change of color in the BFB (given that provides absolutely NO clue to which app needs the attention).

John T. Folden [2011-04-09 0:23 -0000]:
> I think 'LEFT OF SCREEN' REVEAL is a boost to efficiency

Not really, as there will inevitably be a necessary delay until it
opens, otherwise it'll get too much in the way.

> As it is now, a user must move the cursor to the top left of the screen

... Windows key! Windows key! :-)

John T. Folden (john-t-folden) wrote :

Matt, throwing the mouse at the left edge, even with any necessary-but-short delay is still less time/work for the user than the currently inefficient method.

Also, having to resort to the keyboard to overcome this issue is not a valid workaround, imo. A user should not have to resort to bandaids in their workflow.

Neil J. Patel (njpatel) on 2011-04-11
Changed in unity:
importance: Undecided → Medium
status: Triaged → Fix Committed
Didier Roche (didrocks) on 2011-04-11
Changed in unity:
status: Fix Committed → Fix Released
Didier Roche (didrocks) on 2011-04-11
Changed in unity (Ubuntu):
status: Incomplete → Fix Released
Conscious User (conscioususer) wrote :

@Mark:

"We know that long term muscle memory for corner activation is just as good as the edge approach."

You seem to be forgetting that accessing an icon launcher is a two-phase approach:

1 - revealing the launcher

2 - going to the icon

Your assumption above is valid for (1) but not for (2), because (2) does not benefit from Fitt's law and thus distance matters. Imagine a user with a large monitor wanting to access the Trash.

On 11/04/11 15:43, Conscious User wrote:
> Your assumption above is valid for (1) but not for (2), because (2) does
> not benefit from Fitt's law and thus distance matters. Imagine a user
> with a large monitor wanting to access the Trash.

Trash is very easy, in fact, since *both* targets are effectively
infinite in size. By design ;-)

More difficult is an icon somewhere along the length of the launcher.
But the muscle memory then is for the motion from the top left corner to
the icon in question, which is always consistent.

Mark

Mark Shuttleworth (sabdfl) wrote :

So, the official position now is we have the left-edge invocation for
testing. We are looking for false positives and other problems. We will
decide the default behaviour in due course, but we will retain the UI
for the option for Natty either way.

Mark

Conscious User (conscioususer) wrote :

@Mark

Okay, allow me to rephrase: your assumption is valid for *muscle memory* but not for *efficiency*. Trash does benefit from infinite size, but that does not change the fact that the corner approach requires two movements instead of just one.

Not to mention that hovering through all the icons to reach the one you want will activate all the tooltips in the way, which is quite distracting.

Jason Warner (jasoncwarner) wrote :

I'm loving this feature. I think it adds quite a bit and makes the launcher just that much more discoverable for newbies.

Two small suggestions:

1. The wording in the options dialog might read better as:

Show the launcher when the pointer:
[ ] Pushes left edge or top left corner of the screen
[ ] Touches top left corner of the screen only

and

2. I'm assuming there is a timeout on the left-edge behavior. Initial launcher show feels a tad sluggish. Perhaps lowering timeout threshold.

Didier Roche (didrocks) wrote :

Hey Jason,

Just a small note on the impact on 1.:
We sent yesterday the .pot tempate file and processed the string freeze break so that the translator can have some time to translate. So we need to keep that in mind if we are going to rephrase (we already changed a lot of strings after the freeze and I hope we are going to have a fully translated Unity in all major language).

Martin Pitt (pitti) wrote :

Could we please make the new dialog halfway HIG friendly, and add a close button?

manny (estelar57) wrote :

the new behavior is an improvement, but i already found a problem with the flow.

the problem is with the folding and unfolding of icons.

when an App icon Pops-out and wobbles, you move your mouse to that area, but if its Folded, ALL the icons Unfold (taking space) and the icon you want moves from its position and gets dragged down...

This is serious usability because most of the time the icon you want moves away or disappears from view and you will need to scroll to find it, specially on smaller monitors and netbooks (or depending on number of items on launcher at the moment or launcher size).

I've already submitted a while ago a bug report on this behavior, but it hasnt been really looked at yet.

https://bugs.launchpad.net/unity/+bug/734946

Matthew Paul Thomas (mpt) wrote :

Jason, the top left corner is part of the left edge. That's why I didn't mention it separately.

Martin, the window already has a close button. The Gnome 3 "System Settings" panes, of which this would eventually become one, don't have redundant "Close" buttons either.

Changed in unity-2d:
status: New → Confirmed
importance: Undecided → Medium
tags: added: delta-with-3d

Just a comment: I'm getting a high number of accidental reveals when reaching for my browser's back button on a trackpad.

Paul Sladen (sladen) wrote :

Jacob: yeah, I've noticed this too and just highlighted it specifically in bug #763275 ("Launcher: auto-hide gets stuck open if point arrives to left-edge via top-left pixel").

Although we might want to create a design task about to minimise the false positives from the Launcher appearing when all the user wanted to do was hit the browser Back button.

John Lea (johnlea) on 2011-04-19
tags: added: reviewedbydesign
removed: udt
manny (estelar57) wrote :

"I'm getting a high number of accidental reveals when reaching for my browser's back button on a trackpad."

@Jacob

am seeing this too.

Also i keep forgetting that the launcher is there hidden, so i often leave my mouse at the left border...

and i think a lot of new users will not even know where the launcher went...

possible solution:
We need some visual reminder that the launcher is there in order to minimize the false positives. The launcher could visually stick out 4 or 5 pixels.

Other than a reminder, also serves as a "visual limiter" to indicate that you should not cross that area unless you want it revealed. It should also create enough extra space to avoid accidental move of the trackpad to that area when all the user wants to hit is the browser back button.

manny (estelar57) wrote :

oh and about the blue triangle alert.

If the "visual limiter/border" is implemented (as mentioned on my last post), this blue glow alert can be moved to the limiter/border itself (or just the areas where attention is needed).

this would work better for the current default reveal behavior.

manny (estelar57) wrote :

here is a quick mockup i placed together with what am referring to.

notice:

-the browser back button is now further away from the screen edge

-the alerts now stay visible where they originated. Specially Useful when you have more than 1 alert. Less confusion.

-placing pointer on the visual limit/border will not reveal the launcher, will only happen when mouse reaches the screen edge and stays there for a few seconds. Less prone to false positives.

Am not very good at mockups, so hope it makes sense. Thanks.

John T. Folden (john-t-folden) wrote :

Perhaps a better solution would be to disable the "trigger" on the first 50pixels (or whatever) of the left edge when a window is maximized. This way the launcher would never be triggered when a user was actually aiming for the left most toolbar button in a maximized window.

I don't believe we need a visual indicator when the launcher is hidden, that seems to defeat the purpose and adds ugly screen clutter.

As far as alerts go, I seem to recall there was discussion that the icon of the app needing attention would "pop out" from the left edge when the launcher was hidden.

manny (estelar57) wrote :

@John T. Folden

-50px: hm, the 50px might solve the problem for some, but will create confusion for others, who will be clueless as to why the launcher is not revealing. And to launch the first icon, you would need to point your mouse somewhere else. Some might even think something is wrong with their system or that this is a bug. The idea is creative (out of the box), but it still has those flaws.

-visual indication: for those that dont need the indication, they could disable it or set the pixels to 0, maybe add more pixels if they want to. 100% would be equal to launcher "always visible". Anyway 4 or 5px on a transparent launcher is barely noticeable, unless there is an alert (which is what we want people to notice the most).

-Alerts: they do pop out for a split second. That is and looks good. But the blue triangle at the top makes people target their mouse to that area instead of where the alert was originated, so they get 2 alerts in 2 different places for 1 app, thanks to the blue triangle...

for top left reveal behavior is ok, but for the "left edge reveal" it can be confusing.

Anyway, this is design in process, unity has still a way to go, so any idea is welcome to be discussed.

Changed in unity-2d:
importance: Medium → High
Didier Roche (didrocks) on 2011-05-31
Changed in unity-2d (Ubuntu):
status: New → Confirmed
Changed in unity-2d:
milestone: none → 3.8.8
status: Confirmed → Fix Committed
Changed in unity-2d (Ubuntu):
status: Confirmed → Fix Committed
Didier Roche (didrocks) on 2011-06-14
Changed in unity-2d:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity-2d - 3.8.8-0ubuntu1

---------------
unity-2d (3.8.8-0ubuntu1) oneiric; urgency=low

  [ Didier Roche ]
  * new upstream release:
    - [spread] Corruption when switching workspaces after windows have been
      moved to other workspaces (LP: #760787)
    - [launcher] launcher won't fully paint, corrupted view (LP: #764690)
    - [launcher] icons no longer active after an incomplete drag (LP: #768812)
    - drag from dash to launcher (LP: #662616)
    - Don't create windows over the launcher (LP: #688816)
    - [launcher] Does not reveal when hovering over the left edge of the
      screen (LP: #760537)
    - UIFe: Launcher - update launcher reveal interaction to make it more
      accessible to first time users (LP: #754583)
    - [launcher] Trash icon should indicate when it has deleted elements
      (LP: #715611)
    - When windows open for the first time they should not hide the launcher
      (LP: #723878)
    - double clicks should be disabled on bfb/Place launcher icon/double key
      press (LP: #766776)
    - [dash][launcher] Should use real transparency when a compositing manager
      is running (LP: #794042)
    - [dash] Thunderbird icon is pixelated (LP: #767115)
    - [panel] Hovering the mouse cursor over the BFB reveals the current
      window’s menu (LP: #793403)
    - [panel] Hovering the mouse cursor away from the appmenu applet doesn’t
      hide the menu (LP: #793406)
    - unity-2d: does not parse QT_GRAPHICSSYSTEM env var (LP: #791852)
    - Cannot drag applications from dash to desktop (LP: #756614)
  * debian/control:
    - unity-2d-panel recommends the indicator, not unity-2d
    - appmenu-gtk and appmenu-qt are already provided by indicator-appmenu
    - remove other meaningless recommends
  * debian/libunity-2d-private0.install:
    - install everything in Unity2d private directory

  [ Florian Boucault ]
  * debian/unity-2d-launcher.install:
    - do not install usr/lib/qt4/imports/UnityApplications/ anylonger as all of
      UnityApplications features have been moved to the Unity2d QML plugin
      installed by libunity-2d-private0
  * debian/control:
    - unity-2d-places and unity-2d-spread do not depend on unity-2d-launcher.
      All they need is now in libunity-2d-private0.
 -- Didier Roche <email address hidden> Tue, 14 Jun 2011 16:14:18 +0200

Changed in unity-2d (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers