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.

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?:)

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.

adding noemi as she knows best about STK interactions.

(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

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.

(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.

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.

Wilfred, is this definitely a feature in the backlog?

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.

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!

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.

clearing ni as the required info is already shared to Wayne

Hi Saraf, Please attach those to bugzilla rather than via email so anyone involved can view/review them. Thanks

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.

Carrie, can you review the partner proposal here? I believe they also need our proposal for receiving calls while the screen is locked. Thanks

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.

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.

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.

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.

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!

(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.

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).

(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 :-)

(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.

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.

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.

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!

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?

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!

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.

(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.

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!

Hi guys, Just uploaded a revised version. Some changes are noted in red. Please take a look. Thanks!

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?

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!

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.

Also as per your comment, VxD team is going to give button designs. Carrie, when we can expect to get these. Thank you!

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.

Hi All, We'll have visuals by next Monday. Thanks!

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.

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.

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?

Hey, Just updated the spec based on all the comments here (see the attachment- v0.3). Please take a look. Thanks! :-)

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?

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.

I don't have time to answer now, will do next week. Needinfo for comment 46.

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.

(In reply to José Vittone from comment #40) Hi Vittone, We are still waiting for the visuals.Can you give updated.

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!

Current visual proposal for ongoing call. Vicky will confirm or modify this visuals in the following days.

Hi Victoria, Could you please provide with the visual proposal for Incoming call + Lockscreen for this scenario?. Thanks!

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 ;-)

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, 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.

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

Hi Rik, I have updated the patch. Please apply these sms Icon dialer/style/images before applying the Work in Progress patch Thank you.

Just clearing ni as the information is already provided in comment #13 by Mukesh

Dear Mukesh, Can Sungwoo take it?

Assigning the Bug to Sunwoo Yoon. He will do the rest of the implementation. Thank you.

(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

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! :)

updated buttons for the message picker overlay

I'll check visual spec, and work. Thanks

(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.

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.

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

(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

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?

Pau is on it, will post the asset sprite ASAP here.

Here is the sprite of the "message icon" in svg format.

Apply new UX

screenshots

(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 ...

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-

(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?

Youngjun> are you sure it's due for v1.4? I've seen that all madai? flags were moved to 1.5? instead...

(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.

(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?

(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. :(

(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!

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.

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?

The "message" icon in idle state changes its color with respect to the light version.

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!

Hit state spec has been added

(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!

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.

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.

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.

(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!

Dear Noemi. Today, I'll upload new patch(Change activity) I'm sorry too late. Thanks

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

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.

(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

(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.

(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.

(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.

(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.

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?

Sorry, I mistake something. Please forget it

(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

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)

Did you guys get Carrie's feedback to your point in comment #118? Cheers!

I move patch to Git hub

Update the UX spec (no interaction changes).

CDMA part, please refer to p.7. Thanks.

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.

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.

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>

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.

clear feature-b2g=2.0 as this is not must-have in 2.0.

(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?

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?

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 :/

(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.

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!

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.

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?

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.

If message list structure is decided, I'm going to work.

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?

From my understanding, this doesn't need to be in 2.0 as partner can still cherry pick from master.

(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

Next week, Anthony and I are both in holidays. So please request review from :etienne for Dialer and :steveck for SMS. Thanks.

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

(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.

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.

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.

I'd suggest if it's withheld number, we disable the message button here. Thanks!

Can you give me disable button UX? Thanks

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.

ni? Carol. She's taken over the visual design from Vicky. I'll sync with her and update here. Thanks!

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!!!

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.

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

Please see attachment for "pre-defined SMS icon in disable state" Visual spec.

Dear Carol Thanks for your reply I think you miss "lockscreen call" state. Please add this Thanks

Hi, The "Lockscreen call" situation will be the same as "One Incoming call". thanks!

(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!

Hi, Please update this "dialer_ic_sms.svg" for message icon. Thank you!!!!

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

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!

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.

Firefox OS is not being worked on