[AppStream] Information about "mobile-readiness" in AppStream

[Aleix Pol]

On Wed, Feb 5, 2020 at 5:57 PM Matthias Klumpp <matthias at tenstral.net> wrote:
>
> Hi!
>
> One of the most requested features in AppStream over the past few
> years was how to get information about "ready for a mobile device"
> into the specification, so a device running Linux on mobile could
> filter the catalog of applications to select only the ones where the
> application author has marked them as "supported on mobile devices".
> Now that we at Purism are building a Linux phone, the issue has
> surfaced again, and I think it's time to finally solve it.
>
> One of the big issues in past discussion was to define what a "mobile
> device" even is. My a attempt at a definition is the following: A
> mobile device is any computer device that is usually carried around by
> a person and operated using finger/touch input".
> I was made aware at FOSDEM this year that apparently also some apps
> have screen size lower limits, so for me at the moment it makes sense
> to define "mobile readiness" as the result of a minimum screen size
> and the ability to be controlled by touch.
>
> In previous discussions (at
> https://github.com/ximion/appstream/pull/192), a "supports" tag was
> suggested to indicate certain hardware that the application explicitly
> supports and works well on.
>
> Using that, we could have something like:
> ```
> <supports>
>   <control>touch</control>
>   <control>pointer</control>
>   <screen_size compare="ge" unit="in">5</screen_size>
> </supports>
> ```
>
> The new tags found in "supports" could also show up in a "requires"
> element to set an absolute minimum screen size, or require
> cursor/touch input. Apps which do that wouldn't run at all on a device
> not meeting the requirements.
>
> In Android metadata
> (https://developer.android.com/guide/practices/screens-distribution),
> screens are classified into "small", "medium", "large" and "xlarge"
> instead iof giving actual dimensions. But Android also has the ability
> to upscale smaller apps and all its apps are designed for mobile
> anyway, while most of the apps we have AppStream metainfo files for
> are not designed to work on mobile. Yet, doing the same here may also
> be viable, if we define what a "small" screen actually means for the
> app (e.g. can it be smart-watch sized?).
>
> We could of course also only have the information about controls, as
> requested in https://github.com/ximion/appstream/issues/55, and simply
> assume everything that supports "touch" is mobile-ready, as you
> wouldn't use touch input on your massive television screen (but apps
> supporting that usecase can be filtered out via a "tv-remote"
> control).
>
> There is also the question of whether we actually need a "supports"
> tag, and whether we shouldn't simple reuse the "requires" and
> "recommends" relation tags already found in AppStream and just permit
> recommendations about controls and screen sizes.
>
> This mail is primarily intended to start a conversation, and I will be
> very happy about any possible feedback, so we can implement this
> feature the right way(tm) from the start.

Hi Matthias,
Thanks for bringing it up. We actually talked about it yesterday at
the Plasma Mobile sprint, it's definitely something important for us
as well.

I'd say that using the input methods as a first iteration would work
fine, adding screen limitations and others later on.

Regarding the supports, I did it so we'd be able to sort rather than
out right filter on such lists, at least on some cases. We don't want
to make the queries so restrictive that we end up with 3 apps being
listed... Differences between supports and recommends can be too small
though.

Another question is what we are going to do with everything lacking
such metadata. Should we assume that everything requires a keyboard
and mouse unless the application introduces the restrictions? Or
assume that they don't support, require and recommend anything?

Aleix