iOS-Berechtigungsdialoge: schlechte, gute und großartige Beispiele

Wenn eine App deine Kamera, dein Mikrofon oder Face ID haben will, schreibt iOS den Titel und die zwei Buttons. Die eine Zeile, die die App schreibt, ist die Begründung, und die meisten Apps verschwenden sie. Unten findest du sieben Berechtigungsdialoge, die von schlecht bis großartig hochgeklettert sind, die Begründung hinter jeder Stufe und eine Formel für den nächsten, den du schreibst.

Was du schreibst und was iOS schreibt

Der System-Alert hat eine feste Form. iOS liefert den Titel („Möchte auf die Kamera zugreifen“) und die Buttons. Die App liefert einen Satz, den sogenannten Purpose String, der sagt, warum sie Zugriff braucht. Er steht in einem Schlüssel in der Info.plist der App (NSCameraUsageDescription für die Kamera, NSMicrophoneUsageDescription für das Mikrofon) und wird in den Einstellungen unter Datenschutz erneut angezeigt.

Schlecht

Großartig

Beide Alerts haben denselben Titel und dieselben Buttons. Nur der eine Satz hat sich geändert. Der schlechte sagt den Leuten, was sie mit einem Schalter tun sollen, den sie gerade umlegen sollten. Der großartige sagt ihnen, was passiert, wenn sie auf Scannen tippen, sodass die Frage „Warum will eine Buchhaltungs-App meine Kamera?“ beantwortet ist, bevor sie gestellt wird.

Apples Vorgabe für diesen Satz ist kurz: ein knapper, vollständiger Satz, der geradlinig, konkret und leicht verständlich ist, in normaler Satzschreibung, im Aktiv und mit Punkt am Ende. Jede großartige Zeile unten folgt dem.

Stufe für Stufe

1. Kamera

Tidybooks ist eine erfundene App. Apple empfiehlt, dann zu fragen, wenn die Person die Funktion nutzt, die den Zugriff braucht. Der beste Moment für diesen Dialog ist also der erste Tipp auf Scannen, nicht der erste Start.

2. Mikrofon

Hier stammen die schlechte und die großartige Zeile von Apple selbst, Wort für Wort aus den Datenschutzrichtlinien.

Apples schlechtes Beispiel

Apples großartiges Beispiel

Nightly ist eine erfundene App. Die Lehre steckt in den Verben: „ist erforderlich“ versteckt, wer was tut, und „nimmt nachts auf“ sagt es klar. Ehrlichkeit über das Aufnehmen sorgt auch dafür, dass Leute auf Erlauben tippen.

3. Bluetooth

Doorkey Home ist eine erfundene App. Beachte, dass die großartige Zeile den Titel nicht wiederholt. iOS sagt schon „Möchte Bluetooth verwenden“, also investiert der Satz seine Worte in die Begründung.

4. Face ID

Northbank ist eine erfundene Banking-App. Halte Sicherheitstexte bei dem, was die Funktion wirklich tut. Eine Zeile, die mehr verspricht, als die Prüfung liefert, ist schlimmer als eine langweilige.

5. Fotos

Filmstrip ist ein erfundener Foto-Editor. Der Titel, den iOS hier schreibt, lautet „Möchte Fotos hinzufügen“, also die enge Nur-Schreiben-Berechtigung. Der Satz sollte so klingen: Er speichert, er stöbert nicht.

Zwei weitere, frisch geschrieben

Dieselben Regeln gelten für Situationen, die die fünf oben nicht abdecken. Diese zwei sind unsere eigenen Beispiele mit erfundenen Apps.

Die Formel: was es tut, wann, warum es hilft

Jede großartige Zeile oben passt in dieselben drei Teile in einem Satz:

Das „Wann“ ist der Teil, den Teams zuerst streichen, und es ist der, der den Zugriff sicher wirken lässt, denn er verspricht, dass die App nicht in einem Moment handelt, den die Person nicht gewählt hat.

Eine Checkliste für deinen nächsten Dialog

• Ein Satz, aktiv, mit Punkt am Ende. Das ist Apples eigene Latte.
• Nenne den Grund, nie die Berechtigung. iOS hat „Auf die Kamera zugreifen“ schon gedruckt.
• Nenne den Moment. Ein Tipp, eine Nachtzeit, das erste Öffnen einer Funktion.
• Frage, wenn die Funktion es braucht. Nicht beim ersten Start, es sei denn, die Funktion ist der erste Start.
• Kein „erforderlich“ und kein „besseres Erlebnis“. Das klingt nach Forderungen und sagt nichts.
• Versprich nur, was die Funktion tut. Wenn sie nur die App entsperrt, sag genau das.
• Lies ihn auch in den Einstellungen. Derselbe String erscheint unter Datenschutz, ohne Kontext.

FAQ

Was ist ein Purpose String auf iOS?

Es ist der eine Satz, den eine App liefert, um zu erklären, warum sie Zugriff auf etwas Privates will, etwa Kamera oder Mikrofon. Er steht in der Info.plist der App unter Schlüsseln wie NSCameraUsageDescription und wird im System-Alert und in den Einstellungen unter Datenschutz angezeigt.

Wie schreibt man eine gute Berechtigungsmeldung?

Schreibe einen knappen, aktiven Satz mit Punkt am Ende, der sagt, was die Funktion tut, wann es passiert und warum es hilft. „Wenn du auf Scannen tippst, lesen wir den Betrag ab, damit du ihn nie tippen musst.“ ist ein Beispiel für die Form.

Was sind Beispiele für schlechte Berechtigungsdialoge?

Vage oder passive Zeilen ohne Begründung: „Der Mikrofonzugriff ist für ein besseres Erlebnis erforderlich.“, „Kamerazugriff aktivieren.“, „Bluetooth ist erforderlich.“ und „Face ID aktivieren.“ Jede sagt den Leuten, was die App will, und nie warum.

Wer schreibt Titel und Buttons eines iOS-Berechtigungs-Alerts?

iOS. Es schreibt den Titel und die Buttons, also ist der Purpose String der einzige Text, den du kontrollierst. Deshalb muss der eine Satz die ganze Begründung tragen.

Wann sollte eine App um Erlaubnis fragen?

Frage, wenn jemand die Funktion nutzt, die sie braucht, nicht vorher. Apples Vorgabe ist, Zugriff nur anzufragen, wenn die App ihn klar braucht, also gehört ein Kamera-Dialog auf den ersten Tipp auf Scannen.

Quellen

• Privacy: Requesting permission, Apple Human Interface Guidelines. Die Quelle der zwei Mikrofon-Strings, der Vorgabe „brief, complete sentence“ und des Rats, im Kontext zu fragen.
• Requesting authorization to capture and save media, Apple AVFoundation-Dokumentation.
• Writing, Apple Human Interface Guidelines.
• Oben verwendete Info.plist-Schlüssel: NSCameraUsageDescription, NSMicrophoneUsageDescription, NSBluetoothAlwaysUsageDescription, NSFaceIDUsageDescription, NSPhotoLibraryAddUsageDescription, in Apples Information Property List Reference.
• Die Apps in den Beispielen (Tidybooks, Nightly, Doorkey Home, Northbank, Filmstrip und die zwei frischen) sind erfunden. Nur die Mikrofon-Strings stammen von Apple.
• Zuerst veröffentlicht als Karussell auf UX Brainy.