Single-Page-Anwendungen: Alte und neue Lösungen für die Benutzeroberfläche/User Interface (UI)
Single-Page-Anwendungen (SPA) sind heutzutage der Standard für die Implementierung von Benutzeroberflächen für Webanwendungen. Neben der Bereitstellung einer benutzerfreundlicheren Erfahrung, die einer Desktop-Anwendung nahekommt, ermöglicht eine SPA den Entwicklern eine bessere Verwaltung des Datentransfers zwischen Anwendung und Server, wodurch sowohl die Last als auch die Wartezeit reduziert wird. Während der Prozess des Designs und der Entwicklung einer komplexen SPA mühsam sein kann, wurden die verschiedenen Probleme, die diese Art von Architektur aufwirft, mit modernen Entwicklungsframeworks wie Angular oder React weitgehend überwunden. Daher haben sich die Hauptherausforderungen nun auf den Bereich UX (User Experience) verlagert, wo sich die Anforderungen ständig dahingehend entwickeln, dass zu jedem Zeitpunkt so viele Informationen wie möglich zur Verfügung gestellt werden, während sich der Benutzer gleichzeitig darauf konzentriert, seine Aufgaben so effizient wie möglich zu erledigen.
Es gibt keine magischen Lösungen für die Gestaltung einer großartigen SPA. Solange wir an einen Browser gebunden sind, wird jede Benutzeroberfläche immer noch Elemente einer Website verwenden, was bedeutet, dass sie von vielen Benutzern als eine Reihe von „Seiten“ betrachtet wird, die über ein Menü zugänglich sind. Diese Benutzer werden immer versuchen, ihren Weg durch die Anwendung schnell zu finden, indem sie vertraute Interaktionsmuster verwenden, die manchmal nicht genau die sind, die sich der Designer vorgestellt hat. Darüber hinaus muss jede ursprüngliche SPA-Oberfläche eine feine Balance zwischen der Implementierung einer Vielzahl von kundenspezifischen Lösungen und der Beherrschung des Entwicklungsaufwands finden. Dies kann oft zu Übervereinfachungen und Inkonsistenzen führen, die sich aus der Wiederverwendung der gleichen Schnittstellenkomponenten für verschiedene Zwecke oder in unterschiedlichen visuellen Kontexten ergeben, ohne dass die Details der Aufgaben, die die Benutzer in realen Szenarien ausführen müssen, berücksichtigt werden.
Einige Benutzeroberflächen leisten gute Arbeit in Bezug auf die Benutzerfreundlichkeit, in den meisten Fällen mit großer Hilfe von Komponentenbibliotheken und Tools von der Stange (wie Material Design), die Richtlinien und Lösungen für die häufigsten Benutzeranforderungen enthalten. Dennoch, wenn man eine neue Benutzeroberfläche entwirft, insbesondere eine für eine große Unternehmensanwendung, sind die Einschränkungen und Limitierungen einer typischen Web-Oberfläche nicht einfach zu überwinden, und es gibt immer Raum für Verbesserungen.
Ein einfaches Benutzerszenario …
Beginnen wir mit einem recht häufigen Szenario: Die Benutzer möchten den Status eines bestimmten Projekts aus den Projekten, an denen ihr Team gerade arbeitet, aktualisieren. Sie öffnen die Liste der Projekte, filtern sie nach einigen Kriterien (z. B. Kundenname), um schnell das gesuchte Projekt zu finden, und klicken darauf, um dessen Details zu öffnen. Als Nächstes werden die Benutzer eine Liste von Aufgaben durchsehen, die sich auf das Projekt beziehen, die ihnen zugewiesenen Aufgaben finden, den Status einiger Aufgaben mit hoher Priorität ändern und dann eine neue Aufgabe für einen Mitarbeiter erstellen. Schließlich gehen sie zur Liste der Dateien, die sich auf dasselbe Projekt beziehen, und laden einige weitere Dokumente hoch.
… und einige Schnittstellenlösungen
Was wir oben beschrieben haben, ist eine Abfolge von Schritten, die linear bis zu einem Punkt (Projektdetails) verläuft und sich dann in zwei Teilschritte aufteilt, die jeweils über eigene zusätzliche Schritte verfügen. Wenn wir uns bestehende Anwendungen ansehen, werden wir mehrere Lösungen für die Implementierung eines solchen Szenarios finden.
Bei einem seitenbasierten Ansatz würden wir Komponenten für jeden Schritt erstellen und sie nacheinander anzeigen, basierend auf der Auswahl des Benutzers. Wir würden also zunächst eine Liste von Projekten haben, vielleicht unter Verwendung einer Tabellenansicht, um so viele Details wie möglich für jeden Datensatz anzuzeigen, mit üblicher Sortierung und Filterung. Wenn der Benutzer dann das gewünschte Projekt auswählt, ersetzen wir die Liste durch eine Reihe von Detailinformationen zu diesem Projekt. Einige Links werden für den Zugriff auf die Liste der zugehörigen Aufgaben und Dokumente bereitgestellt. Ein Klick auf einen Link ersetzt die Projektdetails durch die nachfolgende Komponente, in der wir vielleicht den gleichen Ansatz der Tabellenansicht mit Sortierung und Filterung für entweder Aufgaben oder Dokumente verwenden werden. Eine weitere Auswahl eines Elements aus der neuen Liste zeigt dessen Details an, eine Option, die für die Dokumente möglicherweise nicht benötigt wird, wenn alle Informationen in die Liste selbst eingepasst werden können. Der letzte Schritt wäre die Anzeige einiger Formulare zum Erstellen oder Bearbeiten von Aufgaben oder zum Hochladen von Dokumenten, oft in einem modalen Dialogfeld. Während dieser Ansatz eine einfache Navigation durch die Anwendung ermöglicht, ist die Gesamterfahrung der Benutzer unterdurchschnittlich, da sie durch eine Menge von Seiten hin und her gehen müssen, um ihre Ziele zu erreichen.
Eine zweite Lösung basiert auf einer einfachen Designregel: Man sollte immer eine Liste von Datensätzen und die Details des ausgewählten Elements aus dieser Liste gleichzeitig in einem geteilten Bildschirmlayout anzeigen. Die Bildschirmfläche wird besser genutzt, mit dem (eher geringen) Nachteil, dass eine geringere Anzahl von Spalten in der Tabellenansicht angezeigt werden kann (sie kann jedoch durch eine reaktionsschnellere generische Liste ersetzt werden). Die nachfolgenden Listen würden das gleiche Muster verwenden, wobei die Liste der Aufgaben paarweise mit den Details der ausgewählten Aufgabe angezeigt wird, während die Liste der Dokumente direkt mit dem Upload-Formular gepaart werden kann. Um so konsistent wie möglich zu sein, kann das Formular zum Erstellen/Bearbeiten einer Aufgabe vorübergehend die Aufgabendetailkomponente auf der rechten Seite des Bildschirms ersetzen, so dass ein modaler Dialog nicht erforderlich wäre. Diese Lösung bietet eine effizientere Art der Interaktion mit der Anwendung und wird häufig in Webanwendungen verwendet.
Eine dritte mögliche Lösung würde versuchen, alle Projektdetails und zugehörigen Daten auf einer einzigen „Seite“ anzuzeigen, während die Liste der Projekte weiterhin ihren eigenen Vollbildschirm haben kann. So sehen die Benutzer in einem mehrfach geteilten Layout alle Projektdetails, sowie die Liste der zugehörigen Aufgaben und die Details einer ausgewählten Aufgabe, die Liste der zugehörigen Dokumente und, zu gegebener Zeit, das Formular zum Erstellen/Bearbeiten der Aufgabe oder das Formular zum Hochladen von Dokumenten. Alle Optionen liegen auf dem Tisch (Bildschirm) für die Benutzer, die wählen können, was sie sehen und was sie in Bezug auf das ausgewählte Projekt tun wollen, ohne jemals die „Seite“ zu verlassen. Auf der anderen Seite besteht die Gefahr, dass sie auf einem derart überfüllten Bildschirm die Konzentration verlieren und den Server durch das Laden vieler Daten belasten, die sie am Ende vielleicht gar nicht nutzen. Trotz einiger offensichtlicher Vorteile ist dies also nicht wirklich die effizienteste Implementierung.
Um die Komplexität zu erhöhen …
Wie wir sehen, kann jede der oben genannten Lösungen eine brauchbare Schnittstelle für das Beispielszenario bereitstellen, jedoch mit unterschiedlichem Grad an Effizienz beim Erreichen der Benutzerziele oder bei der Handhabung der Kommunikation mit dem Server. Bei der Beurteilung der Vor- und Nachteile der einzelnen Ansätze müssen wir jedoch einige Faktoren berücksichtigen, die in einem realen Szenario sehr relevant sind. Erstens können die Datenstruktur und die Beziehungen zwischen Entitäten viel komplexer sein als oben beschrieben und sie können sich auch im Laufe der Zeit ändern. Erweitern wir also das Szenario um einige weitere Anforderungen. Zum Beispiel können wir feststellen, dass einige der Projektdokumente direkt mit seinen Aufgaben verknüpft sind. Die Benutzer sollten in der Lage sein, beim Erstellen oder Bearbeiten einer Aufgabe Dokumente hochzuladen, und diese Dokumente sollten auch in der Liste der Dokumente für das übergeordnete Projekt erscheinen. Oder die Benutzer sollen in der Lage sein, Aufgaben zu erstellen und ein Dokument anzuhängen (darauf zu verweisen), das bereits in der Dokumentenliste des Projekts vorhanden ist. Was ist, wenn wir einen anderen Datentyp in den Mix werfen, z. B. einige Kundenaufträge, die an das gleiche Projekt gebunden sind, Aufträge, die auch Beziehungen zu seinen Dokumenten und/oder Aufgaben haben? Was ist, wenn das Projekt mit einer bestimmten Liste von Benutzern (einem Team) verbunden ist, die ständig aktualisiert werden müssen? Was ist, wenn diese Benutzer unterschiedliche Rollen für das Projekt und/oder die Kundenaufträge haben sollen? Was ist, wenn einige Dokumente nicht nur aktualisiert, sondern auf der Grundlage einiger bereitgestellter Vorlagen erstellt werden sollen? Die Liste der Änderungen kann endlos fortgesetzt werden und es kann sein, dass wir nach einer Weile plötzlich feststellen, dass eine gut implementierte Schnittstellenlösung nicht mehr für die neuen Anforderungen geeignet ist. Ja, normalerweise kann eine Schnittstelle, die um Datentypen herum organisiert ist (Lösung 2), jede Komplexität leicht bewältigen, aber wie? Indem man die Last, die Beziehungen zu verstehen und die relevanten Daten zu finden, auf den Benutzer selbst überträgt. Und das wird niemals gut funktionieren. Dann gibt es noch das typische menschliche Verhalten, das berücksichtigt werden muss. Manchmal können die Benutzer den Fokus auf das verlieren, was sie gerade tun. Sie können vorübergehend durch Ereignisse außerhalb des Bildschirms abgelenkt werden, z. B. durch einen Telefonanruf oder ein Meeting. Außerdem wird die Art und Weise, wie sie die Anwendung nutzen, stark von ihrer Fähigkeit beeinflusst, sich zu organisieren. Sie können mit dem Ausfüllen eines Formulars beginnen und dabei feststellen, dass sie in einem anderen Teil der Anwendung nach zusätzlichen Informationen suchen müssen. Oder sie erinnern sich daran, dass ein anderer Schritt schon vorher hätte erledigt werden müssen. Anstatt sie mit all diesen Situationen alleine fertig werden zu lassen, sollte eine gute Benutzeroberfläche immer versuchen, die Benutzer so gut wie möglich bei der Überwindung von Hindernissen zu unterstützen, Fehler zu vermeiden oder zu beheben, während sie sich auf die Hauptaufgaben konzentrieren, die ausgeführt werden sollen.… und um die Komplexität zu bewältigen
Lassen Sie uns eine andere Lösung für die Benutzeroberfläche vorstellen, die zwar noch beweisen muss, aber recht effektiv zu sein scheint, wenn es darum geht, eine konsistente Benutzererfahrung in großen Geschäftsanwendungen zu gewährleisten. Diese Lösung mit dem Namen „Flow-Interface“ wurde hauptsächlich mit dem Ziel entwickelt, eine effektive Navigation durch die verschiedenen Abschnitte und Unterabschnitte einer komplexen Oberfläche zu ermöglichen, wobei ein besonderes Augenmerk auf hierarchische Datenstrukturen gelegt wurde, bei denen Baumansichten, die offensichtliche Wahl, von alternativen Navigationsmethoden begleitet werden. Zu den weiteren Zielen gehörte die Begrenzung der Anzahl von Server-Lookups durch eine sorgfältige Choreografie des Benutzerverhaltens um die wichtigsten Anwendungsfälle herum sowie eine effiziente Nutzung der großen Bildschirmfläche. (Hinweis: Wir werden hier nicht auf gängige Oberflächenelemente wie eine Kopfzeile oder eine Seitenleiste/ein Menü eingehen, da diese Komponenten in den meisten Anwendungen eher obligatorisch sind und normalerweise so implementiert werden, dass sie möglichst wenig Platz auf dem Bildschirm einnehmen). Das Flow-Interface-Konzept nutzt einige der besten Eigenschaften der zuvor beschriebenen Lösungen und löst gleichzeitig einige ihrer Hauptprobleme. Da die zweite Lösung den Platz auf dem Bildschirm gut ausnutzt, ohne zu viele Daten in ein einziges Layout zu packen, werden wir dort beginnen. Wir werden den Bildschirm in zwei Spalten aufteilen und die Liste der Projekte auf der linken Seite und die Details eines ausgewählten Projekts auf der rechten Seite anzeigen. Die Liste kann einen permanenten oder versteckten Filter sowie einige Sortieroptionen haben und wird ein Minimum an relevanten Informationen zu jedem Projekt in einem benutzerdefinierten Block anzeigen (keine Tabellenansicht). Für die Detailkomponente können wir optional wählen, de Informationen in Abschnitte zu gruppieren und jedes Datenelement in einem visuell unterscheidbaren Label-/Wert-Paar anzuzeigen. Die Idee ist, das Layout für die Komponenten desselben Typs konsistent zu halten, aber ansonsten können wir jedes geeignete Layout innerhalb einer Komponente verwenden.
Jetzt werden die Benutzer die Liste der zugehörigen Aufgaben für das ausgewählte Projekt öffnen wollen, indem sie auf die entsprechende Schaltfläche in der Komponente Projektdetails klicken. Dazu schieben sie die beiden vorhandenen Komponenten nach links (unter die Seitenleiste, falls vorhanden), ohne eine von ihnen aus dem DOM zu entfernen, und machen Platz für die neue Komponente: die Aufgabenliste. Am Ende haben wir dann zwei sichtbare Komponenten: die Projektdetails und die Aufgabenliste. Wir werden auch eine variable Navigationsleiste implementieren, die mit der Reihenfolge der Komponenten (dem Fluss) synchronisiert ist, wobei jede Komponente einen Link haben wird. In diesem Zustand zeigt die Navigation drei Links an, und durch Anklicken des ersten Links, der der ersten ursprünglich sichtbaren Komponente entspricht, schieben wir den Fluss nach rechts und bringen die Projektliste wieder ins Blickfeld. Wir können auch einige Pfeile für die Navigation nach links und rechts zwischen den Komponenten bereitstellen, ebenso wie Tastaturäquivalente.
Die gleichen Regeln gelten für die Ausführung der nächsten Schritte. Die Aufgabendetailkomponente wird als vierter Schritt im Ablauf geöffnet, rechts neben der Aufgabenliste, so dass der Benutzer sowohl die Liste als auch die Details gleichzeitig sieht. Für das Aufgabenbearbeitungsformular werden wir jedoch eine neue Regel hinzufügen. Wenn der Benutzer auf die Schaltfläche „Bearbeiten“ klickt, nimmt die Formularkomponente den Platz der Aufgabendetails im Fluss ein, anstatt sich als neue Komponente zu öffnen. Das ist in Ordnung, weil wir alle Informationen über die Aufgabe im Formular beibehalten werden, so dass die Details nicht mehr auf dem Bildschirm angezeigt werden müssen. Wenn die Benutzer anschließend die Änderungen speichern, nimmt die aktualisierte Aufgabendetailkomponente wieder ihren Platz im Ablauf ein, und das Formular wird entfernt.
Wir können den Fluss leicht weiter ausbauen mit einer Liste von Dokumenten, die mit der aktuellen Aufgabe in Verbindung stehen. Das wäre die gleiche Komponente, die für Projektdokumente verwendet wird, aber bereits gefiltert, um nur die anzuzeigen, die mit der Aufgabe verbunden sind. Ein Formular zum Hochladen von Dokumenten kann folgen und so weiter. Aber was passiert, wenn die Benutzer zur ersten Komponente im Ablauf, der Projektliste, zurückgehen und ein anderes Projekt auswählen? Wir zeigen die neuen Projektdetails als zweite Komponente an, aber wir entfernen auch alle folgenden Komponenten aus dem Fluss, da sie möglicherweise Daten enthalten, die nicht mit dem ausgewählten Projekt in Verbindung stehen. Es ist ein logischer Schritt, und die Benutzer werden ihn sofort verstehen.
Wir haben also bisher drei Hauptmethoden, um Komponenten in einem Ablauf zu verwalten: Hinzufügen einer neuen Komponente (immer auf der rechten Seite, als nächster Schritt im Ablauf), Entfernen einer Komponente (zusammen mit allen nachfolgenden Komponenten von diesem Punkt an) und Ersetzen einer Komponente durch eine andere (während wiederum die nächsten Komponenten entfernt werden, falls vorhanden). Diese Methoden ermöglichen es dem Benutzer, verschiedene Sequenzen von Aktivitäten zu verwalten, indem er bei jedem Schritt auswählt, was er als nächstes sehen möchte. Außerdem bedeutet die gleichzeitige Anzeige von zwei Ablaufspalten (aber nicht dieselben festen Paare wie in Lösung 3), dass die Benutzer immer Zugriff sowohl auf die Daten, die sie sehen oder ändern wollen (die Komponente auf der rechten Seite), als auch auf ihren Kontext (die Komponente auf der linken Seite) haben.
Was wir am Ende erhalten, ist eine dynamische Benutzeroberfläche, die sich an verschiedene Szenarien anpassen kann, während ein einziges Navigationskonzept verwendet wird. Natürlich wirft das gleichzeitige Vorhandensein vieler Komponenten (auf oder außerhalb des Bildschirms) einige Probleme in Bezug auf die Leistung oder die Aktualität der Informationen auf, so dass ein allgemeiner Kommunikationsmechanismus erforderlich ist, um sicherzustellen, dass die Änderungen, die an einer bestimmten Komponente vorgenommen werden, auf eine andere übertragen werden. Auf einer eher technischen Ebene bedeutet dies die Implementierung einer Lösung für das Senden von Daten und Befehlen zwischen Komponenten basierend auf ihrer ID, ihrem Typ oder ihrer aktuellen Position im Ablauf. Darüber hinaus kann die Schnittstelle dem Benutzer die Möglichkeit geben, einige Aktionen wie das Aktualisieren oder Schließen einer Komponente manuell auszuführen.
Multitasking
Das Flow-Konzept mag bei der Beschreibung kompliziert erscheinen, hat sich aber bereits in realen Anwendungen als sehr effektiv erwiesen und ist so einfach zu erlernen, dass es sogar noch erweitert und zu einem „Multi-Flow“ werden könnte. Wie der Name schon sagt, kann die Benutzeroberfläche mehrere Flows gleichzeitig bereitstellen, die in Registerkarten getrennt sind, so dass der Benutzer jeweils einen in die Ansicht holen kann. Natürlich erhöht die Verwaltung mehrerer Registerkarten den Grad der Komplexität aus Sicht der Implementierung, aber die Vorteile, mehr Flows aktiv zu haben, erweitert die Möglichkeiten des Benutzers erheblich. Sie werden in der Lage sein, parallele Threads zu öffnen, um an mehreren Aufgaben gleichzeitig zu arbeiten, eine sehr wichtige Fähigkeit, die in den meisten Webanwendungen fehlt (wird normalerweise durch das Öffnen einer beliebigen Anzahl von zusätzlichen Browser-Tabs erreicht). Die Idee selbst ist nicht exklusiv für Browser, da viele Desktop-Anwendungen (und einige webbasierte) sie nutzen und die meisten Probleme der Benutzerfreundlichkeit, die mit der Anzeige einer variablen Anzahl von Tabs verbunden sind, bereits gelöst wurden. Das Multi-Flow-Konzept kann diese Erfahrungen einfach nutzen und die besten Lösungen für eine gute Integration von Hauptmenü, Multi-Flow-Tabs und flowbezogenen Navigationselementen implementieren.
Das gleichzeitige Öffnen vieler Flows ist zwar keine sehr produktive Art, das Konzept zu nutzen, aber das Hinzufügen einiger Regeln für die Erstellung der Flows sorgt für die notwendige Ordnung und erhöht das Verständnis des Benutzers für die zugrunde liegende Datenstruktur. Eine gute Praxis ist es, die Registerkarten mit der Navigationsleiste zu verknüpfen. Das bedeutet, dass jede Hauptoption im Menü automatisch die zugehörige Komponente in ihrem eigenen Ablauf öffnet. Wenn dieser Ablauf bereits geöffnet ist, wird er zurückgesetzt, indem die bestehende Abfolge von Komponenten geschlossen und eine neue gestartet wird. Das bedeutet, dass die Benutzer in einem realen Szenario nur das Hauptmenü erreichen, um die Abschnitte zu „aktivieren“, mit denen sie im Multi-Flow arbeiten müssen. Sobald sie das getan haben, können sie einfach über Registerkarten zwischen ihnen wechseln. Und noch etwas: Eine bestimmte Komponente sollte nicht auf einen einzigen Fluss beschränkt sein, so dass wir sehr wohl die gleiche Liste von Dokumenten mehr als einmal in verschiedenen Flows geöffnet haben können, gefiltert, um den spezifischen Satz von Dokumenten anzuzeigen, der dort benötigt wird.
Auf technischer Ebene müssen wir möglicherweise mehrere Funktionalitäten implementieren, um ein gutes Benutzererlebnis zu gewährleisten. Abgesehen von der Multi-Flow-Verwaltung benötigen wir z. B. ein cleveres Routing, damit eine bestimmte URL die Anwendung mit einem bereits aktiven Flow öffnet. Dadurch wird sichergestellt, dass Links von externen Apps, wie z. B. einem E-Mail-Client, zu einer bestimmten Oberflächenkonfiguration führen können. Wir können auch eine bestimmte Abfolge von Komponenten speichern und sie bei einer anderen Sitzung wiederherstellen. Oder wir lassen den Benutzer einige Komponenten (z. B. eine bestimmte Projekt-Detailansicht) als Favoriten markieren und ein Widget auf der Startseite oder dem Dashboard anzeigen, von wo aus er sie mit einem Klick in ihrem ursprünglichen Kontext/Flow öffnen kann. Auf dieser Fähigkeit, Kontexte (Ablaufsequenzen) zu speichern und nicht nur Links zu bestimmten Seiten, lassen sich viele Funktionen aufbauen.
Hinweise zu responsiven Layouts
Eine komplexe Schnittstelle lässt sich nicht so einfach an einen kleinen Bildschirm, wie den eines mobilen Geräts, anpassen. Die oben beschriebene Flow-Schnittstelle kann jedoch recht gut auf einem mobilen Gerät gehandhabt werden, wenn wir ein paar wichtige Funktionen implementieren. Die wichtigste davon ist die Umstellung des aktiven Flows auf eine einzelne Spalte, was bedeutet, dass jeweils nur eine Komponente sichtbar ist. Wenn das innere Layout der einzelnen Komponenten selbst responsive ist, müssen wir nur einige Touch-Gesten übernehmen, wie z. B. das Streichen nach rechts und links zwischen den geöffneten Komponenten, um ein Erlebnis zu erhalten, das einer nativen mobilen App recht nahe kommt. Darüber hinaus kann die Flow-Navigationsleiste in ein Dropdown-Menü umgewandelt und die Multi-Flow-Tab-Leiste darauf beschränkt werden, nur Symbole des zugehörigen Datentyps anzuzeigen (vielleicht wie die in der Seitenleiste). Die Anforderungen an die Reaktionsfähigkeit sind also kein Hindernis für diese Schnittstelle.
Fazit
Was wir hier vorgestellt haben, sind nur einige der Möglichkeiten dieses Konzepts. Man kann sich viele weitere Möglichkeiten ausdenken, um seine Flexibilität in verschiedenen Benutzerszenarien zu nutzen. Natürlich gibt es einige Nachteile, die mit der Implementierung einer solchen Schnittstelle verbunden sind. Auf der einen Seite gibt es eine inhärente Komplexität, die verwaltet werden muss, vor allem in Bezug auf die Kommunikation zwischen verschiedenen Schnittstellenkomponenten, die gleichzeitig auf oder außerhalb des Bildschirms geöffnet sind. Das bedeutet, dass es sich für eine kleine Anwendung oder für eine Anwendung, die Navigationspfade mit begrenzter Tiefe verwendet, möglicherweise nicht lohnt, sie zu implementieren. Außerdem gibt es eine gewisse Lernkurve für den durchschnittlichen Benutzer, der zumindest für den ersten Tag seiner Reise mit gut platzierten Anweisungen und Meldungen unterstützt werden muss. Und schließlich kann die Schnittstelle, abhängig von der tatsächlichen Implementierung, eine mittlere bis schwere Belastung für den Browser darstellen (kann eine beträchtliche Menge an Arbeitsspeicher benötigen, um zu laufen). Es ist immer noch eine gute Option, vielleicht die beste für einige Datenstrukturen und Benutzerszenarien, um eine effektive Single-Page-Anwendung zu bauen, mit der die Benutzer gerne jeden Tag arbeiten.＿
29 Jahre im Geschäft | 2700 Software-Projekte | 760 Kunden | 24 Länder