882133 - [SMS/MMS] content vanishes from 'to' field upon closure of contact module

Status: RESOLVED DUPLICATE of bug 880628

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

Description

[ayman maat :maat]

content vanishes from 'to' field upon closure of contact module

***PATH***
1) open message app
2) select new message
3) type '1234' and press either semi-colon or return to indicate that the string is complete and the contact module can be formed
4) again type '1234' and press either semi-colon or return to indicate that the string is complete and the contact module can be formed


***EXPECTED****
two separate modules will be present in the 'to' field both containing the string '1234'

***ACTUAL****
upon the user pressing either semi-colon or return to indicate that the string is complete and the contact module can be formed the second string of '1234' vanishes

The unexpected and unnotified deletion of content the user has just input into the system is extremely bad UX and deviates wildly from the behavior that was specified in HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0.

Comment 1

[Rick Waldron [:rwaldron]]

Ayman, (In reply to ayman maat :maat from comment #0)
> content vanishes from 'to' field upon closure of contact module
> 
> ***PATH***
> 1) open message app
> 2) select new message
> 3) type '1234' and press either semi-colon or return to indicate that the
> string is complete and the contact module can be formed
> 4) again type '1234' and press either semi-colon or return to indicate that
> the string is complete and the contact module can be formed
> 
> 
> ***EXPECTED****
> two separate modules will be present in the 'to' field both containing the
> string '1234'

Existing platforms do not behave like this.


> 
> ***ACTUAL****
> upon the user pressing either semi-colon or return to indicate that the
> string is complete and the contact module can be formed the second string of
> '1234' vanishes
> 
> The unexpected and unnotified deletion of content the user has just input
> into the system is extremely bad UX 

I strongly disagree. This is exactly how both iOS and Android behave. 

> and deviates wildly from the behavior
> that was specified in HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0.

I cannot find any place in this document that describes the "expected" behaviour

Comment 2

[ayman maat :maat]

(In reply to Rick Waldron from comment #1)
> Ayman, (In reply to ayman maat :maat from comment #0)
> > content vanishes from 'to' field upon closure of contact module
> > 
> > ***PATH***
> > 1) open message app
> > 2) select new message
> > 3) type '1234' and press either semi-colon or return to indicate that the
> > string is complete and the contact module can be formed
> > 4) again type '1234' and press either semi-colon or return to indicate that
> > the string is complete and the contact module can be formed
> > 
> > 
> > ***EXPECTED****
> > two separate modules will be present in the 'to' field both containing the
> > string '1234'
> 
> Existing platforms do not behave like this.

...is an incorrect statement
 
> > 
> > ***ACTUAL****
> > upon the user pressing either semi-colon or return to indicate that the
> > string is complete and the contact module can be formed the second string of
> > '1234' vanishes
> > 
> > The unexpected and unnotified deletion of content the user has just input
> > into the system is extremely bad UX 
> 
> I strongly disagree. 

You think its acceptable UX for content the user has just input into the system to just vanish in front of their eyes without any notification or explanation?? Really? Unfortunately Rick that's a very very basic UX design faux pas. There is absolutely no way i am going to underwrite such an interaction model or agree with its implementation in any area of any product that i am in any way responsible for.

> This is exactly how both iOS and Android behave. 

No other mobile OS exists as a UX specification for the design and development of FirefoxOS. The only UX specifications that you should be following or using for guidance are the ones that are made available specifically for this project. If the solution in the specifications that are delivered to you is ambiguous, conflicting, deficient, unachievable or in your professional opinion suboptimal you should be contacting the publisher of the specifications directly though any of the available communication channels, looping in whoever else needs to be in on the conversation, and raising your concerns and then working with them to define a solution. It is not acceptable to simply refer to another OS for a solution and copy the observed behavior.

> > and deviates wildly from the behavior
> > that was specified in HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0.
> 
> I cannot find any place in this document that describes the "expected"
> behaviour


guidance on the addition of multiple instances of the same contact can be found on page 07: 

"
Selection of same result
A user selects a contact with a given channel of communication (say telephone number) from the auto suggestions in order to add them to the ‘to’ field. If they then proceed to generate the same list of auto suggestions a second time the number already selected will still be presented. If the user then selects the same contact with the same channel of communication from the suggestions a second time in order to add to the ‘to’, the ‘to’ field will contain two individual entries for the same contact with same channel of communication. However when the user presses ‘send’ only one message should be sent to the contact.
"

Though this is talking about auto suggestions by extrapolation the principle should be implemented for any other method that a user can enter a contact into the 'to' field. 

N.B. a section of annotation 02 is content left over from a previous version of the document and is a publishing error. It has already been removed from the next edition of the document

If you need any further clarification please do not hesitate to contact me

Comment 3

[Alex Keybl [:akeybl]]

If the current implementation is status quo, then anything more is an enhancement. Not a blocker.

Comment 4

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #2)
> (In reply to Rick Waldron from comment #1)
> > Ayman, (In reply to ayman maat :maat from comment #0)
> > > content vanishes from 'to' field upon closure of contact module
> > > 
> > > ***PATH***
> > > 1) open message app
> > > 2) select new message
> > > 3) type '1234' and press either semi-colon or return to indicate that the
> > > string is complete and the contact module can be formed
> > > 4) again type '1234' and press either semi-colon or return to indicate that
> > > the string is complete and the contact module can be formed
> > > 
> > > 
> > > ***EXPECTED****
> > > two separate modules will be present in the 'to' field both containing the
> > > string '1234'
> > 
> > Existing platforms do not behave like this.
> 
> ...is an incorrect statement
>  
> > > 
> > > ***ACTUAL****
> > > upon the user pressing either semi-colon or return to indicate that the
> > > string is complete and the contact module can be formed the second string of
> > > '1234' vanishes
> > > 
> > > The unexpected and unnotified deletion of content the user has just input
> > > into the system is extremely bad UX 
> > 
> > I strongly disagree. 
> 
> You think its acceptable UX for content the user has just input into the
> system to just vanish in front of their eyes without any notification or
> explanation?? Really? Unfortunately Rick that's a very very basic UX design
> faux pas. 



http://jsfiddle.net/rwaldron/aV95z/show/light/


> There is absolutely no way i am going to underwrite such an
> interaction model or agree with its implementation in any area of any
> product that i am in any way responsible for.

This is exactly how I see implementing your bug, but I did it anyway.