Web manifest: name, icon, and start address of a web application

Useful to know

The web application can have a name, icons and a preferred way of opening. Web application manifest is a JSON file through which this information is made available to the browser. A common use is describing an application that can be added to the device. The file contains one JSON object with named members. Its role is to describe metadata, not to contain the logic of the entire site or to automatically turn each page into a complete application. [1]

Among the described values may be name, short_name, icons, display and start_url. They answer various questions: how the application is said, what icon it presents, and which address is offered at startup. [1] It is useful for these solutions to follow the real task. If the short name is incomprehensible or the icon is not recognized, the syntactically correct file will not solve the confusion. Metadata is part of how the person recognizes and opens the service.

Let's have a fictional app for a small theater program. The visitor adds it to the home screen because he wants to quickly see the upcoming performances. For him, the useful initial view is probably the program, not a technical settings page. This example helps to select the starting address according to the user route. Then you can check if the title and the icon match what the person expects after pressing.

The start_url member sets the suggested opening address at startup. It can be absolute or relative, with the relative being allowed relative to the address of the manifest file itself. The browser has some freedom in processing it. [2] This means that moving the manifest to another folder can change the meaning of a relative path. When checking, the actual authorized address should be considered, not just the text that seems correct in the editor.

The Manifest file is not equivalent to offline support. It describes information about the application. [1] For practical evaluation, it is useful to separately record the expectations of starting, navigating and working in the absence of a network. Thus, promises in the interface will not be based only on the presence of an icon. In the theatrical example, we can ask if a program already considered should remain accessible and how it is shown that the information may not have been updated.

Completed verification involves real opening in the chosen way and following the main links. Does the starting address match expectations? Is the app recognized among other icons? Does the person return easily to the program? These questions link the small JSON file to the overall use. A manifesto has a clear technical task, and a good application is obtained when metadata, navigation, and actual features describe the same experience.