Dogfood Diary: 'Notifications'

[Wilson Page]

Notifications are still quite simple on our platform, notably:

LED

We don't seem to take advantage of the notification LED which seems to have become a standard on other mobile OSs. If you miss the initial notification and you phone is locked, you have to waken/unlock your phone to periodically check. I feel people considering the move to FxOS would miss this.

PER NOTIFICATION CONFIGURATION

There isn't currently a way for apps to take control over the alert tone, vibration on/off/pattern or (as above) LED color. One of the things I really liked about WhatApp/Telegram on Android is that I can choose the type of notification I receive from each of my groups/contacts. For busy groups I don't want my phone to vibrate/sound, but for one-on-one conversations, I do. AFAIK the FxOS platform doesn't offer developers this kind of control over a notification when it is created.

VIBRATION PATTERNS

I also noticed on Android that different apps have different vibration patterns. This means that when I feel the vibration in my pocket, I can (if familiar) tell which app wants my attention.

---

Is this something we should be talking about?

WILSON PAGE

Front-end Developer
Firefox OS (Gaia)
London Office

Twitter: @wilsonpage
IRC: wilsonpage

[Gabriela Montagu]

I think it would be great to have the notification repeating till you unlock and read the text message or notice the lost call.

As it is, notifications sound only once. If I miss them, no way of knowing I received a SMS. The only way to avoid missing notifications is to live with the cell close to me all the time, something I don't want to do. That´s why I would really welcome notifications repeating till unlock and read.

Best regards,
Gabriela
QA Mozilla Hispano Team Responsible


http://www.mozilla-hispano.org
http://twitter.com/mozilla_hispano
http://facebook.com/mozillahispano

_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Julien Wajsberg]

Le 03/11/2014 13:23, Wilson Page a écrit :

Notifications are still quite simple on our platform, notably:

LED

We don't seem to take advantage of the notification LED which seems to have become a standard on other mobile OSs. If you miss the initial notification and you phone is locked, you have to waken/unlock your phone to periodically check. I feel people considering the move to FxOS would miss this.

FWIW I'd really _really_ want this.

[Alexandre Lissy]

https://bugzilla.mozilla.org/show_bug.cgi?id=1065404

I had no time to hack on it since.

[Sam Foster]

I gather we are considering(?) adding LED to the platform - am I the only one a bit uncomfortable naming a core platform API after a somewhat arbitrary hardware implementation detail? Today we have an LED on the device that can be on/off and sometimes its an rgb led so we can vary its color. But maybe in a year or more it will be an OLED, or some other light source. Ultimately I assume it maps to an i/o pin and you could hook up anything at all - another vibration motor, a bubblino, an odor emitter. What is meaningful is not that its an LED, but that its function is to alert or notify. We dont have an api for the specific on-device storage mechanism, we have Storage. Maybe I'm overthinking it but this seems a case of "2014 phone platform", not web platform.

/Sam

----- Original Message -----
From: "Julien Wajsberg" <jwaj...@mozilla.com>
To: "Wilson Page" <wilso...@mozilla.com>, "mozilla-...@lists.mozilla.org" <dev-...@lists.mozilla.org>
Sent: Monday, November 3, 2014 5:37:43 AM
Subject: Re: Dogfood Diary: 'Notifications'

Le 03/11/2014 13:23, Wilson Page a écrit :



Notifications are still quite simple on our platform, notably:

LED

We don't seem to take advantage of the notification LED which seems to have become a standard on other mobile OSs. If you miss the initial notification and you phone is locked, you have to waken/unlock your phone to periodically check. I feel people considering the move to FxOS would miss this.


FWIW I'd really _really_ want this.

[Michael Henretty]

----- Original Message -----
From: "Wilson Page" <wilso...@mozilla.com>
> PER NOTIFICATION CONFIGURATION
>
> There isn't currently a way for apps to take control over the alert tone, vibration on/off/pattern or (as above) LED color. One of the things I really liked about WhatApp/Telegram on Android is that I can choose the type of notification I receive from each of my groups/contacts. For busy groups I don't want my phone to vibrate/sound, but for one-on-one conversations, I do. AFAIK the FxOS platform doesn't offer developers this kind of control over a notification when it is created.
>
> VIBRATION PATTERNS
>
> I also noticed on Android that different apps have different vibration patterns. This means that when I feel the vibration in my pocket, I can (if familiar) tell which app wants my attention.
>

> Is this something we should be talking about?

Thanks for bringing this up Wilson. James Burke raised a bug concerning this about a year ago [1] and we have indeed been discussing this in the WHATWG [2][3]. Currently apps are able to control: vibration pattern, alert tone, whether or not the notification wakes the screen, and whether or not the "Clear all" button closes the notification in question [4][5]. However the user has no way to configure this on a per-app basis yet, and I think that would be a useful discussion to have.

Please also keep in mind that we have moved ahead of WHATWG here and these are experimental features. So in addition to giving more control to the user, we should also discuss what other behaviors should be configurable. LED (or whatever name we land on) seems to be the next target, but some other things that have been discussed are:

silent:
- Don't play sound or vibrate the phone. Possible use case, missed call notification, CMAS.

noList/transient:
- Fire this notification in the toaster only, but don't display it in the tray. Possible use case, chat program (eg. Skype) user just came online notification.

targetTime:
- Specify a datetime for when this notification applies. Possible use case, calendar reminders where the time in the tray can say "5 minutes from now" etc. Currently, the time in the tray only applies to when the notification was actually fired, which is confusing for calendar reminders.

squash:
- When replacing a notification, don't notify the user (through sound/vibration/toaster). Possible use case, email notifications which already get squashed could be configured to not annoy the user by constantly playing sounds/vibrating every time someone replies to a thread.

More ideas welcome!

Thanks,
Michael


1.) https://bugzilla.mozilla.org/show_bug.cgi?id=912645
2.) https://github.com/whatwg/notifications/issues/22
3.) http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0065.html
4.) https://mxr.mozilla.org/mozilla-central/source/dom/webidl/Notification.webidl#72
5.) https://bugzilla.mozilla.org/show_bug.cgi?id=1066385

[Dietrich Ayala]

I'll leave it for Fabrice to elaborate, but after talking to Alexandre
earlier this week, it sounds like this concern is exactly why there's
been some delay in moving forward with the patch in that bug.

On Mon, Nov 3, 2014 at 5:57 PM, Sam Foster <sfo...@mozilla.com> wrote:
> I gather we are considering(?) adding LED to the platform - am I the only one a bit uncomfortable naming a core platform API after a somewhat arbitrary hardware implementation detail? Today we have an LED on the device that can be on/off and sometimes its an rgb led so we can vary its color. But maybe in a year or more it will be an OLED, or some other light source. Ultimately I assume it maps to an i/o pin and you could hook up anything at all - another vibration motor, a bubblino, an odor emitter. What is meaningful is not that its an LED, but that its function is to alert or notify. We dont have an api for the specific on-device storage mechanism, we have Storage. Maybe I'm overthinking it but this seems a case of "2014 phone platform", not web platform.
>
> /Sam
>

[Fabrice Desré]

On 11/03/2014 09:03 PM, Dietrich Ayala wrote:
> I'll leave it for Fabrice to elaborate, but after talking to Alexandre
> earlier this week, it sounds like this concern is exactly why there's
> been some delay in moving forward with the patch in that bug.

That's correct. It was easy to quickly put together something that
reflected the HAL api, but it's much harder to do something we like ;)
Jonas posted a proposal, we need to revisit it.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Rob MacDonald]

This is a great thread and these are definitely features I’d like to advocate on behalf of UX as well. Treating all notifications the same makes it impossible for users to assess the nature, urgency and source of the alert. And users who receive notifications frequently will tune them out or, worse, turn them off.

In addition to the alert types, we should also consider the content and format of the notifications themselves. For example, do we want to allow additional interactions within notifications? What about notification grouping? How do we update existing notifications? Or how about hiding message details on the lock screen?

I realize this isn’t part of the planned 2.2 scope, but I’d really like to get started on some design proposals once the planned features are spec’d out. In the meantime, as Michael suggested, keep the suggestions coming. When we’re ready, ux can work with engineering and product to review and prioritize the list, then spec out proposals for upcoming releases.

Thanks!
Rob

On Nov 3, 2014, at 12:29 PM, Michael Henretty <mhen...@mozilla.com> wrote:

> ----- Original Message -----

[Wilson Page]

Rob, great input, thanks! It's interesting to see how other mobile OSs are packing more and more interactivity into the notification tray. Apps are able to add UI within notifications to enable user to take action without even having to open the app. I recently read an article ('The end of apps as we know them' [1]) that goes into detail about the notification tray becoming the primary area of interaction, it's worth a read/skim.

Grouping is also an interesting point. If a contact sends me 10 messages, should we display 10 notifications, or instead: '10 new messages from <name>'? I'm not sure if we have the APIs in place to achieve this yet. If we want our OS to be competitive in this area in a year's time, we need to be having theses conversations now.

[1] http://blog.intercom.io/the-end-of-apps-as-we-know-them/

WILSON PAGE

Front-end Developer
Firefox OS (Gaia)
London Office

Twitter: @wilsonpage
IRC: wilsonpage

---

From: "Rob MacDonald" <rmacd...@mozilla.com>
To: "Michael Henretty" <mhen...@mozilla.com>
Cc: "Wilson Page" <wilso...@mozilla.com>, "mozilla-...@lists.mozilla.org" <dev-...@lists.mozilla.org>, "Robert Bindar" <robert...@gmail.com>
Sent: Tuesday, November 4, 2014 7:32:46 AM

Subject: Re: Dogfood Diary: 'Notifications'

[Julien Wajsberg]

Le 04/11/2014 11:46, Wilson Page a écrit :

Rob, great input, thanks! It's interesting to see how other mobile OSs are packing more and more interactivity into the notification tray. Apps are able to add UI within notifications to enable user to take action without even having to open the app. I recently read an article ('The end of apps as we know them' [1]) that goes into detail about the notification tray becoming the primary area of interaction, it's worth a read/skim.

Grouping is also an interesting point. If a contact sends me 10 messages, should we display 10 notifications, or instead: '10 new messages from <name>'? I'm not sure if we have the APIs in place to achieve this yet. If we want our OS to be competitive in this area in a year's time, we need to be having theses conversations now.

Yes we can :) there is even a bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1082546
The current behavior is "1 notification per thread", but the notification contains the text for the latest message. This bug will change this into "n new messages" instead.

I discussed about a generic grouping functionality in https://bugzilla.mozilla.org/show_bug.cgi?id=989182 but Robert thought that different apps might have different needs.

[Zibi Braniecki]

It's also an area of my team's interest because Notifications API is currently rooted in the old paradigm of sending synchronous strings from the app to the system. It makes it impossible for l10n to update the strings, retranslate on language change or do any other updates.

As we're thinking about modern Notifications API, I'd like us to consider introducing ways for an app to provide notification's DOM *and* to update it's entry.

One way I thought about it would be for a Notification API to return a UUID that an App can use to update the entry. There could also be a way for an app to get all UUID's of notifications currently displayed that came from this app (even before it has been restarted).

This way an app can combine multiple entries, update translations and even adjust to the context:
- If facebook user went offline, then maybe his message is less urgent now
- If enough time passed, then your reminder about the meeting is becoming less urgent as well
- "You should leave for your flight" should gain urgency and then loose it
- "Fedex reported it couldn't deliver a package" could loose urgency
- "You have 3 missed calls and two text messages from Jannie"
- "49ers - Seahawks starts in 20 min"

All those messages could be adjusted by the app if it's launched, or by a background service of that app (once we have those).

zb.

[Julien Wajsberg]

I think the Notification API already provides all this.

However, I don't see how we could update a notification if the app is
closed.

--
Julien

[Michael Henretty]

Correct, the notification API does allow you to fetch notifications on a per app basis. And while it does not provide the UUID back to apps/content, it does allow apps to specify a "tag" which is a unique id and can be used to replace existing notifications. The only thing that is missing then, from the l10n perspective, is a system message to tell the apps that the language has been changed. It would then be up to the apps, upon receiving the language-changed message, to resend their existing notifications with the updated translations. It's probably a relatively straightforward change, but no small amount of work.

[Zibi Braniecki]

On Tuesday, November 4, 2014 2:20:02 PM UTC-8, Michael Henretty wrote:
> Correct, the notification API does allow you to fetch notifications on a per app basis. And while it does not provide the UUID back to apps/content, it does allow apps to specify a "tag" which is a unique id and can be used to replace existing notifications. The only thing that is missing then, from the l10n perspective, is a system message to tell the apps that the language has been changed. It would then be up to the apps, upon receiving the language-changed message, to resend their existing notifications with the updated translations. It's probably a relatively straightforward change, but no small amount of work.

Yeah, after seeing Julien's response I reread the spec and added some L10n wrapper for Notifications API to my teams goals. It should be fairly straightforward.

Sorry for the noise, I should come better prepared to the conversation :)

zb.

[Julien Wajsberg]

Le 04/11/2014 23:19, Michael Henretty a écrit :
> ----- Original Message -----
> From: "Julien Wajsberg" <jwaj...@mozilla.com>
> Le 04/11/2014 19:37, Zibi Braniecki a écrit :
>>> [snip]
>> I think the Notification API already provides all this.
>>
>> However, I don't see how we could update a notification if the app is
>> closed.

> Correct, the notification API does allow you to fetch notifications on a per app basis. And while it does not provide the UUID back to apps/content, it does allow apps to specify a "tag" which is a unique id and can be used to replace existing notifications. The only thing that is missing then, from the l10n perspective, is a system message to tell the apps that the language has been changed. It would then be up to the apps, upon receiving the language-changed message, to resend their existing notifications with the updated translations. It's probably a relatively straightforward change, but no small amount of work.

Do we really want to launch all applications that have an active
notifications when we change the language? Isn't it a little bit
expensive performance-wise and memory-wise ?

[Michael Henretty]

I imagine in most cases it would only be 1 or 2 apps with active notifications, and there is a decent chance the apps would already be running in the background. Also, how often does one change languages? In any case, since the l10n strings are only accessible by the originating app I don't see much way around it.

[Zibi Braniecki]

On Wednesday, November 5, 2014 12:59:48 AM UTC-8, Julien Wajsberg wrote:

> Do we really want to launch all applications that have an active
> notifications when we change the language? Isn't it a little bit
> expensive performance-wise and memory-wise ?

I don't think we do.

My understanding is that if the app is running it should be able to update its notification (and l10n should provide an API to handle language changes).

If the apps wants to maintain ability to update notifications it has to find a way to keep running (in background for example - like android apps do).

So, my plan is just to wrap Notification API, so that developers can pass l10nIds instead of resolved strings, but that's all :)

zb.

[Michael Henretty]

----- Original Message -----
From: "Zibi Braniecki" <zbigniew....@gmail.com>
> So, my plan is just to wrap Notification API, so that developers can pass l10nIds instead of resolved strings, but that's all :)

Hmmm, so how does the system app resolve these strings when displaying them in the tray/toaster?

[Zibi Braniecki]

It does not, the client app submits the strings, it's just that the developer does not write:

`new Notification('my string', {body: 'my other string'});`

but:

`new L10nNotification('stringId', {body: 'stringId2'});`

We're aiming at removing use cases of mozL10n.get to move to fully asynchronous API. This is a fairly easy step in that direction.

Does it sound like a good idea to you?

zb.

[Julien Wajsberg]

Le 05/11/2014 19:27, Zibi Braniecki a écrit :
> On Wednesday, November 5, 2014 10:17:36 AM UTC-8, Michael Henretty wrote:

> It does not, the client app submits the strings, it's just that the developer does not write:
>
> `new Notification('my string', {body: 'my other string'});`
>
> but:
>
> `new L10nNotification('stringId', {body: 'stringId2'});`
>
> We're aiming at removing use cases of mozL10n.get to move to fully asynchronous API. This is a fairly easy step in that direction.
>
> Does it sound like a good idea to you?

And then you'd need a way to update it with the new locale (I can
imagine the l10nId and l10nArgs could be stuffed in the "data" object).