17 | This document provides an overview of how web applications have started
18 | to be integrated into native application environments, and outlines the
19 | use cases and requirements for a standard that could allow users to
20 | "install" web applications. The use cases and requirements were
21 | gathered by examining the landscape of proprietary solutions, and,
22 | where possible, by gathering statistics about the prevalence and usage
23 | patterns of particular solutions used in the wild.
24 |
25 |
26 | Proprietary solutions that integrate web applications into the
27 | underlying operating system have been used in the wild for a few years
28 | now, so consolidation towards a standardized solution could potentially
29 | benefit users, developers, and browser vendors.
30 |
31 |
32 |
33 |
34 | This document is undergoing heavy revision and changing on an almost
35 | daily basis. If you have any thoughts or comments about the content,
36 | please either join the public-webmob
38 | mailing list or file a
40 | bug on GitHub. All contributions welcome.
41 |
42 |
43 |
44 |
45 | Introduction
46 |
47 |
48 | To launch native applications on either a desktop-class machine or a
49 | mobile device, users are generally presented with icons and
50 | corresponding labels that represent the applications installed on their
51 | system. Having the icons of web applications appear amongst
52 | applications that the user considers native (e.g., those on the home
53 | screen of a device) gives the perception to users that a web
54 | application has been "installed" - even if the processes that go into
55 | actually "installing" a web application differ from those of a native
56 | application.
57 |
58 |
59 |
61 |
62 | Some application icons of Android 4.3, Windows Phone 7, and Mac OS
63 | Mavericks.
64 |
65 |
66 |
67 | At the time of writing, the web platform lacks a standardized means for
68 | a web application to indicate that it can be "installed" and treated as
69 | if it were an native application. As this document will show, the web
70 | platform also lacks sufficient metadata for a Web application to be
71 | successfully integrated into an underlying platform in the same way
72 | native applications are (i.e., not just on the homescreen, but
73 | integration into other contexts such as the task switcher, privacy
74 | and security settings, etc.).
75 |
76 |
77 | Because of this gap in the web platform, browser vendors, including
78 | Google, Apple, Microsoft, and Mozilla, have implemented proprietary
79 | solutions that allow users to add web applications to the homescreen.
80 | To get a web application to more fully integrate with the OS,
81 | developers are sometimes required to use proprietary opt-in mechanisms,
82 | which we discuss later, to indicate to the browser that the web
83 | application can potentially work as a stand-alone application once it's
84 | added to the homescreen. These opt-in mechanisms primarily provide the
85 | OS with metadata (e.g., the icons and name of the application) so when
86 | the web application is added to the homescreen, it appears
87 | indistinguishable from an application that was natively installed.
88 |
89 |
90 |
91 |
92 | Bookmarking
93 |
94 |
95 | To access a web application, users traditionally opened up a web
96 | browser, typed a URL or a search query into a search box, and had the
97 | browser navigate to the web application they wanted. Alternatively, a
98 | user may have "bookmarked" within a Web browser a set of web documents
99 | or web applications they commonly access.
100 |
101 |
102 | More recently, browsers have started to monitor user's browsing habits
103 | to intelligently deduce which are the most common web sites the user
104 | likes to visit (i.e., a type of automatic bookmarking). The browser
105 | will then present visual links to those sites. Depending on the
106 | browser, user-defined and automatically-gleaned bookmarks will appear
107 | as a list of document titles or file names in either a drop-down menu,
108 | "speed-dial"
110 | entries, a toolbar, and/or a dedicated application window or tab. All
111 | these bookmark types are illustrated below.
112 |
113 |
114 |
115 |
116 | In a desktop-based browser, there are at least six different ways to
117 | access bookmarks. Some of those bookmarks are derived dynamically by
118 | monitoring user's browsing habits, such as the most visited sites and
119 | "speed
121 | dial" entries the user sees when they open a new tab.
122 |
123 |
124 |
125 |
126 | Bookmarking on mobile browsers
127 |
128 |
129 | On mobile devices, the interaction model has traditionally been the
130 | same as the one described above: historically, there's been a clear
131 | distinction between opening a native application and accessing a web
132 | application. That is, to access a Web application a user needs to
133 | first locate the Web browser they want to use, launch it, and then
134 | either type-in a URL or select a bookmark. Web browsers on mobile
135 | operating systems have thus added similar bookmarking facilities as
136 | those found in desktop-class browsers. This is shown below.
137 |
138 |
139 |
141 |
142 | The bookmarking facilities of mobile browsers closely resemble
143 | those of desktop-browsers - providing both a traditional list of
144 | bookmarks as well as a "speed dial" that can contain either
145 | automatically gleaned bookmarks or user-configured ones.
146 |
147 |
148 |
149 | The bookmarking facilities of mobile browsers helps reduce some of
150 | the burden of typing URLs. Particularly for sites that the user
151 | visits regularly, it means that a web site can be accessed by a
152 | single press. Additionally, bookmarking facilities help separate
153 | native applications from web sites the user needs to access for other
154 | reasons (e.g., a particular wiki page on an intranet, a document with
155 | commonly required information, etc.).
156 |
157 |
158 | The following table shows some examples of how a user bookmarks a
159 | page on a mobile browser. Both iOS and Android provide the user with
160 | the ability to customize the name of the bookmark, as well as
161 | organize the bookmark by placing it into a particular location.
162 | Firefox OS, however, simply let's the user "star" a page - this gives
163 | the user the option to bookmark the page. Once bookmarked, the site
164 | is added to a bookmarks tab (not shown below), which, unlike other
165 | mobile browsers, does not provide a means to manipulate the metadata
166 | of the bookmark. On Windows Phone the user can "add favorite". It
167 | does not allow the user to choose the location when adding a site,
168 | however, IE Mobile has a separated option called, "Pin to start".
169 |
170 |
171 |
172 | Bookmarking a page on a mobile browser
173 |
174 |
175 |
176 | iOS Safari
177 |
178 |
179 | Android Default Browser
180 |
181 |
182 | Firefox OS 1.1
183 |
184 |
185 | Windows Phone 8 IE 10
186 |
187 |
188 |
189 |
190 |
191 |
192 |
193 |
194 |
195 |
196 |
197 |
198 |
199 |
200 |
201 |
202 |
203 |
204 |
205 |
206 | Side-effects of bookmarking: multiple home screens
207 |
208 |
209 | Because basic bookmarks contain links to a range of different types
210 | of resources, the bookmarking facilities of desktop and mobile
211 | browsers do not integrate into an operating system's application
212 | menu. This means that web applications and "native" applications are
213 | treated as different things. This separation makes sense for many
214 | kinds of web sites (e.g., static, informational websites that provide
215 | little other functionality), but there is a range of applications
216 | that can provide an experience that is analogous to that provided by
217 | an application installed locally on a user's device (e.g., a game, an
218 | office productivity suite, a news or social networking site, a
219 | currency converter or photo manipulation utility, etc.). That said,
220 | it is users who are in the best position to decide what they consider
221 | an "app" and where they would like to access it from (either as a
222 | bookmark or as one of their locally installed applications).
223 |
224 |
225 | As shown below, this desire to treat websites as applications has led
226 | at least one browser maker to attempt to replicate the homescreen
227 | experience directly in the browser itself.
228 |
229 |
230 |
232 |
233 | In iOS 7's Safari web browser, the default tab view presents icons
234 | derived from websites to create what is, in effect, a second
235 | homescreen - image on the left. This can be clearly seen when
236 | contrasted with the actual iOS 7 homescreen -image on the right.
237 | Google Chrome's browser, although not shown here, does the same
238 | thing in iOS: it presents bookmarked pages as a grid of icons.
239 |
240 |
241 |
242 | Although this is a convenient way to access web sites, there are web
243 | applications that would benefit users if they were directly available
244 | from where the user normally accesses their installed applications.
245 | Also relegating web applications to this second homescreen means that
246 | web applications are treated as "second-class citizens": in the sense
247 | that in order to access these applications, a user must first launch
248 | the correct browser (from potentially a range of different browsers),
249 | and then press the icon for the application they wish to load.
250 |
251 |
252 |
253 |
254 | Key components of bookmarking
255 |
256 |
257 | From the discussion above, we can conclude that the key bits of
258 | information that are needed to enable bookmarking are:
259 |
260 |
261 |
262 | Name (label or title):
263 |
264 |
265 | Generally this will be the title of the page being bookmarked.
266 | Mobile browsers usually allow users to change this, specially when
267 | bookmarking to the homescreen.
268 |
269 |
270 | Icon:
271 |
272 |
273 | Generally, the site's favicon. However, proprietary solutions exist
274 | that allow the browser to select from a range of icons.
275 |
276 |
277 | URL:
278 |
279 |
280 | The URL to be loaded when the user activates the bookmark.
281 |
282 |
283 | Organization:
284 |
285 |
286 | Browsers generally provide some facility to allow bookmarks to be
287 | organized (e.g., into folders).
288 |
289 |
290 |
291 |
292 |
293 |
294 | Add to homescreen
295 |
296 |
297 | Ideally, web applications should be immediately available to users
298 | without them needing to launch a separate application (a web browser)
299 | and having to type a URL. A user may have found a web application
300 | through browsing the web (e.g., through a search engine, via a link
301 | given to them by a friend on a social network, or through a website
302 | that works as an "app store"), but once added to the homescreen, the
303 | developer needs to be able to control if in web application opens in a
304 | Web browser environment or if the application is launched
305 | standalone: that is, once the application is launched, it
306 | appears indistinguishable from a native application by allowing the OS
307 | to treat it as equivalent to a native application. This includes, but
308 | is not limited to, integration with OS facilities such as the task
309 | switcher and doing away with browser UI chrome (the address bar,
310 | forward/back buttons, etc.).
311 |
312 |
313 | Some browser makers have long acknowledged this as something developers
314 | want and that users could benefit from: iOS's Safari has had the
315 | capability to add a website to the homescreen since early 2008 (as of
316 | version 1.1.3, as shown in the figure below); the Android's stock
317 | browser has provided the capability to "add to homescreen" since at
318 | least 2009. Windows 8 also provides a similar capability, called
319 | "pinning", which we discuss in more detail below.
320 |
321 |
322 |
323 |
324 | iOS's Safari has almost always provided a way for users to add
325 | websites to the home screen of the device. Once the user presses
326 | "add", the icon for the Web application is placed along side other
327 | native application icons.
328 |
329 |
330 |
331 | The ability to add a web site to the homescreen didn't automatically
332 | make a web application look, feel, or integrate into the operating
333 | system in the same way as native applications did. For instance,
334 | originally in iOS, launching a web application that had been added to
335 | the homescreen took the user back into Safari; in other words, it
336 | worked just like a traditional bookmark. It was only with the release
337 | of iOS 2.2 in September 2008 that applications that had been added to
338 | the home screen gained the capability to be displayed full screen
339 | (i.e., doing away with Safari's application chrome, as shown below).
340 | Apple did this by introducing a proprietary bit of HTML which
341 | developers could make use of if they so chose to. The result of using
342 | this proprietary switch is shown below.
343 |
344 |
345 |
347 |
348 | A side-by-side comparison of Variety's web application
349 | running in Safari next to the same application once added to the
350 | homescreen, on the left and right respectively. Variety's web
351 | application makes use of Apple's proprietary switch so to make sure
352 | that once it's launched from iOS's homescreen the application
353 | integrates with the OS. As seen on the right, this means that browser
354 | chrome, including the navigation buttons, ability to bookmark, and
355 | the URL and search bar, have all been removed by iOS.
356 |
357 |
358 |
359 | Windows 8 also provides similar capabilities, but in two different
360 | forms: one allows a user to "Add site to Apps", meaning that a shortcut
361 | icon to a web application is added amongst natively installed
362 | applications. This is shown below.
363 |
364 |
365 |
366 |
367 | In Windows 8, "adding a site to apps" makes a website appear amongst
368 | other apps. Once added, the launch icon is treated identically from
369 | other applications. Once clicked, the web application is opened in
370 | Internet Explorer.
371 |
372 |
373 |
374 | The second type of bookmarking supported by Internet Explorer is
375 | pinning: this adds the site as a "live tile" to the homescreen. To best
376 | support this functionality, the developer needs to include some
377 | proprietary metadata for the icons and for how often the tile should be
378 | updated. The site is not actually presented in the live tile, but an
379 | RSS feed is used instead.
380 |
381 |
382 |
383 |
384 | On the left, the facility that allows a site to be "pinned" to the
385 | Windows 8 homescreen. On the right, the result of pinning a site is
386 | shown. Note that the content shown in the tile comes from an RSS
387 | feed, and not from the HTML of the site itself.
388 |
389 |
390 |
391 |
392 |
393 | Windows Phone 8 comes with the "Pin to Start" feature as well,
394 | however, the mobile version only displays a static thumbnail of the
395 | web site, and the metadata for the "live tile" is not available.
396 |
397 |
398 |
399 | What initially started as a way to add a link to the homescreen has
400 | incrementally evolved to diminish the functional differences between a
401 | web application and a native application. This has not happened on the
402 | OS level alone: progress on the web platform, such as the ability to
403 | make content available off-line, performance gains through hardware
404 | acceleration, and integration
406 | with native form controls, has assisted in diminishing these
407 | differences.
408 |
409 |
410 | But it should be noted that being able to have bookmarks outside the
411 | web browser is not something particularly new or noble. Desktop
412 | browsers have had that capability for possibly over a decade. However,
413 | giving developers the choice to tightly integrate their web
414 | applications into the OS directly from the Web browser is still
415 | somewhat new (hence all the proprietary switches and fragmentation in
416 | this space). This is different from packaged applications (zipped-up
417 | HTML applications) or hybrid application (applications that are
418 | distributed as native applications, but rely on a Webview), in that
419 | they applications are "installed" directly from the browser itself
420 | rather than from an app store.
421 |
422 |
423 |
424 | Examples of add to homescreen on mobile browsers
425 |
426 |
427 |
428 | iOS 7's Safari
429 |
430 |
431 | Android's Stock browser
432 |
433 |
434 | Firefox OS 1.1
435 |
436 |
437 |
438 |
439 |
440 |
441 |
442 |
443 |
444 |
445 |
446 |
447 |
448 |
449 |
450 |
451 | Key components of the "standalone" web application
452 |
453 |
454 | Web Applications that opt-into being run standalone have somewhat
455 | different requirements to web applications a user has bookmarked to
456 | the homescreen. This is because OS level facilities of interacting
457 | with and controlling native applications are different from those of
458 | a web browsers.
459 |
460 |
461 | In order for a web application to be "installed" in such a way that
462 | it provides a user experience that is indistinguishable from that of
463 | a native application, a number of key things are needed. This list
464 | compliments the list of things needed for bookmarking:
465 |
466 |
467 |
468 | Standalone switch:
469 |
470 |
471 | If a developer feels that their web application is analogous to a
472 | native application (e.g., it works offline, doesn't need a
473 | navigation bar, etc.), then they use some kind of switch (e.g.,
474 | through markup) to indicate this to the OS when the application is
475 | added to the homescreen. Otherwise, the installed web application
476 | is treated as a regular bookmark and launched in the appropriate
477 | browser.
478 |
479 |
480 | Name:
481 |
482 |
483 | The ability for a user to find an application through its name.
484 | Some OSs allow native applications to be found by using multiple
485 | names.
486 |
487 |
488 | Icons:
489 |
490 |
491 | Generally a small graphic that functions as an application's unique
492 | visual identifier amongst a list of installed applications. An
493 | application's icon can also be used in other contexts such a
494 | settings screen, dialogs, notifications and other menus. Because of
495 | the various contexts that a application's icon can appear in an OS,
496 | applications typically need to provide a range of icons at
497 | different sizes and, more recently, specifically targeted at
498 | different device pixel densities.
499 |
500 |
501 | Orientation:
502 |
503 |
504 | Applications, such as games, require that they be started in a
505 | particular orientation to function effectively.
506 |
507 |
508 | Self awareness:
509 |
510 |
511 | The application is aware through script that it was launched
512 | "standalone", rather than in the context of a Web browser. This
513 | differs from native applications, which always run stand alone.
514 |
515 |
516 | Start page:
517 |
518 |
519 | As a web application can be added to the homescreen at any point
520 | the user desires.
521 |
522 |
523 | Security:
524 |
525 |
526 | Different cookie jar. Is it blank slate? are cookies copied over?
527 | webSQL data?
528 |
529 |
530 | Privacy:
531 |
532 |
533 | In web browsers, user's are generally able to control privacy
534 | settings for a particular website through "site preferences" or
535 | through the browser's settings. When a web application is taken out
536 | of the browser context, it needs to either integrate with the
537 | privacy settings at the OS level or some other intermidiary
538 | application needs to provide this capability.
539 |
540 |
541 | Navigation:
542 |
543 |
544 | Applications are generaly composed of one ore more panes, which
545 | together provide the capabilities of the application. Users
546 | generally navigate around different panes depending on what they
547 | are trying to achieve. Web applications, on the othe hand,
548 | generally rely on hyperlinking from one document to another.
549 |
550 |
551 | UI behavior:
552 |
553 |
554 | Unlike web pages, applications generally don't allow users to
555 | select every span of text on the page.
556 |
557 |
558 |
559 |
560 |
561 |
562 | Indication that the application can work standalone
563 |
564 |
565 | As already discussed, web applications can be added to the homescreen
566 | of a device in such a manner that they behave just like bookmarks. That
567 | is, once added to the homescreen, when the icon of the web application
568 | is activated, a web browser is launched and the desired web page is
569 | loaded.
570 |
571 |
572 | However, through various proprietary opt-in mechanisms, developers are
573 | able to inform the browser that the application is able to work
574 | "standalone": that is, it is able to function without the user
575 | interface chrome of a browser - which typically means an web
576 | application will be launched in full screen. Depending on the OS and
577 | browser, these opt-in mechanisms can have various side-effects. One
578 | such web application, Forecast.io, is
579 | shown below running in iOS.
580 |
581 |
582 |
583 |
584 | The figure shows how the Forecast.io web application
586 | integrates with iOS 7's task switcher. Note also the web
587 | application's launch icon is indistinguishable from those of other
588 | applications.
589 |
590 |
591 |
592 |
593 | iOS7 Safari
594 |
595 |
596 | In iOS, then means by which an application developer indicates that
597 | their application can be run "standalone" is by using a meta element
598 | that takes the following form:
599 |
604 | By declaring the above in a document, iOS will launch an application
605 | that has been added to the home page in fullscreen (without any
606 | browser chrome).
607 |
608 |
609 | If the meta tag is omitted, and a user adds a page to the home
610 | screen, then the web application simply opens in a tab within Safari.
611 |
612 |
613 | We analysed the October
614 | data set and found 844 sites declared
615 | "apple-mobile-web-app-capable".
616 |
617 |
618 | TODO: Discuss that a side effect is the following practice, which can
619 | range from the annoying to the just bad and requires browser sniffing
620 | (so you know where to point the "add to home screen" arrow, which is
621 | different on every browser). Having an API might help with this
622 | problem, but allowing developers to be a bit more descrete about
623 | adding to homescreen.
624 |
625 |
626 |
627 |
628 | The figure shows web applications that asks the end-user to add the
629 | web application to the homescreen. On the left forecast.io and ESPN on the right.
632 |
633 |
634 |
635 |
636 |
637 | Chrome beta for Android
638 |
639 |
640 | Google Chrome Beta for Android reuses Apple's convention of using a
641 | meta tag whose name is "apple-mobile-web-app-capable".
642 | It also introduces it's own value
643 | "mobile-web-app-capable".
644 |
649 | By declaring the above in a document, Chrome will launch an
650 | application that has been added to the home page in fullscreen
651 | (without any browser chrome).
652 |
653 |
654 | If the meta element is missing, then the site is
655 | launched as a tab within Chrome.
656 |
657 |
658 | We analysed the October
659 | data set and found 9 sites declared "mobile-web-app-capable". 4
660 | of those websites declared "apple-mobile-web-app-capable" too.
661 |
662 |
663 |
664 |
665 | Firefox OS
666 |
667 |
668 | Firefox OS lacks a way to declaratively indicate to the Web browser
669 | that the application can run standalone when launched. Instead,
670 | Firefox OS relies on an API to provide this functionality. The
671 | mozApps.install() method takes a url to a JSON file as
672 | an argument. The JSON file supplies Firefox OS with the relevant
673 | metadata (e.g., application's name, URLs for the icons, etc.) needed
674 | to make installation possible.
675 |
687 | The Web platform provides two
688 | standardized means to associate icons with a Web application: one being
689 | the link element with the icon link
690 | relationship, and two being the favicon.ico - which is a
691 | graphical resource that a developer places at the root of a site, and
692 | which user agents will automatically attempt to fetch after a document
693 | has loaded.
694 |
695 |
696 | Unfortunately, despite the above two standardized solutions being part
697 | of the platform since at least 2008, support for the above is lacking
698 | and so various proprietary solutions have emerged and continue to
699 | proliferate. This is particularly the case for user agents that support
700 | adding applications to the home screen of a device. For example:
701 |
702 |
703 |
704 | iOS:
705 |
706 |
707 | For "add to home screen", does not support either of the two standard
708 | solutions. Instead, iOS relies on link elements whose
709 | relationship is "apple-touch-icon". It also
710 | automatically searches the root of a website for specially named
711 | files (e.g., "apple-touch-icon-57x57-precomposed.png").
712 |
713 |
714 | Android - Chrome Beta:
715 |
716 |
717 | Will use iOS's "apple-touch-icon" links if it
719 | encounters them in a HTML document, but it will not automatically
720 | scan the root of a site for those icons.
721 |
722 |
723 | Windows 8:
724 |
725 |
726 | For "pinned sites", Windows 8 relies on proprietarily-named
727 | meta elements described below. Like with iOS, when a site is pinned, it also
729 | automatically scans the root of a site for specifically named files
730 | to use as icons.
731 |
732 |
733 |
734 |
735 | The icon link relationship
736 |
737 |
738 | To associate an icon with a web application, HTML recommends using a
739 | link element whose link relationship is
740 | "icon". For example:
741 |
746 | As stated in the [[!HTML] specification:
747 |
748 |
749 | Icons could be auditory icons, visual icons, or other kinds of
750 | icons. If multiple icons are provided, the user agent must select the
751 | most appropriate icon according to the type, media, and sizes
752 | attributes. If there are multiple equally appropriate icons, user
753 | agents must use the last one declared in tree order at the time that
754 | the user agent collected the list of icons. If the user agent tries
755 | to use an icon but that icon is determined, upon closer examination,
756 | to in fact be inappropriate (e.g. because it uses an unsupported
757 | format), then the user agent must try the next-most-appropriate icon
758 | as determined by the attributes.
759 |
760 |
761 | Allowing user agents to discriminate depending on media type, media
762 | query, and size potentially provides a complete responsive solution
763 | for icons: in that the user agent can use these data points to select
764 | the most appropriate icon for a particular context (see the use cases for responsive
766 | images).
767 |
768 |
769 | Despite what the [[!HTML]] specification recommends, support for
770 | discriminating on media, sizes, and type is limited: Given a set of
771 | icons, Gecko-based user agents will use the last known good icon (as
772 | per the [[HTML]] spec). However, no attempt is made to discriminate
773 | on size (via the link element's sizes attribute).
774 | Additionally, Firefox for Android stylizes the icon when a web
775 | application is added to the home screen.
776 |
777 |
778 | Support in Mac OS's Safari is also spotty: given multiple icon
779 | choices, where the last is unavailable, Safari does not attempt to do
780 | any error recovery to find alternative icons. In addition, on iOS,
781 | link rel=icon is not used for "add to homescreen" either
782 | - only the proprietary "apple-touch-icon" solution is supported
783 | (discussed below).
784 |
785 |
786 | Furtunately, <link rel=icon> is fairly well
787 | supported on Chrome on both desktop and on iOS and Android, as is
788 | support in Windows 8: in the aformentioned user agents, the browser
789 | follows the [[HTML]] specification and select appropriate icons based
790 | on the sizes attribute. Both browsers also support error handling.
791 | Unfortunately, in Chrome Beta, when adding to home screen Chrome still
792 | selects the last icon in set, instead of discriminating on size -
793 | this can lead to the wrong icon being selected for the available icon
794 | size of the home screen.
795 |
796 |
797 |
798 |
799 | Favicon
800 |
801 |
802 | Favicons are small graphical icons commonly used by web browsers to
803 | help user's identify a site in the browser's user interface. They
804 | typically appear on tabs, in bookmark lists, and when viewing a
805 | browser's history. As favicons were a Microsoft creation, the
806 | proprietary ICO file
808 | format is a common format used for them. However, browsers are
809 | not restricted to the .ICO format, and all typical file formats used
810 | on the Web are supported (i.e., JPEG, PNG, and GIF).
811 |
812 |
813 |
814 |
815 | Visual favicons of various websites, as shown in the browser tabs
816 | of Google Chrome (above) and Firefox on MacOS below.
817 |
818 |
819 |
820 | A comprehensive
821 | history of favicons can be found on Wikipedia, as well as a
822 | description of the ICO file
824 | format. Relevant to this document is the level of
825 | interoperability of favicons in the platform: all user agents support
826 | favicons both through using a link relationship and by a developer
827 | placing a resource called "favicon.ico" at the root of a web site
828 | (i.e., at "/favicon.ico").
829 |
830 |
831 |
833 |
834 | Because of a constraint in the ICO file format, favicons are
835 | limited to dimensions of 256 x 256 pixels (though icons are not
836 | required to be square). However, they can hold any range of icons
837 | below those sizes. This limitations make favicons unsuitable for
838 | context that require very large icons, but makes them suitable for
839 | most contexts in which icons appear in current OSs.
840 |
841 |
842 |
843 | When an application is added to the home screen of a device, and in
844 | the absence of dedicated proprietary icon declarations within a
845 | document, all user agents tested except iOS make use of favicons.
846 |
847 |
848 | However, Gecko will only ever use the smallest icon in a set of
849 | favicons. Chrome and IE will most of the time select an approprietely
850 | sized icon for the context in which the icon is to be displayed.
851 |
852 |
853 |
854 |
855 | iOS - Touch icons
856 |
857 |
858 | In iOS, Apple provides a proprietary declarative solution for
859 | including icons in a HTML document - known as "touch icons". Apple
860 | iOS has supported touch icons since iOS 1.1.3 and other browsers,
861 | such as Chrome on Android, will also make use of these icons as a
862 | fallback when they are available.
863 |
872 | On iOS, when a web page doesn't specify a custom touch icon, the OS
873 | takes a screenshot of the webstie and creates an icon from it. This
874 | is shown below.
875 |
876 |
877 |
879 |
880 |
881 | When an application is bookmarked, iOS automatically adds some visual
882 | effects to an icon so that it integrates more effectivly with the
883 | built-in icons on the home screen (as it does with application
884 | icons). Specifically, iOS adds:
885 |
886 |
887 |
Rounded corners
888 |
889 |
Drop shadow
890 |
891 |
Reflective shine
892 |
893 |
894 |
895 | As of iOS 2.0, a developer can prevent the addition of these effects
896 | by using the precomposed keyword:
897 |
902 | If no icons are specified in the HTML, iOS Safari will search the
903 | website’s root directory for icons with the apple-touch-icon or
904 | apple-touch-icon-precomposed prefix. For example, if the appropriate
905 | icon size for the device is 57 × 57 pixels, iOS searches for
906 | filenames in the following order:
907 |
908 |
909 |
apple-touch-icon-57x57-precomposed.png
910 |
911 |
apple-touch-icon-57x57.png
912 |
913 |
apple-touch-icon-precomposed.png
914 |
915 |
apple-touch-icon.png
916 |
917 |
918 |
919 | So, for iOS, it’s not necessary to use HTML to add touch icons to a
920 | site, even if one wants to use multiple resolution-specific icons.
921 | This helps avoid having to use proprietary <link
922 | rel="apple-touch-icon"> elements on every single HTML page.
923 | A developer just needs to create different versions of the icon, use
924 | the correct file names and place them in the root of the website.
925 |
926 |
927 |
928 |
929 | Android
930 |
931 |
932 | Android has a default system provided icon, and, as already mention,
933 | it will fall back to using a favicon if it’s available.
934 |
935 |
936 | Although Android is able to fallback to using the iOS icons, the
937 | no-HTML approach doesn’t work on the Android browser (tested in 2.3
938 | Gingerbread, 3 Honeycomb, 4.1 Jelly Bean), although there is
939 | anectodotal evidence it does work
941 | in and 4.2 Jelly Bean’s default browser.
942 |
943 |
944 |
945 |
946 | Windows
947 |
948 |
949 | Web applications intended to be "pinned" rely on meta elements whose
950 | name is "msapplication-square{w}x{h}logo", where
951 | {w} and {h} are the width and height of the
952 | logo.
953 |
954 |
955 | Like iOS, when the proprietary declarations are missing, Windows will
956 | also search the root of a website for specifically named files that
957 | follow the afformentioned file name pattern. If no suitabile icons
958 | are found, Windows will fall back to using a favicon.
959 |
960 |
961 | According to the
963 | IE Blog, Internet Explorer "only downloads the tile
964 | image when the user pins the site to his or her Start screen so sites
965 | don’t incur additional bandwidth costs.
966 |
967 |
968 |
969 |
970 |
971 | Security and privacy
972 |
973 |
974 | The act of adding an application to the home screen serves as a cue to
975 | alter the security policy of an application. For example, in iOS, and
976 | application that has been added to the home screen will no longer share
977 | cookies, localStorage, IDB, etc. with the Safari Web browser. The OS
978 | will also reset all its API permissions, so, for example, any
979 | previously granted permission to access location services that occurred
980 | in the browser are forgotten once the application is added to the
981 | homescreen - the end-user will need to re-enable such permission again
982 | after the application is launched from the homescreen.
983 |
984 |
985 | Furthermore, by adding the application to the home screen, the
986 | application gains its own independent privacy settings in iOS's privacy
987 | menus. This is shown in the figure below.
988 |
989 |
990 |
992 |
993 | iOS privacy settings for location services. Shown is Forecast, which
994 | is an installed web application as well as the Safari Web browser.
995 | Here, users can disable the . More importantly, disabling location
996 | services for the Web browser does not affect the ability of Forecast
997 | to access location services.
998 |
999 |
1000 |
1001 |
1002 |
1003 | Start page
1004 |
1005 |
1006 | A user can add a web application to the home screen from anywhere
1007 | within a website (e.g., while reading a document). Returning to that
1008 | same document when the application starts back up might not be ideally
1009 | what either the user or developer want.
1010 |
1028 | Proprietary uses: msapplication-starturl (found in 403
1029 | sites from the October dataset, 8 of those also declared lin[rel=home])
1030 |
1031 |
1032 | MS related info:
1033 | http://msdn.microsoft.com/en-us/library/ie/gg491732(v=vs.85).aspx
1034 |
1035 |
1036 |
1037 |
1038 | Orientation
1039 |
1040 |
1041 | An application's orientation can be unlocked, meaning that the layout
1042 | of the application can adapt to portrait or landscape, or can be locked
1043 | to either portrait, landscape. Portrait or landscape can be further
1044 | constrained to being flippable or not. Flippable means that if the
1045 | device is rotated 180 degrees, the display is also flipped. Otherwise,
1046 | the orientation remains locked.
1047 |
1048 |
1049 | A developer may also want to lock to a different orientation depending
1050 | on the class of the device, the size of the screen, or the aspect ratio
1051 | of the screen used. For example, use portrait on a phone and landscape
1052 | on a tablet. For example, BBC iPlayer does this (on iOS?).
1053 |
1054 |
1055 | Proprietary solutions - Firefox OS allows applications to be locked to
1056 | particular orientation through their manifest format
1057 |
1058 |
1059 |
1060 |
1061 | Navigation
1062 |
1063 |
1064 | The ability to navigate documents by activating hyperlinks is a
1065 | fundamental aspect of the Web platform. It's what makes the web, the
1066 | web. However, when applications are added to the homescreen of a
1067 | device, and indicate that they are able to function standalone, the
1068 | navigational behavior has some side effects. These side effects
1069 | generally emerge because the applications are launched in full screen
1070 | and devoid of any browser chrome, and so the are no visual indicators
1071 | for the user to get a sense of where they are (as they normally would
1072 | with an address bar). As such, different browsers deals with this
1073 | problem in different ways.
1074 |
1075 |
1076 |
1077 | Android - Chrome beta
1078 |
1079 |
1080 | Chrome allows users to freely navigate web documents by following
1081 | hyperlinks: this works both same origin and across origins. However,
1082 | if a user navigates away from the origin from which the application
1083 | was installed, a small bar with the new origin to be shown. This
1084 | appears to be done as a security precaution to give the user a better
1085 | sense of where they are (specially if they have unexpectedly been
1086 | navigated to another domain).
1087 |
1088 |
1089 |
1090 |
1091 | Windows 8 - IE 11
1092 |
1093 |
1094 | In Windows 8, launching web applications that have been "added to
1095 | Apps" simply open again in IE.
1096 |
1097 |
1098 |
1099 |
1100 | iOS7 Safari
1101 |
1102 |
1103 | On iOS, once an application is added to the homescreen,
1104 | hyperlink-based navigation from one document to another is no longer
1105 | possible by default: this is because in iOS, the "default behavior"
1106 | of activating a link is to open the link in Safari (note however,
1107 | navigating within the document itself via fragment identifiers is
1108 | still possible). The default behavior can be prevented by capturing
1109 | all click events generated by HTML a elements. Once an
1110 | event has been captured, and prevented from performing the default
1111 | action, then the window.location can be manually set by
1112 | script. Preventing the default behavior and manually handling the
1113 | navigation is illustrated by the code below.
1114 |
1125 | Once click events are captured and the default behavior prevented, it
1126 | becomes possible not only to navigate a document within the same
1127 | origin, but also to other origins. However, every document will need
1128 | to include code similar to the one above in order for navigation via
1129 | hyperlinks to continue to work.
1130 |
1131 |
1132 |
1133 |
1134 | Firefox OS
1135 |
1136 |
1137 | ...
1138 |
1139 |
1140 |
1141 |
1142 |
1143 | Requirements
1144 |
1145 |
1146 | A standardized solution:
1147 |
1148 |
1149 |
MUST provide a mechanism that allows a developer to indicate that
1150 | the application is able to function as standalone. If no such
1151 | indication is given by the developer, then the application MUST launch
1152 | in the Web browser as normal. That is, the solution MUST NOT conflate
1153 | bookmarking with allowing a web application to be launched as
1154 | standalone.
1155 |
1156 |
MUST provide a mechanism for the application to check (e.g., via
1157 | script) if it's running as a standalone application.
1158 |
1159 |
MAY provide a mechanism for the developer to interrogate the
1160 | browser about what UI chrome is available (e.g., is there a navigation
1161 | bar?).
1162 |
1163 |
MUST provide a means to include a name for the web application.
1164 | This name is not the same as the document's title, though the document
1165 | title could serve as the name if the name is missing.
1166 |
1167 |
SHOULD provide a means to support a short name for the application.
1168 |
1169 |
MAY provide a means to delcare application names in multiple
1170 | languages.
1171 |
1172 |
MUST specify the default navigation behavior for a standalone
1173 | application.
1174 |
1175 |
MUST clarify the security model with regards to how permissions and
1176 | data are shared with the web browser from which the web application was
1177 | bookmarked or installed. This could possibly allow the developer to
1178 | opt-into (or out of) sharing cookies, storage data, etc. with the
1179 | browser that installed the application.
1180 |
1181 |
MUST provide a means to declare multiple iconic representations
1182 | suitable for a range of contexts. In addition, the solution SHOULD
1183 | allow developers to declare the dimensions, format, as well as a means
1184 | to indicate the preferred device-pixel-ratio at which each icon should
1185 | be used.
1186 |
1187 |
MUST provide a means to declare the orientation that the
1188 | application needs to be in when launched. The solution MUST allow the
1189 | application to fully lock to a particular orientation, or allow a
1190 | soft-lock to a particular orientation: meaning that if the user flips
1191 | the device 180 degrees, the document is also flipped.
1192 |
1193 |
MUST provide a means that allows the developer to declare the URL
1194 | that will be opened when the application is launched. This URL
1195 | overrides the URL from which the document was added to the homescreen.
1196 |
1197 |
SHOULD standardize an API for adding web applications to the
1198 | homescreen.
1199 |
1213 |
1214 |
1215 |
1216 |
--------------------------------------------------------------------------------
/ios_standalone/README.md:
--------------------------------------------------------------------------------
1 | # The state of standalone apps on iOS
2 | For this study, we examined 360 web applications that claim to be capable of running "standalone" in iOS (i.e., the web application asserts that it's usable outside the context of iOS's default browser). We put those claims to the test by manually checking if the apps could, in fact, be used as standalone. To make sure our study is as representative as possible we randomly selected the apps we tested from Alexa's top 78,000 websites.
3 |
4 | ## Add to home screen
5 | Through the use of the "add to home screen" option in Safari, iOS has allowed users to add web apps to the home screen of an iPhone since the 2009 release of iOS2.1. Web developers could make use of this capability to put their web apps on an equal footing as native apps on the user's home screen.
6 |
7 | 
8 |
9 | Over the last 4 years, this capability has seem some uptake in the wild. Through JavaScript libraries, [such as the one created by Matteo Spinelli](http://cubiq.org/add-to-home-screen), iPhone users occasionally encounter a custom pop-up banner suggesting that they "install" the website they are viewing to the home screen.
10 |
11 | 
12 | It's not uncommon to find web applications that ask the user to "install this web app on your iPhone: tap `` and then **add to homescreen**" on the iPhone.
13 |
14 | There are some obvious issues with this pop-up banner approach: not only is it inconsistent across web applications, but it requires developers to both "sniff" for the browser, and then tie a UI component of their own website to that of Safari.
15 |
16 | This is a gamble on the part of the developer, in that Safari can change the look and position of this button at anytime. This problem can be clearly seen above: note there are two kinds of buttons (shown in detail below). If Apple was to relocate or change the look of this button (as it did in iOS7!), it could potentially lead to confusion amongst users.
17 |
18 | 
19 | The iOS6 and iOS7 bookmark buttons, on the left and right respectively.
20 |
21 |
22 | It also means that if another browser tries to provide this functionality, it will have to put the bookmark button in the same location as Safari. Or the burden is put on developers to create a new pop-up banner that points to the right spot in the new browser, so users will then know how to add the web application to the home screen.
23 |
24 | Chrome Beta for Android is also [experimenting with adding web applications to the home screen](https://developers.google.com/chrome/mobile/docs/installtohomescreen), so the above may actually start occurring sooner rather than later.
25 |
26 | ## Purpose of this study
27 | The ability to install a web application to the home screen of a device is currently a topic of interest at the W3C (see the [manifest spec](http://w3c.github.io/manifest/)) and in the web development community:
28 |
29 | * Paul Kinlan's [Add to Home Screen Is Not What the Web Needs. Is It?](http://paul.kinlan.me/Add-to-homescreen-not-the-answer/)
30 | * PPK’s thoughts on [Installable Web Apps](http://www.quirksmode.org/blog/archives/2014/02/installable_web.html)
31 | * [Discussion on twitter](https://twitter.com/marcosc/status/436522185641824256).
32 |
33 | As there is no standardized way to do this in browsers, there are a number of working groups trying to piece together all the bits that would be needed to make installable web apps a standard part of the web platform. These groups include [WebApps](http://www.w3.org/2008/webapps/), [SysApps](http://www.w3.org/2012/sysapps/), and the [Web and Mobile IG](http://www.w3.org/Mobile/IG/).
34 | We hope this study can help inform the standardization of installable web apps currently taking place at the W3C. In particular, we hope that by looking at how developers are making use of the dominant proprietary mobile platform that provides this "add to home screen" capability, we can get an insight into the challenges users, developers, and implementers will face if akin technologies are standardized through the W3C and then become a part of the Web platform.
35 |
36 | ## Definitions
37 | A web application claims to be standalone if it declares the following in its markup:
38 |
39 | ```HTML
40 |
41 | ```
42 |
43 | Or its XHTML equivalent:
44 |
45 | ```HTML
46 |
47 | ```
48 |
49 | Navigated means that the user can follow hyperlinks (or interact with the document) without being thrown back into the default web browser.
50 |
51 | ## Key questions
52 | This study set out to answer the following questions. From the sites that claim to function as standalone, how many:
53 |
54 | * Are truly able to function as standalone?
55 | * Have a custom icon?
56 | * Claim to be standalone, but are actually just desktop sites?
57 | * Are standalone and mobile, but don't declare an icon?
58 | * Claim to be standalone, but have a mistake in their markup that prevents them from working as standalone?
59 |
60 | ## Key findings
61 | The number of sites claiming to run as standalone is insignificant: of all sites we had access to, they represent 1.4% of the dataset (i.e., 1097 out of 78,155 claim to be [`apple-mobile-web-app-capable`](https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref/doc/uid/TP40008193-SW3). So, despite this capability being available since 2009, and irrespective of iOS being the dominant mobile platform, few developers bother to create standalone web apps.
62 |
63 | Despite these 1097 sites claiming they can be used as standalone, what we found was that the majority of web apps (90%, or 324 out of 360) **can not be used as standalone**. Only a tiny fraction (10%, or 36 out of 360) are able to run as standalone - and 28% of those had significant limitations (described below). There is, in fact, a greater percentage (12%) of desktop sites masquerading as installable web apps than there are actual standalone applications.
64 |
65 | Another significant problem is that 85% (307 out of 360) of apps rely on a user's ability to follow hyperlinks. iOS standalone apps don't support following hyperlinks: unless a developer intervenes via JavaScript, the default action is to open links in Safari. The data effectively busts the myth of "single page apps": we found that almost no developers build single page apps in practice for this class of application.
66 |
67 | Of those 36 apps that were [true standalone web apps](#true-app) (i.e., has an icon, is usable on a mobile device, can be navigated), 10 (28%) of those had issues where they either left the user stranded without being able to "go back" - or worst, suddenly navigated to the desktop version of the site. The only option for a user is to drop back to the home screen and open the application again. This causes iOS to load the page that was originally bookmarked. This itself has problems, in that if the user leaves a web app, its state is effectively lost - meaning the application can lose data.
68 |
69 | In other cases, a web application mostly worked but then it was not possible to perform some critical task within the application (e.g., a purchase). In such cases, the application returned the user back into Safari. Others, like [nest.com](http://nest.com), make a best effort at working as standalone, but throw the user back to the default web browser at random points.
70 |
71 | On the up-side, the majority of web apps (76%) where designed to work on a mobile phone, even if only 13% of those could actually be navigated.
72 |
73 | Icon usage, overall, was also fairly healthy - 56% of the web apps we tested included an icon. However, we discovered that at least some web apps included dummy icons from pre-purchased templates - meaning more than one web app included an icon that had nothing to do with the application itself and had the same icon as another site.
74 |
75 | Oddly, many web apps (5%, or 19) incorrectly claim that they can run as standalone - but contain a markup error in their HTML that prevents the application from actually doing so! Of those, 12 out of 19 (63%) even go as far as to include an icon. These icons are still useful when the app is added to the home screen or bookmarked - just the web apps won't run as standalone.
76 |
77 | For more details, see the "[Other observations](#other-observations)" and the "[all questions](#all-questions)" section.
78 |
79 | ## Recommendations to implementers/W3C
80 | From our findings, this is what we would recommend implementers and the W3C consider when standardizing this technology.
81 |
82 | * It has to be possible for users to follow hyperlinks in standalone applications. Even though iOS doesn't support this functionality, the data clearly shows developers rely on this core capability of the Web.
83 | * It needs to be possible to open some links in the system default browser: it doesn't make sense to open some links, like ads, within the application.
84 | * It has to be possible to open a browser window within the application: this is to allow OAuth style authentication (which are blocked from working in iframes).
85 | * It needs to be possible for the user to navigate "back". A significant number of a apps, unfortunately, leave users stranded without a way to "go back" in their browsing history. This is sometimes outside the developers control (e.g., an authentication screen at a different domain doesn't support going back). Having some ability to always go back seems critical to make this class of web application usable by the general public.
86 | * Do not expect, or encourage, developers to create single page applications. Some will, but they will likely do it wrong. Most everyone won't: it's too hard, unnecessary, and evidently error prone.
87 | * Don't expect applications will have good metadata or icons.
88 | * Automatically generated metadata and template engines will likely be an issue. A lot of sites don't seem to test (or might not even know) that their websites supports running as standalone.
89 | * To avoid the issue of UA-specific pop-up banners, a standard way to "install" an application is needed: either through and API and/or some declarative means.
90 | * It needs to be possible to be able to jump between web apps and native apps without requiring the developers to constantly save state. That is, leaving a standalone web application should work the same as jumping from one browser tab to another in a desktop browser.
91 |
92 | ## Criteria
93 | The following is the criteria that we assert an application must meet in order to be a true standalone application.
94 |
95 | Firstly, the web application must have an icon that allows it to be distinguished amongst native applications. This is illustrated below, where the Slashdot icon is easy to locate amongst native iOS applications.
96 |
97 | 
98 | Slashdot icon amongst native apps.
99 |
100 | Secondly, all critical functionality of the application is self contained, without requiring browser chrome to make the application usable. Again, the Slashdot web application running as standalone serves to exemplify such functionality.
101 |
102 | 
103 | Slashdot is fully functional as an application. When necessary, it provides its own interface elements to enable navigations (e.g., a back button). A [video](video/slashdot.mp4) is available.
104 |
105 | Thirdly, the web application must be usable on a mobile phone. That is, the application's creator has made an effort to adapt the content of the application to a mobile device — particularly an iPhone. The criteria we used here was: either the app's creator has made an obvious effort to use common conventions of mobile web applications (e.g., a menu button at the top-right hand side of the screen, as shown below); or the content of the web application is legible and UI components are usable without requiring the user to zoom in (achieved by explicitly declaring a ``).
106 |
107 | 
108 | Nest, on the left, exemplifies a typical "mobile site". The Squawka site on the right exemplifies a desktop site masquerading as a standalone web application. Note how the Squawka site would not be easy to use on a mobile device (requires the user to zoom in, pan around, UI components are hard to press, etc.)
109 |
110 | ## Methods and limitations
111 | This study was conducted using the [webdevddata.org](http://webdevddata.org) dataset. The data was collected over an approx. 12 hour period on the 31st of October, 2013. Over those hours, the response page from 78,155 domains were collected (the crawler follows redirects and saves any `HTTP 200 OK` response). The [source for the crawler](https://github.com/Webdevdata/fetcher) is available on GitHub.
112 |
113 | The domains are fetched in order (from most popular to least) from Alexia's top 1 million sites at the time the data was downloaded. Note that some domains return the same data (e.g., google.com, google.co.uk, etc.). It is assumed that the size of the dataset reduces the influence of these duplicate domains.
114 |
115 | The dataset was filtered for files that matched the CSS selector `meta[name="apple-mobile-web-app-capable"][content="yes"]` (i.e., any `meta` element that has a `name` attribute "`apple-mobile-web-app-capable`" and whose `content` attribute is "`yes`"). This search was done using a custom tool, which was developed by the WebDevData Community Group. The tool makes use of a HTML parser, so to avoid false positives that would result from simply doing a text search. The tool does not load or execute scripts, however. This means that any website that dynamically inserts `meta` elements cannot be matched by the tool. We assumed that relatively few, if any, sites actually do this - primarily because of the frequency in which `meta` elements appear in HTML pages.
116 |
117 | The list of the resulting 1097 matching files are available as a [gist on Github](https://gist.github.com/ernesto-jimenez/9073492). Statistically speaking, we consider this our [population](http://en.wikipedia.org/wiki/Statistical_population) - i.e., our "set of individuals or objects of interest" as defined on Wikipedia.
118 |
119 | To define our sample size, we applied [[Cochran](#cochran)]'s correction formula for populations sizes less than 50,000:
120 |
121 | ```
122 | n1 = 384/(1+384/1097)= 284
123 | ```
124 |
125 | So, according to [[Cochran](#cochran)]'s correction formula, a minimum of 284 sites would need to be sampled to attain a 95% [confidence level](http://www.stats.gla.ac.uk/steps/glossary/confidence_intervals.html#conflevel) (error of 5%). Because we knew there would likely be issues with the sites (e.g., site is down, etc.), and because of redundancies (discussed below), we followed an oversampling technique and randomly selected 500 sites instead. From the 1097 sites, in order to then derive the random sample, the following ECMAScript was used over the dataset.
126 |
127 | ```JS
128 | rand = [];
129 | for(var i = 0; i < 500; i++){
130 | var randKey = Math.random() * data.length;
131 | var itemKey = Math.floor(randKey);
132 | //add it to our collection
133 | rand.push(x[itemKey]);
134 | //remove item just collected
135 | x.splice(itemKey, 1);
136 | }
137 | rand.join(",\n")
138 | ```
139 |
140 | Although we had 500 sites to sample, the reason we ended up with 360 sites was because of time constraints and the redundancies described below. Each site takes about 1 minute to load and check. The sites where manually loaded in Apple's iOS Simulator over a 4 day period between 16-20th of February 2014. The settings for the simulator were "iPhone Retina (4-inch 64Bit)" simulating iOS 7.0. This is shown below.
141 |
142 | 
143 | iOS simulator and settings.
144 |
145 | The [data](https://gist.github.com/marcoscaceres/9041272) is split across four columns:
146 |
147 |
148 |
site
149 |
The domian of the site being examined.
150 |
icon
151 |
If the application includes a custom icon
152 |
mobile
153 |
Is the site a mobile site.
154 |
navigates
155 |
Once launched, is it possible to navigate around the application?
156 |
157 |
158 | The data is coded as follows:
159 |
160 |
161 |
0
"no"
162 |
1
"yes"
163 |
-1
"markup error". Only applies to the "navigation" column.
164 |
165 |
166 | The data was then imported into [SQLite3](http://www.sqlite.org/).
167 |
168 | ```SQL
169 | .mode csv
170 | .import apps.csv webapps
171 | ```
172 |
173 | As all we needed was count and percentages, SQL queries were then used to perform the statistics. See the "[All questions](#all-questions)" section for the actual SQL used.
174 |
175 | ### Redundancies and issues in the data
176 | Although all the domains in the dataset are unique, some domains return the same data as other domains. For example:
177 |
178 | * [sc.com](http://sc.com) is the same as [standardchartered.com.sg](http://standardchartered.com.sg)
179 | * Others redundant sites included, [pricegrabber.co.uk](http://pricegrabber.co.uk), [katproxy.com](http://katproxy.com), [pscufs.com](http://pscufs.com), [rezultati.com](http://rezultati.com), [suite101.net](http://suite101.net), and [meusresultados.com](http://meusresultados.com).
180 |
181 | Some sites returned a `HTTP 403 Forbidden` or simply would refused to connect. This happened even though they worked fine when the original dataset was collected in October 2013:
182 |
183 | * [trknck.com](http://trknck.com)
184 | * [partnerspay.com](http://partnerspay.com)
185 | * [pixable.com](http://pixable.com)
186 |
187 | Some sites did not provide enough information to test all three aspects (icons, navigation, mobile). For example, [webcamtoy.com](http://webcamtoy.com) contains an icon, is mobile, but doesn't provide any interaction or navigation: it tells the user to go to the desktop site instead. As such, it was excluded.
188 |
189 | 
190 | [webcamtoy.com](http://webcamtoy.com) tells the user to load the desktop site instead.
191 |
192 | Some sites declared themselves as standalone through markup, but when loaded in Safari redirect to a mobile version that excludes the required markup. Some examples of sites that do this:
193 |
194 | * [soniarykiel.com](http://soniarykiel.com)
195 | * [tapiture.com](http://tapiture.com)
196 | * [pullandbear.com](http://pullandbear.com)
197 | * [www.larena.it](http://www.larena.it)
198 |
199 | ## Other observations
200 | Some sites, like [youbeli.com](http://www.youbeli.com/), ask the user to add their application to the home screen. However, after the user relaunches the application and clicks on any link, they are thrown back into Safari.
201 |
202 | # All questions
203 | This section lists the questions that we could ask from the data we collected; as well as how those questions are expressed as SQL.
204 |
205 | ### What percentage of web apps are truly able to function as standalone?
206 |
207 | **Answer**: 10%. See the definition of a [true standalone web application](#true-app). See also the caveats below.
208 |
209 | ```
210 | select count(*)
211 | from webapps
212 | where icons is "1" and navigates is "1" and mobile is "1";
213 | 36
214 | ```
215 |
216 | Some applications allow navigation, but then unexpectedly navigate to the desktop version of the web app:
217 |
218 | * [radardedescontos.com.br](http://radardedescontos.com.br)
219 | * [soluto.com](http://soluto.com)
220 | * [kingcounty.gov](http://kingcounty.gov)
221 |
222 | Some web apps provide simple interactions like searching. However, they throw the user back into Safari for any critical functionality (e.g., making a purchase):
223 |
224 | * [nest.com](http://nest.com)
225 | * [songkick.com](http://songkick.com)
226 | * [suite101.fr](http://suite101.fr)
227 | * [urbita.com](http://urbita.com)
228 |
229 | The following web apps work initially, but then leave the user stuck at certain pages. As there is no back button, there is not much the user can do but to quit the app:
230 |
231 | * [sumall.com](http://sumall.com)
232 | * [wisedock.de](http://wisedock.de)
233 | * [comediansincarsgettingcoffee.com](http://comediansincarsgettingcoffee.com)
234 |
235 | ### What percentage of web apps claim to be standalone, but are actually just desktop sites?
236 | **Answer**: 12%.
237 |
238 | ```SQL
239 | select select count(*)
240 | from webapps where
241 | navigates is "0" or navigates is "-1";
242 | 43
243 | ```
244 |
245 | ### What percentage of web apps rely on the user being able to follow hyperlinks?
246 | **Answer**: 85%.
247 |
248 | ```SQL
249 | select count(*)
250 | from webapps
251 | where navigates is "0" or navigates is "-1";
252 | 307
253 | ```
254 |
255 | ### How many web apps are mobile?
256 | **Answer**: 76%.
257 |
258 | ```SQL
259 | select count(*)
260 | from webapps
261 | where mobile is "1";
262 | 274
263 | ```
264 |
265 | ### How many web apps are desktop sites?
266 | **Answer**: 24%.
267 |
268 | ```SQL
269 | select count(*)
270 | from webapps
271 | where mobile is "0";
272 | 86
273 | ```
274 |
275 | ### How many web apps have a custom icon?
276 | **Answer**: 56%.
277 |
278 | ```SQL
279 | select count(*)
280 | from webapps
281 | where icons is "1";
282 | 202
283 | ```
284 |
285 | Even though some web apps have an icon, the icon is actually from a purchased theme (my theme shop). Hence the icon doesn't match the application. This is indicative that developers don't check their sites or templating will cause issues in the future for installable web apps.
286 |
287 | * [pixelbell.com](http://pixelbell.com)
288 | * [smashfreakz.com](http://smashfreakz.com)
289 |
290 | ### How many web apps DO NOT have a custom icon?
291 | **Answer**: 44%.
292 |
293 | ```SQL
294 | select count(*)
295 | from webapps
296 | where icons is "0";
297 | 158
298 | ```
299 |
300 | ### How many web apps can be navigated (irrespective of having an icon or being a mobile site)?
301 | **Answer**: 15%.
302 |
303 | ```SQL
304 | select count(*)
305 | from webapps
306 | where navigates is "1";
307 | 53
308 | ```
309 |
310 | ### How many web apps are desktop sites that can be navigated?
311 | **Answer**: 2%.
312 |
313 | ```SQL
314 | select count(*)
315 | from webapps
316 | where navigates is "1" and mobile is "0";
317 | 6
318 | ```
319 |
320 | ### How many web apps are desktop sites that can be navigated and have an icon?
321 | **Answer**: 1%.
322 |
323 | ```SQL
324 | select count(*)
325 | from webapps
326 | where navigates is "1" and mobile is "0" and icons is "1";
327 | 2
328 | ```
329 |
330 | ### How many web apps are desktop sites, but include an icon?
331 | **Answer**: 11%.
332 |
333 | ```SQL
334 | select count(*)
335 | from webapps
336 | where icons is "1" and mobile is "0";
337 | 38
338 | ```
339 |
340 | ### How many web apps can be navigated, are mobile, but don't declare an icon?
341 | **Answer**: 3%.
342 |
343 | ```SQL
344 | select count(*)
345 | from webapps
346 | where icons is "0" and navigates is "1" and mobile is "1";
347 | 11
348 | ```
349 |
350 | ### How many web apps claim to be standalone, but have a mistake in their markup that prevents them from working as standalone?
351 | **Answer**: 5%.
352 |
353 | ```SQL
354 | select count(*)
355 | from webapps
356 | where navigates is "-1";
357 | 19
358 | ```
359 |
360 | ### How many web apps don't work as standalone and include an icon?
361 | **Answer**: 12.
362 |
363 | ```SQL
364 | select count(*)
365 | from webapps
366 | where navigates is "-1" and icons is '1';
367 | 12
368 | ```
369 |
370 | # Acknowledgements
371 | Huge thanks to Ernesto Jiménez for writting the WebDevData tools that make processing this data possible and for providing the data about "apple-mobile-web-app-capable".
372 |
373 | # References
374 |
375 |
[Cochran]
376 |
Cochran, W. G. (1977). Sampling techniques (3rd ed.). New York: John Wiley & Sons.
377 |
378 |
--------------------------------------------------------------------------------
/ios_standalone/images/add_to_homescreen.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-webmob/installable-webapps/1289d506981ed12e236a13e037e6f1a7bffef86d/ios_standalone/images/add_to_homescreen.jpg
--------------------------------------------------------------------------------
/ios_standalone/images/bookmark.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-webmob/installable-webapps/1289d506981ed12e236a13e037e6f1a7bffef86d/ios_standalone/images/bookmark.png
--------------------------------------------------------------------------------
/ios_standalone/images/github.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-webmob/installable-webapps/1289d506981ed12e236a13e037e6f1a7bffef86d/ios_standalone/images/github.png
--------------------------------------------------------------------------------
/ios_standalone/images/mobile_vs_desktop.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-webmob/installable-webapps/1289d506981ed12e236a13e037e6f1a7bffef86d/ios_standalone/images/mobile_vs_desktop.jpg
--------------------------------------------------------------------------------
/ios_standalone/images/simulator.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-webmob/installable-webapps/1289d506981ed12e236a13e037e6f1a7bffef86d/ios_standalone/images/simulator.jpg
--------------------------------------------------------------------------------
/ios_standalone/images/slashdot.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-webmob/installable-webapps/1289d506981ed12e236a13e037e6f1a7bffef86d/ios_standalone/images/slashdot.jpg
--------------------------------------------------------------------------------
/ios_standalone/images/slashdot_icon.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-webmob/installable-webapps/1289d506981ed12e236a13e037e6f1a7bffef86d/ios_standalone/images/slashdot_icon.png
--------------------------------------------------------------------------------
/ios_standalone/images/webcamtoy.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-webmob/installable-webapps/1289d506981ed12e236a13e037e6f1a7bffef86d/ios_standalone/images/webcamtoy.jpg
--------------------------------------------------------------------------------
/ios_standalone/video/slashdot.mp4:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-webmob/installable-webapps/1289d506981ed12e236a13e037e6f1a7bffef86d/ios_standalone/video/slashdot.mp4
--------------------------------------------------------------------------------
/respecConfig.js:
--------------------------------------------------------------------------------
1 | var respecConfig = {
2 | // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
3 | specStatus: 'unofficial',
4 |
5 | // the specification's short name, as in http://www.w3.org/TR/short-name/
6 | shortName: 'reqs-installable-webapps',
7 |
8 | // if your specification has a subtitle that goes below the main
9 | // formal title, define it here
10 | // subtitle : "an excellent document",
11 |
12 | // if you wish the publication date to be other than the last modification, set this
13 | // publishDate: "2009-08-06",
14 |
15 | // if the specification's copyright date is a range of years, specify
16 | // the start date here:
17 | // copyrightStart: "2005"
18 |
19 | // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
20 | // and its maturity status
21 | // previousPublishDate: "1977-03-15",
22 | // previousMaturity: "WD",
23 |
24 | // if there a publicly available Editor's Draft, this is the link
25 | // edDraftURI: "http://berjon.com/",
26 |
27 | // if this is a LCWD, uncomment and set the end of its review period
28 | // lcEnd: "2009-08-05",
29 |
30 | // editors, add as many as you like
31 | // only "name" is required
32 | editors: [
33 | {
34 | name: 'Marcos Cáceres',
35 | url: 'http://marcosc.com',
36 | mailto: 'w3c@marcosc.com',
37 | company: 'Mozilla',
38 | companyURL: 'http://mozilla.com/'
39 | },
40 | {
41 | name: 'Ernesto Jiménez',
42 | url: 'http://ernesto-jimenez.com',
43 | mailto: 'me@ernesto-jimenez.com'
44 | }
45 | ],
46 |
47 | // name of the WG
48 | wg: 'Web and Mobile Interest Group (WebMob)',
49 |
50 | // URI of the public WG page
51 | wgURI: 'http://www.w3.org/Mobile/IG/',
52 |
53 | // name (without the @w3c.org) of the public mailing to which comments are due
54 | wgPublicList: 'public-web-mobile',
55 |
56 | // URI of the patent status for this WG, for Rec-track documents
57 | // !!!! IMPORTANT !!!!
58 | // This is important for Rec-track documents, do not copy a patent URI from a random
59 | // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
60 | // Team Contact.
61 | wgPatentURI: '',
62 | // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD,
63 | issueBase: 'https://github.com/w3c-webmob/installable-webapps/issues',
64 | otherLinks: [{
65 | key: 'Repository',
66 | data: [
67 | {
68 | href: 'https://github.com/w3c-webmob/installable-webapps'
69 | },
70 | {
71 | value: 'issues',
72 | href: 'https://github.com/w3c-webmob/installable-webapps/issues'
73 | },
74 | {
75 | value: 'Commit History.',
76 | href: 'https://github.com/w3c-webmob/installable-webapps/commits/gh-pages'
77 | }]
78 | }]
79 | };
80 |
--------------------------------------------------------------------------------
/sections/names.html:
--------------------------------------------------------------------------------
1 |
Application Names
2 |
3 |
Usage in native apps
4 |
5 |
Native platforms sometimes allow developers to define more than one display
6 | name for different use cases. The three options are:
7 |
8 |
9 |
Define a single display name. E.g.: Windows Phone and Firefox OS.
10 |
Define a default display name and an optional short name: the platform
11 | chooses whether to use the long or the short name depending on where it is
12 | going to be used. E.g.: iOS applications and W3C Widgets
13 |
Define a default display name and allow fine-grained control to set
14 | display names for different use cases. E.g.: Android Manifest file allows
15 | fine-grained control of the display name to be shown in the home screen,
16 | intents and different activities.
17 |
18 |
19 |
iOS and Android developers also need to define a listings name during the
20 | application submission process to the store which is used in the store
21 | listings. The Windows Store, on the other hand, requires developers to use the
22 | same app name in the manifest and the store.
23 |
24 |
Usage in web applications
25 |
26 |
Web applications have traditionally used the "title" element since it was
27 | available in the standards. However, due to HTML's origin as a
28 | document-publishing format, titles are applied "per page" and tend to be more
29 | descriptive or include status messages. This is annoying. It means users have
30 | to fix the name when adding an app to the home screen to remove page-specific
31 | or status messages.
The value must be a short free-form string giving the name of the Web
41 | application that the page represents. If the page is not a Web application,
42 | the application-name metadata name must not be used. There must not be more
43 | than one meta element with its name attribute set to the value
44 | application-name per document. User agents may use the application name in UI
45 | in preference to the page's title, since the title might include status
46 | messages and the like relevant to the status of the page at a particular
47 | moment in time instead of just being the name of the application.
48 |
49 |
50 |
Support in browsers
51 |
52 |
Internet Explorer
53 |
54 |
The "application-name" metadata defines the name of the Pinned site
55 | application instance. This is the name that appears in a tooltip when
56 | hovering over the Pinned site button on the Windows 7 taskbar. The
57 | application name is also appended to the window title of the Pinned site
58 | application instance.
59 |
If this element is missing, the document title is used instead.
60 |
61 |
62 |
Safari Mobile
63 |
64 |
Since iOS6, apple supports its own version of "application-name" metadata
65 | called "apple-mobile-web-app-title". However, it doesn't use
66 | "application-name"
67 |
68 |
If "apple-mobile-web-app-title" is missing, the document title is used
69 | instead.
70 |
71 |
Chrome Mobile and Firefox for Android
72 |
73 |
Both, Chrome Mobile and Firefox for Android only use the title tag.
74 |
75 |
Current tag ussage
76 |
77 |
We analysed the October data
78 | set (78,156 sites) to review the ussage of the different meta tags to
79 | define names:
80 |
81 |
82 |
"application-name": used in 1,571 sites.
83 |
"apple-mobile-web-app-title": used in 244 sites. 50 of
84 | those sites used "application-name" too.
85 |
86 |
87 |
We also analysed the length of the content of these tags (TODO: FIX wrong
88 | numbers due to character encoding issues):
89 |
90 |
91 |
92 |
93 |
metadata
94 |
min
95 |
max
96 |
mean
97 |
median
98 |
99 |
100 |
101 |
102 |
"application-name"
103 |
2
104 |
312
105 |
20
106 |
13
107 |
108 |
109 |
"apple-mobile-web-app-title"
110 |
2
111 |
190
112 |
11
113 |
8
114 |
115 |
116 |
117 |
118 |
Localizing Application Names
119 |
120 |
All native platforms allow for localization of the manifest contents. The
121 | way they handle localization falls into two categories:
122 |
123 |
124 |
Setting localization keys as names: rather than writing the name in the
125 | manifest the developer would assign a localization key as the name and let
126 | the platform translate it with the native localization system. Platforms
127 | doing this include Android and Windows Phone.
128 |
Adding localized content in the manifest: in this case, the developer
129 | includes the application name in different languages in the manifest itself.
130 | The Widgets spec does this by supporting xml:lang and Firefox OS
131 | incluides a locales property in the manifest.
132 |
133 |
134 |
In both cases, the system gets the application name in the different
135 | languages and chooses which one to show based on the default language. If a
136 | user changes the device's default language, all applications with localized
137 | names in the new language would get the translated names.
138 |
139 |
This is important to note since web localization is usually handled on the
140 | server and resources are served in just one language. E.g.: a web app would
141 | only have one "application-name" meta tag in the language of the
142 | HTML document. This means the device would only get one translation of the
143 | application name. If the user changed the default language, the device would
144 | not be able to translate the app name unless it requested the HTML document
145 | again in the new language.
61 | 
115 | 
141 | 
191 | 
194 | 
197 | 
200 | 
323 | 
347 | 
366 | 
383 | 
392 | 
440 | 
443 | 
446 | 
583 | 
627 | 
814 | 
833 | 
879 | 
992 |