Closed Bug 980843 Opened 10 years ago Closed 6 years ago

[Sora][WAP Push]YOU can not find the push message in message

Categories

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

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sync-1, Unassigned)

References

Details

(Keywords: feature, Whiteboard: [priority])

DEFECT DESCRIPTION:
 [WAP Push]YOU can not find the push message in message
  REPRODUCING PROCEDURES:
 1. recevie a  push message
 2. check it in  notification bar
 3.check it in sms app (ko)
  EXPECTED BEHAVIOUR:
 
 The wap push message should be saved in sms database. When we open sms app, we can see the wap push message we send.
 
 It is very serious bug, it will block the certification. 
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
blocking-b2g: --- → 1.3?
Flags: needinfo?(vchen)
IIRC, this is a design limitation/decission for WAP Push and OMA CP. Both kind of messages should be handle at the Notification bar or the user will lost them.

IMHO, this is a new feature request. I think Wildfred can add it in the backlog and prioritize in the coming releases as a good improvement.
Flags: needinfo?(vchen) → needinfo?(wmathanaraj)
Note that this would require a completely new UX/UI spec and some very large modifications to the codebase. The WAP Push messages are currently managed by their own dedicated application which becomes visible only in response to notifications; as you might imagine removing that application and merging all its code into the SMS app would involve a lot of work and quite a bit of risk.
Last time I got a Wap Push message on another phones, the wap push messages were not visible in the sms app.

(In reply to Gabriele Svelto [:gsvelto] from comment #2)
> Note that this would require a completely new UX/UI spec and some very large
> modifications to the codebase. The WAP Push messages are currently managed
> by their own dedicated application which becomes visible only in response to
> notifications; as you might imagine removing that application and merging
> all its code into the SMS app would involve a lot of work and quite a bit of
> risk.

We could use DataStores to do this and keep it in separate apps. Still, I don't want to do it :p

Beatriz or reporter, can you please light up what's the specific certification requirement here?
Flags: needinfo?(brg)
Flags: needinfo?(sync-1)
Component: Gaia::SMS → Gaia::Wappush
Keywords: feature
See Also: → 981521
blocking-b2g: 1.3? → ---
It's not a test case, but it is important for operators.
Wilfred will follow up
blocking-b2g: --- → backlog
Flags: needinfo?(sync-1)
We were seeing some work being done to include cell broadcast messages into a folder/app so that user can review these messages at a later time.

I think once this is being done we should also include Wap Push messages into the same category.

This will be a feature but not done in v1.5 - possibly v1.6.
Flags: needinfo?(wmathanaraj)
(In reply to Wilfred Mathanaraj [:WDM] from comment #6)
> We were seeing some work being done to include cell broadcast messages into
> a folder/app so that user can review these messages at a later time.
> 
> I think once this is being done we should also include Wap Push messages
> into the same category.

That sounds like a possibility. The reason we didn't want the WAP Push messages to be stored along with the SMS ones is that they can have a complicate UX flow (e.g. request the user to accept some settings then input a PIN which is received via SMS) and it would introduce a lot of corner-cases in the SMS app. So some sort of dedicated app is preferred and if we can "surface" them somehow for later retrieval by the user without "polluting" the SMS app I'd be really happy.
Whiteboard: [priority]
(In reply to Julien Wajsberg [:julienw] (away June 21 to 30) from comment #3)
> Beatriz or reporter, can you please light up what's the specific
> certification requirement here?

Sorry for my late feedback here, after running several certifications in 1.3 builds, this issue had not been raised from our side. I guess the reporter can provide more detail info.
Flags: needinfo?(brg)
We need some UX decisions on this bug so let me describe the problem we're having:

Currently the WAP Push app spends most of its time hidden. When a new message is received it posts a notification. Tapping it dismisses the notification and shows the message. If the message is closed or we tap the home button (which hides the application) the app is closed and thus the message is not accessible anymore to the user. In some situations this is quite problematic as the user has no way to go back to the message.

In bug 1022552 we're experimenting with an approach for content provisioning messages that I'd like to apply to all messages: the notification is not dismissed when tapped but only when the message is explicitly closed by tapping the 'X' button. Going back to the homescreen from the message doesn't dismiss the notification either solving the problem of having to switch between applications (for copying a PIN number for example).

Does this sound like a sensible choice? It would help us close this bug with relative ease.
Flags: needinfo?(firefoxos-ux-bugzilla)
If this is in Wilfred's backlog, then this work will be designed as part of 2.1. We can take the suggestions here into consideration during that work, since this was not part of 2.0. 

Wilfred, please let me know if that's the correct approach. Thanks!
Flags: needinfo?(firefoxos-ux-bugzilla)
Garbiele,

Would it be possible for the Push/Configuration messages to "live" in the SMS app alongside the normal MMS/SMS threads? Perhaps they could be identified as non-standard messages by using their icon from the notifications tray (Configuration message had a cog/gear) left-aligned in the chat list.

I'd find the ability to archive and refer to received Configuration/Push messages very, very handy.

In the case of configuration messages and FFXOS' lack of "profiles" for Data/A-GPS/etc, it could be nice to keep the stock configurations around to restore, reference, or even refer to another who asks.

In the case of push messages, it could be nice to have them in case you got a push from 411 or another info service and you'd like to refer to that info at a later time/date.

I sincerely hope this integrated approach is possible as it feels to me more natural and intuitive than having the Push/Configuration messages only be notifications that have no permanency or ability to be referenced more than once. Seems like a very arbitrary and odd limitation to place upon them.

I must once again defer to the mighty dumbphone platform that allowed for Configration/Push messages to be resident in the Messages app for however long the user wanted. That was a feature I grew rather fond of.
I'm rather against putting everything in one app. But having an app with a similar UI (heck, we can share most of it) to find old messages could be nice.
(In reply to Julien Wajsberg [:julienw] from comment #13)
> I'm rather against putting everything in one app. But having an app with a
> similar UI (heck, we can share most of it) to find old messages could be
> nice.

You mean adding a permanent UI to the WAP Push app similar to the SMS one? I have been experimenting with storing messages in the SMS app and it's really not that complicated as the WAP Push functionality tends to be fairly self contained.
I think that UX-wise it's not good: how do you find them back? Do we need a search functionality for this? Do we need categories? Should we have all in one thread, but in that case we need to forbid the composer.

In the end, it's a UX question.
(In reply to Julien Wajsberg [:julienw] from comment #15)
> I think that UX-wise it's not good: how do you find them back? Do we need a
> search functionality for this? Do we need categories? Should we have all in
> one thread, but in that case we need to forbid the composer.
> 
> In the end, it's a UX question.

Good point, if you receive a configuration message the first time you have inserted a SIM in the phone it might have happened 2-3 years back and then the configuration message would be at the bottom of the SMS conversations. Impossible to find unless you remembered it was there in the first place.
(In reply to Gabriele Svelto [:gsvelto] from comment #16)
> (In reply to Julien Wajsberg [:julienw] from comment #15)
> > I think that UX-wise it's not good: how do you find them back? Do we need a
> > search functionality for this? Do we need categories? Should we have all in
> > one thread, but in that case we need to forbid the composer.
> > 
> > In the end, it's a UX question.
> 
> Good point, if you receive a configuration message the first time you have
> inserted a SIM in the phone it might have happened 2-3 years back and then
> the configuration message would be at the bottom of the SMS conversations.
> Impossible to find unless you remembered it was there in the first place.

Again, look to the venerable dumbphone platform. Why not have two stages to the Messages app? One for message threads, and one stage for "system" messages, wherein Configuration & Push messages would reside.
On my dumbphones, the message app had multiple stages. 

You could toggle stages by swiping the page left/right or perhaps tapping a collapsed header to expose the other stage. You could even make the Messages header text a drop-down that would toggle the stage between Message threads and the "system messages" thread. There are a multitude of ways to go about providing this functionality :)

I seriously doubt anyone can look me straight in the eyes and say that the current method of having transient Configuration/Push messages that can never be recalled is an example of good UX.
(In reply to Brett Edmond Carlock from comment #17)
> (In reply to Gabriele Svelto [:gsvelto] from comment #16)
> > (In reply to Julien Wajsberg [:julienw] from comment #15)
> > > I think that UX-wise it's not good: how do you find them back? Do we need a
> > > search functionality for this? Do we need categories? Should we have all in
> > > one thread, but in that case we need to forbid the composer.
> > > 
> > > In the end, it's a UX question.
> > 
> > Good point, if you receive a configuration message the first time you have
> > inserted a SIM in the phone it might have happened 2-3 years back and then
> > the configuration message would be at the bottom of the SMS conversations.
> > Impossible to find unless you remembered it was there in the first place.
> 
> Again, look to the venerable dumbphone platform. Why not have two stages to
> the Messages app? One for message threads, and one stage for "system"
> messages, wherein Configuration & Push messages would reside.
> On my dumbphones, the message app had multiple stages.

How is that different than 2 or 3 different apps, one for each message types?
That's all I'm saying.


> I seriously doubt anyone can look me straight in the eyes and say that the
> current method of having transient Configuration/Push messages that can
> never be recalled is an example of good UX.

I think these type of messages are meant to be transient. That does not mean they should.
(In reply to Julien Wajsberg [:julienw] from comment #18)
> How is that different than 2 or 3 different apps, one for each message types?
> That's all I'm saying.
Because you're proposing the app-centric approach which invariably leads to the user having to tap around more than taking the task/service-centric approach where you integrate like tasks/services into a single "app" and populate the app with data from those services. The task/service-centric approach means consistent UI, less tapping around.


> I think these type of messages are meant to be transient. That does not mean
> they should.
I feel like that second sentence got truncated. Does not mean they should.... ?

Surely, I agree that their most common use case is transient (insert new SIM, apply profile). But as I stated above, being able to reference this info without having to put it into a note can be good for someone who say, builds/flashes daily (like me). Push messages from services like 411 can oftentimes be good to look back upon as well.

I'm not suggesting that Push/Configuration messages get as much UI space as regular message threads. That would be absurd as they're (like you've mentioned), not commonly used and commonly, used only for a few moments. I think that they should just be able to be recalled and reviewed at will by the user, ideally in the Messages app.

There must be a workable solution :)
(In reply to Brett Edmond Carlock from comment #19)
> There must be a workable solution :)

Yes, and we seem to need better UX in general. I'll raise the issue today during our standup and then try and CC some further people here to try and move this forward somehow, someway.
(In reply to Brett Edmond Carlock from comment #19)
> (In reply to Julien Wajsberg [:julienw] from comment #18)
> > How is that different than 2 or 3 different apps, one for each message types?
> > That's all I'm saying.
> Because you're proposing the app-centric approach which invariably leads to
> the user having to tap around more than taking the task/service-centric
> approach where you integrate like tasks/services into a single "app" and
> populate the app with data from those services. The task/service-centric
> approach means consistent UI, less tapping around.

It makes sense for data you want to always keep around. I'll assume (because UX is a lot of assumptions :) ) that Wap Push or Push data are not looked for often. Therefore, ok, it's maybe nice to have them available _somewhere_, but I don't think having them handy in the Messages app is the right place.

> 
> 
> > I think these type of messages are meant to be transient. That does not mean
> > they should.
> I feel like that second sentence got truncated. Does not mean they
> should.... ?

It was on purpose ("be transient" was implied) but maybe I should have added at least "be" :) I meant: That does not mean they should _be transient_. So like you said.

In the end, I think this will be discussed by our UX people. We'll make sure your point will be heard.
Raising this bug once again in the hope we can move it forward. First a quick summary of the issue here:

- The WAP Push app was meant to display messages only, not to store them for future use. As such it's opened when the user taps on a notification and automatically closed as soon as the user dismisses it (going back to the homescreen is enough for this).

- Some messages (content provisioning with authentication) require some interaction. One scenario we had was that the WAP Push message contained a PIN input and the PIN would be delivered via SMS. This meant we had to prevent the WAP Push app from being automatically closed in this scenario to allow the user to go to the SMS app, read the PIN and then come back to input it. See bug 1022552.

- That being said the flow is not very natural as once you've left the WAP Push app the only way to bring it up again is via the cards-view. If the user doesn't know of its existence (something not uncommon among in non-tech-savvy users) there's no other easily way to go back to the WAP Push app as it is hidden and doesn't have any other way to launch it.

- Finally there's some scenarios when messages being entirely transient is not very desirable, see comment 12 about storing configuration messages for future use.

The issues caused by the transient nature of the WAP Push app have been biting us left and right in the past few months (see bug 966405 for instance besides this bug) and I'd like to hear a clear answer as to how to move forward. In my eyes we've got three ways to proceed:

1) Move the WAP Push functionality into the SMS app. This is similar to how WAP Push works in feature phone OSes and has both significant advantages and disadvantages: on the one hand it would make messages easily discoverable and would allow the user to keep them around, it would also be familiar to feature phone users; on the other hand we would have to move all the WAP Push UX flows into the SMS app which would increase its complexity significantly, we'd also have another database to store messages and code to load possibly slowing it down. All in all the change would be fairly complex to get right from both a correctness and performance POV. I think it's doable but I'm not very fond of it.

2) Make the WAP Push app somewhat easier to access. One possibility is to leave the notifications in the tray for messages that haven't been explicitly closed (i.e. the user only dismissed them by going into another app or the homescreen). This is an easy change and we already do it for content provisioning messages but it could clutter the notification tray if the user doesn't realize he explicitly needs to close the message to get rid of the notification.

3) Leave things as is. I think this is also possible but would require some talks with our partners about what they expect from the app and some research among users to ensure that we're not missing important scenarios (again, comment 12 is relevant, on my old Nokia keeping the configuration messages around was simple and we've been targeting feature phones users since day one so putting them in a familiar environment is important IMHO).
Flags: needinfo?(wmathanaraj)
Perhaps we can combine CBS and Wap Push messages into one app? will add to backlog for us to think for coming releases.
Flags: needinfo?(wmathanaraj)
blocking-b2g: backlog → 2.2?
Message box is important to user.
NI product owner.

I don't think we have the resources for this for v2.2.
Flags: needinfo?(wmathanaraj)
I'm afraid I have to change the nomination from blocking-b2g to feature-b2g because this is clearly a "feature", not a "defect".
Keeping Wilfred's needinfo to prioritize.
blocking-b2g: 2.2? → backlog
feature-b2g: --- → 2.2?
I have read the protocol WAP-167,and I found that a way to store messages is very necessary for wappush app. In section 6.3, for SI message with “signal-low” action,
>The SI MUST be postponed without user intervention (see section 6.3.1for information about postponing SIs).
And in section 6.3.1, it says:
>When an SI is postponed, it is stored in the client for later handling. Since the possibility to 
>postpone several SIs exists, the client MUST provide the end-user with a means to act upon them at a 
>later time. How this is accomplished is implementation dependent, but it is RECOMMENDED that the user 
>can make selections based on the text specified in the indication element. The end-user SHOULD also be 
>given the possibility to delete any postponed SI by means provided by the client.
>
>A client MUST be able to maintain an implementation dependent number of postponed SIs. The number MUST 
>be greater or equal to one, but a value below ten is NOT RECOMMENDED. A RECOMMENDED minimum storage 
>space for each of these SIs is 500 octets. It is implementation dependent how a client handles an SI 
>that is about to be postponed, when this causes the maximum number of postponed SIs to be exceeded.
[Tracking Requested - why for this release]:
not in 2.2 must-have scope.
feature-b2g: 2.2? → ---
tracking-b2g: --- → ?
blocking-b2g: backlog → ---
Flags: needinfo?(wmathanaraj)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.