813147 - Add contact button in the dialer is always enabled.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect, P1)

Description

[Pablo Sanchez [:pabloUX]]

It should be enabled only when some numbers have been typed

Comment 1

[ayman maat :maat]

referencing: 
wireframe pack: HTML5_Dialer_Contacts_20120810_R2S1_V6.0
Page: 05

The functionality to disabel the Add Contact button until numbers are typed is not specified. However from a UX perspective, for the purposes of error prevention, it is a pragmatic improvement of the specified functionality to disable the Add Contact button until a number is  typed. So i agree we should absolutely do this.

Comment 4

[ayman maat :maat]

adding steve as a disabled add contact button might need some visual design work.

Comment 5

[ayman maat :maat]

Josh

You have downgraded this bug from UX-P1 bug to a UX-P3.

It is my considered opinion that Patryk is absolutely spot on, this should a UX-P1. This is not a 'want' to fix its a must fix. If we do not disable the button and give it the affordance of being disabled we have to error handle with a message (which is going to be a poor experience) because we cannot have the end users tapping on a button that looks as if it should be tapped, the button reacting to being tapped but nothing happening.

Can we upgrade this bug again please.

Comment 6

[Josh Carpenter [:jcarpenter]]

(In reply to ayman maat :maat from comment #5)
> Josh
> 
> You have downgraded this bug from UX-P1 bug to a UX-P3.
> 
> It is my considered opinion that Patryk is absolutely spot on, this should a
> UX-P1. This is not a 'want' to fix its a must fix. If we do not disable the
> button and give it the affordance of being disabled we have to error handle
> with a message (which is going to be a poor experience) because we cannot
> have the end users tapping on a button that looks as if it should be tapped,
> the button reacting to being tapped but nothing happening.
> 
> Can we upgrade this bug again please.

Hi Ayman. I agree this is problematic and I'd like to see it fixed. By way of explanation, my ranking was based on the following criteria for UX-P1:

1.) Egregious problems in high traffic areas...
2.) Big bang-for-buck wins...
3.) That cannot be fixed in uxbranch...
4.) That do not add excessive scope...

And on the UX-P1 — UX-P5 meanings:

* UX-P1 — Must fix
* UX-P2 — Should fix
* UX-P3 — Want to fix
* UX-P4 — Nice to have
* UX-P5 — V2

As near as I can tell, this bug...

* is limited to Contacts
* does not block the user from fulfilling the primary use case
* likelyhood of encountering is relatively low (limited to one flow, and requires the user to press the button)
* penalty for encountering is relatively low (button simply fails)

So based on that criteria and impact evaluation, I feel safe calling this a UX-P3, relative to the other major system-wide quality issues we still have. As we proceed, however, we can always upgrade into UX-P1 or UX-P2. This is still "want to fix", after all.

Does that make sense?

Comment 7

[ayman maat :maat]

Hi Josh

No, mate, I am sorry from a UX perspective I simply cannot agree with your reasoning.  This button sits on an interface of high usage: The Dialer, next to a CTA of extremely high usage: the call button. Therefore it is located in primary real estate. So we currently have a scenario whereby a CTA in primary real estate looks as if it should be tapped, reacts to being tapped ...but nothing happens. When Heuristics (for example Nielson's 10 principles of IxD design) are applied in order to give structure to the assessment of importance and so ranking of bugs, this bug one breaks rule 101 of UX (@ 60%):

 - Visibility of system status (fail)
 - User control and freedom (fail)
 - Consistency and standards (fail)
 - Error prevention (fail)
 - Aesthetic and minimalist design (fail)
 - Help users recognize, diagnose, and recover from errors (fail)

We cannot hypothesis about the volume of users that will interact with a CTA. Particularly one located in primary real estate.

The bottom line is that interaction with this CTA which is in prime real estate on the dialer leaves the user in no mans land. When a user experiences dissonance in interaction, specifically in such a sensitive location, the perceived integrity of our product is undermined. Therefore i cannot support the downgrading of this bug.

Comment 8

[Josh Carpenter [:jcarpenter]]

I see now this relates to Dialer, not Contacts (my mistake; I had two similar bugs confused).

I just tested this on my dogfooding device. 

* Open dialer
* Numbers field is blank. "Add Contact" button looks normal. 
* I press "Add Contacts"
* ....Nothing happens.
* I enter some numbers. 
* I press "Add Contacts"
* Contacts opens via transition.

Per the criteria I posted, we're focused right now on major product quality issues. 

This issue has...

* a very small user penalty (a brief moment of confusion)
* relatively low likelihood of being encountered (is safe to assume that most users will not try to tap the button when the number field is blank)
* an obvious implicit reason for failure ("Oh I haven't entered any numbers yet, of course I can't save anything...")
* a limited scope (Dialer only).

Therefore IMO it's a clear P3, or even P4. 

Again, I'm not saying we won't fix this, and I appreciate how it's probably like a pebble in the show of the Dialer app for you,  but right now we need to direct our energies towards major system-wide quality issues, and revisit bugs like these as we have more time.

Comment 9

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: Associated PR.

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky):

Comment 10

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 693298 [details]
Associated PR.

Not risky and simple to solve.

a=me

Please merge once you get the r+ from Ismael

Comment 11

[Francisco Jordano [:arcturus] [:francisco]]

btw German, any chance of having unit test for this?

Comment 13

[Germán Toro del Valle (:gtorodelvalle)]

Since it is a UI-related issue, I would not recommend it ;-) Unless you tell me otherwise, of course :-)
So merging, and :arcturus , if you consider it appropriate, please contact me and we will include a follow up for the unit test ;-)
Thanks everyone!

(In reply to Francisco Jordano [:arcturus] from comment #11)
> btw German, any chance of having unit test for this?