Closed
Bug 959011
Opened 11 years ago
Closed 7 years ago
[MADAI][Dialer] Sending pre-defined message during call reject
Categories
(Firefox OS Graveyard :: Gaia::Dialer, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: sharaf.tir, Assigned: promise09th)
References
Details
(Keywords: feature, Whiteboard: [m+])
Attachments
(28 files, 19 obsolete files)
3.05 MB,
application/pdf
|
Details | |
280.52 KB,
application/pdf
|
Details | |
311.94 KB,
image/png
|
Details | |
159.52 KB,
image/png
|
Details | |
196.25 KB,
image/png
|
Details | |
1.65 KB,
application/zip
|
Details | |
220.25 KB,
image/png
|
Details | |
196.41 KB,
image/png
|
Details | |
63.34 KB,
image/png
|
Details | |
287.10 KB,
image/png
|
Details | |
258.57 KB,
image/png
|
Details | |
246.85 KB,
image/png
|
Details | |
253.88 KB,
image/png
|
Details | |
209.13 KB,
image/png
|
Details | |
194.02 KB,
image/png
|
Details | |
170.08 KB,
image/png
|
Details | |
136.88 KB,
image/png
|
Details | |
136.55 KB,
image/png
|
Details | |
136.35 KB,
image/png
|
Details | |
157.56 KB,
image/png
|
Details | |
249.58 KB,
image/png
|
Details | |
1.64 MB,
application/pdf
|
Details | |
2.39 MB,
application/pdf
|
Details | |
199 bytes,
text/html
|
steveck
:
feedback+
|
Details |
657.60 KB,
application/x-zip-compressed
|
Details | |
195.12 KB,
image/jpeg
|
Details | |
383.58 KB,
application/zip
|
Details | |
960 bytes,
image/svg+xml
|
Details |
During an incoming call user can now either accept or reject the call.
We should add one more option for rejecting and sending a pre-defined text message to the caller stating any of the pre-defined reasons.
When this third option is selected , user will be prompted to select a message template from a list and then the call is automatically rejected and after that the text message is send to the caller.
Comment 1•11 years ago
|
||
I wonder how this feature work in parallel of STK.
For example, my operator opens an STK app with this kind of feature already when I reject a call.
Would be cool to have product input, Wolfred, do you know who owns STK on the product team? You?:)
Flags: needinfo?(wmathanaraj)
Comment 2•11 years ago
|
||
The initial implementation plan for this feature is following:
1. This feature will be applicable for only incoming call.
2. Apart from "End" and "Answer" options, there will be one new option "Reject Call with text"
Reject Call with text Mode
==========================
3. On selecting this option, the Call screen will switch to 5 Pre-defined text
page with "Send" option and "Decline Call" option also if user feels he
does'nt want to send the text.
4. Till the "send" option is not clicked, the phone will in call State.It will
get rejected only when message is sent
For More than 1 Call
=====================
For the call in waiting, there will be one option "Ignore with text" apart from "Ignore"
For Lockscreen Call
====================
UX input is required on how to add "Reject Call with text" option there
Since only two way is there to unlock the Lock-screen. On swiping left,"End"
Call is selected and on swiping right "Answer" Call is selected.
For reference, I have attached video from Nexus.Please check.
UX input is required on the above scenarios.
Comment 3•11 years ago
|
||
adding noemi as she knows best about STK interactions.
Flags: needinfo?(wmathanaraj) → needinfo?(noef)
Updated•11 years ago
|
Flags: needinfo?(noef)
Comment 4•11 years ago
|
||
(In reply to Wilfred Mathanaraj [:WDM] from comment #3)
> adding noemi as she knows best about STK interactions.
Regarding STK, notice that this feature might not be offered by all operators (feature operator dependent). It would work as follows:
1- STK app is registered to some of the following call related STK events:
icc._iccManager.STK_EVENT_TYPE_MT_CALL
icc._iccManager.STK_EVENT_TYPE_CALL_CONNECTED
icc._iccManager.STK_EVENT_TYPE_CALL_DISCONNECTED
2- Then, STK gaia app will inform to the SIM card about any call related event (incoming call, rejected call...), in this case, once the rejected call event is received by the SIM card, STK app will launch a specific dialog to the user offering different messages to be sent
Comment 5•11 years ago
|
||
Thanks.
I think the best option to move forward is to implement the feature with an optional setting to disable it.
This way if an operator wants to implement this from the STK app it will be able to disable the feature.
Comment 6•11 years ago
|
||
(In reply to Etienne Segonzac (:etienne) from comment #5)
> I think the best option to move forward is to implement the feature with an
> optional setting to disable it.
> This way if an operator wants to implement this from the STK app it will be
> able to disable the feature.
Thanks Etienne,
We are working on the UX specs for this feature.
Hi,
Can you give a reference for the dialer specs for v1.4?
It will very helpful for considering UI scenarios for this feature.
Thank you.
Flags: needinfo?(cawang)
Comment 7•11 years ago
|
||
Hi Etienne,
In comment #2
I have given all the scenarios of "Reject Call With Text" feature.
For this scenarios,
We need a UX person who can propose UX specs for this feature in above UI scenarios.
Can you refer this to a Appropriate dialer UX person
who can help us with this feature.
Thank you.
Flags: needinfo?(etienne)
Updated•11 years ago
|
Flags: needinfo?(etienne) → needinfo?(firefoxos-ux-bugzilla)
Comment 8•11 years ago
|
||
Wilfred, is this definitely a feature in the backlog?
Comment 9•11 years ago
|
||
Hi,
This is one of the MADAI mandatory feature.
And We are going to implement this feature.
But we need inputs from Mozilla on UI scenarios mentioned in comment #2.
We need your UX engineer help on this feature.
Flags: needinfo?(swilkes)
Comment 10•11 years ago
|
||
Hi, for the complete Dialer spec, it would be the one that Francis did in 1.2. Dialer didn't change a lot during 1.3 and 1.4. Thanks!
Flags: needinfo?(swilkes)
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(cawang)
Comment 11•11 years ago
|
||
Hi Mukesh, Sharaf,
Can you base on your feature requirements create a UX proposal base on our current spec provided in comment 10?
Carrie can review your proposal and help you forward once you have it available.
Thanks.
Flags: needinfo?(sharaf.tir)
Flags: needinfo?(mukeshk1990)
Reporter | ||
Comment 12•11 years ago
|
||
clearing ni as the required info is already shared to Wayne
Flags: needinfo?(sharaf.tir)
Comment 13•11 years ago
|
||
Hi Saraf,
Please attach those to bugzilla rather than via email so anyone involved can view/review them.
Thanks
Flags: needinfo?(sharaf.tir)
Comment 14•11 years ago
|
||
Hi Wayne,
We have created the UI proposal for above feature and need Mozilla
UX team to review it.
(In user scenario #3, we need Mozilla UX input since its related with
lock screen slider)
Thanks.
Flags: needinfo?(mukeshk1990) → needinfo?(wchang)
Comment 15•11 years ago
|
||
Carrie, can you review the partner proposal here?
I believe they also need our proposal for receiving calls while the screen is locked.
Thanks
Flags: needinfo?(wchang) → needinfo?(cawang)
Comment 16•11 years ago
|
||
Comment 17•11 years ago
|
||
Hi Etienne
This is a test patch of our work in progress and is uploaded to show a demo
of this feature Implementation.
The patch is not 100% complete as per UI proposal uploaded by us(attachment #3 [details] [diff] [review])
but its out understanding that it will give you a better overview of
UI proposal uploaded for this feature and will help you in giving feedback and inputs needed.
Note: Please copy the sms icons( in attached zip file in attachement #4)
before applying the patch.
Please give your suggestions.
Attachment #8377052 -
Flags: feedback?(etienne)
Comment 18•11 years ago
|
||
Comment on attachment 8377052 [details] [diff] [review]
Work in progress Demo Patch
Review of attachment 8377052 [details] [diff] [review]:
-----------------------------------------------------------------
Forwarding to Rik who is more on top of new features work.
Attachment #8377052 -
Flags: feedback?(etienne) → feedback?(anthony)
Comment 19•11 years ago
|
||
Hi Rik,
The work in progress patch has been updated and lint errors are removed.
Please give your feedback on implementation
and following.
- FFOS support for private numbers. In case if it support private
number, what should be this feature in that case?
Thank you.
Attachment #8377052 -
Attachment is obsolete: true
Attachment #8377052 -
Flags: feedback?(anthony)
Attachment #8377595 -
Flags: feedback?(anthony)
Comment 20•11 years ago
|
||
Comment on attachment 8377595 [details] [diff] [review]
WIP DeclineCall_demo.patch
Review of attachment 8377595 [details] [diff] [review]:
-----------------------------------------------------------------
I'm just commenting the feature, not the code.
We should not send the SMS directly from the dialer app. Instead we should start an activity that opens the SMS app. That will let users edit the message but also choose from which SIM they want to send the message.
Also, if I intend to send a SMS by opening the menu but the call drops in the meantime (because it goes to voicemail or the caller hang up), the menu disappears. That sounds unfortunate.
So I think we need more UX input before landing this. And we'll need visual input too.
Attachment #8377595 -
Flags: feedback?(anthony)
Comment 21•11 years ago
|
||
Hi everyone,
Given that we have different ways to reject calls on locked/unlocked screen, the behavior of sending pre-defined messages might be inconsistent in these two scenarios. Hence, the UX team need some time for internal discussion and will deliver the spec next week. In addition, from the attached spec, it looks like we only provide 5 default messages as options, but it might not be precise enough to cover all cases. So, are we considering providing an input field or a shortcut to access Messages APP for customized messages? Thanks!
Flags: needinfo?(cawang)
Comment 22•11 years ago
|
||
(In reply to Anthony Ricaud (:rik) from comment #20)
Thanks Rik for your comment.
> We should not send the SMS directly from the dialer app. Instead we should
> start an activity that opens the SMS app. That will let users edit the
> message but also choose from which SIM they want to send the message.
As feature wise, when the call comes, the user would not have enough time to go
message App and type message and then send.
This feature is mainly to quick reply when we are involved in some other activity
and we dont have much time.
Also, i think its appropriate to send message from that SIM only that rejected the call
so that the caller would recognize who has sent message.
> Also, if I intend to send a SMS by opening the menu but the call drops in
> the meantime (because it goes to voicemail or the caller hang up), the menu
> disappears. That sounds unfortunate.
This feature is implemented so that the user can reply in quick to the caller
in case of any urgency.So it is kept as a part of dialer.
Also if the caller hang up or goes to voice mail, the user can respond from message App
or go to call log and send SMS.
> So I think we need more UX input before landing this. And we'll need visual
> input too.
Yeah, thanks for raising these issues. We would also like to get UX input on this feature.
Comment 23•11 years ago
|
||
About the comment 20, I'm with Mukesh on this one. It's just a quick response. No need to access the Message APP (unless we want to allow users customized their message there).
Comment 24•11 years ago
|
||
(In reply to Carrie Wang [:cwang] from comment #23)
> About the comment 20, I'm with Mukesh on this one. It's just a quick
> response. No need to access the Message APP (unless we want to allow users
> customized their message there).
IMHO, as a user of this feature, I love to have a way to customize the list of messages available to be sent but outside of the functionality, maybe in a settings menu for messaging or calls...
Agree with the fact that this is a fast way to "answer" a call :-)
Comment 25•11 years ago
|
||
(In reply to Mukesh kumar from comment #22)
> As feature wise, when the call comes, the user would not have enough time to
> go
> message App and type message and then send.
> This feature is mainly to quick reply when we are involved in some other
> activity
> and we dont have much time.
That's a valid comment but whatever we do, I think having a "Other…" option that would open the SMS app is still useful. The two use cases I can see are mostly "Can't answer, doing something else, need fast reply" or "Can't answer, quiet environment, can take time to answer".
> Also, i think its appropriate to send message from that SIM only that
> rejected the call
> so that the caller would recognize who has sent message.
I'd like UX to chime in on that one. Maybe the SIM card you received the call on is not the one you chose for SMS and so it would be expensive to send a SMS with that one. Also, if we're not gonna respect the user's preferred choice, we need to inform them before sending the message.
> This feature is implemented so that the user can reply in quick to the
> caller
> in case of any urgency.So it is kept as a part of dialer.
> Also if the caller hang up or goes to voice mail, the user can respond from
> message App
> or go to call log and send SMS.
Thinking about this use case (answer after call is over), I think we should implement this as a SMS activity. When you press the button, it rejects the call and opens a SMS activity. That way, only the SMS app has the SMS permissions (that was bothering me to add this permission to the Dialer). And we can answer after the call is gone. And all the Dual SIM handling stays in the SMS app.
(In reply to Carrie Wang [:carrie] from comment #23)
> About the comment 20, I'm with Mukesh on this one. It's just a quick
> response. No need to access the Message APP (unless we want to allow users
> customized their message there).
Even in the Dual SIM case? Also, this wasn't the only issue raised. See above.
Flags: needinfo?(cawang)
Comment 26•11 years ago
|
||
I'd like to provide 5 default messages for quick choices and an additional "customized message" that users can tap it and go to Message APP to compose a new message (meanwhile, the call is rejected).
For DSDS scenario, I think whenever the user taps the pre-defined message, it will be sent from the primary SIM for outgoing SMS. If they want to switch SIM, they can tap the "customized" and do the on-the-fly SIM swap in Message APP. Only in this way, the whole behavior could align with our DSDS general guideline.
Flags: needinfo?(cawang)
Comment 27•11 years ago
|
||
Hi Carrie,
We have got some suggestions from you on this feature.
But we are still waiting for the complete UX specs on this feature
especially the Lock screen scenarios.Please give your comment.
Flags: needinfo?(cawang)
Comment 28•11 years ago
|
||
Hi,
I just upload the spec of sending pre-defined messages during call reject.
Since we didn't reach any conclusion on these feature-related comments, UX team spent some time on internal discussion.
Please have a look. Any comment will be appreciated. Thanks!
Flags: needinfo?(cawang)
Comment 29•11 years ago
|
||
Thanks Carrie.
Feature specs looks all good to me.
The only one concern I have is In Lock Screen Incoming Call, if we have 'click feature'
it may get triggered by mistake or unknowingly.
Should we need a swipe feature in place of click feature or it should be like this only?
Flags: needinfo?(cawang)
Comment 30•11 years ago
|
||
Hi Mukesh,
I've considered "swipe", but we will have "swipe-up for notification" in our future theme. Hence, to prevent the possible inconsistency in the future, I'd suggest adopting "tap" to trigger the pre-defined messages. In addition, given that it needs two steps to send a message (tap the button + tap a message), I'm not that concerned with this issue.
We will let VxD to get involved with the button design.
Thanks!
Flags: needinfo?(cawang)
Comment 31•11 years ago
|
||
The spec looks pretty clear to me, except:
- it doesn't say what happens when the call drops (because the caller hangs up or because it reached voicemail) while you have the menu displayed. I think the menu should stay open to let the receiver choose a message.
- should we also stop the vibration and sound when that menu opens? It seems a good thing because you might be in a situation where you don't want the ringtone to continue. But it could also be a bad thing because if the phone is in your pocket and a unvolontary "tap" triggers the menu, you could miss calls.
Flags: needinfo?(cawang)
Comment 32•11 years ago
|
||
(In reply to Anthony Ricaud (:rik) from comment #31)
> The spec looks pretty clear to me, except:
> - it doesn't say what happens when the call drops (because the caller hangs
> up or because it reached voicemail) while you have the menu displayed. I
> think the menu should stay open to let the receiver choose a message.
This doesnt seem necessary since this feature is useful when we want to end the call urgently
and with a very quick message. If the call is already ended. I think its better to go to call
log and send a proper message to that missed call log.
I left this to Carrie to decide.
> - should we also stop the vibration and sound when that menu opens? It seems
> a good thing because you might be in a situation where you don't want the
> ringtone to continue. But it could also be a bad thing because if the phone
> is in your pocket and a unvolontary "tap" triggers the menu, you could miss
> calls.
How about stopping ringtone while keeping the vibration ON when menu opens. By this way,
the user will always know in any case the call is incoming and not ended.
Comment 33•11 years ago
|
||
Hey Anthony,
Thanks for pointing out these details.
Yes, I think we shall keep the messages menu open even the call is dropped. And yes, I think we shall mute the ringtone and the vibration as well. Since we provide a way for users to tap and go Message APP to customize texts, it will be very weird to keep the phone ringing while editing. In addition, I think we shall automatically decline the call when users tap "cancel" or "send" buttons in the Message APP.
It looks like more details are brought up. I'll just update the spec and upload again. Thanks!
Flags: needinfo?(cawang)
Comment 34•11 years ago
|
||
Hi guys,
Just uploaded a revised version. Some changes are noted in red. Please take a look. Thanks!
Attachment #8384499 -
Attachment is obsolete: true
Comment 35•11 years ago
|
||
Hi Carrie,
there is one issue which I need to point
- lockscreen -> incoming call -> Tap "Decline wih message" -> Message App (without unlocking lock-screen)
does it not pose a security threat?
We can access many Apps from SMS App.
I mean is going to message App without unlocking lock screen is proper way?
Flags: needinfo?(cawang)
Comment 36•11 years ago
|
||
Hi Mukesh,
On screen 3-2, I adopt "x" button to replace the "<" in Message APP. In this way, users won't see other message threads after sending this message and then get back to lockscreen. To me, it's more like a "quick edit" page for sending messages (maybe I shouldn't use "Message APP" as the title in the spec). I think this is the quickest way for customization. However, I'd like to know if we can really do this "quick edit" approach rather than bringing up the whole Message APP (with the "<" button to access the message history and cause the privacy issue)? If the answer is no, then yes, users should insert passcode before accessing Message APP.
Thanks!
Flags: needinfo?(cawang) → needinfo?(mukeshk1990)
Comment 37•11 years ago
|
||
Hi Carrie,
Even if we dont have '<' button, we would still have '+' and "Attach" button which can directly access contact APP, gallery , Music and Video APP.
Considering we have to switch Message APP on Customize, 'quick edit' cannot be done in Message APP.
We can only switch to other app by launching activity and if that APP has some activities,
we cannot stop them from triggering.
Rik can also give some inputs on above.
Flags: needinfo?(mukeshk1990) → needinfo?(anthony)
Comment 38•11 years ago
|
||
Also as per your comment, VxD team is going to give button designs.
Carrie, when we can expect to get these.
Thank you!
Flags: needinfo?(cawang)
Comment 39•11 years ago
|
||
OK, then I'm fine with popping up the keypad for passcode before they get into Message APP and will upload the revised version later.
Jose will in charge of the icon design. ni? him to confirm the date.
Thanks.
Flags: needinfo?(cawang) → needinfo?(vittone)
Comment 40•11 years ago
|
||
Hi All,
We'll have visuals by next Monday.
Thanks!
Flags: needinfo?(vittone)
Comment 41•11 years ago
|
||
Yeah I think it's better to actually respect the passcode when pressing that button.
Julien: Could you check attachment 8386661 [details] and tell us what you think. I recommended implementing this with a SMS activity.
Flags: needinfo?(anthony) → needinfo?(felash)
Comment hidden (obsolete) |
Comment 43•11 years ago
|
||
Rik came to explain me what he had in mind: have the choice screen live in the Messages app.
Then I agree with him, please disregard most of my comment 42.
The activity would take a list of strings and optionally a serviceId or iccId (let's say serviceId).
Also, I think we should see the phone number/contact name in that screen, and also the SIM that will be used in a DSDS setup.
Comment 44•11 years ago
|
||
The only part of comment 42 that is still relevant is:
"Also, you need to specify what happens in DSDS Mode. I guess you'll want to send the message using the same SIM that the incoming phone call."
Carrie: Could you be explicit about this in the spec?
Flags: needinfo?(cawang)
Comment 45•11 years ago
|
||
Hey,
Just updated the spec based on all the comments here (see the attachment- v0.3). Please take a look. Thanks! :-)
Attachment #8386661 -
Attachment is obsolete: true
Flags: needinfo?(cawang)
Comment 46•11 years ago
|
||
Carrie, some comments:
* if we implement this using an activity in the Messages app, and if the menu where we choose a message (let's call it the "message chooser") lives in the Messages app, then you can drop the call either just before starting this menu, or after we completely leave the activity.
Another possibility would be to have one activity displaying the menu, but when the user presses "customize", we would call "postResult" with a specific result, allowing the Dialer to end the call and start the existing "send sms" activity. I don't like this so much though, what's your thought Anthony?
* what happens when the user presses the back button in the Messages view?
Note that if we do the 2nd possibility above, we would have a cross and no way to go back to the message chooser anyway. (unless I missed something)
* This is more a comment for Anthony: would we have the attention screen while in the message chooser, if we don't drop the call?
Comment 47•11 years ago
|
||
Hi,
I think second possibility has a bigger disadvantage of launching message screen as an activity
If user after switching to message screen wishes to go back and 'answer' or 'end' the call, he has to
close the activity
it will be better to have message screen as a part of call-screen rather than launching it
always as an activity and closing activity.
In other OS, it the same behavior.
Carrie proposal looks good to me.
Comment 48•11 years ago
|
||
I don't have time to answer now, will do next week. Needinfo for comment 46.
Flags: needinfo?(anthony)
Comment 49•11 years ago
|
||
The first possibility will also launch as an activity. I don't see the issue with using an activity, because we can make that pressing the back button or cancel will cancel the activity and thus go back to the call. What we can't do with the initial planned implementation is ending the call when we click on a the choosen message.
Comment 50•11 years ago
|
||
(In reply to José Vittone from comment #40)
Hi Vittone,
We are still waiting for the visuals.Can you give updated.
Flags: needinfo?(vittone)
Updated•11 years ago
|
Flags: needinfo?(wchang)
Comment 51•11 years ago
|
||
Hey, Jose is leaving the project and now Victoria will take over the visual design here.
However, while discussing with the visual team, we came up a new idea for declining calls on lockscreen. Please check the attachment.
The message icon only appears when users tap the circle handle (the one with left/right arrows on it). With this visual hint, he can then decide to drag the handle to answer/decline/ send a message. The rationale behind this new idea is that we want to keep the interaction "Drag to select" consistent on this page. In the previous proposal, users should drag to answer/decline, but tap to send msg. With the same design logic, we will keep "Tap to select" as what I did in the previous spec in other scenarios (in APP and multiple calls) so that the interaction will be the same on that page.
The new idea might be more complicated for implementation. Hence, we'd like to know if this is feasible from engineering perspective? Thanks!
Flags: needinfo?(vittone)
Comment 52•11 years ago
|
||
Current visual proposal for ongoing call. Vicky will confirm or modify this visuals in the following days.
Comment 53•11 years ago
|
||
Comment 54•11 years ago
|
||
Updated•11 years ago
|
Blocks: dialer-visual-refres
Comment 55•11 years ago
|
||
Hi Victoria,
Could you please provide with the visual proposal for Incoming call + Lockscreen for this scenario?. Thanks!
Flags: needinfo?(vpg)
Comment 56•11 years ago
|
||
Hi guys! As Noemí previously set (Blocks: bug 950760, in fact according to this very bug some of the visuals attached in bug 950760 are now outdated), this bug covers much of the functionality related to the visual refresh of the Dialer regarding the incoming and outgoing call page. My doubt is: do you plan to cover the implementation of the provided visuals too?, once the flow and "low level" details (via activity, etc.) are decided and implemented. Seems a lot of work for a bug to me ;-)
Comment 57•11 years ago
|
||
A few points here:
This week we (TEF + Taipei UX teams9 had a review of the interaction and visual for the losckscreen and decided that the proposed solution is not yet ideal and a new proposal from the interaction team is about to come early next week, based on that I will visually design it. So expect new interaction specs and visual design next week.
This new visuals will, indeed, affect the current refresh screens for Incomming call, Lockscreen incomming call and Second incomming call.
Thanks.
NI from Carrie so she provides specs.
Flags: needinfo?(cawang)
Comment 58•11 years ago
|
||
Hi, about the new proposal in comment 51, I’d suggest to have some testing or more precise illustration on the transition of dragging the circle handle to pre-defined messages. We had the same issue on the normal Lockscreen page that we can’t really “drag” the handle from A to B, we can only extend the handle to reach B. We might have the same issue here. Please take it into account and do the issue review once the design is lockdown.
Comment 59•11 years ago
|
||
Hi Rik,
Please give feedback on the patch uploaded on functionality basis since
the UI visuals and lock screen call is yet to be finalized.
The patch is made according to the UX spec provided by Carrie in comment#45.
Thanks
Attachment #8364200 -
Attachment is obsolete: true
Attachment #8377042 -
Attachment is obsolete: true
Attachment #8377595 -
Attachment is obsolete: true
Attachment #8394768 -
Flags: feedback?(anthony)
Updated•11 years ago
|
Flags: needinfo?(wchang)
Updated•11 years ago
|
Whiteboard: [m+]
Comment 60•11 years ago
|
||
Attachment #8394768 -
Attachment is obsolete: true
Attachment #8394768 -
Flags: feedback?(anthony)
Attachment #8395508 -
Flags: feedback?(anthony)
Comment 61•11 years ago
|
||
Hi Rik,
I have updated the patch.
Please apply these sms Icon dialer/style/images before applying the Work in Progress patch
Thank you.
Reporter | ||
Comment 62•11 years ago
|
||
Just clearing ni as the information is already provided in comment #13 by Mukesh
Flags: needinfo?(sharaf.tir)
Comment 63•11 years ago
|
||
Dear Mukesh,
Can Sungwoo take it?
Flags: needinfo?(promise09th)
Flags: needinfo?(mukeshk1990)
Comment 64•11 years ago
|
||
Assigning the Bug to Sunwoo Yoon.
He will do the rest of the implementation.
Thank you.
Assignee: mukeshk1990 → promise09th
Flags: needinfo?(mukeshk1990)
Comment 65•11 years ago
|
||
(In reply to Carrie Wang [:carrie] from comment #51)
> Created attachment 8393598 [details]
> Screen Shot 2014-03-19 at 12.25.07.png
>
> Hey, Jose is leaving the project and now Victoria will take over the visual
> design here.
> However, while discussing with the visual team, we came up a new idea for
> declining calls on lockscreen. Please check the attachment.
>
> The message icon only appears when users tap the circle handle (the one with
> left/right arrows on it). With this visual hint, he can then decide to drag
> the handle to answer/decline/ send a message. The rationale behind this new
> idea is that we want to keep the interaction "Drag to select" consistent on
> this page. In the previous proposal, users should drag to answer/decline,
> but tap to send msg. With the same design logic, we will keep "Tap to
> select" as what I did in the previous spec in other scenarios (in APP and
> multiple calls) so that the interaction will be the same on that page.
>
> The new idea might be more complicated for implementation. Hence, we'd like
> to know if this is feasible from engineering perspective? Thanks!
Hi Carrie,
Given the status of this bug and the particular project schedule, can we go with your proposal in comment 45 for now and refine this later for future releases?
Since Mukesh has been working base on that as well.
Thank you
Comment 66•11 years ago
|
||
Yes, agree with Wayne. We can adopt the spec from comment 45 for now and keep refining it in the future. Vicky will update the final visual spec here. Thanks everyone! :)
Flags: needinfo?(cawang)
Comment 67•11 years ago
|
||
Flags: needinfo?(vpg)
Updated•11 years ago
|
Attachment #8397190 -
Attachment description: Lockscreen incomingCall reject with message → Visual Mockup. Lockscreen incomingCall reject with message
Comment 68•11 years ago
|
||
Comment 69•11 years ago
|
||
updated buttons for the message picker overlay
Attachment #8393684 -
Attachment is obsolete: true
Comment 70•11 years ago
|
||
Comment 71•11 years ago
|
||
Updated•11 years ago
|
Attachment #8397197 -
Attachment description: Visual Spec: Lockscreen decline with message → Visual Spec: Incomming Call. decline with message
Comment 72•11 years ago
|
||
Assignee | ||
Comment 73•11 years ago
|
||
I'll check visual spec, and work.
Thanks
Flags: needinfo?(promise09th)
Comment 74•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] (away until March 24) from comment #46)
> Carrie, some comments:
>
> * if we implement this using an activity in the Messages app, and if the
> menu where we choose a message (let's call it the "message chooser") lives
> in the Messages app, then you can drop the call either just before starting
> this menu, or after we completely leave the activity.
>
> Another possibility would be to have one activity displaying the menu, but
> when the user presses "customize", we would call "postResult" with a
> specific result, allowing the Dialer to end the call and start the existing
> "send sms" activity. I don't like this so much though, what's your thought
> Anthony?
Whatever we do, we need to stop the ringtone/vibration when the message chooser is displayed.
I think the choice of whether the new "quickanswer" activity does everything or just displays a menu and then starts the "send sms" activity will be up based on the current UX limitations of activities. If it sucks to transition between "quickanswer" and "send sms", then "quickanswer" should do everything. But if it doesn't suck in terms of UX then it will probably be less code to modify on the SMS side of things.
> * This is more a comment for Anthony: would we have the attention screen
> while in the message chooser, if we don't drop the call?
I'm not sure right now but the call would probably be reduced to the status bar. We can refine once we have a first iteration.
Flags: needinfo?(anthony)
Comment 75•11 years ago
|
||
Comment on attachment 8395508 [details] [diff] [review]
WIP_Call_Decline_with_Message.patch
Review of attachment 8395508 [details] [diff] [review]:
-----------------------------------------------------------------
This patch is not implementing this as a SMS activity as I explained in comment 25.
Attachment #8395508 -
Flags: feedback?(anthony) → feedback-
Assignee | ||
Comment 76•11 years ago
|
||
Hi, Victoria
I have a question about your new UX.
In your new UX, backgroud color is #e7e7e7(looks white).
But, now call screen show black(or translucent) image in call.
If you want to change all dialer background color from black to white, I think I make new bugzilla(Change dialer UI to white).
Do you think that we treat color-change in this bug?
Please check this
Flags: needinfo?(vpg)
Comment 77•11 years ago
|
||
(In reply to promise09th from comment #76)
> Hi, Victoria
>
> I have a question about your new UX.
> In your new UX, backgroud color is #e7e7e7(looks white).
> But, now call screen show black(or translucent) image in call.
> If you want to change all dialer background color from black to white, I
> think I make new bugzilla(Change dialer UI to white).
> Do you think that we treat color-change in this bug?
>
Hi,
All this changes you mention, from dark to light UI are collected in the Dialer Refresh Metabug (https://bugzilla.mozilla.org/show_bug.cgi?id=950760). SO there's no need to create a new one.
Thanks.
> Please check this
Flags: needinfo?(vpg)
Assignee | ||
Comment 78•11 years ago
|
||
I have a one more question.
In your new UX, use new message icon.
How to get this icon? Do I make this icon or do I request GUI part?
Assignee | ||
Updated•11 years ago
|
Flags: needinfo?(vpg)
Comment 79•11 years ago
|
||
Pau is on it, will post the asset sprite ASAP here.
Flags: needinfo?(vpg) → needinfo?(b.pmm)
Comment 80•11 years ago
|
||
Here is the sprite of the "message icon" in svg format.
Flags: needinfo?(b.pmm)
Assignee | ||
Comment 81•11 years ago
|
||
Apply new UX
Assignee | ||
Comment 82•11 years ago
|
||
screenshots
Assignee | ||
Updated•11 years ago
|
Attachment #8401659 -
Flags: feedback?(anthony)
Assignee | ||
Comment 83•11 years ago
|
||
(In reply to Anthony Ricaud (:rik) from comment #75)
> Comment on attachment 8395508 [details] [diff] [review]
> WIP_Call_Decline_with_Message.patch
>
> Review of attachment 8395508 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> This patch is not implementing this as a SMS activity as I explained in
> comment 25.
I didn't understand what you point.
Explain me please ...
Comment 84•11 years ago
|
||
Please in order to UI review this patch, can you provide screenshots of this once the visual refresh is implemented? This does not look OK at all, because it is shown in the old design scenario, so it cannot live on the phone like this.
THanks-
Comment 85•11 years ago
|
||
(In reply to Victoria Gerchinhoren [:vicky] from comment #84)
> Please in order to UI review this patch, can you provide screenshots of this
> once the visual refresh is implemented? This does not look OK at all,
> because it is shown in the old design scenario, so it cannot live on the
> phone like this.
>
> THanks-
Dear Victoria and Wayne,
New visual refresh from you is based on V1.5. But as you know, MADAI use V1.4 visual refresh.
If we use V1.5 visual refresh on V1.4, it will be so ugly.
So we need GUI assets of this feature for V1.4. We will implement V1.4 visual and V1.5 visual too.
Can you provide it?
Flags: needinfo?(wchang)
Flags: needinfo?(vpg)
Comment 86•11 years ago
|
||
Youngjun> are you sure it's due for v1.4? I've seen that all madai? flags were moved to 1.5? instead...
Comment 87•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #86)
> Youngjun> are you sure it's due for v1.4? I've seen that all madai? flags
> were moved to 1.5? instead...
This feature was created for MADAI Mandatory feature. I know that this feature will be implemented for V1.5. But we will cherry pick this feature for MADAI.
Comment 88•11 years ago
|
||
(In reply to Youngjun Kim from comment #87)
> (In reply to Julien Wajsberg [:julienw] from comment #86)
> > Youngjun> are you sure it's due for v1.4? I've seen that all madai? flags
> > were moved to 1.5? instead...
>
> This feature was created for MADAI Mandatory feature. I know that this
> feature will be implemented for V1.5. But we will cherry pick this feature
> for MADAI.
If this is now targeted for 1.5 no dark version of this features will go be released, right?
Flags: needinfo?(vpg)
Comment 89•11 years ago
|
||
(In reply to Youngjun Kim from comment #87)
> (In reply to Julien Wajsberg [:julienw] from comment #86)
> > Youngjun> are you sure it's due for v1.4? I've seen that all madai? flags
> > were moved to 1.5? instead...
>
> This feature was created for MADAI Mandatory feature. I know that this
> feature will be implemented for V1.5. But we will cherry pick this feature
> for MADAI.
It's not called "cherry pick" anymore if you have different patches for each branch... This sounds unsafe to me, especially that this feature requires change in both the Messages and the Dialer app, and that the activity handling in Messages is being refactorized in 1.5 so the patch will end up quite different. :(
Comment 90•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #89)
> (In reply to Youngjun Kim from comment #87)
> > (In reply to Julien Wajsberg [:julienw] from comment #86)
> > > Youngjun> are you sure it's due for v1.4? I've seen that all madai? flags
> > > were moved to 1.5? instead...
> >
> > This feature was created for MADAI Mandatory feature. I know that this
> > feature will be implemented for V1.5. But we will cherry pick this feature
> > for MADAI.
>
> It's not called "cherry pick" anymore if you have different patches for each
> branch... This sounds unsafe to me, especially that this feature requires
> change in both the Messages and the Dialer app, and that the activity
> handling in Messages is being refactorized in 1.5 so the patch will end up
> quite different. :(
ni to Wilfred to confirm the target version for this feature. Thanks!
Flags: needinfo?(wmathanaraj)
Comment 91•11 years ago
|
||
we need to answer first victoria's question - so ni UX for comment 88.
If Madai needs it then will land it based on the landing criteria plus UX needs.
Flags: needinfo?(ux-review)
Updated•11 years ago
|
Flags: needinfo?(wmathanaraj)
Comment 92•11 years ago
|
||
Wilfred, Noemi,
Even though for FxOS this is now targeted for v1.5 and will not get landed to FxOS 1.4 branch, partner will include this in the Madai project, which is v1.4 based.
Can we support them with the visuals compatible with v1.4?
Flags: needinfo?(wchang)
Comment 93•11 years ago
|
||
The "message" icon in idle state changes its color with respect to the light version.
Comment 94•11 years ago
|
||
Comment 95•11 years ago
|
||
Comment 96•11 years ago
|
||
Comment 97•11 years ago
|
||
Comment 98•11 years ago
|
||
Comment 99•11 years ago
|
||
Comment 100•11 years ago
|
||
Comment 101•11 years ago
|
||
Comment 102•11 years ago
|
||
Visual material needed for the current (not refreshed) version of the phone uploaded. Use this same icon in white: https://bug959011.bugzilla.mozilla.org/attachment.cgi?id=8401213
There's a wrong opacity value in 2 of the files, it will be replaced in the next hour.
Thanks!
Comment 103•11 years ago
|
||
Attachment #8404552 -
Attachment is obsolete: true
Comment 104•11 years ago
|
||
Hit state spec has been added
Attachment #8404541 -
Attachment is obsolete: true
Comment 105•11 years ago
|
||
Attachment #8404655 -
Attachment is obsolete: true
Comment 106•11 years ago
|
||
(In reply to Victoria Gerchinhoren [:vicky] from comment #57)
> A few points here:
>
> This week we (TEF + Taipei UX teams9 had a review of the interaction and
> visual for the losckscreen and decided that the proposed solution is not yet
> ideal and a new proposal from the interaction team is about to come early
> next week, based on that I will visually design it. So expect new
> interaction specs and visual design next week.
>
> This new visuals will, indeed, affect the current refresh screens for
> Incomming call, Lockscreen incomming call and Second incomming call.
>
> Thanks.
>
> NI from Carrie so she provides specs.
Hi,
Bug 994645 has been created as follow up to track the ongoing discussion about a new interaction proposal due to the concerns raised with the current one (such as what happen if the phone is in my pocket/bag when receiving an incoming call, just tapping on reject message icon could reject the call by mistake, the idea of maintaining interaction "drag to select"...). Thanks!
Updated•11 years ago
|
Attachment #8395508 -
Attachment is obsolete: true
Comment 107•11 years ago
|
||
Comment on attachment 8401659 [details]
decline_with_message_140404.patch
Review of attachment 8401659 [details]:
-----------------------------------------------------------------
(In reply to promise09th from comment #83)
> I didn't understand what you point.
> Explain me please ...
The "send sms" button in Dialer should call a web activity called "quickreply". This new quickreply activity lives inside the SMS app. So most of this patch will live in the SMS app. Only the display of the button and the click handler will live in Dialer.
Attachment #8401659 -
Flags: feedback?(anthony) → feedback-
Comment 108•10 years ago
|
||
Clearing the needinfo to ux-review.
Please needinfo specific people if possible because needinfoing ux-review causes daily emails to all UX people – regardless of whether they are working on FxOS, Desktop or elsewhere.
Flags: needinfo?(ux-review)
Comment 109•10 years ago
|
||
I am the Program Manager for the UX team for Firefox OS and this is the first I have seen of the ux-review alias. Can someone please clarify what this is for and who it goes to?
For the Firefox OS team, the main flags we use are:
* Setting ni? to the general Firefox OS alias for UX, which is firefoxos-ux-bugzilla@mozilla.com. We triage out of this to the correct UX people who are actually available at the time.
* Setting ui-review? on attachments to either the general UX alias (as above) or to the main interaction (not visual) designer on a particular bug. After the IxD is ui-review+, visual design review can proceed.
Flags: needinfo?(firefoxos-ux-bugzilla)
Comment 110•10 years ago
|
||
(In reply to Anthony Ricaud (:rik) (out until May 13th) from comment #107)
> Comment on attachment 8401659 [details]
> decline_with_message_140404.patch
>
> Review of attachment 8401659 [details]:
> -----------------------------------------------------------------
>
> (In reply to promise09th from comment #83)
> > I didn't understand what you point.
> > Explain me please ...
> The "send sms" button in Dialer should call a web activity called
> "quickreply". This new quickreply activity lives inside the SMS app. So most
> of this patch will live in the SMS app. Only the display of the button and
> the click handler will live in Dialer.
Hi promise09, are you working on this?. Thanks!
Flags: needinfo?(promise09th)
Assignee | ||
Comment 111•10 years ago
|
||
Dear Noemi.
Today, I'll upload new patch(Change activity)
I'm sorry too late.
Thanks
Flags: needinfo?(promise09th)
Assignee | ||
Comment 112•10 years ago
|
||
I upload new patch.
I make "quickreply" activity in sms app, and send message in sms app too.
I apply not all UI scenario but decline message button UI.
Please check this patch, Thanks
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(anthony)
Assignee | ||
Updated•10 years ago
|
Attachment #8401659 -
Attachment is obsolete: true
Attachment #8401659 -
Attachment is patch: false
Updated•10 years ago
|
blocking-b2g: --- → backlog
feature-b2g: --- → 2.0
Updated•10 years ago
|
Flags: needinfo?(firefoxos-ux-bugzilla)
Assignee | ||
Updated•10 years ago
|
Attachment #8419931 -
Flags: feedback?(anthony)
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(anthony)
Comment 113•10 years ago
|
||
Comment on attachment 8419931 [details] [diff] [review]
Bug-9959011-Decline-call-with-message_140509.patch
Review of attachment 8419931 [details] [diff] [review]:
-----------------------------------------------------------------
This is not the appropriate design. In dialer, only the quick message button should exist. When you press it, it starts the quickreply activity directly. That activity is the one that will display the list of pre-defined messages.
Attachment #8419931 -
Flags: feedback?(anthony) → feedback-
Assignee | ||
Comment 114•10 years ago
|
||
(In reply to Anthony Ricaud (:rik) from comment #113)
> Comment on attachment 8419931 [details] [diff] [review]
> Bug-9959011-Decline-call-with-message_140509.patch
>
> Review of attachment 8419931 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> This is not the appropriate design. In dialer, only the quick message button
> should exist. When you press it, it starts the quickreply activity directly.
> That activity is the one that will display the list of pre-defined messages.
I have a question.
Message list has "cancel" button. So, even if message list is shown, call is not ended yet.
In this case, sms can end a call when user select message list, and also sms app should have 'telephony' permissions. I think this operation is weird.
So, I think dialer should have message list.
Please tell me your opinion
Flags: needinfo?(anthony)
Assignee | ||
Comment 115•10 years ago
|
||
(In reply to Anthony Ricaud (:rik) from comment #113)
> Comment on attachment 8419931 [details] [diff] [review]
> Bug-9959011-Decline-call-with-message_140509.patch
>
> Review of attachment 8419931 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> This is not the appropriate design. In dialer, only the quick message button
> should exist. When you press it, it starts the quickreply activity directly.
> That activity is the one that will display the list of pre-defined messages.
And, sms app is not shown over the call screen
So, I don't know how to show sms app without terminating the callscreen app.
Comment 116•10 years ago
|
||
(In reply to promise09th from comment #114)
> Message list has "cancel" button. So, even if message list is shown, call is
> not ended yet.
> In this case, sms can end a call when user select message list, and also sms
> app should have 'telephony' permissions. I think this operation is weird.
> So, I think dialer should have message list.
>
> Please tell me your opinion
I think we can use activity.postResult() when the user selects a button to tell callscreen to hang up the incoming call. I haven't tested it though. Can you try that?
(In reply to promise09th from comment #115)
> And, sms app is not shown over the call screen
> So, I don't know how to show sms app without terminating the callscreen app.
We should resize the callscreen app to go to the status bar. This is similar to what happens when you press the button to place a new call. See https://github.com/mozilla-b2g/gaia/blob/193fdafa2af1fe69a227e01ea3015b125a602f33/apps/callscreen/js/call_screen.js#L418-L428.
Flags: needinfo?(anthony)
Assignee | ||
Comment 117•10 years ago
|
||
(In reply to Anthony Ricaud (:rik) from comment #116)
> I think we can use activity.postResult() when the user selects a button to
> tell callscreen to hang up the incoming call. I haven't tested it though.
> Can you try that?
OK, I'll try this.
> We should resize the callscreen app to go to the status bar. This is similar
> to what happens when you press the button to place a new call. See
> https://github.com/mozilla-b2g/gaia/blob/
> 193fdafa2af1fe69a227e01ea3015b125a602f33/apps/callscreen/js/call_screen.
> js#L418-L428.
If I use 'placeNewCall' function for this feature, I think this feature has several issue.
1. UX is not matched
Can't implement attachment 8397192 [details] UX because callscreen app is always shown in statusbar
2. When incoming call is ended by opponent, message list is not hide(android scenario)
3. In lockscreen mode(+ passcode), user unlock lockscreen when user select 'decline message' button.
4. When user select "decline message" button and select cancel again and again, it is possible to occur performance issue...(This is not sure)
But, I'll try to make new patch. Please reply your opinion for these issues
Thnaks.
Flags: needinfo?(anthony)
Comment 118•10 years ago
|
||
(In reply to promise09th from comment #117)
> 1. UX is not matched
>
> Can't implement attachment 8397192 [details] UX because callscreen app is
> always shown in statusbar
I don't think this is a problem. We can ask Carrie.
> 2. When incoming call is ended by opponent, message list is not hide(android
> scenario)
If the caller hangs up, you'd still want to warn them why you couldn't answer so that's cool.
> 3. In lockscreen mode(+ passcode), user unlock lockscreen when user select
> 'decline message' button.
This is something that we want to fix in bug 1012889.
> 4. When user select "decline message" button and select cancel again and
> again, it is possible to occur performance issue...(This is not sure)
I'm not sure I understand the problem you describe here.
Flags: needinfo?(anthony)
Assignee | ||
Comment 119•10 years ago
|
||
When I use 'postResult' function, activity is ended by postResult function.
So, I can't see customize screen in SMS app...
So, I will use Inter-app Communication API(Bug 876397) like this
=====================================================================
// callscreen : call_handler.js
navigator.mozSetMessageHandler('connection', function(connReq) {
if (connReq.keyword !== 'declinemessage') {
return;
}
var port = connReq.port;
port.onmessage = function(event) {
handleMessageScreen();
};
port.start();
});
=====================================================================
// sms : activity_handler.js
navigator.mozApps.getSelf().onsuccess = function gotSelf(evt) {
var app = evt.target.result;
if (!app.connect) {
return;
}
app.connect('declinemessage').then(function onConnAccepted(ports) {
ports.forEach(function(port) {
var message = {
state: 'customize-sms'
};
port.postMessage(message);
})
});
};
=====================================================================
Is this any problem when I use this API?
Flags: needinfo?(anthony)
Assignee | ||
Comment 120•10 years ago
|
||
Sorry, I mistake something. Please forget it
Flags: needinfo?(anthony)
Assignee | ||
Comment 121•10 years ago
|
||
Attachment #8419931 -
Attachment is obsolete: true
Attachment #8429857 -
Flags: feedback?(anthony)
Assignee | ||
Comment 122•10 years ago
|
||
(In reply to Anthony Ricaud (:rik) from comment #118)
I upload patch to follow your comment. I move message popup from callscreen to sms.
Please check this patch.
Thanks
Assignee | ||
Comment 123•10 years ago
|
||
And, I found issue relating lockscreen.
https://bugzilla.mozilla.org/show_bug.cgi?id=1016837
Please check this(Because of this issue, message list is not shown normally in lockscreen)
Comment 124•10 years ago
|
||
Did you guys get Carrie's feedback to your point in comment #118? Cheers!
Assignee | ||
Updated•10 years ago
|
Attachment #8429857 -
Flags: feedback?(anthony)
Assignee | ||
Comment 125•10 years ago
|
||
I move patch to Git hub
Attachment #8430631 -
Flags: feedback?(anthony)
Assignee | ||
Updated•10 years ago
|
Attachment #8429857 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Attachment #8430631 -
Attachment description: Bug_959011_Declinew_call_with_message_140529.html → Bug_959011_Decline_call_with_message_140529.html
Comment 126•10 years ago
|
||
Update the UX spec (no interaction changes).
Attachment #8390332 -
Attachment is obsolete: true
Comment 127•10 years ago
|
||
CDMA part, please refer to p.7. Thanks.
Comment 128•10 years ago
|
||
Just a reminder, feature to be in 2.0 should be landed before branch date which is 6/9.
If this is not feasible, then let's consider removing feature-b2g flag and defer to 2.1.
Comment 129•10 years ago
|
||
Please let me know if this will be completed by the end of Sprint 3, which is this Friday. Flagging Joe and David to check on this as most Visual Refresh items cannot be deferred to 2.1 and this may need to be reassigned.
Flags: needinfo?(jcheng)
Flags: needinfo?(dscravaglieri)
Assignee | ||
Comment 130•10 years ago
|
||
Comment on attachment 8430631 [details]
Bug_959011_Decline_call_with_message.html
><html>
> <head>
> <meta http-equiv="Refresh"
> content="2; url=https://github.com/mozilla-b2g/gaia/pull/19917" />
> </head>
> <body>
> Redirect to pull request 19917
> </body>
></html>
Attachment #8430631 -
Attachment description: Bug_959011_Decline_call_with_message_140529.html → Bug_959011_Decline_call_with_message.html
Attachment #8430631 -
Attachment filename: Bug_959011_Declinew_call_with_message_140529.html → Bug_959011_Decline_call_with_message.html
Assignee | ||
Comment 131•10 years ago
|
||
Attachment #8401660 -
Attachment is obsolete: true
Attachment #8430631 -
Attachment is obsolete: true
Attachment #8430631 -
Flags: feedback?(anthony)
Attachment #8433095 -
Flags: feedback?(anthony)
Assignee | ||
Comment 132•10 years ago
|
||
Assignee | ||
Comment 133•10 years ago
|
||
Dear Anthony Ricaud
Carrie Wang upload UX scenario.
Before I check this scenario, we need to discuss some features
[MADAI] Pre-defined message for call reject_v0.4.pdf : 10 page / 11 page
I check page 10 and page 11 scenario, message list should be shown before unlock lockscreen.
But, now SMS app show message list, we need to unlock screen before we select message list.
So, we do not satisfy this scenario.
When I check Bug 1012889, bug 1012889 is not fixed in 2.0 or 2.1...etc. If bug 1012889 is fixed, we do not satisfy lockscreen scenario.
So, I think we rollback structure to previous structure(Dialer app show message list, and SMS app send message).
Please tell me your opinion
And, Please check new patch, also.
Thanks.
Flags: needinfo?(anthony)
Comment 134•10 years ago
|
||
clear feature-b2g=2.0 as this is not must-have in 2.0.
feature-b2g: 2.0 → ---
Comment 135•10 years ago
|
||
(In reply to promise09th from comment #133)
> Dear Anthony Ricaud
>
> Carrie Wang upload UX scenario.
>
> Before I check this scenario, we need to discuss some features
>
> [MADAI] Pre-defined message for call reject_v0.4.pdf : 10 page / 11 page
About page 10: If we fix bug 1012889, the lockscreen will not even be seen.
About page 11: I think we should change the interaction here. With the current design, someone could send text messages without ever entering the passcode (and thus spend the user's money). So displaying the passcode first makes sense to me. Carrie: What do you think?
Flags: needinfo?(jcheng)
Flags: needinfo?(dscravaglieri)
Flags: needinfo?(cawang)
Flags: needinfo?(anthony)
Comment 136•10 years ago
|
||
Comment on attachment 8433095 [details]
Bug_959011_Decline_call_with_message.html
This is going in the good direction, congrats! I left some comments on Github.
I haven't looked at the CSS nor the tests. And I gave a quick glance at SMS. I'll ask a SMS peer to feedback that part.
One thing that feels weird when using the feature is this:
- Receive a call
- Choose to send a quick reply
- Tap one of the replies
In this case, the callscreen will reopen with a transition, show the call has ended for a tiny bit and then close again. Can we avoid reopening the screen in that case?
Attachment #8433095 -
Flags: feedback?(anthony) → feedback?(felash)
Updated•10 years ago
|
No longer blocks: dialer-visual-refres
Comment 137•10 years ago
|
||
Comment on attachment 8433095 [details]
Bug_959011_Decline_call_with_message.html
gave some comments
while it's a good idea to use a separate page for quick reply, we have bug 818000 in Gecko currently that I think would make us lose the various system messages.
So this is a quite bad situation :/
Attachment #8433095 -
Flags: feedback?(felash)
Comment 138•10 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #137)
> while it's a good idea to use a separate page for quick reply, we have bug
> 818000 in Gecko currently that I think would make us lose the various system
> messages.
>
> So this is a quite bad situation :/
Nope, let's mark it as a blocker.
Depends on: 818000
Comment 139•10 years ago
|
||
I think that sending pre-defined messages is something that can be done very quickly. Hence, I'd still go with not entering the passcode first unless users want to customize the message. Thanks!
Flags: needinfo?(cawang)
Comment 140•10 years ago
|
||
Carrie: I don't see how displaying the passcode before or after having showed the list changes the time it takes to complete the task. You still need to tap the passcode eventually. Actually, I even think displaying the passcode after picking a message will be confusing. A lot of people will not understand that they need to enter the passcode to actually send the text message.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(cawang)
Comment 141•10 years ago
|
||
Hey, try to think in this way. If you have set passcode and there is an incoming call while screen is locked, do you need to enter passcode before answering it? No. Although in some roaming cases, receiving this kind of call will cost some additional fee to the callees, still, they don't really need to unlock it before answering it. Because, we already provide caller's info on the page, so users can decide if they want to answer/ decline it or even spend some money to reply a short message if it is an important call.
What do you say?
Flags: needinfo?(cawang) → needinfo?(anthony)
Comment 142•10 years ago
|
||
Given the date and the fact that design related conversation is still happening, this will likely not make 2.0 FL. Sprint 4, which began today, is not for new feature development.
Based on Wesley's earlier comments, it seems like this may not be a must-have, but flagging Wesley and Wilfred on that possibility/partner perspective.
Flags: needinfo?(wmathanaraj)
Flags: needinfo?(whuang)
Assignee | ||
Comment 143•10 years ago
|
||
If message list structure is decided, I'm going to work.
Comment 144•10 years ago
|
||
Thanks Carrie for the rationale, it makes sense to me.
I discussed how to implement that UX while keeping the code in the SMS app. We need bug 927862 to be solved. If it isn't solved in the timeframe we're looking for, we have a backup plan that is a bit hackish but that could let us ship.
In the mean time, I think we should work on landing the current status of this patch. It will not be the perfect UX that we want but once it lands, we will be able to refine it.
promise09th: Does that sound ok for you?
Depends on: attention-window
Flags: needinfo?(anthony)
Comment 145•10 years ago
|
||
From my understanding, this doesn't need to be in 2.0 as partner can still cherry pick from master.
Flags: needinfo?(wmathanaraj)
Flags: needinfo?(whuang)
Assignee | ||
Comment 146•10 years ago
|
||
(In reply to Anthony Ricaud (:rik) from comment #144)
> Thanks Carrie for the rationale, it makes sense to me.
>
> I discussed how to implement that UX while keeping the code in the SMS app.
> We need bug 927862 to be solved. If it isn't solved in the timeframe we're
> looking for, we have a backup plan that is a bit hackish but that could let
> us ship.
>
> In the mean time, I think we should work on landing the current status of
> this patch. It will not be the perfect UX that we want but once it lands, we
> will be able to refine it.
>
> promise09th: Does that sound ok for you?
OK, I see. I'll work
Comment 147•10 years ago
|
||
Next week, Anthony and I are both in holidays. So please request review from :etienne for Dialer and :steveck for SMS.
Thanks.
Assignee | ||
Comment 148•10 years ago
|
||
Comment on attachment 8433095 [details]
Bug_959011_Decline_call_with_message.html
I modify some patches.
But, I don't know how to implement below comment
> can you make all this a separate object ? "QuickReplyPanel" would work for me
I don't understand why converting 'leaveQuickReplyActivity' function to 'QuickReplyPanel' object.
Julien has vacation, so I request feedback to steveck
Attachment #8433095 -
Flags: feedback?(schung)
Comment 149•10 years ago
|
||
(In reply to promise09th from comment #148)
> Comment on attachment 8433095 [details]
> Bug_959011_Decline_call_with_message.html
>
> I modify some patches.
>
> But, I don't know how to implement below comment
>
> > can you make all this a separate object ? "QuickReplyPanel" would work for me
>
> I don't understand why converting 'leaveQuickReplyActivity' function to
> 'QuickReplyPanel' object.
>
>
> Julien has vacation, so I request feedback to steveck
I replay your questions on github, hope that could help you to move forword.
Updated•10 years ago
|
Attachment #8433095 -
Flags: feedback?(schung)
Assignee | ||
Comment 150•10 years ago
|
||
When I check patch in master, it is not working.
And I found that Bug 1033364 patch occur some problems in this patch.
So, I will check and upload patch again.
Assignee | ||
Comment 151•10 years ago
|
||
I have a question.
In android case, when receiving incoming call that include withheld number, message button is not shown.
But now, we do not have any scenario when receiving withheld incoming call.
I think we need some scenario in this case
Please check this.
Flags: needinfo?(cawang)
Comment 152•10 years ago
|
||
I'd suggest if it's withheld number, we disable the message button here. Thanks!
Flags: needinfo?(cawang)
Assignee | ||
Comment 153•10 years ago
|
||
Can you give me disable button UX?
Thanks
Flags: needinfo?(cawang)
Assignee | ||
Comment 154•10 years ago
|
||
Comment on attachment 8433095 [details]
Bug_959011_Decline_call_with_message.html
Dear Julien Wajsberg
I upload new patch that add "quick_reply.js" for "QuickReplyPanel"
But, I don't know this structure is right.
So, please check "quick_reply.js" file.
If you say OK, I make unit test for "quick_reply.js" file.
Thanks.
Attachment #8433095 -
Flags: feedback?(felash)
Comment 155•10 years ago
|
||
ni? Carol. She's taken over the visual design from Vicky.
I'll sync with her and update here. Thanks!
Flags: needinfo?(cawang) → needinfo?(chuang)
Comment 156•10 years ago
|
||
Hi,
I would like the disabled button & the text with 40% Opacity.(please see the attachment)
Could you provide the message png files for me? so I can make the btns in the same size.
Thanks!!!
Flags: needinfo?(chuang) → needinfo?(promise09th)
Comment 157•10 years ago
|
||
Comment on attachment 8433095 [details]
Bug_959011_Decline_call_with_message.html
I added some comments on github.
However, I discussed with Anthony, and we'd like to experiment with activities on our side, so I'm adding a NI to check this later.
Attachment #8433095 -
Flags: feedback?(felash)
Flags: needinfo?(felash)
Assignee | ||
Comment 158•10 years ago
|
||
Dear Carol
Please inform me more details about Call_Incoming_msg_btn.jpg (Background color and ETC)
And, you can get message file from attachment(refer Asset. SVG. Decline with message icon (1.75 KB, image/svg+xml))
And, please provide me second incoming call scenario(refer Visual Spec: 2nd incomming call. decline with message (246.85 KB, image/png))
Thanks
Flags: needinfo?(promise09th) → needinfo?(chuang)
Comment 159•10 years ago
|
||
Please see attachment for "pre-defined SMS icon in disable state" Visual spec.
Flags: needinfo?(chuang) → needinfo?(promise09th)
Assignee | ||
Comment 160•10 years ago
|
||
Dear Carol
Thanks for your reply
I think you miss "lockscreen call" state.
Please add this
Thanks
Flags: needinfo?(promise09th) → needinfo?(chuang)
Comment 161•10 years ago
|
||
Hi,
The "Lockscreen call" situation will be the same as "One Incoming call".
thanks!
Flags: needinfo?(chuang) → needinfo?(promise09th)
Assignee | ||
Comment 162•10 years ago
|
||
(In reply to Carol Huang [:Carol] from comment #161)
> Hi,
> The "Lockscreen call" situation will be the same as "One Incoming call".
> thanks!
Dear Carol
I check your comment.
And, can you give me new message icon? When I check your UX, message icon is different
Thanks!
Flags: needinfo?(promise09th) → needinfo?(chuang)
Comment 163•10 years ago
|
||
Hi,
Please update this "dialer_ic_sms.svg" for message icon. Thank you!!!!
Attachment #8401213 -
Attachment is obsolete: true
Flags: needinfo?(chuang) → needinfo?(promise09th)
Assignee | ||
Comment 164•10 years ago
|
||
Comment on attachment 8433095 [details]
Bug_959011_Decline_call_with_message.html
I upload new patch(I apply your comments in github)
And, I apply disable button scenario in callscreen app
Refer Created attachment 8464488 [details]
Please check this patch
Thanks
Attachment #8433095 -
Flags: feedback?(felash)
Flags: needinfo?(promise09th)
Assignee | ||
Updated•10 years ago
|
Attachment #8433095 -
Flags: feedback?(felash) → feedback?(schung)
Comment 165•10 years ago
|
||
Comment on attachment 8433095 [details]
Bug_959011_Decline_call_with_message.html
Few comments on github, it looks good except lack of unit test for quick reply part. Please request review when you are ready, thanks!
Attachment #8433095 -
Flags: feedback?(schung) → feedback+
Comment 166•10 years ago
|
||
Sorry I didn't have the time to look at it before my holidays.
Here are the current blocking issues:
* we don't like the IAC to do this; Anthony and I would like to see how we can do the same thing without IAC, using only activities. Unfortunately we have our hands quite full until start of september... So if you can try yourself, it could be nice
* we want that this activity is in a standalone HTML file to be really quick to launch. However this needs bug 818000 so that system messages continue to work while this HTML file is launched. Bug 818000 only prevents the system message from working, so you can still work on this solution right now.
Hope this helps moving this forward.
Flags: needinfo?(felash)
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
Updated•9 years ago
|
tracking-b2g:
backlog → ---
Keywords: feature
Comment 167•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•