1207094 - [Messages] Disable appropriate controls when in low storage condition

Status: RESOLVED WONTFIX

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

Description

[Julien Wajsberg [:julienw]]

See spec in blocking bug.

Comment 1

[Steve Chung [:steveck]]

Hi Julien,
I'm think that whether we should implement this device storage into service(shim) or just normal helper. It might be more directly if we go for service/shim, but it will need event handling mechanism in the Bug 1201016 when we receive the storage change event. Here are some thoughts:
 - land the event handling part in this patch(If you feel the solution in Bug 1201016 is fine)
 - Ignore the storage change event in this sprint and solve this in next sprint
 - Use normal helper structure and refactor after branching

Comment 2

[Julien Wajsberg [:julienw]]

Solution 1: I think you'd only need the change in [1], not the whole patch?
Also I wonder, if we don't use a Shared Worker but do a direct shim (in iframe) -> view communication for this, we may even not need [1]?

Solution 2: I think it's better to solve this now, unless this takes too much time. But I feel we have enough time.

Solution 3: This could work for me too, if solution 1 takes too much time.

[1] https://github.com/mozilla-b2g/gaia/pull/31800/files#diff-13668e689eb8efc7825c419c754ea55e

Comment 3

[Steve Chung [:steveck]]

(In reply to Julien Wajsberg [:julienw] (PTO Sept 23rd) from comment #2)
> Solution 1: I think you'd only need the change in [1], not the whole patch?
> Also I wonder, if we don't use a Shared Worker but do a direct shim (in
> iframe) -> view communication for this, we may even not need [1]?
> 
> [1]
> https://github.com/mozilla-b2g/gaia/pull/31800/files#diff-
> 13668e689eb8efc7825c419c754ea55e

It's not related to the Shared Worker, it's about the bridge's event broadcasting and all the instances will get the event. The way to avoid receiving duplicated event firing from different instance is by instance id, or we don't follow the bridge structure at all.

Comment 4

[Julien Wajsberg [:julienw]]

But if the client listen to the specific iframe, then it's not broaddcasted everywhere, right ?

But anyway I don't mind landing only the change in [1].

Comment 5

[GitHub Autolander Bot]

Attachment: [gaia] steveck-chung:message-low-storage > mozilla-b2g:master

Comment 6

[Steve Chung [:steveck]]

Hi Katie,

I have some questions about the spec[1]:
- In the spec the option menu about the message in page 11/12 was marked as out of scope, it that means we don need to handle the message option for low storage in 2.5?
- If we create a new message(non-threaded) draft before low storage, the conversation will exist in the inbox and user can still enter the compose view even in low storage case. Should we block the recipient editing(and show low storage dialog) as well?
- If we don't have any conclusion in bug 891344 comment 57, it would be possible to share the media from other apps even in low storage. Do we need to do anything to prevent the media sharing like discard the draft or force return to caller app directly? 

[1] https://mozilla.app.box.com/s/bfrwwxdaz1o646h8tmmnlq61lv92sy3f

Comment 7

[Steve Chung [:steveck]]

Comment on attachment 8668863 [details] [review]
[gaia] steveck-chung:message-low-storage > mozilla-b2g:master

Hey folks,
I create a WIP about the low storage disabling prototype without unit tests. I haven't tested with real low storage case on device, only tested with hard-coded client return. I think it's not perfect and left some thoughts in the github. Please let me know if you have any other idea about the prototype, thanks!

Comment 8

[katieC]

Hey Steve. Good questions. 

> - In the spec the option menu about the message in page 11/12 was marked as
> out of scope, it that means we don need to handle the message option for low
> storage in 2.5?
Disabling action menu items isn't a current ux pattern and apparently does not exist elsewhere in the os. I'll try to dig into that on Monday by connecting with the UX frameworks team (leaving my NI).

> - If we create a new message(non-threaded) draft before low storage, the
> conversation will exist in the inbox and user can still enter the compose
> view even in low storage case. Should we block the recipient editing(and
> show low storage dialog) as well?

Yes... Let's keep it simple, no editing draft messages, they are read-only. If user taps to edit the recipient list or the message, present the user with the Low Storage Notice dialogue. Let the user navigate back to the inbox easily by tapping the '<' back button in the header, as no changes have been made.

> - If we don't have any conclusion in bug 891344 comment 57, it would be
> possible to share the media from other apps even in low storage. Do we need
> to do anything to prevent the media sharing like discard the draft or force
> return to caller app directly? 

Another good question. Can you explain what you mean by 'force return to caller app directly'?

We definitely want to prevent user frustration during a media sharing activity, however for 2.5, my understanding is, addressing how the Share Activity works in a low storage condition (ex: do we disable/hide sharing to Messages or Email App) is not in scope. That said, we should address this less than ideal user experience as best we can given what we know. So, can we do this:

1. ex: User taps Share icon while in Gallery, looking at image 001.jpg
2. Action Menu displays 'Share to' list, ex: Bluetooth, Email, Messages, Wallpaper
3. User taps Messages
4. Open Messages App or navigate to already open Messages App
5. Display Low Storage Notice dialogue
6. User taps "Ok"
7. Dismiss dialogue
  • if Messages App was launched (wasn't already open when user tapped Messages from share menu), quit & close Messages App. Go back to Gallery App, image 001.jpg
  • If Messages App was already open, slide back to Gallery App, image 001.jpg

Comment 9

[Steve Chung [:steveck]]

(In reply to katieC from comment #8)

> Another good question. Can you explain what you mean by 'force return to
> caller app directly'?

I think the flow you provided below is exactly what I mean to force return, just display the dialog and return the gallery app without giving any chance to let user able to compose the message.

> 
> We definitely want to prevent user frustration during a media sharing
> activity, however for 2.5, my understanding is, addressing how the Share
> Activity works in a low storage condition (ex: do we disable/hide sharing to
> Messages or Email App) is not in scope. That said, we should address this
> less than ideal user experience as best we can given what we know. So, can
> we do this:
> 
> 1. ex: User taps Share icon while in Gallery, looking at image 001.jpg
> 2. Action Menu displays 'Share to' list, ex: Bluetooth, Email, Messages,
> Wallpaper
> 3. User taps Messages
> 4. Open Messages App or navigate to already open Messages App
> 5. Display Low Storage Notice dialogue
> 6. User taps "Ok"
> 7. Dismiss dialogue
>   • if Messages App was launched (wasn't already open when user tapped
> Messages from share menu), quit & close Messages App. Go back to Gallery
> App, image 001.jpg
>   • If Messages App was already open, slide back to Gallery App, image
> 001.jpg

About the 7, just a reminder that the message app opened by gallery would be another instance than original message app, so it will no affect the original gallery app.

Comment 10

[katieC]

Hey Steve,

> About the 7, just a reminder that the message app opened by gallery would be another instance than
> original message app, so it will no affect the original gallery app.

This confuses me - you're saying there would be 2 different instances of Messages App? I'm adding a Share Activity page to the spec, I just want to make sure I understand the flow.

Small update - I've requested a UX Frameworks review of the new pattern: disable action menu items when in low storage condition (spec pages 11 & 12). They meet tomorrow (5:30pm Pacific). They'll discuss the request and let me know. I'll post any update here and in the specs. Thank you for your patience. :)

Comment 11

[Steve Chung [:steveck]]

(In reply to katieC from comment #10)
> Hey Steve,
> 
> > About the 7, just a reminder that the message app opened by gallery would be another instance than
> > original message app, so it will no affect the original gallery app.
> 
> This confuses me - you're saying there would be 2 different instances of
> Messages App? I'm adding a Share Activity page to the spec, I just want to
> make sure I understand the flow.
> 
Sorry about the unclear comment, I mean the the case when message app is opened and sharing media via other app - The message compose panel opened for sharing is actually another new message instance instead of reusing the opened message app. We still need to close the new message panel to quit sharing, and it will not affect the original opened message app.

Comment 12

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8668863 [details] [review]
[gaia] steveck-chung:message-low-storage > mozilla-b2g:master

General idea looks good to me! I've left few questions and nits at GitHub.

Thanks!

Comment 13

[Steve Chung [:steveck]]

Comment on attachment 8668863 [details] [review]
[gaia] steveck-chung:message-low-storage > mozilla-b2g:master

Cancel the request since it's not the top priority now.

Comment 14

[katieC]

Hey Steve,
This is just an FYI, as this feature isn't a 2.5 priority, but the ux spec was been updated after hearing back from the UX Frameworks team. Specific change to Messages App recommendation, is to disable the "..." options menu when in a Critically Low Storage condition (less than 5Mb) - as disabling items in an action menu is not an existing pattern (refer to comment 6 and 8).
Thanks!

Comment 15

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 16

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(