Bezeichnung: Anforderung
Definition: Anforderungen, die sich im Zuge der Requirementsanalyse
bzw. im Rahmen der Testläufe mit dem Prototypen ergeben haben oder die
präzisiert wurden.
Anmerkungen: Anforderungen wurden zunächst aus den Interview-Items der
Erstbefragung über die Abstraktionsstufen Topics, Kategorien,
Funktionsblöcke abgeleitet. Eine Umkehr der Abstraktionskette steht noch
aus. Anforderungen sind damit in einen Begründungszusammenhang
eingebettet, der selbst weiterentwickelt werden muss.
Bezeichnung: Anwendungssystem
Definition: Die Modellierung geht von einem Bi-System
Nutzer –
nutzt – Applikation aus, das im Projektkontext zu entwickeln ist und
in dem die Interaktionen zwischen den Komponenten
Nutzer und
Applikation genauer strukturiert werden.
Anmerkungen: Der aktuelle Ausbau der Modellierung konzentriert sich auf
die Ausmodellierung der beiden Komponenten
Nutzer und
Applikation insbesondere hinsichtlich eines genaueren
Verständnisses der Interaktion zwischen beiden in den verschiedenen
Frames. Dabei wird unsererseits ausschließlich auf der
Systemtest-Ebene der Applikation modelliert. Das Bi-System ist
seinerseits in ein oder mehrere gesellschaftliche Obersysteme eingebettet,
insbesondere in das globale Informationssystem, aus dem sowohl die Daten
zu Öffnungszeiten, Events, GPS usw. kommen, als auch das
Sprachinteraktions-Framework Siri von Apple. Es kann deshalb gut sein,
dass das Anwendungssystem im weiteren Verlauf um weitere Komponenten zu
erweitern ist.
Siehe auch: gl:Projektkontext,
gl:App
Bezeichnung: App
Definition: Die Applikation bildet als systemische Struktur
zusammen mit dem Nutzer das Anwendungssystem als Bi-System. Die
Applikation muss die Anforderungen erfüllen, die sich aus der
nutzergetriebenen Interaktion zwischen beiden Teilen ergeben. Teil der
Applikation ist die App im engeren Sinne.
Anmerkungen: Die Applikation muss insbesondere die Anforderungen im
Wechsel verschiedener
Frames auf der Nutzerseite nachvollziehen,
sich mit diesen abgleichen und die erforderlichen Informationen
zeitkritisch beschaffen. Die Applikation ist über das Bi-System in
mehrere
Informationsräume eingebettet, insbesondere in das
globale Informationssystem, aus dem sowohl die Daten zu Öffnungszeiten,
Events, GPS usw. kommen, als auch das Sprachinteraktions-Framework Siri
von Apple.
Siehe auch: gl:Nutzer,
gl:Projektkontext,
gl:Anwendungssystem
Bezeichnung: Ausrichtung
Definition: Die initiale Position des Nutzers bestimmen, damit die
Route gestartet werden kann. Den Nutzer in die richtige Richtung
drehen.
Bezeichnung: Bodentextur
Definition: Die unterschiedliche Beschaffenheit von Untergrund
Anmerkungen: Dies kann zum Beispiel Kopfsteinpflaster, ein Waldweg oder
eine gefliesste Halle sein. Mittels eines Blindenleitstocks kann diese
Beschaffenheit von den Nutzern ertastet werden.
Bezeichnung: Device-Handling
Definition: Die Nutzung des Device ist benutzerfreundlich mit
Berücksichtigung der spezifischen Bedürfnisse der Zielgruppe.
Anmerkungen: Hier sind in erster Linie Fragen des Haltens, Fortbewegens
und der Ausrichtung des Device relevant.
Bezeichnung: Device-Nutzung
Definition: Im Gegensatz zum Device-Handling sind hier die
Nutzerfunktionen gemeint, die auf die Gerät-User-Ebene abzielen.
Bezeichnung: Gebäudeinformation
Definition: Die Eigen- und Besonderheiten des zu betretenden
Gebäudes.
Anmerkungen: Das umfasst Informationen wie Öffnungszeiten des Infopoints,
Fahrstühle, Toiletten, Rolltreppen usw.
Bezeichnung: Gemischte Wege
Definition: Wege und Straßenabschnitte, die von unterschiedlichen
Verkehsteilnehmern geteilt werden.
Anmerkungen: Ein klassisches Beispiel ist hier ein gemischter Fuß- und
Radweg oder eine Spielstraße.
Bezeichnung: Handout
Definition: Ein Handout enthält im Gegensatz zu einem
(vollständigen) Transkript eines Testlaufs nur dessen Schlüsselstellen als
mehrspaltige Tabelle im vereinbarten Format.
Anmerkungen: Handouts werden etwa von internen Testläufen angefertigt, in
denen es vor allem um das Aufdecken von Problemen und Fehlern geht, um
diese in der nächsten Überarbeitung des Prototyps zu beheben. Ein Handout
liegt in der Regel als odt-Datei vor. Die Tabelle besteht aus 6 Spalten
(ID, Zeitmarken, Problem, Lösungsvorschlag, Anmerkungen, Klassifikatoren).
Die Klassifikatoren dienen dazu, die Zuordnung einzelner Zeilen zu
Anforderungen oder Issues zu verwalten und werden in den RDF-Graphen
Classifier.ttl extrahiert.
Siehe auch: gl:Transkript
Bezeichnung: Hindernis
Definition: Objekte im Sinne von Hürden im Raum.
Anmerkungen: Diese können mobil (zum Beispiel ein Schirmständer oder ein
rollbares Flipchart) oder immobil (zum Beispiel eine Kücheninsel) sein.
Bezeichnung: Infrastruktur
Definition: Gegebene technische Bedingungen, unter denen die
Applikation arbeitet.
Anmerkungen: In der Infrastruktur sind zum einen die vollen Ressourcen
abgebildet wie
BIM/Gebäudedaten und
mögliche Endgeräte
(damit sind zum einen die möglichen Trackingtools des Endgerätes gemeint
wie
Sensorik und
Augmented Reality, zum anderen
Betriebssystem und
Device-Typ) sowie deren Stakeholder.
Dazu gehören weiter Prozessressourcen im
Backend, das als
Prozessualisierung der Infrastruktur verstanden werden muss. Sie bilden
zusammen den
Konfigurationsraum, der als Ressource für die
Architektur genutzt wird und durch die Nutzerfunktionen der
Zielgruppe beeinflusst wird.
Siehe auch: gl:Personalisierung
Bezeichnung: Initiale Ausrichtung im operativen Gebrauch
Definition: Die Applikation muss sich initial im Raumsystem
lokalisieren und dies von Zeit zu Zeit wiederholen.
Anmerkungen: Die Applikation muss sich initial im Raum ausrichten und die
Laufrichtung bestimmen. Die Bestimmung der Laufrichtung erfolgt durch
einen User-Gerät-Abgleich, welcher den Aspekt der Sicherheit wieder
hervorhebt. Nach dem Start der Anwendung muss eine Auswahlmöglichkeit für
die Bestimmung der Laufrichtung je nach Haptik, Handling und Endgerät
durch den Nutzer gegeben sein.
Bezeichnung: Interaktionsmöglichkeiten und Interaktionssequenz
Definition: Eine Folge zusammenhängender Interaktionen von
Nutzer und
App .
Anmerkungen: Eine Interaktionssequenz ist die reale Abfolge von
Interaktionen, die sich aus den implementierten
Interaktionsmöglichkeiten unter den konkret gegebenen Bedingungen
ergibt.
Bezeichnung: Transparenz der Interoperabilität
Definition: Die App muss mit anderen Anwendungen sowie mit
verschiedenen Betriebssystemen (vor allem iOS und Android) kompatibel
sein, um Medienbrüche zu vermeiden.
Anmerkungen: Eine Anforderung an das Gerät und die App ist die technische
Kompatibilität mit anderen technischen Apps, Produkten oder Services wie
Betriebssystem (iOS, Android), Gerät (iPhone, Samsung) und technischen
Erweiterungen (Wearables, Knochenleithörer …) usw. Diese Kompatibilität
muss transparent für den Nutzer sein.
Die Kompatibilitätsanforderungen stehen in direkter Abhängigkeit zu den
infrastrukturellen Gegebenheiten.
Bezeichnung: Issue
Definition: Issues sind Abweichungen im Verhalten des Prototyps von
dem in den Requirements festgeschriebenen Verhaltens, die im Rahmen der
Testläufe mit dem Prototypen festgestellt wurden und vom Entwicklerteam zu
fixen sind.
Anmerkungen: Issues werden auch von den Entwicklern in einem eigenen,
deutlich detaillierteren entwicklungsnahen Issue-System erfasst und
verwaltet, das auch Probleme aus den Phasen Modul- und Integrationstest
umfasst. Unsere Issues beziehen sich ausschließlich auf die Phase des
Systemtests. Deshalb wurde beschlossen, dass die Issues des UL-Teams in
einem separaten System erfasst und durch das UL-Team verwaltet werden. AP
liefert ein regelmäßiges Feedback zu Weiterentwicklungen und gefixten
Issues.
Bezeichnung: Kalibrierung des Zusatzgeräts
Definition: Das Zusatzgerät muss kalibriert werden, um
Schrittzahlen des Nutzers korrekt in Entfernungen umzurechnen.
Bezeichnung: Kontext
Definition: Kontext ist auf der Seite des
Nutzers ein
raum-zeitlicher Zusammenhang, der bei der Zielbestimmung implizit
vorausgesetzt wird.
Bezeichnung: Kurskorrektur
Definition: Ansage innherhalb der
Applikation , die
den
Nutzer darauf hinweist, dass er/sie die offizielle Route
verlässt.
Anmerkungen: Damit soll sichergestellt werden, dass die Person immer auf
der idealen Route bleibt.
Bezeichnung: Kalibrierungsmodus
Definition: Modus, in dem die App an die Parameter des spezifischen
Nutzers angepasst wird. Dazu muss der Nutzer (ggf. mehrfach) 10 Schritte
in langsamem Tempo laufen.
Bezeichnung: Navigationsmodus
Definition: Modus, in dem der Nutzer auf seinem Weg vom
IBN-Assitenzsystem unterstützt wird.
Anmerkungen: Die Navigation vollzieht sich in Echtzeit und in der realen
Situation. Hier wird der Nutzer permanent getrackt und geführt. Auf
Abweichungen der Route muss in Echtzeit reagiert werden.
Bezeichnung: Orientierungsmodus
Definition: Modus, in dem der Nutzer an einem Ort von der
Applikation weitere Informationen über die Umgebung erhält.
Anmerkungen: Der Modus der Orientierung als Sonderform der Navigation
vollzieht sich in Echtzeit und in der realen Situation. Diese
Ortsgebundenheit ermöglicht die Antwort auf die Frage „Wo bin ich?“ und
kann sowohl als Startpunkt für die Navigation als auch für einen erneuten
Vorbereitungsmodus vor Ort dienen.
Bezeichnung: Tutorial-Modus
Definition: Modus, in dem der Nutzer Informationen über die
Bedienung der App erhält.
Anmerkungen: Der Modus wird am Anfang der App-Nutzung aktiviert und kann
vom Nutzer übersprungen oder nach endlicher Zeit abgebrochen werden.
Siehe auch: gl:Tutorial
Bezeichnung: Vorbereitungsmodus
Definition: Modus, in dem sich der Nutzer zu Hause auf einen Gang
unter Anwendung der Applikation vorbereitet.
Anmerkungen: In diesem Modus soll ortsunabhängig die ideale Route der
Navigation im Voraus gefunden werden. In einer geschützten Umgebung kann
die Route abgespielt werden, was in der realen Situation ein Gefühl von
Sicherheit gibt. Die wesentliche Hürde der Überforderung in einem neuen
Raum soll so abgebaut werden.
Bezeichnung: Modusauswahl
Definition: Die Unterscheidung von Modi dient dazu, die jeweiligen
kontextuellen Einsatzbedingungen der Applikation genauer zu fixieren und damit
spezifische funktionale Zusammenhänge zu aktivieren.
Anmerkungen: Aktuell werden die Modi
Vorbereitungsmodus,
Orientierungsmodus und
Navigationsmodus unterschieden.
In den ersten beiden Modi ist die Applikation das primäre Hilfsmittel; es
geht darum, ein für die
Zielstellung angemessenes
Informationspaket aus dem
globalen Informationsraum
zusammenzustellen, wobei im Vorbereitungsmodus der
Referenzort
variabel ist, im Orientierungsmodus der aktuelle Standort der Referenzort
ist. Im Navigationsmodus geht es darum, eine vorab
festgelegte
Route zu verfolgen. Die Applikation ist dabei nur
eines der Hilfsmittel.
Siehe auch: gl:Modus_Vorbereitung,
gl:Modus_Navigation,
gl:Modus_Orientierung
Bezeichnung: Nachfragemöglichkeit
Definition: Nachfragemöglichkeiten dienen dazu, die Übereinstimmung
der situativen Bilder im Kopf des
Nutzers und in der
Applikation weitergehend zu koordinieren
Anmerkungen: Die Hauptanforderung des Nutzers ist ein Bedürfnis nach
Sicherheit. Dieses soll durch Nachfrage und Kommunikation erfüllt werden.
Dem Bedürfnis kann, wenn möglich, schon im Vorbereitungsmodus begegnet
werden. Die Funktion aus diesen Anforderungen ist Assistenz und
Hilfeleistung. Das bedeutet, dass die Assistenzfunktion durch eine
Nachfragemöglichkeit sichergestellt wird, welche sich in der Architektur
der Anwendung wiederfinden muss.
Bezeichnung: Nutzer
Definition: Eine Person der Zielgruppe der Blinden oder stark
Sehbehinderten.
Anmerkungen: Wir verwenden den Begriff in dieser generalisierten
männlichen Form und meinen dabei natürlich Personen aller Geschlechter.
Wir verwenden diese Kurzform, um in relevanten Texten die Zielgruppe nicht
mehrfach in der langen Version zu benennen. Wir haben gesehen, dass sich
die Bedürfnisse und persönlichen Möglichkeiten von Blinden und stark
Sehbehinderten an vielen Stellen stark unterscheiden, dass aber auch die
Historie der Sehbehnderung sowie das Alter im spezifischen Zugang zu den
technischen Möglichkeiten der zu entwickelnden Applikation große Bedeutung
haben. Der Begriff Nutzer wird nur verwendet, wenn diese Unterschiede im
beschriebenen Kontext nur untergeordnete Bedeutung haben.
Bezeichnung: Personalisierung der Applikation
Definition: Die Applikation kann personalisiert werden.
Anmerkungen: Aus den Anforderungen der sprachlichen Differenzierung sowohl
in der Kategorie „vorne/links“ als auch in der Kategorie „Schritte/Meter“
und aus der Anforderung des Detaillierungsgrades leitet sich das
Zusammenspiel der Funktionen der Spezifizierung des Profils und einer
Sprachinteraktion ab.
Diese Stakeholderanforderung einer umfassenden Profilspezifizierung muss
als Anfang und als Konfigurationsraum der Applikation verstanden werden.
Hier sind in erster Linie alle relevanten Nutzerfunktionen gemeint, die sich
auf die User-Gerät-Ebene beziehen.
Bezeichnung: Problemerkennung und Problemvermittlung
Definition: Die Applikation weist vorab auf problematische
Situationen hin.
Anmerkungen: Wird eine problematische Situation wie etwa Hindernisse oder
der Übergang Outdoor/Indoor erkannt, so soll diese in Echtzeit an den
Nutzer kommuniziert werden. Diese Intervention als spezielle Sprachausgabe
erfordert eine besondere Abstimmung von Problemerkennung und
Problemvermittlung im operativen Bereich.
Bezeichnung: Projektkontext
Definition: Der Projektkontext ist die systemische Struktur der
drei Partner als Komponenten, in der das Anwendungssystem entwickelt
wird.
Anmerkungen: Das Konzept ist genauer in der TRIZ-Modellierung des
Gesamtzusammenhangs erläutert und bildet den Rahmen, innerhalb dessen sich
die entwicklugsbezogene Kooperation zwischen AP und dem UL-Team
entfaltet.
Siehe auch: gl:Anwendungssystem
Bezeichnung: Randorientierte POI-Setzung
Definition: Personen, die einen Blindenleitstock zur Orientierung
verwenden, nutzen die Ränder eines Weges als Anhaltspunkt.
Anmerkungen: Für Blinde und sehschwache Personen dienen Wegränder und
Kanten als maßgebliche Anhaltspunkt bei der Navigation. Beim Setzen von
Markierungspunkten sollte deshalb berücksichtigt werden, dass diese an
Rändern und Kanten und nicht in der Mitte eines Weges liegen, da diese
imaginären Punkte im Wahrnehmungsraum von Blinden und Sehbehinderten
selten vorkommen.
Bezeichnung: Referenzort
Definition: Im Vorbereitungsmodus ist das der Startort, im
Orientierungs- und Navigationsmodus die jeweilige Position.
Anmerkungen: Die Applikation muss den Referenzort aktiv verfolgen, um
stets genau zu wissen, wo sich der Nutzer gerade befindet. Der Referenzort
ist das Zentrum des jeweiligen
Handlungsraums.
Siehe auch: gl:Modus_Navigation,
gl:Modus_Orientierung
Bezeichnung: Sicherheitsbedürfnis
Definition: Subjektives Bedürfnis des Nutzers nach Sicherheit.
Bezeichnung: Skip-Modus
Definition: Längere Ausführungen der Applikation können unterbunden
werden.
Anmerkungen: Ist kein Modus! Ein zu hoher Detaillierungsgrad der
Informationen wird oft als störend empfunden. Dementsprechend muss die
Sprachinteraktion nicht nur die Art und Weise der Präsentation, sondern
auch die Menge der Informationen bedenken. Eine Empfehlung ist es daher,
eine Funktionalität zum Überspringen von Informationen anzubieten.
Bezeichnung: Standort
Definition: Der eigene Standort (Orientierungsmodus) oder die
eigene aktuelle Position (Navigationsmodus) .
Siehe auch: gl:Modus_Navigation,
gl:Modus_Orientierung
Bezeichnung: Testlauf
Definition: Testläufe dienen der Bewertung, in welchem Umfang die
Architektur des Prototypen mit den Nutzerbedürfnissen abgestimmt ist. Es
werden interne Testläufe und Testläufe mit Probanden unterschieden.
Bezeichnung: Interner Testlauf
Definition: Interne Testläufe dienen dazu, den Entwicklungsstand
des jeweiligen Prototypen zu bewerten und dessen Nutzung im Detail
praktisch kennenzulernen. Sie werden in der Regel zusammen mit dem
Entwicklerteam durchgeführt.
Anmerkungen: Dabei wurden bisher in kleineren Begehungen im
Robert-Koch-Park spezifische Probleme der Interaktions- und Sprachkonzepte
anhand des Gebrauchs des Prototypen identifiziert und im Nachgang durch
die Entwickler bearbeitet. Diese Zusammenarbeit von Evaluationsteam der
Universität und Entwicklerteam von BitCtrl strebt nach schnellen oder auch
umfänglichen Verbesserungen der Grundarchitektur der Anwendung und ihrer
Usability.
Zu internen Testläufen werden kurze Auswertungen aus dem aufgenommenen
Material als
Handout bereitgestellt und zeitnah an die Entwickler
weitergegeben. In einer zweiten Bearbeitungsphase wird das Handout mit
RDF-Klassifikatoren angereichert und entsprechende Informationen in der
Web-Übersicht des UL-Teams für die weitere wissenschaftliche Verwendung
ergänzt.
Interne Testläufe dienen der schnellen Problemlösung in der Entwicklung
der App und der direkten Optimierung in ihrer Anwendung. Sie sind die
Grundlage für die Bewertung des Entwicklungsstands des Prototypen und der
technischen Vorbereitung von Testläufen mit Probanden. Ein detailliertes
Transkribieren und Auswerten dieser internen Testläufe unter
sozialwissenschaftlichen Gesichtspunkten ist nicht vorgesehen.
Siehe auch: gl:Handout
Bezeichnung: Testlauf mit Probanden
Definition: Testläufe mit Probanden dienen der detaillierten
Bewertung, in welchem Umfang Personen der Zielgruppe mit verschiedener
Technik-Affinität den Prototypen für die vorgesehenen Zwecke nutzen
können, welche weiteren Besonderheiten dabei zu berücksichtigen sind und
welche Probleme in der Nutzung auftreten. Die Testläufe werden unter
sozialwissenschaftlichen Aspekten vorbereitet, durchgeführt und
ausgewertet.
Anmerkungen: Die Video-Aufzeichnungen dieser Testläufe werden umfassender
aufbereitet und dazu genauere
Transkripte erstellt, um die
Testläufe auch für eine sozialwissenschaftliche Auswertung zugänglich zu
machen. Die genaue Form der Aufbereitung ist im Glossareintrag
Transkript ausgeführt.
Siehe auch: gl:Transkript
Bezeichnung: Tracking
Definition: Im
Navigationsmodus muss der
Standort
des Nutzers durch die App kontinuierlich verfolgt werden, um
positionsrelevante Trigger korrekt auszulösen.
Siehe auch: gl:Standort,
gl:Modus_Navigation
Bezeichnung: Transkript
Definition: Transkript eines Testlaufs als mehrspaltige Tabelle im
vereinbarten Format.
Anmerkungen: Ein Transkript ist eine pseudonymisierte Aufzeichnung, die
aus den Video- und Audioaufzeichnungen eines Testlaufs gewonnen wird.
Pseudonymisiert bedeutet, dass Verweise auf Sprecher in abgekürzter Weise
dargestellt sind, um verschiedene Aussagen derselben Person innerhalb des
Transkripts einander zuordnen zu können, aber die Zuordnung zu einer
realweltlichen Person weitgehend unmöglich ist. Damit werden anerkannte
Datenschutzgrundsätze erfüllt, um die Transkripte weiter öffentlich
verwenden zu können.
Zur Erstellung und Konsolidierung des Transkripts werden zunächst die
ersten vier Spalten (ID-Quelle, Zeitstempel, Sprecherkuerzel, Text)
ausgefüllt. Diese Informationen wird später in den Spalten 5 und 6
(Anmerkungen, Klassifikatoren) weiter angereichert.
Die Klassifikatoren dienen dazu, die Zuordnung einzelner Zeilen zu
Anforderungen oder Issues zu verwalten und werden in den RDF-Graphen
Classifier.ttl extrahiert.
Einige Transkript wurden in finalem Zustand in eine CSV-Datei verwandelt,
womit die einzelnen Zeilen (Sequenzen) über den Primärschlüssel
ID-Quelle+Zeitstempel+Sprecherkuerzel (der eindeutig sein muss)
referenziert werden können.
Die genauen Transkriptionsregeln sind in der Datei
Transkriptionsregeln.odt im Repo-Verzeichnis
Begleitende-Studien/Transkripte zusammengestellt.
Bezeichnung: Trigger
Definition: Ein Trigger ist ein Ereignis im Teilsystem App, das
eine gewisse Aktivität der App auslöst.
Anmerkungen: Wichtigste Trigger sind durch die App erkannte
Intents, auf die der Nutzer eine adäquate Reaktion der App
erwartet. Es gibt aber auch interne Trigger wie Zeitabläufe ("Du bist
noch auf dem rechten Weg") oder Ortsmarken ("In 5 Metern rechts
abbiegen").
Siehe auch: gl:App
Bezeichnung: Anleitungssystem zur Nutzung der App
Definition: Es wird ein umfassendes Anleitungssystem benötigt, um
die Handhabung der Applikation zu erlernen.
Anmerkungen: Die Anforderungsanalyse zur Interaktion von Applikation und
Nutzer ergab den Bedarf eines spezifischen Tutorials, welches mit der
Spezialisierung des Profils verbunden werden sollte. Dies dient der
Nutzerfreundlichkeit und der Device-Konfiguration.
Das Anleitungssystem muss intuitiv sein, da sonst die App nicht genutzt
wird (Aussage Veronika). Es ergibt sich der Widerspruch, dass die Nutzung
erlernt werden muss (das haben die Probanden mehrfach betont), aber die
Bereitschaft gering ist, darauf eigenständige Energie zu verwenden. Die
Nutzung der App muss in deren Gebrauch erlernt werden. Bezug zu ISO
4291-11.
Siehe auch: gl:Modus_Tutorial,
gl:App
Bezeichnung: Vibration der App
Anmerkungen: Wir hatten damals die Vibration eingeführt, um dem blinden
Nutzer regelmäßig eine Bestätigung zu geben, wenn er sich während der
Navigation auf der berechneten Route bewegt. Das ist notwendig, weil es
sonst je nach Route vorkommen kann, dass mehrere hundert Meter Strecke von
der App keine Ansage kommt. Das verunsichert den Nutzer. Da aber eine
regelmäßige Erinnerung "Du befindest dich auf der Route. Weiter so."
schnell nervig wurde, haben wir es erst auf einen Ton und später auf eine
Vibration reduziert. Das nur kurz als Hintergrund, warum wir die
Vibration überhaupt verwenden.
Von einem allgemeinen Konzept, wie die Vibration die Kommunikation
zwischen Nutzer und App unterstützt, kann keine Rede sein.
Tutorial: Vibration wird (zurzeit) zur Bestätigung des Route und beim
Erreichen des Ziels verwendet. Wenn man dem Nutzer das so sagt, ist das
meiner Meinung nach ausreichend Information, um bei der ersten Nutzung zu
verstehen, was mit der Vibration gemeint ist. (Mail Tobias vom
25.05.2022)
Siehe auch: gl:Tutorial,
gl:DeviceHandling
