Closed
Bug 925318
Opened 11 years ago
Closed 11 years ago
Remove first time explanation on how to close the keyboard
Categories
(Firefox OS Graveyard :: Gaia::Keyboard, defect)
Firefox OS Graveyard
Gaia::Keyboard
Tracking
(blocking-b2g:koi+, b2g-v1.2 fixed)
People
(Reporter: rik, Assigned: rik)
References
Details
Attachments
(1 file)
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 2•11 years ago
|
||
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.
Flags: needinfo?(firefoxos-ux-bugzilla)
Updated•11 years ago
|
Blocks: 1.3-keyboard
Assignee | ||
Comment 3•11 years ago
|
||
Actually, I'd like to disable this in 1.2.
blocking-b2g: --- → koi?
Comment 4•11 years ago
|
||
(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?
Flags: needinfo?(firefoxos-ux-bugzilla)
Comment 5•11 years ago
|
||
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?
Flags: needinfo?(firefoxos-ux-bugzilla)
Comment 6•11 years ago
|
||
blocking-b2g: koi? → 1.3?
Comment 7•11 years ago
|
||
I think the annoyance is mainly for us because we |make clean| quite often.
Assignee | ||
Comment 8•11 years ago
|
||
(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.
blocking-b2g: 1.3? → koi?
Updated•11 years ago
|
Flags: needinfo?(firefoxos-ux-bugzilla)
Comment 9•11 years ago
|
||
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.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(cawang)
Comment 10•11 years ago
|
||
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!
Flags: needinfo?(cawang)
Comment 11•11 years ago
|
||
Based on UX feedback, moving to v1.3 and aim for quality improvement.
blocking-b2g: koi? → 1.3?
Assignee | ||
Comment 12•11 years ago
|
||
(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?
Assignee | ||
Comment 13•11 years ago
|
||
Here is the safest patch ever to disable this. It's just flipping a setting.
Attachment #823925 -
Flags: review?(rlu)
Comment 14•11 years ago
|
||
Comment on attachment 823925 [details]
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.
Attachment #823925 -
Flags: feedback?(cawang)
Comment 15•11 years ago
|
||
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•11 years ago
|
||
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.
blocking-b2g: 1.3? → 1.3+
Comment 17•11 years ago
|
||
It's strange to me that Bug 905241 got koi+'ed, maybe we should move the discussion to that bug.
Comment 18•11 years ago
|
||
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]
> 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•11 years ago
|
||
Comment on attachment 823925 [details]
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.
Attachment #823925 -
Flags: review?(rlu)
Attachment #823925 -
Flags: review+
Attachment #823925 -
Flags: feedback?(cawang)
Comment 20•11 years ago
|
||
This is actually already tracked as a koi+ blocker in bug 905241.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Comment 21•11 years ago
|
||
Actually wait - I'm wrong here, disregard.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 22•11 years ago
|
||
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.
blocking-b2g: 1.3+ → koi?
Comment 23•11 years ago
|
||
(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•11 years ago
|
||
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?
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Comment 25•11 years ago
|
||
(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•11 years ago
|
||
Sounds like this already landed per https://bugzilla.mozilla.org/show_bug.cgi?id=905241#c22.
blocking-b2g: koi? → koi+
status-b2g-v1.2:
--- → fixed
Comment 27•11 years ago
|
||
Triaged agreed to block on this and pref off the feature.
Comment 28•11 years ago
|
||
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
Updated•11 years ago
|
Assignee: nobody → anthony
Comment 29•11 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•