PWA Vorlage

Diese ist selbstverständlich in HTML5 oder höher aufzubauen. Es wird das Design über CSS3 gestaltet und die Dynamik über Javascript gelöst, wobei alle Javascript-Bibliotheken oder -APIs Dritter natürlich auch genutzt, also eingebunden, werden können.

Dieses Konstrukt, das im Web eben einer klassischen Webseite gleichkommt, wird bei einer PWA auch App-Shell genannt.

APP-Shell

HTML
Struktur

CSS
Design

JavaScript
Logik

Wie bei einer normalen Webseite

Es ist damit kein JAVA nötig

PWAs sind ja eigentlich eine Lösung für das ansonsten umständliche hybride Verfahren, in dem eine HTML5-WebApp durch einen nativen Java-WebClient geschoben wird. Das native Verfahren (.apk) soll ja nun hier überflüssig werden.

Einschränkung

Sollte eine Anwendung geplant sein, die mehr Mächtigkeit über das Smartphone haben soll, als es Javascript überhaupt möglich macht, dann hat es keinen Sinn, dies partout mit einer WebApp lösen zu wollen.

CMS - Content Managment System

Wie bei der WebSite auch, kann ein CMS eingesetzt werden. Wie gesagt KANN, MUSS ABER NICHT. Diese Seite hier ist auch nicht mit einem CMS generiert, sondern wurde mit den Fingern in einen Text-Editor getippt.

Eine Offline-Seite

Wenn das Gerät gar nicht am Internet angeschlossen ist, kann eine Offline-Seite auf das Gerät in den Cache gespeichert werden, die dann geladen wird. In dieser Seite kann z.B. draufstehen

Es ist aber auch so möglich, ein ganzes Spiel unterzubringen, das keinen ständigen Internet-Besuch braucht. Werr eine Applikation bauen möchte, die lediglich nur einmal geladen werden soll udn keine nwebseitige Anbindung benötigt, hat nun ein Verfahren, eben solche Applikationen ohne einen Store auf all die Endgeräte zu bringen, deren Browser die Progressiven Webapps auch unterstützen. Wohl dem, der nun den passenden Browser auf dem Markt bringt.

Jedenfalls sollte die Offline-Seite so aufgebaut werden, dass ein Nutzer diese auch offline nutzen kann.

Im Gegensatz zur PWA würde bei einer klassichen WebAPP (Bookmark auf dem Screen mit eigenem Icon) im Offline-Falle ein Netzwerkfehler angezeigt.

navigator.onLine

Vielleicht nützlich: Es gibt die Möglichkeit, den Netzwerkstatus des Endgerätes herauszufinden, und dann entsprechend zu reagieren. Denn wenn das Gerät wieder online ist, könnte es interssant sein, entsprechend zu reagieren.

navigator.connection (Chrome)

Ähnlich läßt sich reagieren, wenn die Verbindung zu schwach ist.

for ( element in navigator.connection )

keine Elemente, das Objekt gibt es in deisem Browser nicht.

unbekannt

Ein Design

eher ein responsives Design

Da mobile Geräte unterschiedlich groß sind und eine unterschiedliche Nutzung genießen, muss sich das Design dem Gerät anpassen. Übrigens nicht nur das Design, sondern auch die Bedienlogik.

Einen Viewport

@media rules

@media-rules sind nicht mehr der allerneuste WebDesigner*Innen-Schrei für Responsive Design, da die Endgeräte physisch zwar ihre Größen in etwa behalten (7cm * 14cm bleiben 7cm * 14 cm) , logisch hingegen aber immer größere Auflösungen bekommen (Das Samsung Galaxy S9+ hat zb 1440 x 2960 Pixel, das S5 hingegen hatte 360 x 640 Pixel. Die Auflösung kann höher sein, als ein gängiger Monitor in der Schule.)

Lieber ein dynamisches Design aufbauen, statt alles wegschalten

Ebenfalls kein wirklich spritziges Responsive Design ist, wenn alles an HTML ausgeliefert wird, und je nach Endgerät das mit CSS und Javascript weggeschaltet wird, was man nicht dort sehen möchte (Adaptives Javascript). Responsive Design verlangt eigentlich die Ausspielung der jeweils passenden Designs über Javascript (hipper wären Javascript-APIs, wenn man modular und vernetzend denken möchte), zumal die Eigenheiten und Mächtigkieten des Endegerätes meist eh über Javascript erkannt werden.

z.B.: Der Webclient, mit dem auf diese Seite zugegriffen wird, wird über das Object navigator ausgelesen:

Statt aber sich Browserweichen zu bauen, die sich am Namen des Browsers orientieren, ist es zukunftsorientierter, sich, wie schon gesagt, der Mächtigkeit des Browsers und seiner Umgebung anzupassen.

Auch PWAs (und natürlich WebSites) müssen umweltschonend geplant und realisiert werden. Jetzt geht es ja auch um die Kosten der Internetverbindung. Alles, was sich dann an HTML und unnötigen CSS einsparen läßt, sorgt auch für schnellere Ladezeiten.

Es muss aber soviel HTML strukturell mindestens statisch aufgebaut werden, so dass die Robots der Suchmaschinen auch etwas Futter haben. Robots können ja nicht denken oder gar gucken.

Es ist sozuagen das Ende des reinen WebDesigners eingeläutet, der nicht wirklich programmieren kann. Mal abgesehen davon geht es hier eh nicht um ScreenDesign, sondern eben um WebDesign, eigentlich um WebDevelopement. Spätestens jetzt müsste auch klar sein, warum. Heutige WebDesigner lösen ihre Javascript-Probleme mit jQuery, das ist eine Bibliothek, die einfaches Scripten edrlaubt, ohne dass alle möglichen Komplexitäten und Eigenheiten diverser Browser und Bertriebsysteme im Hintergund beachtet werden müssen.

Heutige Webseiten werden in komplexen APIs ausgespielt, so dass jeweils das aufgebaut wird, was je nach Gerät gebraucht wird.

Ein smartes Design

Es wird oft auf Denglisch gern von "Mobiles Design" geredet, was etwas wässerig ist. Mobil(e) sagt nichts über das Endgerät aus, sondern nur, welche Verbindung gewählt wurde: Mobile oder Wifi, bzw Ethernet ... WebDesign für Smartphones ist eigentlich kein abgespecktes Desktop-Design. Die Anwender sind bestimmte Dinge mit ihren Smartphones gewohnt. Diese sollten unterstützt werden.

Ein Touch-Icon

Das erinnert ein wenig an die alten Fav-Icons von Microsoft Explorer (Vorgänger von Edge).

Es ist eigentlich nicht so schlau, irgendein Bildchen in verschiedenen Größen abzuspeichern. Je nach Motiv ist es ratsam, es für kleinere Auflösungen nicht so bunt und zu kleinteilig zu gestalten, und für größere Auflösungen dann nicht blutleer und zu klobig werden zu lassen.

Beim Logo-Design sollte also auch darauf geachtet werden, diese Anforderungen erfüllen zu können. Denn, wenn das Icon doof oder zu unprofessionell aussieht, will es keiner auf sein teures Smartphone haben. Schade ...

Tipp: Bei Google, Apple und anderen gibt es massig Infos über das Gestalten smarter Icons

<link rel="apple-touch-icon" href="./assets/images/KlickiBunti-180x180.png" />

Eine Icon-Auflösung für den Splash-Screen

Der Custom Splash Screen erscheint dann, wenn die PWA (aber auch eine WebApp) vom Screen des Endgerät aus startet. Ab Chrome 47

Icon

{

 "src": "./assets/images/KlickiBunti-512x512.png",

 "sizes":"512x512",

 "type": "image/png"


}

Hintergrundfarbe

Weitere Angaben zum Screen

Icon-Hintergrundfarbe

Wenn die Icons auf dem Screen ein eigenes Rendering haben, z.B. Kästchen mit runden Ecken, nutzen sie diese Angabe.

Einen Namen, bzw Title

standalone

Eine WebApp kann mit und ohne Browser-Navigationselemente eingeblendet werden. Ohne ist dann so wie Ganzer Bildschirm.

Ein Manifest

SSL Verschlüsselung (HTTPS)

Für die Datenübertragung. Die ServiceWorker tauschen sensible Daten zwischen Nutzer und Server aus. Da ist es bestimmt nicht zu viel verlangt, wenn hier eine Verschlüsselung gefordert wird.

ServiceWorker

Eingebunden wird der ServiceWorker über Javascript und die ServiceWorker API des Browsers

Elegant ist natürlich, erst abzufragen, ob es überhaupt diese API im aktuellen Browser gibt. Außerdem ist es schlau, den ServiceWorker am Ende zu registrieren, wenn die Seite aufgebaut ist, und je nachdem, ob die Installation gelungen ist oder nicht, sich entsprechend bemerkbar zu machen.


<script>

if ("serviceWorker" in navigator) {

 window.addEventListener('load', function() {

  navigator.serviceWorker.register( "./service-worker.js").then(

   function(erfolg) {

    console.log( "ServiceWorker wurde registriert.", erfolg);

   }

  ).catch(

   function(fehler) {

    console.log( "ServiceWorker wurde leider nicht registriert.", fehler);

   }

  );

 });

}

</script>

48 x 48 Android mdpi
96 x 96 Android xhdpi
180 x 180 iOS
192 x 192 Android xxxhdpi

Was braucht eine Progressive WebApp ?

Eine Webseite

HTML, CSS + Javascript