Was ist ein CSS Framework?

Im Wesentlichen besteht ein CSS-Framework aus mehreren Stylesheets, die von WebentwicklerInnen verwendet werden können. Dabei können Defaultwerte für Farben, Layout, Fonts etc. konfiguriert werden. Im Allgemeinen werden Stylesheets von anderen Technologien je nach Framework unterstützt und erweitert. Gängige Beispiele dafür sind SASS und JavaScript.

Mit CSS Frameworks werden also fertige Stylesheets zur Verfügung gestellt und können im HTML-Code eingebettet werden. Viele Frameworks verfügen auch bereits über integrierte Komponenten-Klassen wie beispielsweise Cards, Navigationskomponenten und Sliders.

Bei den Frameworks wird zudem zwischen component- und utility-based unterschieden. Die meisten bekannten Frameworks wie beispielsweise Bootstrap sind komponentenbasiert. Sie legen also den Fokus auf bereits vorgefertigte Elemente. Utility-based Frameworks haben den Nutzen, EntwicklerInnen so gut wie möglich Flexibilität in ihrem Design und der Umsetzung zu gewährleisten. Diese bieten also Klassen an, damit Webentwickler ihre Komponenten effizient und flexibel für ihr individuelles Design implementieren können.

Wann macht die Verwendung eines CSS Frameworks sinn?

Ob ein CSS Framework nun wirklich verwendet werden soll oder nicht, über dieses Thema wird viel diskutiert. Einige meinen, es sei essentiell, um die Entwicklung effizient zu gestalten, da vieles an Arbeit durch den Einsatz des Frameworks abgenommen wird. Andererseits sind Designer oft der Ansicht, dass dadurch alle Webseiten ähnlich aussehen. Daher gilt es an jeden die Vor- und Nachteile für sein eigenes Projekt abzuwägen. Möchte man ein sehr spezielles, individuelles Design sind eventuell component-based Frameworks nicht die richtige Wahl. Andererseits können hierbei utility-based Frameworks ihren Beitrag leisten, einem die Entwicklung von eigenen Komponenten zu vereinfachen. Für kleine Projekte könnten zusätzliche Frameworks auch ein Overhead bedeuten, zumal auch Ressourcen dafür bereitgestellt werden müssen, welche womöglich in diesem Umfang nicht gebraucht werden. Alles in Allem muss jeder selbst entscheiden, ob er ein CSS Framework für sein Projekt selbst als sinnvoll erachtet oder nicht. Hier sind die Vorteile, die im Web am meisten genannt werden:

• Das Einhalten von UX-Richtlinien wird durch die Verwendung von vorgefertigten Klassen und Komponenten von CSS Frameworks vereinfacht. Es wird also dementsprechend ein Standard geboten, welcher cleane und symmetrische Layouts ermöglicht.
• Je nach Anforderung können EntwicklerInnen schneller eine benutzerfreundliche und optisch ansprechende Benutzeroberfläche erstellen, ohne bei Null anfangen zu müssen.
• Ist man selbst kein Webdesigner, können vor Allem komponentenbasierte Frameworks zum Thema Styling und Design eine Erleichterung bieten. Vor Allem für Projekte, wo kein individuelles Design von Bedeutung ist.
• Da diese Frameworks über gebrauchsfertige Stylesheets verfügen, ermöglicht ihre Verwendung eine schnellere Web-Entwicklung. EntwicklerInnen müssen sich somit nicht tiefergehend mit CSS-Code auseinandersetzen.
• Die Cross-Browser Functionality ist ein großer Pluspunkt bei CSS Frameworks. Sie machen es einfach Web-Anwendung oder Webseiten zu entwickeln, die mit mehreren Browsern und Browser-Versionen kompatibel sind.

Je nachdem welches Framework verwendet wird, gelten die genannten Vorteile. Wie bereits erwähnt, hängt die Effektivität und Effizienz der Nutzung eine Frameworks jedoch von Umfang und Typ des eigenen Projektes ab. Folglich wird ein kurzer Überblick über bekannte Frameworks gegeben.

5 Bekannte Frameworks im Überblick

Bootstrap

Das von Twitter entwickelte Framework Bootstrap (BS) ist wohl das bekannteste von allen. Es zählt zu den Komponenten-Frameworks, basiert auf den Technologien HTML, CSS, Javascript und unterstützt zudem SASS. Der Schwerpunkt von BS liegt vor Allem auf den Responsive- und Mobile-First Ansatz bei Webseiten und dessen Layout basiert auf einem 12-Grid-System.

BS bietet eine sehr umfangreiches Set an Komponenten an. Die breite Auswahl an Lösungen zu Overlays, Layouts, UI-Elemten, Buttons, Alerts, Cards und viele mehr zählen zu den größten Stärken von BS.

Ein weiterer Vorteil liegt in der übersichtlichen und sehr detaillierten Dokumentation. Es werden auch viele Beispiele zur Verwendung der vorgefertigten Komponenten und auch Erweiterungen angeboten.

Das Framework ist schließlich für jene geeignet, die Newcomer bei CSS sind und eine komponentenbasierte Basis für ihr Projekt benötigen.

TailwindCSS

TailwindCSS zählt derzeit zu den beliebtesten Frameworks und ist anders als Bootstrap utility-based. Das bedeutet, es werden hauptsächlich Utility-Klassen angeboten, um eigene Komponenten einfach und schnell entwickeln zu können. Die größte Stärke bei TailwindCSS liegt also im hohen Maß an Flexibilität und der minimalen Einschränkung bei der Website-Entwicklung. Dieses Framework ist vor Allem für jene geeignet, welche ein sehr spezielles und individuelles Design implementieren müssen. Der Einsatz dieser Utility-Klassen setzt jedoch ein bereits fortgeschrittenes Wissen über CSS voraus, um es effizient nutzen zu können.

Foundation

Auch Foundation ist ein responsives, Mobile-First CSS Framework und ist besonders für die Erstellung großer Web-Anwendungen geeignet. Es stellt Grid, HTML-, SASS- und CSS-UI-Elemente, Vorlagen und Code für Navigation, Buttons, Typografie, Forms und weiteres zur Verfügung. Es umfasst auch optionale Funktionalitäten, die von JavaScript-Erweiterungen angeboten werden. Eine Besonderheit stellt dabei beispielsweise die Motion-UI dar, eine SASS Bibliothek um flexible CSS-Animationen zu unterstützen. Zudem wird ein eigenes E-Mail Framework zur Verfügung gestellt.

Bulma

Bulma ist ein komponentenbasiertes, responsives CSS Framework, basiert auf CSS Flexbox, kommt ganz ohne JavaScript aus und verwendet dasselbe Grid-System wie Bootstrap. Der Fokus liegt auf lightweight, also darauf nur das zu verwenden was man auch wirklich zur Umsetzung benötigt. Um das zu ermöglichen, werden einige Optionen zur einfachen Anpassbarkeit mithilfe von Sass-Files, Webpacks und Variablen geboten. Bulma ist zudem mit Font Awesome 4 als auch mit Font Awesome 5 kompatibel.

Es ist in der Community aufgrund des leichten Erlernens und der einfachen Verwendung sehr beliebt.  Es bietet eine gute Anzahl an Komponenten, die leicht anpassbar und kombinierbar sind. Bulma ist also sowohl für Anfänger als auch fortgeschrittene EntwicklerInnen geeignet.

Material Design Lite & MaterializeCSS

Mit Material Design Lite können Webseiten mit dem Erscheinungsbild von Material Design erstellt werden. Es ist nicht auf JavaScript-Frameworks angewiesen und zielt darauf ab, die geräteübergreifende Verwendung zu optimieren.

MaterializeCSS ist ein weiteres Framework, dass basierend auf einen responsiven Ansatz entwickelt wurde. Ein großes Plus ist das ansprechende Design der Elemente. Es basiert auf dem Material Design von Google und bietet eine Reihe an UI-Komponenten an. Ein weiterer Vorteil liegt auf der einfachen Erlernbarkeit und es bietet eine sehr umfassende Dokumentation an.

Fazit

Je nach Projektgröße und -art können CSS Frameworks eine Erleichterung und Zeitersparnis in der Web-Entwicklung darstellen. Es gibt bereits einige Frameworks, die eine Menge an Funktionalität anbieten. Dabei wird in utility-based und component-based unterschieden. Ist eine hohes Maß an Flexibilität bei der Umsetzung von Bedeutung, kann Tailwind als utility-based Framework eine gute Option darstellen. Dieses Framework erfordert jedoch ein fortgeschrittenes Wissen über CSS. Ist man in diesem Bereich ein Newcomer und braucht ein Framework, dass leicht zu erlernen ist und bereits einiges an Komponenten anbietet, kann vor allem Bulma, Bootstrap oder aber auch Materialize eine gute Alternative bieten.

Quellen

https://www.browserstack.com/guide/top-css-frameworks

https://www.designerinaction.de/tipps-tricks/web-development/css-frameworks/

https://dev.to/theme_selection/best-css-frameworks-in-2020-1jjh

https://getbootstrap.com/

https://bulma.io/

https://getmdl.io/started/index.html

https://materializecss.com/

https://tailwindcss.com/docs/

https://getuikit.com/docs/introduction

The post CSS Frameworks appeared first on Mobile USTP MKL.

Zuständigkeiten

Für die Design Guidelines sowie die Umsetzung des Designs war Michaela zuständig. Auch die Frontendentwicklung mittels Android lag in ihrem Zuständigkeitsbereich.

Datenbank, Backendentwicklung mit NestJs und Content lag in Bettinas Zuständigkeit.

Masterklassen Zusammenarbeit

Im Rahmen des zweiten Semesters war außerdem im Rahmen einer anderen Lehrveranstaltung die Zusammenarbeit zwischen den Masterklassen angedacht. Somit hatten wir das Glück drei Kollegen beauftragen zu können uns bei der Erstellung der Inhalte zu unterstützen.

Lisa-Maria Gaff und Miriam Widhalm aus der Masterklasse Grafik Design haben uns wunderschöne Grafiken, Icons und ein fantastisches Logo kreiert und Sebastian Fröhlich war für die Fotografische Darstellung ausgewählter Wiener Sehenswürdigkeiten verantwortlich.

Einen herzlichen Dank nochmal an dieser Stelle!

Design

Michaela war für das Design und die grafischen Guidelines verantwortlich. Nach der Erstellung der Mockups und der Richtlinien wurde das Design verfeinert und schließlich fertiggestellt.

Technologien

Im Backend war die Entscheidung schnell klar, dass wir mit NestJs und TypeORM arbeiten wollen. Für die Frontendentwicklung war die Entscheidung etwas schwieriger. Für die Navigation an sich sollte MapBox verwandet werden. Die Technologie für die Frontendentwicklung fiel, aufgrund der Verwendung von Navigation, auf Android.

Funktionen

Als erstes wird nach der Installation der App ein Onboarding angeboten, um den Benutzer bereits zum Start die verschiedenen Funktionen vorzuführen. Nach der Registrierung beziehungsweise des Logins hat ein Benutzer die Möglichkeit sich die verfügbaren Städte anzusehen. Unter einem Benutzerprofil können die angegebenen Daten wie Username und Email eingesehen und auch das aktuelle Passwort auf ein neues abgeändert werden. Bei uns ist es momentan möglich Linz und Wien zu erforschen. Auch die zukünftig verfügbaren Städte sind hier aufgelistet aber noch nicht auswählbar.

Nach einer Stadtauswahl bekommt man die auswählbaren Kategorien, sowie die verfügbaren Sehenswürdigkeiten angezeigt. Auch die einzelnen Sehenswürdigkeiten kann man sich genauer ansehen und bekommt grundlegende Informationen zu den einzelnen Plätzen.

Ein großer Teil der App besteht im Planen der Routen. Ein Nutzer kann sich seine bereits erstellten Routen ansehen und auch die veröffentlichten Routen anderer Nutzer speichern und zu einem späteren Zeitpunkt gehen.

Für die Routenplanung haben wir einen Konfigurator. Durch die Eingabe mehrerer Parameter wird eine Sammlung an Sehenswürdigkeiten aus dem Backend geliefert, die der Nutzer im Frontend noch weiterbearbeiten kann bevor er diese abspeichern und gehen kann.

Einer der größten Teile der App bildet unter anderem die Routen-Optimierung und Navigation zu den einzelnen Teilzielen innerhalb einer Route ab. Diese Funktionalitäten wurden im dritten Semester noch in Android/Kotlin mit dem Plugin Mapbox Navigation und Optimization umgesetzt.

Learnings

Bettina

Für mich bestanden die größten Learnings in NestJs, sowie in TypeScript und TypeORM. Außerdem konnte ich mich weiter mit dem Aufbau von Datenbanken auseinandersetzen und auch mit der Serverkonfiguration für NodeJs Projekte. Auch konnte ich mich mit der API Definition unserer App auseinandersetzen und mir den Mailversand genauer ansehen.

Michaela

Da für mich die Entwicklung in Android (und Kotlin) ganz was Neues war, bestand für mich hier das größte Learning. Dazu gehörte nicht nur Basiswissen wie beispielsweise wie binde ich Vectoren oder Images ein, was ist eine Activity oder ein Fragment, wie verwende ich Navhosts, sondern auch der Einsatz von Retrofit und der Mapbox stellten eine neue und interessante Herausforderung für mich da. Jedoch habe ich das Styling von Screens und Einbinden von Ressourcen um Einiges zeitaufwändiger empfunden als in der Webentwicklung.

Wie es weitergehen soll…

Wir haben noch viele Ideen, wie wir FeliCity noch besser machen können. Unser Ziel wäre es hier, die App zu veröffentlichen und möglicherweise noch für iOS zu entwickeln.

Admin Interface

Das Admin Interface wurde mit dem React Framework NextJs entwickelt. Die Daten werden über die NestJs API abgerufen und aktualisiert. Anmelden können sich hier nur Admin Mitglieder, die damit die Berechtigung haben Inhalte zu aktualsieren. Das Interface soll also nicht, wie die zugehörige App zum navigieren genutzt werden, sondern zu Administrativen Zwecken verwendet werden. Das Design ist an die mobile Applikation angepasst.

Das Admin Interface soll dafür genutzt werden die Daten auf dem aktuellen Stand zu halten. Hierfür können die Formulare genutzt werden. Beispielsweise für eine Stadt:

Auf die gleiche Art und Weise können Städe, Sehenswürdigkeiten oder Routen erstellt oder aktualisiert werden.

The post FeliCity – Projektbeitrag appeared first on Mobile USTP MKL.

Dieser Artikel enthält einige nützliche Tipps, die bei der Optimierung des Pagespeeds helfen können.

Caching

Ladezeiten kann man verringern, indem man häufig oder dieselben Inhalte nicht immer wieder erneut laden muss. Und dabei hilft das Caching. Dabei wird zwischen serverseitigen- und Browser-Caching unterschieden werden.

Das serverseitige Caching ist bei häufigen Requests von Resourcen, wie Datenbank-Anfragen, hilfreich damit diese nicht immer wieder ausgeführt werden müssen. Mit Browsercaching kann man Ressourcen der Webseite im Browser zwischenspeichern, beispielsweise Headerelemente wie Bilder. Alles was man nicht unnötig nochmal neu anfordert bzw laden muss, hilft natürlich bei der Performance.

Bilder komprimieren und Lazy Loading

Oft haben Bilder eine größere Auflösung, als wirklich benötigt wird. Daher ist hier die Komprimierung dieser eine sehr gute Möglichkeit, um den Pagespeed hinaufschnellen zu lassen. Denn Bilder gehören neben CSS und JS zu den ressourcenintensivsten Formaten. Die Komprimierung von Bildern beschleunigt also den Download und die damit verbundene Ladezeit der Seite deutlich.

Eine weitere Möglichkeit ist das sogenannte Lazy Loading. Dieses Script sorgt dafür, dass Bildressourcen erst dann angefordert werden, wenn sie gebraucht werden, sprich wenn sie im Blickfeld der NutzerInnen sind. Vor allem bei sehr bildlastigen Websites kann man so bei der Ladezeit einiges einsparen. Aber nicht nur das Lazy Loading kann hier helfen, Ladezeit bei später gebrauchte Ressourcen einzusparen. Allgemein sich Gedanken zu machen welche Ressourcen früher benötigt werden und hier priorisiert die Elemente zu laden, kann sich positiv auf die Performance auswirken. Bildelemente die beispielsweise erst im Footer angezeigt werden, können also ruhig zum Schluss geladen werden anstatt ganz am Anfang.

Bad Requests

Das Anfordern von Ressourcen, die es nicht gibt, hat nicht nur eine schlechte User Experience zur Folge, sondern bremst auch erheblich die Performance der Webseite ein. Daher heißt es unbedingt darauf achten, ob Ressourcen die man anfordert wie beispielsweise Bilder oder Fonts, wirklich zur Verfügung stehen.

Optimierung von HTML, CSS und JS

Auch HTML, CSS und JS können so optimiert werden, um Datenvolumen einzusparen. Bei HTML kann beispielsweise bereits durch das Weglassen von überflüssigen Kommentaren und Leerzeilen Einiges eingespart werden. Auch sollte darauf geachtet werden, eher größere als viele JS- und CSS-Files zu generieren, um HTTP-Requests gering zu halten. Auch sollte man die CSS-Dateien vor JS einbinden, um den BenutzerInnen bereits die Darstellung der Seite früher richtig anzuzeigen. Denn Pagespeed-Analysetools kalkulieren den Score des Pagespeeds auch anhand des sogenannten “Cumulative Layout Shifts”. Dieser validiert, welche unerwarteten Änderungen BenutzerInnen am Layout der Webseite noch visuell wahrnehmen können. Allgemein lohnt es sich, sich Gedanken zu machen, wann welche Ressource wirklich benötigt wird. Ist es zb. Notwendig diverse JS-Dateien direkt im Header zu laden, oder reicht es im Footer?

Zusätzlich sollte man CSS- und JS-Dateien komprimieren. Dafür kann man beispielsweise JS-Taskrunner verwenden. Ist es ein kleines Projekt mit wenig CSS und JS, gibt es einige Webseiten die das Minimieren solcher Files gratis anbieten.

Critical CSS und Third Party

Oft rentiert es sich Inline-JS und -CSS zu verwenden, besonders auf der Startseite. Bei CSS ist es zum Beispiel von Vorteil ein sogenanntes „Critical CSS“ zu erstellen, dass die wichtigsten Styles liefert. Alle andern Styles können somit im Footer nachgeladen und wirken sich nicht mehr negativ auf den PageSpeed aus. Auch hier gibt’s es schon einige Webseiten, wo lediglich die Website-Adresse angegeben werden muss, um sich das Critical-cSS generieren lassen zu können.

Bei Third-Party Ressourcen wie beispielsweise Bootstrap, ist es übrigens auch oft ratsam eine CDN zu verwenden, anstatt diese auf dem eigenen Server bereitzustellen. CDNs weisen meist eine bessere Performance beim Ausliefern auf. Falls man aus irgendeinem Grund dennoch Bootstrap direkt am Server verwendet, dann kann es auch viel einsparen, nur die Elemente einzubinden (beispielsweise nur den Slider), die man wirklich benötigt.

Verwendung von Pagespeed-Analysetools

Es gibt bereits einige Webseiten, die detaillierte Informationen über eine Webseite in Bezug auf den Pagespeed liefern. Diese zeigen dir anhand verschiedener Kriterien einen bestimmten Pagespeed-Score, an dem du dich orientieren kannst. Dieser kann auch nützlich sein, die bereits ergriffenen Maßnahmen zu validieren. Der vermutlich bekannteste Analysereport bietet Google an: „PageSpeed Insights“. Diesen Report kann man auch direkt unter den Developer Tools in Chrome unter den „Lighthouse“ generieren lassen. Anhand verschiedener Kriterien wird der Score kalkuliert und genau aufgelistet, welche Ressourcen und Aufgaben am meisten an Ladezeit beanspruchen:

• First Contentful Paint: Die Zeit, welche für das Darstellen des ersten Textes oder Bildes der Seite benötigt wird
• Speedindex: Der Geschwindigkeitsindex gibt an, wie schnell die Inhalte einer Seite sichtbar dargestellt werden.
• Largest Contentful Paint: Largest Contentful Paint gibt an, wie lange das Zeichnen des längsten Texts oder des größten Bilds dauert
• Time to Interactive: Die Zeit bis Interaktivität entspricht der Zeit, die vergeht, bis die Seite vollständig interaktiv ist
• Total Blocking Time: Summe aller Zeiträume (in Millisekunden) zwischen FCP und Zeit bis Interaktivität, wenn die Aufgabendauer 50 ms überschreitet
• Cumulative Layout Shift: Cumulative Layout Shift misst die Bewegung sichtbarer Elemente innerhalb des Darstellungsbereichs.

Solche Analysetools sind also ein mächtiges Werkzeug, um bestehende Probleme auf der eigenen Webseite zu finden und mit den Empfehlungen diese zu beseitigen. Gmetrix bietet beispielsweise zusätzlich auch ein Wasserfall-Diagramm an, um genauere Wartezeiten von bestimmten Ressourcen analysieren zu können. Übrigens kannst du dir so ein Diagramm auch unter den Devtools im Chrome unter Netzwerk ansehen.

Fazit

Die Ladezeit ist ein wichtiges Qualitätskriterium der Webseite und bestimmt oft darüber, ob BenutzerInnen auf einer Webseite verweilen oder nicht. Es gibt Richtlinien, die dabei helfen können, die eigene Webseite zu optimieren. Dazu zählt das Cachen von häufig verwendeten identischer Daten. Ein wichtiger Punkt ist auch das Optimieren von Bildern und Quellcode-Ressourcen, wobei auch darauf geachtet werden sollte, ob diese überhaupt zur Verfügung stehen um Bad Requests zu vermeiden. Auch das Priorisieren der Ressourcen und die Verwendung von CDNs und Critical CSS beeinflussen die Ladezeiten positiv. Analysetools wie PageSpeed Insights und GtMetrix sind mächtige Werkzeuge, die detaillierte Reports über Pagespeed-Probleme der Webseite Aufschluss geben können.

Quellen

https://developers.google.com/speed/docs/insights/v5/about

https://gtmetrix.com/

https://wao.io/de/ratgeber/pagespeed-optimierung/

https://pixeltale.de/lazy-load/

https://www.klickkonzept.de/online-marketing-blog/seo/pagespeed-optimierung/

https://www.omsag.de/online-marketing-blog/seo/pagespeed-optimierung-mit-diesen-tipps-zur-blitzschnellen-website/

The post Pagespeed-Optimierung appeared first on Mobile USTP MKL.

Für die Evaluierung der Benutzerfreundlichkeit eines Software-Produktes haben sich in den letzten Jahren mehrere Methoden etabliert. Zu diesen Methoden zählt vor Allem das traditionelle „In-Lab Testing“, welches bereits als Hauptmethode für die Evaluierung der Usability von Software angesehen werden kann (Alghamdi et al., 2013). Jedoch sind traditionelle In-Lab Usability Tests auch oft mit erhöhtem Zeit- und Kostenaufwand sowie mit einer herausfordernden Rekrutierung verbunden (Schade, 2013). Auch aufgrund der aktuellen Quarantäne- und Reisebeschränkungen durch COVID-19 ist es vielen UX-ResearcherInnen derzeit nicht möglich, Usability-Tests im Labor durchzuführen.

Um vor Allem den Einschränkungen in Bezug auf den Aufwand, Kosten und Rekrutierungsproblemen entgegenzuwirken, wurde in den letzten Jahren bereits eine weitere Usability Evaluierungsmethode entwickelt, das Remote Usability Testing. Anders als bei traditionellen In-Lab Tests befinden sich ProbandInnen und ModeratorInnen bei dieser Form an zwei verschiedenen Orten. Diese Evaluierungsform unterscheidet sich in einer asynchronen (nicht moderierter) und synchronen (moderierter) Vorgehensweise (Alghamdi et al., 2013).

In diesem Artikel wird auf Basis einer Literaturrecherche eruiert, inwiefern sich das In-Lab Testen, asynchrone- und synchrone Remote Testing in deren Methodik, Interaktion mit ProbandInnen und in der Datenerhebung unterscheiden. Auch werden deren Kosten und Zeitaufwand gegenübergestellt. Im ersten Abschnitt wird die grundlegende Theorie zu den Usability Evaluierungen aufgearbeitet. Darauf aufbauend werden deren Unterschiede thematisiert, um wichtige Merkmale dieser Methoden zu eruieren. Der letzte Abschnitt die wesentlichen Ergebnisse der Gegenüberstellung von dem In-Lab -, asynchrone- und synchrone Usability Testing gegenüber.

2. Usability Testing

Um einen Vergleich zwischen den Usability Testing Methoden ziehen zu können, muss zuerst ein Verständnis für Usability Evaluierungen und deren Ziel geschaffen werden. Die Usability Evaluierung wird als die Bewertung der Benutzeroberfläche einer bestimmten Anwendung definiert, um deren tatsächliche oder wahrscheinliche Usability zu bestimmen (Alghamdi et al., 2013, S. 63, zitiert nach Koutsabasis et al., 2007).  Die ISO-Norm 9241-11 beschreibt die Usability als das Ausmaß der Benutzbarkeit eines Produktes durch bestimmte BenutzerInnen in einem bestimmten Nutzungskontext, um ihre Ziele effizient, effektiv und zufriedenstellend erreichen zu können (International Organization for Standardization, 2019).

Die Usability Evaluierung kann formativ oder summativ erfolgen. Die formative Evaluierung hat das Ziel, die Produktentwicklung voranzutreiben und wird daher während der gesamten Entwicklungsphase eines Produktes durchgeführt, wohingegen bei der summativen Vorgehensweise eine abschließende Bewertung im Mittelpunkt steht und daher am Ende der Entwicklung stattfindet (Alghamdi et al., 2013).

Bei der Usability Evaluierung gibt es mehrere etablierte Methoden, wobei das Usability Testing, die Usability Inspection und die Model-Based Evaluierung die am weitest verbreiteten sind. Usability-Tests haben vorrangig das Ziel, Informationen darüber zu erheben, wie BenutzerInnen das System verwenden und lokalisieren bestimmte Problemstellen innerhalb einer Schnittstelle. Gängige Techniken sind hierbei das traditionelle In-Lab Testing und das Remote Usability Testing (Alghamdi et al., 2013).

2.1 Traditionelles In-Lab Testing

Dabei befinden sich sowohl die Usability-SpezialistInnen als auch die ProbandInnen am selben Ort (Schade, 2013).  ModeratorInnen stellen TeilnehmerInnen Fragen und eine Reihe von Aufgaben, die sie bei der Verwendung des zu evaluierenden Produktes durchführen. In-Lab Tests weisen ein kleineres Sample auf und kommen meist in den zuvor erläuterten formativen Studien zum Einsatz, wo im Mittelpunkt die iterative Designverbesserung steht (Tullis & Albert, 2013).

2.2 Remote Usability Testing

Remote Usability Tests sind wie herkömmliche Usability Evaluierungen, mit dem Unterschied, dass TeilnehmerInnen und ModeratorInnen sich an verschiedenen physischen Orten befinden. ProbandInnen interagieren mit dem Softwareprodukt im eigenen Umfeld, wie beispielsweise von Zuhause aus, im Büro oder in einer anderen natürlichen Umgebung (Schade, 2013). Bei den Remote Usability Tests gibt es zwei wesentliche Unterteilungen in der Methodik. Hierbei wird unterschieden, ob es sich dabei um einen synchronen (moderierten) oder asynchronen (nicht moderierten) Usability Test handelt (Alghamdi et al., 2013).

2.2.1 Asynchrones Remote Usability Testing

Laut Alghamdi et al. (2013) sind bei asynchronen remoten Testverfahren BenutzerInnen sowohl räumlich als auch zeitlich von den EvaluatorInnen getrennt. Die TeilnehmerInnen verwenden hierbei ihre eigenen technischen Ressourcen, welche die Benutzeraktivitäten mithilfe interaktiver Programme oder aufgabenbasierten Umfragen steuern und messen (S. 66).

2.2.2 Synchrones Remote Usability Testing

Das synchrone Remote Usability Testing ist eine Methode zur Bewertung der Usability, die eine große Ähnlichkeit mit dem herkömmlichen In-Lab Testen aufweist (Alghamdi et al., 2013, zitiert nach Selvaraj, 2004). Der Hauptunterschied zu traditionellen In-Lab Tests besteht in der natürlichen Umgebung, aus welcher BenutzerInnen an der Studie teilnehmen und diese somit auch eigene Ressourcen verwenden können. Um die Evaluierung zu überwachen, befinden sich Usability-ExpertInnen im Labor und kommunizieren über das Internet mit den BenutzerInnen in Echtzeit (Alghamdi et al., 2013).

Folglich ähneln sich asynchrone und synchrone Remote Usability Tests in der natürlichen Umgebung, in der der Usability Test von den ProbandInnen durchgeführt wird. Traditionelle In-Lab Tests werden im Labor durchgeführt, wo sich ModeratorInnen als auch TeilnehmerInnen am selben Ort zur selben Zeit befinden. Der größte Unterschied, bei moderierten und unmoderierten Remote Usability Tests ist die zeitliche Trennung von ModeratorIn und TeilnehmerIn. Die Zeit stellt folglich auch den wesentlichen Hauptfaktor für die unterschiedliche Vorgehensweisen in diesen beiden Methoden dar, sowohl in der Planung, Verwendung von diversen Tools und Datenerhebungsmethodik. Diese wichtigen Merkmale werden in den nächsten Abschnitten diskutiert.

3. Ablauf und Methodik

Beim asynchronen Remote Usability Testing durchlaufen die TeilnehmerInnen ein vordefiniertes Skript mit Fragen und Aufgaben. Dabei werden die Daten automatisch erfasst und sind für Studien mit vielen TeilnehmerInnen geeignet (Tullis & Albert, 2013). Fragebögen werden verwendet, um BenutzerInnen anzuleiten, anstatt ModeratorInnen einzusetzen, wodurch finanzielle und zeitliche Ressourcen eingespart werden können (Alghamdi et al., 2013).

Ein weiterer Vorteil besteht darin, dass keine Skills für die Moderation benötigt werden, da die vordefinierten Online-Instruktionen die Rolle der EvaluatorInnen ablösen (Moran & Pernice, 2020). Dies bringt jedoch auch den Nachteil mit sich, dass ein Nachfragen bei unklaren Instruktionen während des Testens den TeilnehmerInnen nicht möglich ist. Auch gibt es nicht die Möglichkeit BenutzerInnen zu bitten, einen Kommentar bei Unklarheiten weiter zu elaborieren (Morgan & Pernice, 2020). Daraus wird interpretiert, dass der Durchlauf des Tests und die damit verbundenen Instruktionen mit einer genaueren Planung und verstärkter Durchführung von Pretests verbunden ist als bei In-Lab Evaluierungen und synchronen Remote Tests.

Synchrone Remote Usability Tests ähneln in der Methodik den herkömmlichen traditionellen In-Lab Tests. Anders jedoch als bei In-Lab Studien, wird es bei den moderierten Remote Usability Tests den ProbandInnen ermöglicht, aus ihrer natürlichen Umgebung heraus an dem Prozess teilzunehmen und ihre eigenen PCs zu verwenden (Alghamdi et. Al, 2013). Bei moderierten Remote Tests befinden sich BenutzerInnen und ModeratorInnen gleichzeitig in einer virtuellen Umgebung und kommunizieren in Echtzeit über technische Ressourcen und Anwendungen (Schade, 2013). Beiden Seiten ist es also möglich bei Bedarf weitere Fragen zu stellen oder zur Klärung aufzufordern (Moran & Pernice, 2020). Um dieses Setting bei synchronen Tests zu ermöglichen, kommen Videokonferenz- und Bildschirmfreigabeanwendungen zum Einsatz. Dadurch wird es ModeratorInnen ermöglicht, die Aktivitäten der BenutzerInnen zu beobachten und durch Videoaufzeichnungen die Durchführung der Testszenarien zu protokollieren (Alghamdi et. Al, 2013). Das Evaluierungsteam kann den Test somit auch gleichzeitig verfolgen und die Ergebnisse unmittelbar nach der Sitzung diskutieren (Moran & Pernice, 2020).

Vergleichsweise zu asynchronen Remote Usability Tests werden sowohl bei synchronen remote – als auch bei den In-Lab Tests Skills für das Moderieren benötigt. Schade (2013) meint hierzu, dass das Interpretieren von Stille am anderen Ende und dadurch das Wählen des richtigen Zeitpunktes für die Fragestellungen remote erschwert werden kann. Das gelte auch für In-Lab Studien, jedoch könnte diese Problematik bei moderierte Remote Tests verstärkt werden. In Bezug auf die Moderation meinen Alghamdi et. Al (2013) sowie Moran & Pernice (2020), dass die Methodik des Lauten Denkens zudem auch nur bei synchronen Remote Tests und In-Lab Tests Sinn ergäbe. Folglich kann diese Technik bei asynchronen Tests nicht die gewünschte Effektivität erzielen, zudem ModeratorInnen für die Anleitung und Aufforderung des lauten Denkens als essenziell angesehen werden können.

4. Datenerhebung und Effektivität

Laut Albert, Tullis und Tedesco (2010) eignen sich asynchrone Usability-Studien zum Erheben sowohl qualitativer als auch quantitativer Daten. Da Daten von vielen Teilnehmern gesammelt werden können, ist es möglich, in kurzer Zeit quantitative Daten aus einer großen Stichprobe zu erheben. Qualitative Daten können zudem beispielsweise über wörtliche Kommentare gesammelt werden, wobei BenutzerInnen ihre Erfahrung mit dem Produkt notieren (Albert, Tullis & Tedesco, 2010). Folglich eignen sich jedoch asynchrone Usability Tests vor allem für quantitative Studien, da hier eine größere Stichprobe als bei In-Lab und synchronen Remote Usability Tests möglich ist.

Tullis & Albert (2013) meinen, dass beim asynchronen Remote Testens die TeilnehmerInnen nicht direkt von den Usability-SpezialistInnen beobachtet werden können, wodurch es schwierig sein kann, problembasierte Daten zu erheben. Während asynchrone Studien eine hervorragende Möglichkeit seien, viele Daten zu sammeln, ist es zudem auch weniger ideal, wenn UX ResearcherInnen einen tieferen Einblick in das Verhalten und die Motivation der BenutzerInnen zu erhalten möchten. Auch Albert, Tullis und Tedesco (2010) sehen die Grenzen im unmoderierten Remote Usability Testing in der Evaluierung der Verhaltensweisen von BenutzerInnen, vor allem wenn komplexere Fragen involviert sind. Hier sei ein traditionelles Lab-Testing oder synchrones Remote Testing geeigneter.

Alghamdi et. al. (2013) äußern hierzu auch, dass der asynchrone Ansatz keine Beobachtungsdaten und Aufzeichnungen von plötzlichem verbalem Verhalten zulässt. Sie meinen, dass das zu einer Einschränkung der Gültigkeit und Genauigkeit der Ergebnisse führt und die Wahrscheinlichkeit verringert, dass Usability-Probleme entdeckt werden. Andererseits kann dies aufgrund der günstigen Kosten und der leichteren Zugänglichkeit für BenutzerInnen möglicherweise bedeuten, dass größere Stichproben analysiert werden könnten, was zu einem genaueren und realistischeren Ergebnis führen würde. Größere Stichproben bieten eine bessere Darstellung der BenutzerInnen, während eine natürliche Testumgebung die Testverzerrung ausgleicht, die in einem Labor auftreten kann. Dies führt häufig dazu, dass sich die Teilnehmer unter Druck gesetzt fühlen, was die Genauigkeit der Usability-Ergebnisse genauso beeinträchtigen kann (Alghamdi et. al, 2013, S.66, zitiert nach Bastien, 2008).

Eine Studie von Alghamdi et. al (2013) untersuchte diese beiden Testmethoden und stellte diese in Bezug auf deren Effektivität gegenüber. Die Untersuchung ergab, dass die synchrone Testmethode im Allgemeinen besser abschneidet als die asynchrone Testmethode, vor allem bei der Identifizierung von Usability-Problemen. Synchrone TestteilnehmerInnen waren zudem effektiver bei der Aufdeckung schwerwiegender und kritischer Usability-Probleme als solche im asynchronen Testdurchlauf. Die asynchronen Testteilnehmer führten die gestellten Aufgaben jedoch schneller aus und es wurde zudem herausgefunden, dass eine positive Korrelation zwischen der aufgewendeten Zeit zur Aufgabenlösung und den entdeckten Problemen bestand.

Daraus wird geschlossen, dass im Allgemeinen zwar eine breitere Stichprobe durch das asynchrone Testen verwendet werden kann, jedoch das Identifizieren von Usability Problemen durch die synchrone Methode effektiver ist. Auch für einen tieferen Einblick in Motivation und Gründe von Verhaltensweisen der BenutzerInnen ist die synchrone remote Methode oder das In-Lab Testen besser geeignet. In Bezug auf Metriken wie das Erheben der Task Performance macht es auch einen Unterschied ob das asynchrone oder synchrone Testen zum Einsatz kommt, zumal ProbandInnen von asynchronen Testverfahren laut der Studie von Alghamdi et. al (2013) eine schnellere Performance bei der Aufgabenerledigung aufweisen. Dabei muss jedoch auch erwähnt werden, dass ein kleines Sample bei dieser Studie verwendet wurde und vermutlich das Ergebnis nicht generalisiert werden kann.

5. Dauer der Test-Sessions

Ein weiterer bedeutender Faktor des asynchronen Testens ist die verfügbare Zeit für die Durchführung. Albert, Tullis und Tedesco (2010) meinen hierzu, dass in den meisten Usability-Labortests, ob persönlich oder synchron remote problemlos 60 bis 90 Minuten dauern können. Die meisten Online-Usability Studien sollten aufgrund der schwindenden Aufmerksamkeit von BenutzerInnen jedoch nur von 15 bis maximal 45 Minuten andauern. Auch Moran und Pernice (2020) nennen hierbei die kürzeren Test-Sessions bei einer durchschnittlichen Dauer von 20 Minuten der nicht moderierten Remote Usability Tests einen Nachteil gegenüber von In-Lab und moderierten Remote Evaluierungen. Die Testsitzungen bei moderierten Remote Usability Tests können hingegen länger dauern und lassen somit Raum für eine explorative Untersuchung des Produktes (Moran & Pernice, 2020).

Daraus wird geschlossen, dass Usability-Tests mit vielen und umfangreichen Aufgabenstellungen, welche länger dauern, entweder synchron remote oder im Labor durchgeführt werden sollten, um die Qualität des Evaluierungsergebnisses möglichst gering zu verzerren.

6. Rekrutierung und Qualität des Samples

Durch Remote Usability Tests wird die Rekrutierung bereits im Allgemeinen erleichtert, da man sich nicht aufgrund von Zeitressourcen und Kosten auf nahgelegene Orte einschränken muss. Auch wird es so ermöglicht, mit weniger Aufwand das Produkt in mehreren Ländern zu evaluieren. Somit wird eine große Reichweite an ProbandInnen ermöglicht (Albert, Tullis & Tedesco, 2010). Speziell das asynchrone Remote Usability Testing bietet für quantitative Daten die Möglichkeit eine größere Stichprobe für den Test zu rekrutieren (Tullis & Albert, 2013). Bei synchronen Remote Usability Tests wird meist ein kleineres Sample verwendet und deckt sich hierbei mit den In-Lab Tests.

Auch Moran und Pernice (2020) sehen in der Rekrutierung die Vorteile im asynchronen Testen. Allerdings erwähnen sie hierbei auch die damit verbundenen Nachteile in der Repräsentativität der BenutzerInnen, der Variabilität in der Motivation und im Engagement der TeilnehmerInnen für den Test und ein erhöhtes Risiko, dass TesterInnen in Ihrer Umgebung abgelenkt werden. Hier meinen sie, dass es weniger wahrscheinlich ist, dass bei der synchronen Evaluierung Teilnehmer Zeit mit Aktivitäten verbringt, die nicht mit dem Test zusammenhängen. Andererseits lässt diese natürliche Umgebung auch Situationen, in denen die BenutzerInnen das Produkt verwenden, realitätsnaher evaluieren, als in In-Lab-Evaluierungen (siehe auch Abschnitt 7). Daraus wird geschlossen, dass es auch stark darauf ankommt, ob diese Merkmale in der Studie von Bedeutung sind. Zudem könnte diese negativen Aspekte durch eine größere Stichprobe ausgeglichen werden. In Bezug auf die Repräsentativität des Samples sehen auch Albert, Tullis und Tedesco (2010) die Verwendung sorgfältig ausgewählter Screener-Fragen und -Kontingente als gute Lösung, um den passenden Teilnehmertyp zu finden und einer negativen Beeinflussung der Repräsentativität entgegenzuwirken.

7. Natürliche Umgebung

In einer typischen Labor-Usability-Studie werden TeilnehmerInnen aufgefordert, eine Reihe von Aufgaben auszuführen. Dabei kann die tatsächliche Erfahrung, die ProbandInnen in ihrer natürlichen Umgebung haben, verloren gehen. Dies können technische Aspekte wie die Größe des eigenen Bildschirms, die Systemleistung oder der verwendete Browser sein. Aber auch ablenkende Situationen im Alltag können somit nicht miteinbezogen werden, die man im Usability Labor so gut es geht kontrolliert (Albert, Tullis & Tedesco, 2010). Folglich kann durch das Remote Usability Testing die Realität bei der Verwendung des Produktes besser miteinbezogen werden.

Laut Albert, Tullis und Tedesco (2010) ist der bedeutendste Punkt der asynchronen Evaluierung, die gegebene Anonymität, wodurch die Beeinflussung des Ergebnisses durch die soziale Erwünschtheit wegfällt. Im Kontext von Usability Tests bedeutet das, dass TeilnehmerInnen die ModeratorInnen möglicherweise nicht enttäuschen möchten und daher ein positiveres Feedback geben, als wenn dieser Moderator nicht anwesend wäre. Online-Usability-Studien schließen diese Beeinflussung aus, da Daten anonym erfasst werden können (Albert, Tullis & Tedesco, 2010). Diese Beeinflussung bleibt sowohl bei In-Lab Tests als auch bei synchronen Remote Tests eine Problematik.

8. Fazit

Im Vergleich zu In-Lab Testing weist sowohl das asynchrone als auch das synchrone Remote Usability Testing einen großen Vorteil in Kosten – und Zeitaufwand auf, da die Reise zum Labor wegfällt. Zudem bietet das remote Testverfahren die Möglichkeit, die natürliche Umgebung der BenutzerInnen miteinzubeziehen. Dies kann vor Allem in Bezug auf die technischen Ressourcen einen Vorteil bieten, weitere Usability Probleme aufzudecken. Die größte Unterscheidung zwischen synchronen und asynchronen Testen ist die zeitliche Trennung, welche wesentliche Merkmale in der Durchführung und Planung bei beiden Methoden mit sich bringt. Bei den asynchronen Evaluierungen durchlaufen TeilnehmerInnen den Test ohne EvaluatorInnen und werden durch automatisierte Instruktionen durch den Test geleitet. Bei synchronen Tests sind ModeratorInnen und TeilnehmerInnen im Gegensatz dazu nicht zeitlich getrennt und kommunizieren über das Internet. Dabei kommen Aufzeichnungs-, Screensharing- und Videokonferenz-Tools sowohl für die Durchführung als auch Protokollierung zum Einsatz.

Unterschiede gibt es in der Dauer der Testsessions. Asynchrone Tests sollen aufgrund der Aufmerksamkeit der BenutzerInnen zirka 20 Minuten dauern, welche eine geringere explorative Untersuchung als bei synchronen remote und In-Lab Tests zu Folge hat. In Bezug auf die Quantität der erhobenen Daten ist bei dem asynchronen Testen eine größere Stichprobe möglich. Diese ist folglich für quantitative Studien sehr gut geeignet. Andererseits bieten synchrone remote – und In-Lab Tests einen geeigneteren Ansatz, um einen tieferen Einblick in die Verhaltensweisen und Motivation der BenutzerInnen zu erlangen. Auch ist die Thinking Aloud Methodik für asynchrone Tests nicht geeignet.

In Bezug auf die Moderation werden hierfür keine Skills beim asynchronen Testen benötigt. Jedoch ist, durch die wegfallende persönliche Moderation, die Planung von automatisierten Instruktionen vermutlich aufwändiger und mit intensiveren Pretests verbunden. In Bezug auf die Effektivität der zwei remoten Testverfahren, zeigte eine Studie, dass synchrone Tests besser abschneiden, wobei hier das Sample gering ausfiel und daher eine Generalisierbarkeit vermutlich nicht möglich ist. Auch in Bezug auf den Vergleich der Repräsentativität und Variabilität von Engagement der TeilnehmerInnen kann gedeutet werden, dass diese eine größere Herausforderung bei asynchronen Tests als bei synchrone und In-Lab Tests darstellt. Wobei im Gegensatz dazu asynchrone Tests als einziger drei Methodem die Anonymität gewährleistet und somit die soziale Erwünschtheit keinen negativen Einfluss auf das Testergebnis nehmen kann. 

Folglich bieten alle 3 Verfahren ihre Vor- und Nachteile. Der wesentlichste Punkt ist hierbei, ob es sich um eine quantitative Studie handelt. Dann ist vermutlich die asynchrone Methode am besten geeignet. Möchte man einen tieferen Einblick in Verhalten und Motivation der BenutzerInnen erfassen, sind synchrone Remote oder das In-Lab Usability Testing eine bessere Wahl. In Bezug auf Remote Testing im Allgemeinen in Vergleich mit In-Lab Tests ist wohl auch hier der Kosten- und Zeitaufwand ein bedeutender Faktor, der bei Remote Testing deutlich geringer ist.

Literaturverzeichnis

Alghamdi, A. S. et al. (2013). A Comparative Study of Synchronous and Asynchronous Remote Usability Testing Methods. International Review of Basic and Applied Sciences, 1(3). https://www.researchgate.net/publication/261557037_A_Comparative_Study_of_Synchronous_and_Asynchronous_Remote_Usability_Testing_Methods

Schade, A. (2013, 12 Oktober). Remote Usability Tests: Moderated and Unmoderated. Nielsen Norman Group. https://www.nngroup.com/articles/remote-usability-tests/

Moran, K. & Pernice, K. (2020, 12 April). Remote Usability Tests: Moderated and Unmoderated. Nielsen Norman Group. https://www.nngroup.com/articles/remote-usability-tests/

International Organization for Standardization. (2019). Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems. (ISO Standard No. 9241-210:2019). https://www.iso.org/standard/77520.html

Tullis, A. & Albert, B. (2013). Measuring the User Experience: Collecting, Analyzing and Presenting Usability Metrics (2^nd ed.). Elsevier.

Albert, B., Tullis, A. & Tedesco, D. (2010). Beyond the Usability Lab: Conducting Large-scale Online User Experience Studies. Elsevier.

The post In-Lab -, Asynchrones – und Synchrones Remote Usability Testing appeared first on Mobile USTP MKL.

PWAs können nützliche Features von Native Apps bieten, wie die Offline-Fähigkeit, Installierbarkeit oder der Empfang von Push-Benachrichtigungen. PWAs verringern also die Lücke zwischen der User Experience in webbasierten und nativen Anwendungen.

Nennenswerte Features sind:

• Die Möglichkeit Offline zu laufen
• Eine hohe Performance in Relation zu reinen Webanwendungen
• Background processing mit Serviceworkers in einem separaten Thread
• Der Zugriff auf die Sensoren des Endgeräts
• Die Unterstütztung von Push-Benachrichtigungen
• Installation der App über den Browser/Hinzufügen eines Icons am Homescreen

In diesem Artikel wird erläutert, wie man mit dem leistungsfähigen Framework ReactJs eine React-App für PWAs optimieren kann. Dazu werden wir uns das allgemeine Project-Setup von React ansehen, einen ServiceWorker implementieren, kurz auch das Manifest diskutieren und zum Schluss wie wir unsere App builden und diese installieren können.

React Project-Setup

Im ersten Schritt erstellen und initialisieren wir ein neues React-Projekt. Dazu installieren wir uns über NPM das create-react-app Modul in unserem Projekt-Folder. Dieses nimmt uns schon mehrere Konfigurationen und Setup für unsere PWA ab: npm install -g create-react-app

Jetzt kannst du über den Befehl create-react-app <app_name> das Projekt erstellen lassen.Ist die Projektstruktur angelegt, führen wir unsere App aus, um zu testen ob das Projekt-Setup funktioniert hat. Dazu wechseln wir in unser neu erstelltes App-Verzeichnis und starten die Webanwendung mit npm start

Hat alles funktioniert, solltest du nun folgende Seite über deinen localhost sehen:

Serviceworker

Im nächsten Schritt schauen wir uns den Public-Folder genauer an. Hier müssen wir nun einige Konfigurationen vornehmen, dass wir unsere erstellte React-App für eine PWA optimieren. Dafür brauchen wir im ersten Schritt einen Serviceworker.

Die technische Grundlage für eine PWA bilden die Serviceworker. Ein Serviceworker ist ein Code, den dein Browser im Hintergrund verarbeitet, um die Offline-Fähigkeit für Webanwendungen zu ermöglichen. Es fängt Requests vom Netzwerk ab und verarbeitet sie als Vermittler zwischen deinem Browser und dem Netzwerk. Dieses Skript ist nur im Produktionsmodus aktiv und übernimmt also das Caching und Ausliefern der Assets der Web-App.

Um den Serviceworker zu verwenden brauchen wir in unser public/index.html im body-Tag eine Abfrage, ob der Serviceworker von dem verwendeten Browser überhaupt unterstützt wird. Wenn ja, soll dieser beim Laden registriert werden.

Diese Codezeilen ermöglichen es uns nun, einen eigenen Serviceworker zu verwenden, dazu legen wir uns das definierte Script serviceworker.js im public-Folder an.

Um das ganze zu testen, öffnen wir die Developertools im Browser. Hier haben wir die Möglichkeit unter dem Reiter „Application“ unseren Serviceworker und das Manifest (dazu später mehr) anzusehen. Wichtig dabei ist, dass wir für das Testen den „Reload“ aktivieren. Danach löschen wir den Storage und laden die Seite nochmal neu, um zu sehen, ob unsere Registrierung erfolgreich war.

Nun brauchen wir Events und Konfigurationen für unseren Serviceworker. Das ist zum Einen der Cache und die Urls die gecached werden sollen. Dabei haben wir die „normale“ index.html und eine offline.html die angezeigt werden soll, wenn keine Internetverbindung besteht.

//cache aktivieren

const CACHE_NAME = “version-1”;

const urlsToCache = [“index.html”, “offline.html”];

//das ist der serviceworker

const self = this;

Events brauchen wir drei. Das erste Event installiert unseren Serviceworker. Wir öffnen damit den Cache und fügen unsere definierten Files hinzu:

//event für die Installation des ServiceWorkers

self.addEventListener(“install”, (event)=>{

  event.waitUntil(

    caches.open(CACHE_NAME)

      .then((cache)=>{

        console.log(“Opened Cache”);

        return cache.addAll(urlsToCache);

      })

  )

})

Nun probieren wir das Ganze im Browser aus. Wir löschen unseren Browser-Storage und laden die Seite neu. Danach solltest du, wenn alles funktioniert hat, die entsprechende „Opened Cache“-Message in der Konsole sehen. Beim erneuten „Reload“ sollte die Meldung nicht mehr ausgegeben werden, da nun der Cache bereits verwendet wird.

Nun bauen wir uns einen EventListener der auf unsere Anfragen horcht. „Requests“ können beispielsweise Images oder API-Calls sein. Wenn das Holen der angefragten Ressource fehlschlägt, bedeutet das, dass wir keine Internetconnection haben und liefern die offline.html zurück.

//auf Request horchen

self.addEventListener(“fetch”, (event) => {

  // Antwort mit angeforderter Ressource

  event.respondWith(

    //Request beispielsweise ein Image oder API-Call

    caches.match(event.request)

      .then(()=> {

        return fetch(event.request)

          .catch(()=> caches.match(“offline.html”))

      })

  )

})

Im nächsten Schritt brauchen wir noch einen EventListener der uns unseren Serviceworker aktiviert.

//aktivieren des SW

self.addEventListener(“activate”, (event) => {

  const cacheWhitelist = [];

  cacheWhitelist.push(CACHE_NAME);

  event.waitUntil(

    caches.keys().then((cacheNames) => Promise.all(

      cacheNames.map((cacheName) => {

        if(!cacheWhitelist.includes(cacheName)){

          return caches.delete(cacheName);

        }

      })

    )

  ))

})

Der Serviceworker ist nun soweit fertig! Jetzt kannst du dir eine x-beliebige offline.html Seite erstellen und dann testen wir den Code. Wenn alles funktioniert hat, wird immer der aktuellste Cache herangezogen und die Offline-Seite angezeigt werden, wenn keine Internetverbindung besteht. Dazu kannst du in den Entwicklertools den Reiter „Network“ verwenden. Hier stellen wir auf Offline um und laden die Seite neu.

Das war der schwierigste Teil! Mit dem Lighthouse-Audit schauen wir uns nun an, wie gut unsere App bereits für die PWA optimiert ist. Dazu lassen wir uns den Lighthouse-Bericht erstellen. Diesen findest du im Reiter “Lighthouse” in den Entwicklertools. Achtung! – gehe sicher, dass du auch den Network-Mode wieder auf Online umgestellt hast. Mit unseren derzeitigen Konfigurationen sollte der Report für die PWA schon relativ gut aussehen.

Dank unserer Initialisierung durch create-react-app wurden uns schon Konfigurationen für das Manifest abgenommen.

Manifest

Ein Web-App-Manifest ist standardmäßig in Create-React-App enthalten und ermöglicht es jedem, die React-Anwendung auf seinem Gerät zu installieren. In React ist das Manifest ein ganz normales Json-File wo verschiedene Properties definiert werden können, wie die App auf dem Homescreen nach Installation aussehen soll. Standardmäßig sind das der Name, die Beschreibung, das App Icon, die Theme-Farbe, die Display-Settings und auch die Starturl der App, wenn sie geöffnet wird.

Create-React-App hat all diese Konfigurationen bereits für dich vordefiniert, die du ganz einfach an deine eigene React-App anpassen kannst. Wichtig dabei ist, dass du es natürlich auch in deiner index.html einbindest.

    <link rel=”manifest” href=”%PUBLIC_URL%/manifest.json” />

Eine weitere Validierung, die im Lighthouse-Audit fehlgeschlagen ist, ist das maskable icon. Maskable Icons sind ein neues Format, das sicherstellt, dass das PWA-Icon auf allen Endgeräten entsprechend passt. Auf neueren Android-Geräten erhalten PWA-Icons, die nicht dem maskierbaren Symbolformat entsprechen, einen weißen Hintergrund. Um es als „maskable“ zu liefern, geben wir ein weiteres Property „purpose“ im Icons array in unserem Manifest an:

… 

 “icons”: [

    {

      “src”: “favicon.ico”,

      “sizes”: “64×64 32×32 24×24 16×16”,

      “type”: “image/x-icon”,

      “purpose”: “any maskable”

    },

…

Production-Build

Eine Validierung schlägt beim Lighthouse-Audit noch fehl. Es besteht derzeit noch kein Redirect von HTTP traffic zu HTTPS. Wir müssen also unsere App noch für die „Production“ builden und deployen. Dazu führen wir den Befehl npm run build aus, der uns unsere gesamten Ressourcen unseres Projektes „bundlet“ und einen Build-Ordner erstellt.

Um nun unseren Build zu veröffentlichen und zu testen, kannst du für Testzwecke beispielsweise die Seite netlify verwenden. Nach Veröffentlichung, wenn du den Weblink nun öffnest, solltest du eine fertig optimierte React PWA haben. Dazu kannst du sicherheitshalber erneut die oben beschriebenen Tests auf der Webseite und den Lighthouse-Audit durchlaufen lassen. Zum Testen des Offline-Modus würde ich zusätzlich noch empfehlen, einmal wirklich das Internet abzuschalten.

Installieren der App

Unsere PWA ist nun fertig optimiert und nun können wir die App auch installieren. In deinem Browser siehst du ein Plus-Symbol, welches dir erlaubt, die App auf deinen Homescreen hinzuzufügen und als App auszuführen. Dasselbe funktioniert über „App installieren“ am Smartphone über Chrome. Sobald du auf Installieren klickst, wird automatisch eine Verlinkung auf deinem Desktop erstellt und die App installiert.

Fertig ist deine erste React PWA!

Tipp: Es gibt auch einen eigenen Store für Progressive Web Apps wo du deine PWA veröffentlichen kannst. Diesen findest du unter https://progressiveapp.store

Zusammenfassung

Zusammengefasst sind PWAs Apps die über den Browser aufgerufen werden, sich jedoch wie Native Apps anfühlen. Sie bieten nützliche Features von Native Apps, wie die Offline-Fähigkeit, Installierbarkeit und weisen eine weit bessere Performance als reine Webanwendungen auf. Sie verringern die Lücke zwischen der User Experience in webbasierten und nativen Anwendungen.

Zusätzlich wurde erläutert, wie eine React-App erstellt und für PWAs optimiert werden kann. Verwendet haben wir dazu create-react-app, dass uns schon ein Projekt-Setup mit Vorkonfigurationen für unsere PWAs bietet. Auch der Serviceworker war ein großes Thema, der die technische Grundlage von PWAs darstellt. Mit Serviceworker kann eine PWA Ressourcen cachen und diese zwischensgepeicherten Daten verwenden, wodurch eine bessere UX ermöglicht wird. Damit können Web-Apps dynamisch geladen werden, während man durch die App navigiert und den Datenverkehr minimiert. Zusätzlich haben wir erfahren, dass uns das Manifest Konfigurationen für den Homescreen und die Installation ermöglicht.  Mit dem Lighthouse-Audit kann man PWAs auf ihre Optimierung testen. Schlussendlich wurde erläutert, wie man am Ende die PWA “buildet” und auf dem Endgerät installiert.

The post Erstellen einer PWA mit React appeared first on Mobile USTP MKL.

Im Rahmen der MKL „Mobile“ wurde daher die responsive Webanwendung HikingGuide implementiert. Die Aufgabenstel­lung bestand in der Erstellung und Implementierung eines Konzeptes, bei der ein QR-Code sinnhaft zum Einsatz kommen kann.

Der HikingGuide stellt Informationen über Wander­routen einer Region digital zur Verfügung. Die Idee bestand darin, Flyers mit dem QR-Code für die Webapp auf Infor­mationstischen von Wanderhotels zu platzieren. Der QR-Code soll dabei direkt auf die Region des Wanderhotels verweisen, um so direkt auf die gewünschten Wanderrouten zu gelangen. Die Anwendung differenziert hierbei auf die Regionen von Österreich, beispielsweise beliebte Wanderziele wie Fieberbrunn oder das Salzkammergut. Zudem zeigt es in einer Übersicht wichtige Tourdaten wie Schwierigkeitsgrad, Kilometer, Dauer und natürlich auch die Höhenmeter. Hat man die passende Route gefunden, kann durch eine Detailseite die Wegbeschreibung und Bilder der Route eingesehen werden. Zudem soll es die Möglichkeit bieten, eine digitale Wanderkarte über GPX oder auch die Wegbeschreibung als PDF herunterzuladen, um so während der Wanderung auch offline zur Verfügung zu stehen.

Folgende Technologien wurden für das Projekt verwendet:

ReactJS, React Bootstrap, SCSS, Laravel (PHP Framework), MySQL, REST API

Probiers aus!

Unter folgenden Link gelangst du zu der Web-Anwendung:

http://flock-1583.students.fhstp.ac.at

WICHTIG: Im Rahmen dieses Projektes wurden keine „echten“ Tourdaten oder GPX-Dateien passend zu der beschriebenen Route verwendet! Der Content dient daher nur als Repräsentation von Funktionalitäten der App.

The post Print to Mobile – HikingGuide appeared first on Mobile USTP MKL.