Add a title field to snap metadata

[Robert Ancell]

There are currently three naming fields in the snap metadata:
name: a codename for the snap (can't contain spaces)
summary: a one-line description of the snap
description: A multi-line description of the snap

For example for the Ubuntu calculator app we have:
name: ubuntu-calculator-app
summary: Ubuntu Calculator app
description: The calculator app for all Ubuntu devices.

What is missing is the 'title' field from the store - this is more appropriate to use in a graphical system to display this. For example, this should be "Calculator" for ubuntu-calculator-app.

I think the following needs to be done:
1. A title field needs to be specified in the .snap metadata.
2. snapd needs to return this field for local snaps from the metadata, and return the store field for searches.
3. The store should take the title field from the metadata when uploading and automatically set it in the store.
4. Snapcraft needs to have updated documentation / prompt the user to enter this field.
5. snapd-glib needs support for this field.
6. GNOME Software should use this field where appropriate.

[Robert Ancell (robert-ancell)]

Currently gnome-software is using sumary or name instead of this field.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matthias Klumpp (ximion)]

If Snappy would support AppStream metadata... ;-)

[Mark Shuttleworth (sabdfl)]

Yeah yeah patches welcome :p

Would it be sensible to have title be an optional field, and use the
Capitalized name if it is not provided? In the past, we've seen it's
hard to get complete and accurate metadata when there is a lot of
duplication in the schema.

And yes, appstream would be welcome.

Mark

[Robert Ancell (robert-ancell)]

Given the current name conventions I think capitalizing the name would be a bad heuristic, e.g.

ubuntu-calculator-app -> "Ubuntu Calculator App" (should be "Calculator" or "Ubuntu Calculator")
minecraft-server-jdstrand -> "Minecraft Server Jdstrand" (should be "Minecraft Server")
stonscipap-snap -> "Stonscipap Snap" (should be "Stone, Scissors, Paper").

I think it's fine any of the metadata fields to be optional (title, summary, description), though the tools should pretty heavily encourage a developer to populate these. In the case of GNOME Software we can always fall back to name and "No description provided" or hide software without sufficient metadata.

[Mark Shuttleworth (sabdfl)]

Good point. Perhaps just fallback to name - uncapitalised - would be best.

[Gustavo Niemeyer (niemeyer)]

The bug description is misleading. There's a single name field in snaps today, and its called "name". Summary is not a name, and description is not a name. If gnome-software or anything else is using "summary" as a name, that's a pretty obvious bug that would be great to see fixed.

We can discuss the introduction of an alternative name field which is free-form and not unique, but that's a separate conversation. Proper applications supporting the snap format shouldn't mangle snap names, and shouldn't misuse fields for incorrect purposes.

[Mark Shuttleworth (sabdfl)]

I think Robert is using 'name' in the 'primary key' sense, and 'title'
in the 'display name' sense.

Mark

[Gustavo Niemeyer (niemeyer)]

Yes, but the discussion above also implies that we have multiple naming fields, and that gnome-software is currently using summary as it ("Currently gnome-software is using sumary or name instead of this field.").

We should discuss the possibility of another field, per above note, but let's please not use a summary as a display name meanwhile. This will encourage people to put wrong data in the wrong field.

In terms of the proposal itself, would be good to have a conversation about it considering the pros and cons. If we allow a free form name, we may end up with multiple applications named exactly the same thing (for above example, imagine 10 different "Calculator" applications). How much better is this than having a single "calculator" application? Our whole apt/deb story circles around applications with unique and well-defined lowercased names. What are the benefits of breaking that?

[Robert Ancell (robert-ancell)]

Please ignore what gnome-software is currently using. The title and description of this bug is about adding a new field because none of the current fields are sufficient. Please don't get hung up on the semantics on the fields; call them "naming", "describing", "metadata" - whatever.

I don't think having multiple apps with the same name is an issue. This is already possible with .debs, this is possible with clicks and is possible with Android apps [1] (I'm not sure about Apple apps since their store is not searchable online). In practise, this doesn't seem to be a problem because the credibility of an app is determined by the publisher and ratings. Also, app writers are already motivated to use a name that stands out from the existing "Calculator".

For a real-life comparison consumers don't get confused between a Casio calculator and an HP calculator - if we have 10 calculators in the store I would expect them to all be called "Calculator" (or something similar).

Our apt/deb story does not use the package name in the GUI. It uses the "Name" field from the .desktop file. The package name is an implementation detail.

[1] https://play.google.com/store/search?q=calculator

[Gustavo Niemeyer (niemeyer)]

If gnome-software is using summary as a name, it needs to be fixed to not do that, ASAP.

Whether to have a different field is an unrelated conversation which is of less urgency than that. We have a name field today, and it should be used.

[Mark Shuttleworth (sabdfl)]

The name field today is the best fallback, but it is obviously
unsatisfying ("ubuntu-personal-calculator") as primary keys don't make
nice human-friendly names.

I think what we want is a translatable displayname, and I would support
that, but Robert, why not just have this in the desktop file itself?

Mark

[Robert Ancell (robert-ancell)]

The challenge with the desktop display name is the one to many relationship of snaps to apps.

Here's a couple of cases:

1. A single snap with a single (graphical) app. This is probably going to be the vast majority of snaps used on desktop. In this case using the "Name" field from the is both desirable and most appropriate since this ensures the installed icon matches the name shown in GNOME Software (or other client).

2. A single snap with multiple (graphical) apps. While this is probably less likely than case 1 there are some examples:

2a. A snap with a number of top-level apps. In this case the snap acts as an app bundle. An example of this is Libreoffice. We could either:
- Show a name that is a combination of the "Name" fields from each .desktop file. e.g. "Libreoffice Writer, Libreoffice Calc, ..."
- Show a "bundle name" as taken from the "title" field of the snap, e.g. "Libreoffice".
- Split the snap into an item for each app in the libreoffice snap in GNOME Software. This going to be a complex user experience (installing one will install multiple apps, GNOME Software doesn't really support this concept).

2b. A snap with a primary app and one or more supporting apps. In this case the supporting apps are probably not worth explicitly mentioning. We could use case 1 for this. However, there's no way to determine between case 2a and 2b.

My thoughts on this is the best solution is to have a "title" field in the snap, but if that isn't present fall back on the "Name" field from the first .desktop file and the snap name after that. This gives the snap developer the maximum flexibility to do the right thing for the type of snap and matches the field they've already entered in the snap store. Snapcraft would ideally check if the title field is absent but .desktop files are provided and prompt the user to keep the snap metadata fields set and in sync.

I'm not sure what the vision is for snaps and desktop but I'd highly recommend that we discourage case 2 above (multiple graphical apps per snap) as I think it's a bad user experience.

[Robert Ancell (robert-ancell)]

For completeness, some reasons why the "name" field is bad for displaying:
- It's not translatable.
- It's not able to accurately express the name of snap/app (limited characters allowed).
- It's optimised for command line usage, not desktop cases (tends to be unnecessarily short, abbreviated).
- It is used for both name and publisher differentiation (e.g. "libreoffice", "libreoffice-rancell").

[Mark Shuttleworth (sabdfl)]

OK. I have a feeling though that the apps: section is not ordered, which
means we need some other way to call out the "definitive" app for the
snap, i.e. the one which is represented in GNOME Software.

So it feels to me that we need:

 * a way to associate desktop files with the apps in the snap (i.e. a
'desktop-file' property of the app in the snap.yaml) which transcends
the 'command' property for the purposes of GUI shells and software stores.

 * a way to indicate which of the apps in the snap is the 'definitive'
one, the single one which should be represented in the store

Does that make sense?

Mark

[James Tait (jamestait)]

For reference Click Package Index ("the store") already has a title field. It is returned by default in the details and search endpoints:

$ curl -s 'https://search.apps.ubuntu.com/api/v1/snaps/search?q=ubuntu-clock-app&size=1' -H 'X-Ubuntu-Series: 16' | jq .
{
  "_embedded": {
    "clickindex:package": [
      {
        "publisher": "Ubuntu Core App Developers",
        "ratings_average": 0,
        "name": "ubuntu-clock-app.ubuntucoredev",
        "package_name": "ubuntu-clock-app",
        "title": "Clock",
        "icon_url": "https://myapps.developer.ubuntu.com/site_media/appmedia/2016/03/icon_1.png",
        "price": 0,
        "summary": "Ubuntu Clock application for the Unity desktop",
        "content": "application",
        "alias": "ubuntu-clock-app",
        "version": "3.6+snap3",
        "_links": {
          "self": {
            "href": "https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-clock-app"
          }
        },
        "architecture": [
          "amd64"
        ],
        "prices": {},
        "plugs": [
          "opengl",
          "unity7"
        ],
        "snap_id": "vjQhIxU28Zszo6iEjbbrmosRqSpBq4GD",
        "slots": [],
        "revision": 5
      }
    ]

And snapd 2.21 at least requests it explicitly:

[14/Feb/2017:06:57:57 +0000] "GET /api/v1/snaps/search?confinement=strict%2Cclassic&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2Cconfinement&q=appear.in HTTP/1.1" 200 2454 "-" "snapd/2.21 (series 16; classic) ubuntu/16.04 (amd64)"

I'd have to check where the value for that field is coming from though - whether it's automatically extracted from somewhere or provided by the developer in the web UI.

[Natalia Bidart (nataliabidart)]

Hi Robert,

Would you mind clarifying for me the difference between this bug and LP #1555569?

As per the bug I linked, and the email thread conversation with subject "Package metadata: title, description and tagline" (sorry for the public in general but that happened in an internal mailing list), the agreement was that gnome-software should always use the title value from the snap data and in a future the snap.yaml would allow for that title to be defined in the file itself. Relevant piece of emails:

* Natalia: So I would like to have a "title" or "verbose name" for the package name being provided from the yaml file. What shall we do to move forward with this?

* Gustavo: Yes, it sounds fine to have a title there (prefer that over display name or verbose name for being a single noun), but can we not do it just yet?

Right now the publisher of a snap can edit the title via the developer portal website, as a workaround until snap.yaml supports the new title field.

I think we should close this bug as duplicate of LP: #1555569.

[Matthias Klumpp (ximion)]

Okay, I think I need to point out that the AppStream metainfo format solves all the problems you have (providing a human-readable translated name, associating a snap and a .desktop file, integrating it with GNOME Software)- it will even allow one to specify multiple launch-commands per software component soon (I am working on a proposal for that, and I expect to land the specification addition for the AppStream 0.11 release).
So, you maybe want to look into that in addition to introducing a new "title" field for snap.yaml and the store.

[Mark Shuttleworth (sabdfl)]

IIRC, the idea was to capture the AppStream link in the store, and have
snapd query the store for that if asked? I'm happy to go forward with
that, no additional snap.yaml data needed.

Mark

[Robert Ancell (robert-ancell)]

Oh (insert expletive here). Natalia - you are right, this is a duplicate of bug 1555569. I was reviewing our outstanding issues with snapd and for some reason I didn't find that bug and opened a new one.

The feature exposing the .desktop information is being tracked in bug 1661590.

[Gustavo Niemeyer (niemeyer)]

We just got a bug report saying gnome-software is actually showing summaries as a title:

https://forum.snapcraft.io/t/title-summary-pulled-from/469

[Robert Ancell (robert-ancell)]

See bug 1688407 for the reversion in 17.04. (Also not this bug is a duplicate and comment on bug 1555569 if you have more information to add).