Closed Bug 838000 Opened 11 years ago Closed 11 years ago

[SMS/MMS][User Story] Dialer invocation from message

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:leo+, b2g18 fixed)

RESOLVED FIXED
blocking-b2g leo+
Tracking Status
b2g18 --- fixed

People

(Reporter: pdol, Assigned: ssaroha)

References

()

Details

(Keywords: feature, Whiteboard: [LOE:M])

Attachments

(6 files, 4 obsolete files)

UCID: Messages-003

User Story:
As a user, I want the ability to directly dial a phone number from a message so that I don't need to remember the number to manually enter it into the Dialer.
Keywords: feature
Summary: [B2G][SMS][User Story] Dialer invocation from message → [SMS][User Story] Dialer invocation from message
Whiteboard: u=user c=sms s=v1.1-sprint-2
Assignee: nobody → ssaroha
For the UX here, would it be similar to the behavior when you click on a phone number in the call log (attached screen shot)? That would address both this story and bug 838002.
Whiteboard: u=user c=sms s=v1.1-sprint-2 → u=user c=sms s=v1.1-sprint-1
Summary: [SMS][User Story] Dialer invocation from message → [SMS/MMS][User Story] Dialer invocation from message
Whiteboard: u=user c=sms s=v1.1-sprint-1 → u=aganesan@mozilla.com c=sms s=v1.1-sprint-1
Dylan:

Yes, that is right. It should be as shown in attachment 711610 [details] except that the title on that screen should be '<the phone number>' that the user tapped on instead of Add new number. Alternately, if that retrieving that information to this screen is costly, it can be 'Unknown number'. 

As a side note, I would like another option to be added to the Call log scenario which is 'Send message' right after the call option (I don't know if there is already a user story or bug for that)

Arun
Marking this as blocking bug 838002 then as it seems likely that both issues will be solved by the same fix.
Blocks: 838002
(In reply to Arun Balachandran Ganesan [:abc] from comment #2)
> As a side note, I would like another option to be added to the Call log
> scenario which is 'Send message' right after the call option (I don't know
> if there is already a user story or bug for that)

That looks like bug 838022, so we'll tackle it over there when that one is prioritized.
Yes. Thanks, Dylan!
Thanks Arun for confirming the UX. I will go ahead and implement changes as per comment #2 and #3.
You are welcome, satender. Ping me on IRC if you have questions [:abc]
Hi Fabrice,
just submitted a pull request for the sms changes at https://github.com/mozilla-b2g/gaia/pull/8159

please review.
https://github.com/mozilla-b2g/gaia/pull/8159
Attachment #715069 - Flags: review?(fbsc)
Attachment #715069 - Flags: review?(fabrice)
Attachment #715069 - Flags: review?(alberto.pastor)
Whiteboard: u=aganesan@mozilla.com c=sms s=v1.1-sprint-1 → u=aganesan@mozilla.com c=sms s=v1.1-sprint-1 [LOE:M]=3-4 days
As suggested by Francisco, creating a separate pull request for contact activity changes for ease of review.
Hey :satender. Can we create diferent bugs for each one of the different Pull Requests? It will make it easier to merge and back out without affecting other working functionality.

Thanks!
Blocks: 844054
hi Alberto,
ok, will create a different bug for the second pull request. although, second pull request is a pre-req for the functionality in first pull request to fully work.

I will mark this bug as a dependent on the second one.

Thanks
Satender
No longer blocks: 844054
Depends on: 844054
Comment on attachment 716976 [details] [review]
pull request for contact activity changes to allow adding number to existing contact

this pull request move to another bug 844054.
Attachment #716976 - Flags: review?(fabrice.desre)
Attachment #716976 - Flags: review?(alberto.pastor)
Whiteboard: u=aganesan@mozilla.com c=sms s=v1.1-sprint-1 [LOE:M]=3-4 days → u=aganesan@mozilla.com c=sms s=v1.1-sprint-1 [LOE:M]
Depends on: 844303
Whiteboard: u=aganesan@mozilla.com c=sms s=v1.1-sprint-1 [LOE:M] → [LOE:M]
Comment on attachment 715069 [details] [diff] [review]
html link for Pull Request review

Adding stas@ to review l10n stuff added in file apps/sms/locales/sms.en-US.properties
Attachment #715069 - Flags: review?(stas)
Hi Arun! We would need some visuals/specs about this bug in order to check that the PR is working as expected. Could you attach it to this bug? Thanks!
Flags: needinfo?(aganesan)
Hi Arun/Casey, 
Specifically, one of the comments in PR is around the styles when there is a phone number in the message, Currently there is an 'orange color', from a UX perspective what should be the expected behavior here.
Arun,
please take a look at this screenshot which has phone number highlighted in orange currently.
Hi Satender,
Despite of your screenshot (I checked that screen as well), I would need the visual from Arun with the HEX of the color in order to check it. We would need this info in order to check that everything works & seems as expected.
the patch injects DOM nodes dynamically and uses data-l10n-id to localize them.

I don't think it will work in all scenarios with our pre-compilation on production.

I would recommend using l10n.get() to pool the strings instead
hey guys:

#ff4e00 is the color code. For visual design questions, you can flag :peterla or :patryk — that's where I got this info too.


Cheers,
Arun
Flags: needinfo?(aganesan)
have made the changes to use l10n.get for the 3 localized strings as suggested by Zbigniew. updated pr has the change.
Dylan: 

https://www.dropbox.com/s/toey9cb2vtow2jo/messages-calling_01Mar2013.pdf

I updated the specs here. There should be no title for the prompt (my fault). Please let me know if there are any questions.

(flagging you as needsinfo to make you notice this — is there a better way for doing it in bugzilla?)

Arun
Dylan:

I stand corrected. I checked with the UX team. It's okay to have a title, but I have update the specs with a new title. Thanks!
Depends on: 848778
Hi Arun! We have created a new bug https://bugzilla.mozilla.org/show_bug.cgi?id=848778 for creating a 'generic' action-menu with a configurable 'Title' and 'Options'. Could you append the info there and take a look? Thanks!
(In reply to Arun Balachandran Ganesan [:abc] from comment #23)
> Dylan: 
> 
> https://www.dropbox.com/s/toey9cb2vtow2jo/messages-calling_01Mar2013.pdf
Hi Arun, can we make the title of the prompt as the target content, e.g., 745-434-3455 in the figure? Since user may need the information to confirm his action. 

> 
> I updated the specs here. There should be no title for the prompt (my
> fault). Please let me know if there are any questions.
> 
> (flagging you as needsinfo to make you notice this — is there a better way
> for doing it in bugzilla?)
> 
> Arun
Flags: needinfo?(aganesan)
pyang:

https://www.dropbox.com/s/inwltmtb2jkh0dr/dialer-invocation-in-messages.pdf

This is the updated specs. Let me know any thoughts you may have. (It's pending UX feedback). I will confirm here once UX has reviewed it. Thanks!

Cheers,
Arun
Flags: needinfo?(aganesan)
Blocks: mms-p1
Per partner and release-driver discussions, marking blocking- until all MMS functionality in bug 849867 is complete, allowing it all to be checked-in at once to avoid SMS bustage.
blocking-b2g: leo+ → -
Borja & Pyang:

If the phone number in the message is one that is already in my contacts, will my mobile recognize that? Thanks!

Arun
Flags: needinfo?(fbsc)
Currently this feature it's not implemented. We could check if the number it's in the Contacts DB as well, but this would change the behaviour explained in the WF right? Because one number which is tied to a contact, should show only the 'call' action?
Flags: needinfo?(fbsc)
That's right, Borja. I'm updating my specs to accommodate this scenario. It should show 'call' and 'view contact'. It should also display the contact name instead of the number.
Hi Borja,
It may be the case if it's a mobile phone, but not if it is from an office.  Recommend to request review for use scenario.
Restoring leo+ for the non-MMS dependent v1.1 SMS features.
No longer blocks: mms-p1
blocking-b2g: - → leo+
Depends on: 850582
(In reply to Arun Balachandran Ganesan [:abc] from comment #30)
> Borja & Pyang:
> 
> If the phone number in the message is one that is already in my contacts,
> will my mobile recognize that? Thanks!
> 
> Arun

It's out of the scope of the User Story, 
besides a user could want to have the same phone number associated to different contacts
Attached file Acceptance criteria for US 838000 (obsolete) —
Attachment #724351 - Attachment is obsolete: true
Maria:

https://www.dropbox.com/s/3rl8tdq0y4yg31d/dialer-invocation-in-messages.pdf

The specs are complete from UX side (and in line with the acceptance criteria listed above) Can you please check  ASAP and raise a flag if something needs to be changed?
Thank you!

Cheers,
Arun
Flags: needinfo?(oteo)
Attached file Acceptance criteria for US 838000 (obsolete) —
Attachment #724374 - Attachment is obsolete: true
Flags: needinfo?(oteo)
One important thing to highlight: 
In case we have several clickable items in a single bubble, evey item should have an indepedent clickable area.
(In reply to Arun Balachandran Ganesan [:abc] from comment #39)
> Maria:
> 
> https://www.dropbox.com/s/3rl8tdq0y4yg31d/dialer-invocation-in-messages.pdf
> 
> The specs are complete from UX side (and in line with the acceptance
> criteria listed above) Can you please check  ASAP and raise a flag if
> something needs to be changed?
> Thank you!
> 
> Cheers,
> Arun

yes, they are aligned :)
Now Ayman will release a new WF version, just for including in one single document all the SMS US for v1.1 based in your WF and what we agreed with the development team.
Thanks a lot for your work, it's helped us a lot :)
(In reply to Maria Angeles Oteo:oteo from comment #41)
> One important thing to highlight: 
> In case we have several clickable items in a single bubble, evey item should
> have an indepedent clickable area.

Yes, I just updated the specs with this note.

Thanks!
Wireframe release:
HTML5_SMS-MMSUserStorySpecifications_20130315_V1.0

**new wireframes**
- SMS with phone number
- Phone number long press options
- Phone number not in contact list options
- SMS with URL
- SMS with email
- Email long press options

**updated wireframes**
- none

**deleted wireframes**
- none


to address this bug specifically refer to page: 5
Attachment #715069 - Attachment is obsolete: true
Attachment #715069 - Flags: review?(stas)
Attachment #715069 - Flags: review?(fbsc)
Attachment #715069 - Flags: review?(fabrice)
Attachment #715069 - Flags: review?(alberto.pastor)
Comment on attachment 726024 [details] [review]
new patch based on latest acceptance criteria

Could you take a look to the new Strings? Thanks!
Attachment #726024 - Flags: review?(stas)
Attachment #726024 - Flags: review?(l10n)
Comment on attachment 726024 [details] [review]
new patch based on latest acceptance criteria

From my side R+. We need only to have R+ from l10n team and we could merge it! Thanks for your work in SMS App. Soon we will have email management as well!! Thanks! Gracias! ;)
Attachment #726024 - Flags: review?(fbsc) → review+
Comment on attachment 726024 [details] [review]
new patch based on latest acceptance criteria

This patch looks like you're adding 4 strings and using 2? r- based on that.
Attachment #726024 - Flags: review?(stas)
Attachment #726024 - Flags: review?(l10n)
Attachment #726024 - Flags: review-
Comment on attachment 726024 [details] [review]
new patch based on latest acceptance criteria

removed the 2 strings not needed for this patch, based on l10n feedback. pls review again.
Attachment #726024 - Flags: review?(stas)
Attachment #726024 - Flags: review?(l10n)
Attachment #726024 - Flags: review-
This might be TEF or Taipei owning testing here.

Tony - Can you find out who owns this user story?
Flags: needinfo?(tchung)
Flags: in-moztrap?
(In reply to Jason Smith [:jsmith] from comment #50)
> This might be TEF or Taipei owning testing here.
> 
> Tony - Can you find out who owns this user story?

The testing of this US owns to TEF team, they are preparing the test plan for it
Flags: needinfo?(tchung)
Comment on attachment 726024 [details] [review]
new patch based on latest acceptance criteria

r=me, thanks.
Attachment #726024 - Flags: review?(stas)
Attachment #726024 - Flags: review?(l10n)
Attachment #726024 - Flags: review+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Uplifted commit 69f637108ed2196e873355c417fe876454bd4e88 as:
v1-train: 32b4246938b4b24c957b673eb03604886c2ad0f6
Updated Acceptance Criteria agreed with UX team and development, so QA team can update their test cases according to it
Attachment #724599 - Attachment is obsolete: true
It probably didn't work on v1-train until now that Bug 848778 was uplifted.
Flags: in-moztrap? → in-moztrap+
Removing the testcase, as it's invalid.   We'll rewrite and resubmit.
Flags: in-moztrap+ → in-moztrap?(jhammink)
Attachment mime type: text/plain text/plain → text/x-github-pull-request text/x-github-pull-request
Covered in https://moztrap.mozilla.org/manage/caseversion/79792/.
Flags: in-moztrap?(jhammink) → in-moztrap+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: