595441 - Use haptic feedback when clicking buttons in chrome and content

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I really like this feature on the Galaxy S.  This seems like a nice, quick way to provide more feedback when (successfully) clicking a link etc.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

We have access to haptic APIs, even on the N900, so we can add haptic feedback,
very sparingly, to the front-end widgets.

For now, we should look at adding haptic feedback when clicking buttons in the
UI and web content.

Not for clicking links.

Comment 3

[Michael Wu [:mwu]]

One thing to note is that on android, we have access to two kinds of haptic feedback api. One is for buttons, and the other controls the vibrator on the phone more directly and allows full control - http://developer.android.com/reference/android/os/Vibrator.html . I suspect we should prefer the basic haptic feedback for most things - button presses and such, so the user can control whether haptic feedback is wanted in general (Settings->Sound->Haptic Feedback). The more sophisticated haptic feedback should be something available to content for games and such.

Comment 4

[Madhava Enros [:madhava]]

There are a couple places in the browser where it would be interesting to provide some haptic feedback.

Are there differing degrees of vibration duration/intensity offered by the "standard" button api?

- chrome button-presses are probably the most straightforward decision; having a user be able to turn these off with the centralized "haptic feedback" switch (in Android "Settings") is a must.

- links? There's possibly some value here, as it's sometimes not clear, when your finger is on top of the visible part of the link, to know if you've actuated anything. If there are multiple degrees of feedback we can offer, I'd be tempted to use a lesser one here than for buttons, where we're trying to line up with an actual visual "push in" change.

- completion of long tap?  Could use the standard button-press vibration to indicated that the long tap has been actuated (would basically be concurrent with the context menu/action coming up). Again, I'd be tempted to use a lesser vibration than for buttons, if possible

- tab selection? feedback on tab switch, again, perhaps a lesser intensity than button pressing.  The tab close button might have the stronger feedback, as with other depressable buttons.

- feedback around sidebars; two models: 1. some (lesser intensity) feedback when the user drags past the edge, or 2. some (lesser intensity) feedback when the bar snaps into/out of place.

Comment 5

[Brian Dils [:briandils]]

I love the idea of haptic feedback on small devices. I think it makes a lot of sense in the mobile context. I do think we should be very careful on how we implement this though. There are so many different options, as Madhava shown. My worry is that once we introduce it for certain functionality, we can never take it back.

Does anyone mind if I start use cases from the UX side? 

------------------------------------------------------------------------

On a side note, there is a separate project I'm involved with where we are exploring haptic feedback for accessibility. This probably won't affect the normal user because there would be a accessible "mode" the user would have to instantiate. Just thought I should mention it though...

Comment 6

[Jeremias Bosch (:jbos)]

Is there any implementation of this done?

Comment 7

[Jeremias Bosch (:jbos)]

Also needed for MeeGo, added bug with patch for backend support

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

Clearing tracking as this is in Native.