Manifest: short_names are too short: allow developers to specify multiple lengths?

[mgiuca]

While implementing manifest apps on Desktop platforms, we've noticed an unfortunate pattern in Manifests which is that the short_name field is set to something extremely short, presumably to fit in the very tiny space afforded by Android app shortcuts. Examples:

• Google Santa Tracker short_name is "Santa".
• Remember the Milk short_name is apparently "RTM".
  
  
  
  • According to @owencm in a meeting this morning. Is this a PWA? Or just an Android app. It doesn't seem to have a manifest.
  
  

I need to do a wider survey, but I'm worried we're going to end up with the short_name being excessively short for Desktop use cases (and we don't want to use the full name when we mention the app title in menus, for example, "Open link in $APPNAME").

A suggestion from Alan on my team was that we treat short_name like icons and allow multiple sizes, with the user agent being able to choose which size to use. A suggestion would be that short_name can optionally be a list of strings, with the semantics of being increasingly short versions of the app title. The user agent may use any of the short_name strings whenever it wants.

For example, Santa Tracker's short_name could be:

"short_name": ["Santa Tracker", "Santa"]

On Android, we might choose the shortest one, while on Desktop we might choose the longer one. This could be done dynamically based on how much space is available.

[marcoscaceres]

We might need a new member (e.g., “alt_names”) or it won’t be backwards compatible.

[mgiuca]

Take my emoji as "begrudging acknowledgement of hard truth".

[dominickng]

I'm not convinced that short names being too short are a problem worth adding a new manifest member (and the requisite parsing and additional complexity in the installation code). "RTM" is a really well-known abbreviation for "Remember the Milk"; other examples include "YNAB"; that's the name of the desktop app for "You Need A Budget".

In Santa Tracker's case, the name "Santa Tracker" is short enough to be unelided on a Nexus 5 and Pixel, but is elided on a Nexus 5X.

[mgiuca]

In Santa Tracker's case, the name "Santa Tracker" is short enough to be unelided on a Nexus 5 and Pixel, but is elided on a Nexus 5X.

I think the fact that it elides differently on different devices of the same operating system (not even "new" vs "old", but oscillating between versions) perfectly makes my case that the name should be chosen by the UA as appropriate, from a pool of developer-supplied names, rather than asking developers to supply a single "short name" (which is likely to be a name that can be seen without eliding on the developer's personal phone) and then eliding it if necessary.

Clearly, the developers of Santa Tracker would prefer "Santa Tracker" over "Santa" if it would fit, but prefer "Santa" over "Santa Track…" if it does not.

I'll acquiesce, though, as there are numerous technical hurdles:

• The backwards incompatibility of changing the short_name field (or needing to add a new member).
• The fact that on Android, at least with the WebAPK solution, we can't dynamically scale the app name based on the font size and available space, since it has to be set in the APK.

So, closing for now. #sad

[marcoscaceres]

Remember that name(s) are not just used for display, but also for searching.

My banking app is called "goMoney AU"... but I can find it by searching for "anz", "bank", etc. In the AppStore, it's name is "ANZ goMoney Australia". So, there might still be value to having alternative_names

[marcoscaceres]

s/for searching/for searching at OS level... like with Spotlight in MacOS and iOS.

[mgiuca]

Maybe, but I am also wary of enabling keyword stuffing on fields that are processed by search indexes but not normally seen by humans. In your example, the name should be "ANZ goMoney Australia" and the short_name should be "goMoney AU"; then typing "anz" would find it (due to the name), and typing "bank" should either a) not find it, because we don't allow keyword stuffing, or b) find it because it has "banking" in categories and the UA explicitly allows indexing of categories as well.

Either way, this doesn't seem appropriate for hidden "alternative names".

[marcoscaceres]

Either way, this doesn't seem appropriate for hidden "alternative names".

Yeah, I had forgotten about "categories". And I agree... what we have I think is sufficient.