Talk a bit more about app vs. tab? #1
Comments
|
I think you're right. If we're going to have a badging API, we should be able to phase out favicon hacks with this. Though tabs require a bit more consideration than what I've got here. Some points:
I'll update the explainer to be less clear on this point. [Edit: Done; see "Possible areas for expansion".] |
|
Yay! Regarding per-tab badging, or some tabs not having a badge: although these ideas make sense in theory, in practice, surveying my current favicon/title-badged tabs, it seems like all tabs from the app would want the same badge. Right now they all synchronize using the back-end server. I guess maybe they'd want different badges, if the contents of the tab were not synced correctly? E.g. you have two mail windows open, one has an unread message list with 4 unread messages, the other has an unread message list with 5 unread messages. Should they be badged with 4 and 5, respectively? Or should they just be badged with a single value, and the fact that their contents are not synced with their badge is a temporary glitch. For the record, the tabs I'm considering that currently use favicon/title badges: IRCCloud, Twitter, Facebook Messenger, Google Chat, Google Hangouts, Gmail. |
|
You might also want different badges if you had different contexts in the same app. For example, (I don't use Slack so I'm not super sure how it works but...) Slack might have two completely different organizations which are open in different tabs, but share a service worker or origin. You might want to show individual unread counts for that tab's organization. |
Agree. I also run multiple gmails (marcos@marcosc and mcaceres@mozilla) in separate tabs. |
|
Could also be useful for text editors (with a this file hasn't been saved badge) and Github pull requests (they display the status of the PR in the favicon). That said, this is already possible through favicon hacks, maybe its worth providing a slightly more ergonomic API here instead of superseding it with this Badge API (which is going to have some pretty hard limitations because we have to conform with what's available on all supported platforms). Maybe <link rel="shortcut icon badge" href="/favicon.ico" badge="99">or something. As for badging different windows of apps in different ways, it'd be nice but I don't think there's really a way to display this on most platforms:
If we added a separate API for setting a per tab badge there'd be an opportunity for third party libraries to keep the badges in sync, if apps really want to do this. |
|
Wanted to throw in some information from Twitter's time playing around with this...we do do those old favicon and title hacks on our old site. But on the new version we do not, and we've heard some users complaining that they can't tell when new content or notifications are available on Twitter. We'd love for this API to affect favicon as well as the app icon. |
|
That's a nice suggestion, particularly for desktop. |
|
This is a bit more complicated than it seems, the new badging API is doing something kind of different to what was being done with favicon hacks. Favicons: One badge per instance of an app There are definitely some cases where it would be handy to treat badging both the same (e.g. Messenger.com) but in some cases they're distinct. As I say it, there seem to be two(ish) main ways forward with this:
<link rel="shortcut icon badge" href="/favicon.ico" badge="99">
Badge.set(99, { perInstance: true });I'm partial to option one, as they do seem to be two distinct things (if you wanted to use both together, it should be possible to make a JS library). It would also be much easier to support things like glyph icons (difficult with the existing badge API because different OS's support different sets of glyphs/not at all, and this could mean your icon will be displayed differently in different places). With the <link rel="shortcut icon badge" href="/favicon.ico" badge="🌧">And just specify that your character/number will be displayed in the bottom right corner of your page's tab icon. (and sorry about the slow reply, I've been travelling the last two weeks) |
|
@mgiuca @marcoscaceres and I had a bit of a talk about this offline. We're considering an API where urls are badged, as opposed to apps or tabs. When a url is badged, all urls in the url's scope are also badged. The most specific badge for a url is applied. If no scope is specified the origin should be badged.
Basic Examples // on https://site.com/index.html
// Sets the badge for https://site.com to be '5'. This will be applied to all urls on
// site.com which don't specify a badge.
Badge.set(5);
// Sets the badge for all tabs on https://site.com/index.html (and only that
// specific url) to be '7'.
Badge.set(7, { scope: '/index.html' });For installed applications, the most specific badge which includes the web-app's scope is applied. App Examples // In an installed application with the scope https://my.app/stuff/actual-app/
Badge.set(7); // Set's the OS specific badge to 7
Badge.set(6, { scope: '/stuff' }); // Updates OS specific badge to 6
Badge.set(5, { scope: '/stuff/actual-app/' }); // Updates OS specific badge to 5
Badge.set(4, { scope: '/stuff/actual-app/page' }); // Doesn't effect OS badge, badges tab favicon for page.
Badge.set(99, { scope: '/stuff' }); // Doesn't effect OS badge (it's still 5).Questions Badge.set(5);
Badge.set(10, { scope: '/index.html' });
Badge.clear({ scope: '/index.html' });
// What's the badge for index.html? Is it cleared? Or is it '5'?
// If its cleared, do we expect the same behavior for Badge.set(0, ...);
Badge.set(0, '/index.html);I think clearing is going to be fairly complicated, as in some scenarios, apps will want to defer back to a parent scope, while in others, they explicitly want to be cleared. @mgiuca @marcoscaceres any thoughts? |
|
This is a really interesting idea. I can imagine having Twitter tabs open
for notifications and DMs, with a different count on each.
It might be good to think about different colours of the badge so that
users don't have to remember which tab is which.
We also have users who monitor search result pages. They have several
searches and are interested in new results. We don't currently poll for
these but we might in the future. Those URLs would use query string params
for the search query, which would mean this badging solution wouldn't be
applicable. I imagine this would be a common use case. How would query
strings fit with this solution?
Thanks
Kenneth
…On Sun, 14 Jul 2019, 23:58 Jay Harris, ***@***.***> wrote:
@mgiuca <https://github.com/mgiuca> @marcoscaceres
<https://github.com/marcoscaceres> and I had a bit of a talk about this
offline.
We're considering an API where urls are badged, as opposed to apps or
tabs. When a url is badged, all urls in the url's scope
<https://www.w3.org/TR/appmanifest/#dom-webappmanifest-scope> are also
badged. The most specific badge for a url is applied. If no scope is
specified the origin should be badged.
Note we would either need to generalize the scope algorithm from the App
Manifest <https://www.w3.org/TR/appmanifest> or Service Worker
<https://www.w3.org/TR/service-workers-1/#service-worker-registration-scope>
specs or copy it into the spec for badging.
*Basic Examples*
// on https://site.com/index.html
// Sets the badge for https://site.com to be '5'. This will be applied to all urls on// site.com which don't specify a badge.Badge.set(5);
// Sets the badge for all tabs on https://site.com/index.html (and only that// specific url) to be '7'.Badge.set(7, { scope: '/index.html' });
For installed applications, the most specific badge which includes the
web-app's scope
<https://www.w3.org/TR/appmanifest/#dom-webappmanifest-scope> is applied.
*App Examples*
// In an installed application with the scope https://my.app/stuff/actual-app/Badge.set(7); // Set's the OS specific badge to 7Badge.set(6, { scope: '/stuff' }); // Updates OS specific badge to 6Badge.set(5, { scope: '/stuff/actual-app/' }); // Updates OS specific badge to 5Badge.set(4, { scope: '/stuff/actual-app/page' }); // Doesn't effect OS badge, badges tab favicon for page.Badge.set(99, { scope: '/stuff' }); // Doesn't effect OS badge (it's still 5).
*Questions*
Since we talked, I came up with some questions about clearing.
Badge.set(5);Badge.set(10, { scope: '/index.html' });Badge.clear({ scope: '/index.html' });
// What's the badge for index.html? Is it cleared? Or is it '5'?// If its cleared, do we expect the same behavior for Badge.set(0, ...);Badge.set(0, '/index.html);
I think clearing is going to be fairly complicated, as in some scenarios,
apps will want to defer back to a parent scope, while in others, they
explicitly want to be cleared.
@mgiuca <https://github.com/mgiuca> @marcoscaceres
<https://github.com/marcoscaceres> any thoughts?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABGGUDJNIN44TWNUI5OWCTP7QN25ANCNFSM4FILQ7BA>
.
|
|
Hmm, I could be convinced with regard to query strings (seems like it would be a pretty common scenario) but it would mean that Badging scope would work differently to scope in ServiceWorkers and AppManifests, which doesn't seem ideal. Moving to a url with a structure like Colours definitely sound like something we could add support for in future but it almost certainly won't be in the initial version of the API. Would you mind creating a separate issue for it, so we don't lose track of it? Something like this seems like it would make sense. Badge.set(7, {
scope: '/page',
color: 'red' // Valid values from css colors? https://www.w3.org/TR/2018/REC-css-color-3-20180619/#colorunits
}); |
|
Yeah, we probably want stick to the copying the scope behavior for SWs, otherwise things will get very confusing. If the SW one changes, the this one should change too. About the colors, I'm not sure... I guess it could work for tabs, but there is a potential for accessibility problems (or then people wanting to change the text color too). I'd be more inclined to not add anything like this yet, as it's more of a "nice to have" feature. If we can get interop just to show a badge number for an app, that would already be a big achievement. |
I think we should refrain from adding colors right now. No platform I know of would be happy with injecting random colours to the badge since they all have their own style (e.g., Android uses the average color of the icon). Other than that, this SGTM. If we use the Manifest scope matching algorithm (which only checks the path), you wouldn't be able to set different badges on a page with the same path but different query. I think this is probably fine --- if you have different badge status for different pages then I think those should have different paths in your URL scheme. Though I could be convinced otherwise. I don't think "monitoring search result pages" is a strong enough use case to have a badge. |
|
I'm starting to swing back towards "tab only" and we should explore all possible avenues for cross tab communication. When the page navigates, we need to reload the favicon regardless, so as part of that, the document could update the Badge indicator on DOMContentLoaded or service worker registration. If a page in another tab needs to update other tabs/windows, then could it use |
|
How would we distinguish between a badge to apply to the tab and a badge to apply to the app? |
|
Yeah whatever solution we come up with needs to allow for app icon badging (and not just the icon of an active window; also for the shelf icon of an app that currently doesn't have any windows open). That is Chrome's primary motivation for designing this API. We're happy to accommodate other use cases but we're not going to drop the app badging use case. |
|
There's a new explainer up which fully talks about app vs tab badging with equal weighting. Closing this now, but I've opened a follow-up issue #49 to discuss whether we want these to be a single unified API or two separate APIs. |
First of all, this is really cool!! I loved reading the proposal and seeing the care that went into coming up with something that was flexible and powerful, but also mapped to a wide variety of hosts.
One aspect that I found surprising was in the goals/non-goals section, about this being specifically an application-wide badge, instead of a per-tab badge. Partially this is because I have a lot of tabs today that implement their own badges using favicons or
<title>changes.Upon reflection, I think the restriction makes sense. (I can't think of any of the web apps I use which have different badge counts in different tabs; they all synchronize.) Still, it might be worth a dedicated section with a few paragraphs spelling out the problem space here and why being app-wide is the best solution.
I also would wonder if it's worth softening the non-goal
I think it'd be a bit of a shame for web developers if they had to continue using their favicon/
<title>tricks, in addition to this API, to give users a good experience when used in a tab. It seems like, if you applied the badging to all tabs under a given application, it would be a win for the user and web developer.If you're worried about collision with existing techniques, it could be opt-in, e.g.
set(x, { evenWhenNotInstalled: true }).This could greatly reduce the custom code web developers have to write to update their favicons/titles and synchronize across tabs.
The text was updated successfully, but these errors were encountered: