797788 - Deleting accounts should be responsive

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Calendar, defect, P3)

Description

[James Lal [:lightsofapollo]]

When deleting account the ui does not appear to block. So the user can click the confirm button many times. This is most noticeable with a large calendar

Comment 1

[James Lal [:lightsofapollo]]

... where the user can repeatedly click the button while deleting.
We should completely block user input (and make it clear why they are waiting) when deleting accounts.

Comment 2

[Jason Smith [:jsmith]]

Putting into the nom queue as the user experience here is awkward and confusing (just tested this with two of my family members). Both of them appeared to be confused due to a lack of progress and confirmation. So I'm arguing to block for the same reasons why we decided to block on bug 810153.

Comment 3

[Jason Smith [:jsmith]]

No rationale provided. Renominating.

Comment 4

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #3)
> No rationale provided. Renominating.

I should note that we technically did block on bug 810153. And it's easy to reproduce this bug too with a typical calendar you import.

Comment 5

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Gaia Triage : -, is there a reason why this should block shipping?  Is there any ill effects mentioned here in terms of functionality?  If hitting delete, multiple times is the worst of the effect and it does delete the account, then isn't it working correctly?  Would you stop shipping for this bug?  Nothing in this bug states anything of the sort that we can tell in triage.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Naoki Hirata :nhirata from comment #5)
> Gaia Triage : -, is there a reason why this should block shipping?  

UX concluded that a user's sense of progress is a "must have" for v1 for the target market. The probability of hitting this pretty much happens on every deletion of a calendar that's imported for common calendar sizes (in other words, not just 2 events).

> Is there any ill effects mentioned here in terms of functionality? 

Not relevant to the argument. Quality analysis does more than just looking at functionality - you need to look at the other parts to. UX severity is ALWAYS a critical factor to analyze. It's too common of a scenario and was caught during some off the cuff usability testing.

> If hitting delete, multiple times is the worst of the effect and it does >delete the account, then isn't it working correctly?  

That's irrelevant to this argument. You are looking at this from the wrong perspective - functionality only. If give a user a poor UX, then they won't use the product effectively.

> Would you stop shipping for this bug?  Nothing in this bug states anything of > the sort that we can tell in triage.

Disagree strongly. Looks like this was triaged incorrectly, given that the argument fails to provide a UX perspective given past trends where we effectively concluded progress was a "must have" for v1 in the target market. Back into triage it goes for ineffective analysis.

Comment 7

[Jason Smith [:jsmith]]

Adding Josh for his perspective on this.

Comment 8

[Josh Carpenter [:jcarpenter]]

Thanks Jason, well stated. I agree that this is problematic, for exactly the reasons you've outlined. By failing to provide any perceivable response to the user's input we frustate them and undermine their trust in the entire product. Yes this does eventually work, but in the mean time we've annoyed our user. A credible product needs to take UX quality more seriously than just "it eventually works". 

I've marked this a UX-P2. We should fix this for release. 

My recommendation: once the user has tapped delete perhaps we add an interstitial spinner animation to the screen and blocking the inputs from being pressed further. I defer to Casey on the best approach (UX owner of Calendar), and have added him for needsinfo.

Also cc'ding James Lal for feasibility estimate. I note the current LOE is "S".

Comment 9

[David Scravaglieri [:scravag]]

I agree it's a kind of frustration to delete an account whiteout beeing prompted, but we will not block on it for V1.

Comment 10

[James Lal [:lightsofapollo]]

David (#9) there is a prompt before deleting the account. The issue is when you confirm you basically get "stuck" at the prompt until the user completes this.

There are two good options:

1. Block (simplest) until delete is done. IIRC we already apply a CSS class to the view when deleting so we could show a layer over the view with a spinner to prevent user interaction with very (<1 day) effort.

2. Since we have the capability of "hiding" an account's events on demand we can "instantly" hide all of the events and let the user go on their way without blocking while also giving the impression of deleting the account. This is not terribly difficult either (but more work then 1) and is the best UX option.
The only risk here is if the transaction fails (which is unlikely but possible).

Comment 11

[Casey Yee]

I'd say for simplicity the lower effort and the very short time remaining to go with option 1.  It's quite rare for the user to need to delete accounts often so the blocking won't be much of an issue.  It also gives us options for handling the transaction fail case.

Comment 13

[James Lal [:lightsofapollo]]

My implementation here is option #2 in comment #10

Comment 14

[James Lal [:lightsofapollo]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10256

Pointer to Github pull-request

Comment 15

[Kevin Grandon :kgrandon]

This looks good, but am hesitant on R+ due to the extraneous commit. Remove that and we should be good to land!

Comment 16

[Kevin Grandon :kgrandon]

In master: https://github.com/mozilla-b2g/gaia/commit/a7cc7c46f073d9ef3893307da9e27f51fdf0e4fc

Comment 17

[Jason Smith [:jsmith]]

This is probably worthwhile to uplift, but I think we just passed the date to allow for uplifts.