Pocket-Modus
Vom Telefon oder Tablet aus annotieren. Touch-Geräte landen automatisch bei einem wischbaren Kartenstapel mit Bedienelementen in der Daumenzone, Offline-Annotation mit Synchronisierung und Installation auf dem Startbildschirm als PWA.
Neu in v2.7.0
Potato unterstützt das Annotieren von Telefonen und Tablets aus. Ist der Pocket-Modus aktiviert, landen Touch-Geräte, die die Aufgabe öffnen, automatisch auf einer mobilen Oberfläche: ein Kartenstapel mit Label-Schaltflächen in der Daumenzone, Navigation per Wischgeste, Offline-Annotation mit automatischer Synchronisierung und Installation auf dem Startbildschirm als PWA. Am Desktop erscheint die gewohnte Oberfläche, dort ändert sich nichts.

Nicht jeder Annotationstyp gehört auf ein Telefon. Span-Markierungen und Bounding-Boxen sind Desktop-Aufgaben. Potato ist da eindeutig: touch-taugliche Aufgaben bekommen die mobile Oberfläche, alle anderen eine klare Warnung statt einer beschnittenen Oberfläche, und das Admin-Dashboard zeigt in beiden Fällen, wer von welcher Geräteklasse aus annotiert.
Konfiguration
pocket:
enabled: true # master switch for the mobile interface (default: false)
auto_redirect: true # send phones/tablets to /pocket automatically (default: true)
batch_size: 25 # items fetched per batch; also the offline queue depth (1-200)Welche Annotationstypen sich für mobile Geräte eignen
| Touch-tauglich (mobil ausgeliefert) | Nur Desktop |
|---|---|
radio, multiselect, likert, slider, number, text/textbox, pure_display | span, Bild- und Bounding-Box, Video, Audio, multirate und alles Weitere |
Eine Aufgabe ist nur dann touch-tauglich, wenn alle ihre Schemata in der linken Spalte stehen. Eine Aufgabe mit auch nur einem Desktop-Schema wird nicht auf Touch heruntergebrochen: Telefone werden nicht umgeleitet, und sie sehen einen ausblendbaren Hinweis, dass die Aufgabe nicht für mobile Geräte optimiert ist.
Wer mit mobilen Annotatoren rechnet, sollte dafür entwerfen. Der Idealfall ist eine Aufgabe mit einem einzigen radio-Schema, bei der ein Tippen einem gelabelten Element entspricht.
Wie die Geräteweiche funktioniert
| Gerät | Aufgabe touch-tauglich, Pocket aktiviert | Aufgabe nicht touch-tauglich |
|---|---|---|
| Desktop | gewohnte Oberfläche | gewohnte Oberfläche |
| Telefon / Tablet | Umleitung auf die mobile Oberfläche | gewohnte Oberfläche + ausblendbare Warnung |
Die Erkennung läuft in zwei Schichten.
- Serverseitig (User-Agent). Telefone und die meisten Tablets geben sich zu erkennen und werden umgeleitet, bevor die Desktop-Seite überhaupt gerendert wird. API-Clients und unbekannte Agents zählen als Desktop, Skripte und Integrationen werden also nie umgeleitet.
- Clientseitig (Zeigerprüfung). Manche Tablets geben sich als Desktop aus. iPadOS-Safari etwa meldet sich als Mac. Ein Skript auf der Annotationsseite prüft, ob der primäre Zeiger des Geräts grob ist (ein Finger), und leitet auch diese Geräte um. Laptops mit Touchscreen bleiben unberührt, denn ihr primärer Zeiger ist das Trackpad.
Die Weiche greift nur bei Annotatoren in der Annotationsphase. Einwilligungs-, Anleitungs- und Umfrageseiten bleiben unangetastet.
Am Desktop kann man freiwillig wechseln: Bei Pocket-tauglichen Aufgaben zeigt die Navigationsleiste einen Link Kompaktansicht auf /pocket, wo aus dem Kartenstapel eine schnelle Beschriftungsansicht mit einem Klick pro Element wird. Mobil führt der Link Desktop-Website wieder heraus, und die Wahl gilt für die restliche Sitzung.
Die mobile Oberfläche
- Kartenstapel — ein Element pro Karte. Nach links wischen für das nächste Element, nach rechts für das vorherige, mit Pfeiltasten für die Bedienung ohne Touch. Auf Geräten, die das unterstützen, bestätigt ein haptischer Impuls jedes Speichern.
- Bedienelemente in der Daumenzone — die Label-Schaltflächen sitzen im unteren Drittel des Bildschirms, wo der Daumen tatsächlich hinkommt. Touch-Ziele sind 48 px oder größer, auf Telefonen mit Notch werden die Safe-Area-Abstände eingehalten, und
prefers-reduced-motionwird beachtet. - Schema-Darstellung — Aufgaben mit einem einzelnen radio- oder likert-Schema springen beim Tippen von selbst weiter. Karten mit mehreren Schemata zeigen alle Bedienelemente plus ein ausdrückliches Speichern & weiter.
- Offline-Annotation — der aktuelle Batch wird vorgeladen und in localStorage gespiegelt. Bricht die Verbindung ab, geht das Annotieren weiter, ein Chip zeigt "Offline — N saves queued", und die Warteschlange wird bei erneuter Verbindung automatisch geleert. Ein Service Worker legt die App-Shell nach dem ersten Besuch im Cache ab, sodass die Seite auch ohne Verbindung lädt. Einen Batch im WLAN vorladen, überall annotieren und synchronisieren, sobald das Gerät wieder Empfang hat.
- Als App installieren — die Seite liefert ein Web-Manifest mit, sodass "Add to Home Screen" eine eigenständige App mit eigenem Icon ergibt.
Gespeichert wird über denselben Endpunkt /updateinstance und dieselbe Payload wie auf der Desktop-Seite. Der Pocket-Modus fügt keinen neuen Schreibpfad hinzu, für Exporte, Übereinstimmungsstatistiken, das Admin-Dashboard und die Qualitätskontrolle sind das also ganz gewöhnliche Annotationen.
Der Geräte-Tab
Das Admin-Dashboard bekommt einen Tab Geräte, der pro Annotator zeigt: zuletzt gesehenes Gerät, Besuche nach Geräteklasse, wie oft die mobile Oberfläche genutzt wurde und wann der letzte Besuch war. Eine Zusammenfassungszeile nennt die Kernzahl („3 von 12 Nutzern haben von einem Telefon oder Tablet aus zugegriffen").
Das ist in zwei Richtungen aufschlussreich. Ist die Aufgabe nicht touch-tauglich und der Geräte-Tab zeigt trotzdem Annotatoren auf Telefonen, dann haben diese die Warnung gesehen und weitergemacht, ihre Ergebnisse lohnen also einen Blick. Und weil Besuche unabhängig davon erfasst werden, ob der Pocket-Modus aktiviert ist, beantwortet der Tab die Frage „Würde der Pocket-Modus etwas bringen?", bevor man ihn einschaltet.
Die Daten liegen in <output_annotation_dir>/pocket/device_visits.json, ausschließlich als Aggregate pro Nutzer. Ein Tracking je Element gibt es nicht.
Fehlerbehebung
- Ein Telefon wird nicht umgeleitet. Prüfen, ob
pocket.enabledundpocket.auto_redirecttrue sind, ob die Aufgabe touch-tauglich ist (GET /pocket/api/routingzeigtcapable: true) und ob der Nutzer in dieser Sitzung nicht „Desktop-Website" gewählt hat. - Ein iPad bekommt beim ersten Laden die Desktop-Seite. iPadOS-Safari meldet sich als Mac, der Server kann es also nicht abfangen. Die clientseitige Zeigerprüfung leitet es um, sobald die Skripte der Seite laufen.
- Ein Nutzer ist mobil „fertig", aber die Desktop-Seite zeigt noch offene Elemente. Möglicherweise gibt es nicht synchronisierte Offline-Speicherungen. Der Sync-Chip zeigt die Warteschlange, die geleert wird, sobald das Gerät wieder online ist.
Weiterführende Informationen
- Aufgabenzuweisung — mobile Nutzer ziehen aus derselben Warteschlange wie alle anderen
- Admin-Dashboard — wo der Geräte-Tab zu finden ist
- Crowdsourcing auf Prolific und MTurk
- Quelldokumentation