Cards view needs better instructions on how to Close a running App



Firefox OS
5 years ago
5 years ago


(Reporter: GH to BZ, Assigned: kgrandon)



Firefox Tracking Flags



(Whiteboard: interaction, UX-P2, BerlinWW)


(3 attachments)



5 years ago
[GitHub issue by tonychung on 2012-08-01T17:50:55Z,]
In cards view, there's no intuitive menu that swiping the open application will kill the process.   can we add some kind of arrows or pointers to show this?    @patrykdesign, @jcarpenter , @caseyyee 

## Environment :
Otoro phone, build 2012-08-01
 gaia commit: 91588ac7f94b9c3a74cbccd30f106b1616d03df6
 Gecko commit: 8f5bbf2de08edd6df2e5d1871a5a2e8a58372151


## Repro :
1. open a few apps
2. launch cards view by holding the Home button down
3. Verify there's no UI or clear direction that swiping away the Application will close the process.  it's highly unintuitive to a unfamiliar user.

## Expected :
* Have some visual indication that swiping away the app will close the process.  

## Actual :
* No way to indicate how to close an app process by swiping out.

Comment 1

5 years ago
[GitHub comment by jcarpenter on 2012-08-01T19:43:27Z]
Agreed. Teaching this to users will be an important part of the first run experience. It's on our list :) 

I envision overlays that:

1. Teach the user how to get the Task Switcher.
2. Once in the Task Switcher, indicate how to close apps by swiping upwards. 

I am also not vehemently opposed to augmenting the swipe-to-delete functionality with a more obvious "close" button (eg: a red X button in top right). We'll have that option in our back pocket if the swipe-to-delete approach proves unworkable.

Comment 2

5 years ago
[GitHub comment by caseyyee on 2012-08-02T00:50:34Z]
As Josh mentioned, this is something that we are working on already.
I'd like to understand a little better why a user would have to manage system resources and under what circumstances:

1. Under what conditions do we expect the user to manage system resources?  % of memory remaining?   Number of open applications?

2. Can we give the user a warning if the device is running low on system resources?  

3. Under what conditions does the system automatically kill applications?  What are the UX implications of this?   What are the possible issues in doing this?  My key concern here is loosing user data.

@vingtetun @cgjones

Comment 3

5 years ago
[GitHub comment by cgjones on 2012-08-02T06:05:36Z]
What problem are we trying to solve here?  When free memory gets low, the kernel will kill background processes that are using the most memory.  The processes/apps get a notification when free memory is low, and they get a notification when they're put in the background.  The user should never have to manually manage memory.  Data loss is possible, but not really more so than just closing an app.

Comment 4

5 years ago
[GitHub comment by benfrancis on 2012-08-02T10:55:26Z]
Do we want users to be able to close apps themselves? If no then there's nothing to do here. But if yes (as seems to be the case) then we should make it obvious how to do it. The current cards view is completely lacking in affordances about how to do this.

I like the idea of adding the close buttons back, but another alternative might be visual hints similar to those we added to the lock screen. Personally I don't think we should rely too much on the first run experience for training users how to do things as it's often rushed because people are keen to get playing with their new toy!

Comment 5

5 years ago
[GitHub comment by tonychung on 2012-08-02T15:44:11Z]
this bug is tracking the visual pieces of card view, and giving a clearer set of instructions if users wanted to close the app themselves.   The screenshot shows there's no intuitive way a user would know to use swipe up/down to kill the app if desired.  

I was not trying to start a discussion in this bug about memory management or data loss.   Just visual cues to make the swipe-to-close functionality more visible.

Comment 6

5 years ago
[GitHub comment by jcarpenter on 2012-08-02T23:27:08Z]

For a subjective usability issue like this, where we're not going to know if we've resolved successfully until user testing, do we leave this open in interim? Or close as soon as our proposed solution is added, and re-open another bug to track again if user testing reveals need to revise?

Comment 7

5 years ago
[GitHub comment by tonychung on 2012-08-03T00:31:03Z]
@jcarpenter, np, this certainly can be a future discussion.  Please leave it open though.   I did not nom this as blocking-basecamp V1, but it certainly would be good to have some visual clarification to this feature.  I've already seen more than one user here, not know we could swipe to close until i showed them.

Comment 8

5 years ago
[GitHub comment by benfrancis on 2012-08-13T11:58:08Z]
@jcarpenter Completely agree that user testing is the best way to test this, but is that likely to happen before launch? Were the visual cues added to the lock screen as a result of user testing or just dogfooding like this issue?

Comment 9

5 years ago
[GitHub comment by jcarpenter on 2012-08-15T02:21:51Z]
> Completely agree that user testing is the best way to test this, but is that likely to happen before launch?

You're quite right that we may not have much time for user testing feedback. In this instance I'm fairly comfortable deferring final decision because it will be a relatively easy feature to add late in process, if needed (just confirmed that with Vivien, who is strolling about the SF office in a leisurely manner ;)

> Were the visual cues added to the lock screen as a result of user testing or just dogfooding like this issue?

In that case it was always our intent to add the cues.


5 years ago
Component: Gaia → Gaia::System
I would like to nominate this bug since it appears that some people does not know/understand how to close an application using the Cards View. I have heard about someone that tried to opened an hosted application but it was redirected to a wifi page since it was a captive portal. Then he left and the next time he try to open the application the captive portal login was still here and he didn't know how to escape.

The gesture is not intuitive and having an explicit close button would help a lot here.

I can imagine a very simple red close button living on the center top of each screenshots.
blocking-basecamp: --- → ?
blocking-basecamp: ? → -
Created attachment 700920 [details]
Screenshot of new close button design

Agreed. Patryk has put together the attached screenshot, which we should try to add for 1.0. Patryk, can you attach the asset?
Flags: needinfo?(padamczyk)
Whiteboard: [label:needsUXinput][label:system/card_view] → interaction, UX-P2, BerlinWW
Created attachment 700957 [details]
Close Icon
Flags: needinfo?(padamczyk)


5 years ago
Assignee: nobody → kgrandon

Comment 13

5 years ago
Created attachment 701057 [details]
Github pull request pointer
Attachment #701057 - Flags: review?(timdream+bugs)
Attachment #701057 - Flags: review?(timdream+bugs) → review+

Comment 14

5 years ago
Comment on attachment 701057 [details]
Github pull request pointer

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): missing feature
User impact if declined: Users will be confused about how to close apps.
Testing completed: Manual testing of card switcher. Ensures existing behaviors work.
Risk to taking this patch (and alternatives if risky): Would only impact card switcher.
Attachment #701057 - Flags: approval-gaia-master?(21)
Comment on attachment 701057 [details]
Github pull request pointer

Sounds a very nice improvement.
Attachment #701057 - Flags: approval-gaia-master?(21) → approval-gaia-master+
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.