905169 - [Messages][Multirecipient] Change the specified slide behaviors for the recipients panel

Status: RESOLVED WONTFIX

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

Description

[Julien Wajsberg [:julienw]]

In Bug 884890 we were discussing how some currently specified behaviors for the recipients panel are not ideal.

Below are the discussions:

Julien's proposition:

STR 1:
* slide down the panel
* tap inside it to add a new recipient
=> it's slid up, whereas I think it should stay slid down in that case.

STR 2:
* tap inside the panel
* slide down the panel
* type something
=> it's slid up, whereas I think it should stay slid down in that case too.


Ayman's thoughts:

ok, i was thinking this over lastnight. We should do this as it is an improvement to the UX but one thing we need to bear in mind is that in doing it we are removing a mechanism to close the opened 'to' field. This puts more 'pressure', shall we say, on creating an affordance/easily selectable touch area to drag the 'to' field up in order to close it. I would therefore suggest that when the to field is open we leave more of a gap between the underside of the last contact module at the bottom of the list of recipients and the bottom edge of the 'to' field. This would give a greater target area and also reduce the risk of user scrolling the list of recipients instead of closing the 'to' field when it is open.


Julien's answer:

It would still close if the user focusses the message composer. Don't you think this is enough ?

There are basically 4 actions that could be done on this panel:
1. entering recipients
2. typing a message
3. canceling and going back to the thread list
4. sending the message

It seems to me that 3. and 4. are irrelevant in this discussion as we'll leave the "new thread" panel.

2. already slides up the recipients panel.

1. is the important case here. I'd argue that if the user slid down the recipients panel, we shouldn't slide it up while he's entering recipients. There is imho no good argument to slide up the recipient panel if the user slid it down before, except if he focusses the message composer.

The only reason where the user would like to slide up the panel is to see and/or write the current message and it seems to me that focusing the message itself is a good enough affordance for this.

What do you think Ayman ?

Comment 1

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #0)
> Julien's answer:
> 
> It would still close if the user focusses the message composer. Don't you
> think this is enough ?

no i don't. 

1) Every action should have an equal opposite reaction in order to simplify the building of the users mental model of interaction. So if the user pulls down to open the 'to field', we need to (if feasible) pull up to close. When designing I bent this 'rule' by substituting the pull up for interaction with the keyboard, but this is being removed now.

2) We need to hand the scenario whereby the user opens the 'to field' with focus still in the  'message field'. Currently the only way to close the 'to field' in this scenario is to:

2.1) tap on the message field. however the affordance for this is low as the cursor focus is still in the message field so pragmatically why would a user tap there to close the close the 'to field'
2.2) type in the message field. this currently does not close the 'to field'.. but if it did reliance on typing more text in the message field to close the 'to field' is undesirable for the simple reason that the user might not *want* to type any more text in the 'to field'

3) We need to handle the scenario of the user opening the to field to refer to it when the keyboard is closed. Keyboard closed allows the user to see more of the thread. Selecting the message field will open the keyboard as well as close the to field… which would just be inconvenient if the user wished to continue reading the thread.

> 
> There are basically 4 actions that could be done on this panel:
> 1. entering recipients
> 2. typing a message
> 3. canceling and going back to the thread list
> 4. sending the message
> 
> It seems to me that 3. and 4. are irrelevant in this discussion as we'll
> leave the "new thread" panel.
> 
> 2. already slides up the recipients panel.
> 
> 1. is the important case here. I'd argue that if the user slid down the
> recipients panel, we shouldn't slide it up while he's entering recipients.
> There is imho no good argument to slide up the recipient panel if the user
> slid it down before, except if he focusses the message composer.
> 
> The only reason where the user would like to slide up the panel is to see
> and/or write the current message and it seems to me that focusing the
> message itself is a good enough affordance for this.
> 
> What do you think Ayman ?

At this point i am still of the mind that we need to include slide up behavior if we are going to remove the 'tap on keyboard to close 'to field' behavior.

Comment 2

[Julien Wajsberg [:julienw]]

(In reply to ayman maat :maat from comment #1)
> (In reply to Julien Wajsberg [:julienw] from comment #0)
> > Julien's answer:
> > 
> > It would still close if the user focusses the message composer. Don't you
> > think this is enough ?
> 
> no i don't. 
> 
> 1) Every action should have an equal opposite reaction in order to simplify
> the building of the users mental model of interaction. So if the user pulls
> down to open the 'to field', we need to (if feasible) pull up to close. When
> designing I bent this 'rule' by substituting the pull up for interaction
> with the keyboard, but this is being removed now.

I perfectly agree with this argument.


> 2) We need to hand the scenario whereby the user opens the 'to field' with
> focus still in the  'message field'. Currently the only way to close the 'to
> field' in this scenario is to:
> 
> 2.1) tap on the message field. however the affordance for this is low as the
> cursor focus is still in the message field so pragmatically why would a user
> tap there to close the close the 'to field'
> 2.2) type in the message field. this currently does not close the 'to
> field'.. but if it did reliance on typing more text in the message field to
> close the 'to field' is undesirable for the simple reason that the user
> might not *want* to type any more text in the 'to field'

You meant "message field" at the end, but yes I agree with all this.


> 3) We need to handle the scenario of the user opening the to field to refer
> to it when the keyboard is closed. Keyboard closed allows the user to see
> more of the thread. Selecting the message field will open the keyboard as
> well as close the to field… which would just be inconvenient if the user
> wished to continue reading the thread.

There is no thread here as we are in the "new thread" panel.


The argument 1 makes a lot of sense to me. But now here is a counter proposition. ;)

Bottom line: I'd like to remove the pull down gesture. Rather :

1. when the user taps the recipients panel it would slide down and open and focus. The user would always see the whole recipient list (unless it's too big of course) when it's adding a recipient. To be honest, it always felt weird to me to not have it open in that case.

2. when the user taps the message composer, the recipients panel would slide up.

With this proposition, there is no way to open the recipients panel and still have the focus in the message composer, which might have been a goal of the initial specification.


If that doesn't work for you and if we want to keep the pull down gesture, then I agree we need to do a pull up gesture too.

Comment 3

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #2)
> (In reply to ayman maat :maat from comment #1)
> > (In reply to Julien Wajsberg [:julienw] from comment #0)
> > > Julien's answer:
> > > 
> > > It would still close if the user focusses the message composer. Don't you
> > > think this is enough ?
> > 
> > no i don't. 
> > 
> > 1) Every action should have an equal opposite reaction in order to simplify
> > the building of the users mental model of interaction. So if the user pulls
> > down to open the 'to field', we need to (if feasible) pull up to close. When
> > designing I bent this 'rule' by substituting the pull up for interaction
> > with the keyboard, but this is being removed now.
> 
> I perfectly agree with this argument.
> 
> 
> > 2) We need to hand the scenario whereby the user opens the 'to field' with
> > focus still in the  'message field'. Currently the only way to close the 'to
> > field' in this scenario is to:
> > 
> > 2.1) tap on the message field. however the affordance for this is low as the
> > cursor focus is still in the message field so pragmatically why would a user
> > tap there to close the close the 'to field'
> > 2.2) type in the message field. this currently does not close the 'to
> > field'.. but if it did reliance on typing more text in the message field to
> > close the 'to field' is undesirable for the simple reason that the user
> > might not *want* to type any more text in the 'to field'
> 
> You meant "message field" at the end, but yes I agree with all this.
> 
> 
> > 3) We need to handle the scenario of the user opening the to field to refer
> > to it when the keyboard is closed. Keyboard closed allows the user to see
> > more of the thread. Selecting the message field will open the keyboard as
> > well as close the to field… which would just be inconvenient if the user
> > wished to continue reading the thread.
> 
> There is no thread here as we are in the "new thread" panel.

ah! touché ...got me there :-) 

> 
> 
> The argument 1 makes a lot of sense to me. But now here is a counter
> proposition. ;)
> 
> Bottom line: I'd like to remove the pull down gesture. Rather :
> 
> 1. when the user taps the recipients panel it would slide down and open and
> focus. The user would always see the whole recipient list (unless it's too
> big of course) when it's adding a recipient. To be honest, it always felt
> weird to me to not have it open in that case.
> 
> 2. when the user taps the message composer, the recipients panel would slide
> up.
> 
> With this proposition, there is no way to open the recipients panel and
> still have the focus in the message composer, which might have been a goal
> of the initial specification.
> 
> 
> If that doesn't work for you and if we want to keep the pull down gesture,
> then I agree we need to do a pull up gesture too.


I like what your suggesting and its a pragmatic evolution of the interaction model we already have. But i am hesitating for two reasons:

reason 1) tap behavior… 

We have a situation whereby 'tap' on a recipients module triggers one of two behaviors:

1.1) if the recipient is in the contact list: an overlay is opened that delivers the number that the message is about to be sent to

1.2) if the recipient is not in the contact list: the recipients module is put back into an editable state

in view of this to add another tap behavior (to open the 'to field') on the the closed 'to field' would certainly be overloading the area. That said if we were to disable 'tap on recipient module' behavior when the 'to field' is closed your proposition would certainly be one to peruse.  In order to do that we would need two different states for the recipient modules in the 'to field'; one where the 'to field' is closed and affording that the names or numbers cannot be selected, the other where the 'to field' is open and affording that the names and numbers can be selected as per point 1 and 2 above...

However...

reason 2) Auto Suggestions

Auto Suggestions *completely* slipped my mind during this discussion (largely because I am a little overloaded and distracted at the moment).. 

We have to consider the Auto Suggestions delivered from the users contact list as the user is adding new recipients. This is the *other* reason why I specified the 'to field' to slide back up when the user types on the keyboard. If we leave the 'to field' open as the user is typing we have no real estate to display the Auto Suggestions...or at least we significantly reduce it.

Problem with reducing it is that one contact can have several phone numbers associated to it so in the auto suggestions a single contact can have several lines. This makes the suggestions list longer than in other instances where it is presented. We could of course use the auto suggestions pattern from Dialer, but I don't want to do that as it is not an optimal UX in our message app scenario. Due to the fact that a single contacts can have several entries in the auto suggestions we need to maximize the real-estate for the suggestions in order to keep it usable/consumable.  

For the end user the presentation of / access to Auto Suggestions, i would say, is of higher value over keeping the 'to field' open during editing.

With Auto Suggestions in mind I am of the opinion that we would need to do some more detailed/protracted design surgery on the message composition screen than we at first thought in order to keep the 'to field' open during editing.. so maybe we have been pursuing/discussing an enhancement that is not practical to pursue right now due to timelines/resource etc etc.

what do you think?

Comment 4

[Julien Wajsberg [:julienw]]

I like the proposition where basically "slid up" = "not editable" and "slid down" = "editable". This means we should give the focus to add a recipients when it's slid down too, so that the user does not need to tap again to have the focus.

I perfectly agree your second point too, autosuggestions is a very important subject here, I forgot it too.

Basically, we want to see autosuggestions when the user is "composing" the recipients, but we want to see the recipients panel when the user is "modifying" the recipients.

What comes to my mind here is :

* as soon as we do have at least a autosuggestion, we slide up the panel like we used to. Another possibility is to slide it up as soon as the user types one character. (these two situations might be quite equivalent in the real life).

* And we slide it down again as soon when the user chooses one suggestion, that means when the user is not editing a recipient at that moment.

Comment 5

[Julien Wajsberg [:julienw]]

Hey Omega,

I just found this old bug about the recipients sliding behavior. Since you want to refine this behavior, maybe you'll find the discussion here interesting.

Comment 6

[Omega Feng [:Omega] [:馮於懋]]

ni? new UX owner Jenny.

Comment 7

[Jenny Lee]

(In reply to Julien Wajsberg [:julienw] from comment #5)

Hello Julien, just letting you know that I've updated the spec addressing this issue already but I want to go over the design with Vicky first ;) hopefully I'll be able to release it some time next week. Tks!

Comment 8

[Jenny Lee]

Attachment: [Message] Recipient panel behavior v.1.pdf

See attached for the new recipient panel design and let me know if there's any problem, thanks!

Comment 9

[Julien Wajsberg [:julienw]]

Hey Jenny,

in light of all the past discussions we had here with the previous UX designer, I find that your proposal is really good as it addresses most of the things we said here.

One comment though: I think we should remove the "slide down" gesture. What do you think?

Comment 10

[Jenny Lee]

(In reply to Julien Wajsberg [:julienw] from comment #9)
> Hey Jenny,
> 
> in light of all the past discussions we had here with the previous UX
> designer, I find that your proposal is really good as it addresses most of
> the things we said here.
> 
> One comment though: I think we should remove the "slide down" gesture. What
> do you think?

Thanks Julien :D !!

I find the sliding gesture quite intuitive. When user finishes editing recipient and taps on composer to type message, the to field slides up to collapse (see p.6 screen 6), naturally, it can be slid down. Also the half hidden bubbles (see p.7 screen 1) hints user that there are more names on top, that he can slide down the panel to see the rest of the hidden parts. 
So, if you don't feel strongly about removing the gesture (is there any concern?), I suggest we keep it. Thanks!

Comment 11

[Julien Wajsberg [:julienw]]

I was considering that merely tapping is enough to display the full recipient panel.

This is in light of what Ayman said in comment 1: if we have a "slide down" gesture, we should have a "slide up" gesture too for the opposite behavior. Since we don't want a "slide up" gesture (because we already have a lot of other actions that trigger this behavior) we might as well remove the "slide down" gesture.

I'll also argue that the "slide down" gesture never felt right to me, because the panel does not follow the finger; instead, the finger does a "slide down" gesture, and only _then_, the panel slides down. And indeed, it's not very easy to do a real "the-panel-follows-the-finger" slide...

And lastly we can make the panel display fully as soon as the user "touchstart" in the panel; means it will likely be faster than when we need to wait for a gesture or a "click" (which I think happens about 400ms after "touchstart" if we listen to gestures).

Comment 12

[Julien Wajsberg [:julienw]]

Maybe we can just do both codes and see which one feels batter. There is not much difference between both codes.

Comment 13

[Jenny Lee]

I see your point. Could you do both codes and let's see which one feels better as you suggested, if the sliding doesn't feel right, I'll remove it, thanks ;)

Comment 14

[Jenny Lee]

Attachment: [Message] Recipient panel and composer v1.1.pdf

Hello, see attached for updated spec. Thanks!

Comment 16

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 17

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(