Closed Bug 988705 Opened 6 years ago Closed 5 years ago

[Messages] In an existing message, tapping Title in Header will pop up an action menu

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(tracking-b2g:backlog)

RESOLVED DUPLICATE of bug 1048717
tracking-b2g backlog

People

(Reporter: Omega, Unassigned)

References

Details

(Whiteboard: [priority], ux-most-wanted, 2x-uxnom)

Attachments

(1 file)

Attached image TapHeader.png
Repro Steps:
1) In Messages app, tap an existing message
2) Tap Contact Name on Header

Actual:
An action menu pops up (Call & View contact)

Expected:
No action menu when tapping title.
Just put Call & View in the top-right menu.

OS version: 1.3.0.0-prerelease
Platform version: 28.0a2
Build identifier: 20140128164615
Update channel hamachi/1.3.0/nightly
to backlog and add [top25]
blocking-b2g: 1.5? → backlog
Whiteboard: [Top25]
I actually think using the header for this is nice, as it's a bigger tap target than the option menu for something we do a lot.

I would agree to _add_ these options to the top right menu though.

We might want to redefine what actions we do for each icons too. Maybe the "view contact" item could be only in the settings menu. But I use a lot the header for calling, for example.

Also, take care that the specified action menu is different whether the sender is a known contact or is unknown.
Have you guys decided anything particular on that? This caught my eye as it's still marked as [Top25], so I consider it as important :)
Flags: needinfo?(felash)
Flags: needinfo?(ofeng)
Nothing new still comment 2 :)
Flags: needinfo?(felash)
oops wrong bug :)
(In reply to Julien Wajsberg [:julienw] from comment #4)
> Nothing new still comment 2 :)

Ok, thanks for update, let's wait for Omega's feedback :) Personally I'd also like to tap on contact name to perform an action, probably I just used to use it on my android device :)
Whiteboard: [Top25] → [Top25], ux-most-wanted
Blocks: 994991
Sorry for late response.
It makes in Android since it has that kind of design pattern: a title with a bottom-right triangle which indicates it's tappable and there are more actions. For sure it's more intuitive if we have that pattern in Building Blocks, but we don't have it now. I think it may be a long-term work to add a new pattern in Building Blocks. Anyway, ni? Building Blocks UX owner Harly for more inputs.
Flags: needinfo?(ofeng) → needinfo?(hhsu)
As a daily user I use this a lot; tapping on the contact header gives actions to react on the actual number or contact, while tapping on the menu gives actions to react on messages. This makes definitely sense in my opinion.
Currently there is no Building Blocks pattern on header with action on title. But I think in the case for message, it make sense to provide this feature to the user. I will propose a pattern to the framework team, will keep you all posted on any updates.
Flags: needinfo?(hhsu)
(In reply to Julien Wajsberg [:julienw] from comment #9)
> As a daily user I use this a lot; tapping on the contact header gives
> actions to react on the actual number or contact, while tapping on the menu
> gives actions to react on messages. This makes definitely sense in my
> opinion.

+1. FYI I'm another heavy user of this feature and I find it quite practical.
After discussion, since some users tend to find Call & View etc. actions in top-right menu and don't know tapping title behavior, we think we just add the Call & View etc. into the top-right menu, and still keep tapping title behavior, for 1.5.
Framework team are working on adding some visual hint on Header title to make them visually tappable, maybe for 2.1. When it's done, we can decide how to refine this again then.
Works for me, thanks Omega !
Whiteboard: [Top25], ux-most-wanted → [mentor=:julienw][lang=javascript][Top25], ux-most-wanted
To a contributor: the involved code is in thread_ui.js:
* the method used to thow the option menu when tapping the icon is "showOptions".
* the method used to show the option menu when tapping the header is in "prompt" (called from "onHeaderActivation", you'll see there are different paths whether it's a known contact or not)
having two methods to do the same activity is not really the best implementation. We need to have a decision on if the header can be used in such manner.

If currently we have no decision on the header option across the platform then we should leave this implementation as is and come back to this once a decision is made and we do a clean cut over to the new implementation.
(In reply to Wilfred Mathanaraj [:WDM] from comment #15)
> having two methods to do the same activity is not really the best
> implementation.

Why this? Different users have different habits and expectations, I think it's perfectly OK to have 2 ways to do the same thing.

For example, to send a SMS to a known contact, there are 3 ways:
* from the contact card, press the 'send sms" button
* from the messages app, type the first letters/phone number then press enter
* from the messages app, press the "+" button
we did reviewed and deciced that this is not good to have two different way just because we have not decided how to handle it at platform level. 

UX is working at platform level to define what is the best approach once a decision is made it makes sense to apply this to all apps in the OS.
Whiteboard: [mentor=:julienw][lang=javascript][Top25], ux-most-wanted → [mentor=:julienw][lang=javascript][priority], ux-most-wanted
Whiteboard: [mentor=:julienw][lang=javascript][priority], ux-most-wanted → [priority], ux-most-wanted
See also bug 1040874.
See Also: → 1040874
Whiteboard: [priority], ux-most-wanted → [priority], ux-most-wanted, 2x-uxnom
blocking-b2g: backlog → ---
2.2 moved the call action to a separated button. I couldn't find which bug has introduced the change. Closing as WORKSFORME. Feel free to find the duplicate, if you know it.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → DUPLICATE
Duplicate of bug: 1048717
You need to log in before you can comment on or make changes to this bug.