925318 - Remove first time explanation on how to close the keyboard

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

Description

[Anthony Ricaud (:rik)]

Every since this was implemented, I am crying and hitting walls every time I see this image. I think it is a bad idea because:
- It's interrupting me in my task.
- I tried to do what the image suggests and it doesn't work. If I swipe on the keyboard, I'm just typing the last letter my finger touched.

Comment 1

[Anthony Ricaud (:rik)]

UX: Please see comment 0

Comment 2

[Stephany Wilkes]

Removing the ni? to UX for this as there is a lot of keyboard work in 1.3 and 1.4, and Carrie's design for the 1.3 keyboard changes addresses this case. I'll attach it to the meta-bug for 1.3.

Comment 3

[Anthony Ricaud (:rik)]

Actually, I'd like to disable this in 1.2.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Anthony Ricaud (:rik) from comment #3)
> Actually, I'd like to disable this in 1.2.

What's UX opinion on this?

Comment 5

[Stephany Wilkes]

As a release, 1.2 is very far along already, and the criteria for making that release are already strict. Is there a strong reason that this could not wait until 1.3 and ship along with the rest of the planned keyboard improvements?

Comment 6

[Preeti Raghunath(:Preeti)]

Moving to 1.3? based on comment 3 and comment 5

Comment 7

[Jan Jongboom [:janjongboom] (inactive)]

I think the annoyance is mainly for us because we |make clean| quite often.

Comment 8

[Anthony Ricaud (:rik)]

(In reply to Stephany Wilkes from comment #5)
> As a release, 1.2 is very far along already, and the criteria for making
> that release are already strict. Is there a strong reason that this could
> not wait until 1.3 and ship along with the rest of the planned keyboard
> improvements?
This is a feature introduced in v1.2 that's why I want to disable in v1.2. I don't think our new users should see this in the first seconds of interacting with our phones.

Comment 9

[Stephany Wilkes]

UX has previously commented in comment #5. We would not block koi on backing this out, as this is not (comparatively) an urgent change for a late-in-the-game release. I'm flagging Carrie, who is working on many keyboard designs for 1.3, to advise on the future of this feature, but this is still not a blocking issue as far as UX is concerned. We can take it up in triage if folks feel strongly otherwise.

Comment 10

[Carrie Wang [New account: [e-mail]]]

Hi everyone, for this feature, we think it's all about the performance issue.
We'll refine it with eng on v1.3/ 1.4 (speed and distance of the swipe) to make it usable and useful.
Meanwhile, we'll provide some other ways for users to close the keyboard whenever they want. Thanks!

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Based on UX feedback, moving to v1.3 and aim for quality improvement.

Comment 12

[Anthony Ricaud (:rik)]

(In reply to cawang from comment #10)
> Hi everyone, for this feature, we think it's all about the performance issue.
What performance issue?
> We'll refine it with eng on v1.3/ 1.4 (speed and distance of the swipe) to
> make it usable and useful.
So if it's not usable, can we disable the instruction screen?

Comment 13

[Anthony Ricaud (:rik)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/13171

Here is the safest patch ever to disable this. It's just flipping a setting.

Comment 14

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 823925 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/13171

Before the UX can confirm how we could improve the design here, I tend to keep the implementation as is.

Is there any strong reason that we should disable the tutorial screen for swipe down gesture while keeping the gesture there?
Carrie, do you think this is what we want?

Thanks.

Comment 15

[Stephany Wilkes]

There is not a strong reason to disable the tutorial screen for 1.2 so late in the 1.2 release. The blocking criteria are higher, not lower.

Comment 16

[Bruce Huang [:bhuang] (inactive)]

Plus'ing for now for possible keyboard improvements that we can pick up.  Assuming the decision here is enable/disable as opposed to a whole new feature.

Comment 17

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

It's strange to me that Bug 905241 got koi+'ed, maybe we should move the discussion to that bug.

Comment 18

[Carrie Wang [New account: [e-mail]]]

We've have some further discussion on this bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=905241

Thanks!

(In reply to Rudy Lu [:rudyl] from comment #14)
> Comment on attachment 823925 [details] [review]
> https://github.com/mozilla-b2g/gaia/pull/13171
> 
> Before the UX can confirm how we could improve the design here, I tend to
> keep the implementation as is.
> 
> Is there any strong reason that we should disable the tutorial screen for
> swipe down gesture while keeping the gesture there?
> Carrie, do you think this is what we want?
> 
> Thanks.

Comment 19

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 823925 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/13171

r=me with UX agree to remove this - bug905241#c18.

Rik,

Could you help update the commit message to include Bug bug905241 as well for better tracking.
Thanks.

Comment 20

[Jason Smith [:jsmith]]

This is actually already tracked as a koi+ blocker in bug 905241.

Comment 21

[Jason Smith [:jsmith]]

Actually wait - I'm wrong here, disregard.

Comment 22

[Jason Smith [:jsmith]]

I'm disagreeing with the UX argument here - if you haven't implemented an implementation correctly for something you built in 1.2, disabling it is a requirement. We should not simply quality in a release for something that was added that regresses the UX. I'm renoming for the same reasons why bug 905241 is a blocker.

Comment 23

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #22)
> I'm disagreeing with the UX argument here - if you haven't implemented an
> implementation correctly for something you built in 1.2, disabling it is a
> requirement. We should not simply quality in a release for something that
> was added that regresses the UX. I'm renoming for the same reasons why bug
> 905241 is a blocker.

slip quality in a release*

Comment 24

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Patch landed to remove the keyboard tutorial screen,
https://github.com/mozilla-b2g/gaia/commit/1e212079cca612f9a91bd79ad6042f90748ce9d7

--
Jason, thanks for your input, we have landed the patch to remove the keyboard tutorial screen.
Does that make sense to you?

Comment 25

[Jason Smith [:jsmith]]

(In reply to Rudy Lu [:rudyl] from comment #24)
> Patch landed to remove the keyboard tutorial screen,
> https://github.com/mozilla-b2g/gaia/commit/
> 1e212079cca612f9a91bd79ad6042f90748ce9d7
> 
> --
> Jason, thanks for your input, we have landed the patch to remove the
> keyboard tutorial screen.
> Does that make sense to you?

Yup, that makes sense to me. I'm going to discuss this in triage on Tuesday - this should have been a koi+ from the beginning, as it's preffing off a broken feature on 1.2 that was built on 1.2.

Comment 26

[Jason Smith [:jsmith]]

Sounds like this already landed per https://bugzilla.mozilla.org/show_bug.cgi?id=905241#c22.

Comment 27

[bhavana bajaj [:bajaj]]

Triaged agreed to block on this and pref off the feature.

Comment 28

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Not sure why, but this patch was never uplifted to v1.2 branch but this bug has been set as status-b2g-v1.2:fixed.

--
Gaia v1.2,
https://github.com/mozilla-b2g/gaia/commit/92cd11ea023dd6598d82d859ae3c945ff6589ce6

Comment 29

[Ben Bucksch (:BenB)]

The swipe feature must be discoverable, or it's practically non-existent. I agree we should not interrupt the user, but if the swipe is supposed to be the solution for closing the keyboard, then the user must know about it.
Compare rationale for bug 943692.