Do we need a way to express "System requirements"?

[marcoscaceres]

In traditional software distribution, it is common for software developers to express minimum "system requirements" for an application, particularly in games. For example, DOOM 3 from apple's App Store has the following system requirements:

As more sophisticated capabilities become disproportionally available to different devices and user agents, some apps stores on the Web have eluded to using something similar to warn or prevent users from purchasing software that their devices might not be able to execute.

Google's manifest format currently only asks developers to list two requirements (plugins or 3d).

"requirements": {
  "plugins": {
    "npapi": true
  },
  "3D": {
    "features": ["webgl"]
  }
}

The system application working group published a draft specification that contained required_features member in the manifest format ():

"required_features": ["touch", "geolocation", "webgl"]

*Mozilla may be using the "required_features" member above in their store, but it's currently not part of their documentation.

As can be seen from above, the list of requirements are both arbitrary encroaches on things that should be device independent (e.g., touch) and things that are a standard part of the Web platform (geolocation) - and, in the case of geolocation, that already include a permission model.

Some initial questions are:

• Doesn't this sanction a means for developers to build experiences that exclude people (e.g., "touch only!")?
• Shouldn't developers provide alternative fallback mechanisms for when features are not supported?

[raucao]

Doesn't this sanction a means for developers to build experiences that exclude people (e.g., "touch only!")?
Shouldn't developers provide alternative fallback mechanisms for when features are not supported?

There are enough cases, where you cannot create high-quality, competitive experiences that work well with all possible input methods, screen sizes, and computing hardware. Why should the desktop version of the latest 3d blockbuster game work equally well on a $100 phone? And what would be the desktop fallback for an accelerometer-driven UI?

[marcoscaceres]

TL/DR: the distributed installation model might make this a requirement in manifests. However, I would like to explore a sane way of doing this without just listing every possible feature of the platform. It's also not clear how such a list scales as new features get added to the platform.

(Sorry about the long rant... trying to map out the problem more fully).

@skddc you are correct - but it's not really about equality; it's about being responsive and degrading gracefully where possible. A responsive solution would be to use touch to simulate tilting (but yes, this might mean significantly changing a game, which adds costs to the point of being prohibitive). An acceptable graceful degradation in an app would be "you can't run this game because it needs an accelerometer and 3d hardware".

I guess what I am trying to explore is if this is best handled in the application itself or at the store level. I see how this breaks down when a manifest is linked from a "store": without the user first being able to try the app, they will have no way of knowing if it runs or not (note that this is also what is suggested in the DOOM3 example above, where potential buyers are encouraged to install the "MacMatch" feature thing from some random website if they are unsure about their device's capabilities... that is pretty sucky UX). Having some way in the manifest to declare the system requirements would help there.

My main concern is about the level that this is taken to. The Web operates as a medium that generally does not exclude users based on device capabilities or input modalities. If we start giving developers the opportunity to discriminate directly on features, we are changing one of the fundamental principles of the platform. Hence, we need to think carefully about the level of granularity a feature like this would afford developers.

Note that Google only seems to allow exclusion on 3D (the plugin stuff is not relevant for hosted apps). But the SysApps proposal is much more discriminating - using a yet to be specified list of features to exclude on. This doesn't need to be a hard exclude (though it will likely be in cases, as stores will want to reduce the possibility of a user returning a purchase if a traditional purchasing model is used - rather than a subscription or freemium model): at install time, a store or a user agent could still allow installation, but with a warning that some features might not work as expected.

The other problem that you mention is that of having an app purchased for multiple devices - in which case you could end up with the app installed on both, but only usable on one device. The inverse of this problem is purchasing an app from my desktop machine, to be later installed on some device of my choosing. In that case, the store may not know what the capabilities of my device are. However, the user agent could then check at install time (when my purchases are synched across devices) against the manifest and warn me if there might be incompatibility issues.

[AMorgaut]

The other problem that you mention is that of having an app purchased for multiple devices 
- in which case you could end up with the app installed on both, but only usable on one device. 
The inverse of this problem is purchasing an app from my desktop machine, to be later installed 
on some device of my choosing. In that case, the store may not know what the capabilities of
my device are. However, the user agent could then check at install time (when my purchases
are synched across devices) against the manifest and warn me if there might be incompatibility 
issues.

I value that approach a lot as I wanted many times to buy from the desktop to finally use on mobile and vice versa. I do think in this regard that the "purchase" action should be considered differently than the "install" one.

So the purchase should not be blocked but having the requirements easily accessible to the store somewhere allow it to list them and filter applications based on those too. On purchase, the store should probably still provide a warning or a confirm dialog to be sure the user is aware that the app is not usable on the current platform. Note: if a store is aware on the devices owned by the customer, because authenticated to the store from the different devices, or manually specified in the customer profile, the store could list the devices on which he will be able to use the application.

[AMorgaut]

Note also that such property goal looks to me very similar to the one of the dependencies property from the Package CommonJS specification which also has variants in the npm node.js packages like devDependencies. We might imagine a specific sysDependencies.

cf my recent issue: "The manifest format should be JSON Package compliant" https://github.com/w3c/manifest/issues/50

[marcoscaceres]

We haven't found applications themselves needing this in the use case search. So closing. This can be handled as a store thing.