Die Republik ist nur so stark wie ihre Community. Werden Sie ein Teil davon und lassen Sie uns miteinander reden. Kommen Sie jetzt an Bord!
Das Speichern der Position in der Cloud ist ja im Prinzip nur nötig, wenn sie auf mehreren Geräten synchronisiert werden soll.
Für die meisten Nutzer könnte der selbe Effekt ja auch erreicht werden, wenn die Position ganz einfach im verwendeten Browser bzw. der App lokal gespeichert würde.
Beim Login über die App könnte gar eine end-to-end-verschlüsselte Synchronisation im Hintergrund realisiert werden, die nicht mal zulasten der Convenience ginge. Bis dahin wäre der Datenschutz also nicht angekratzt, mit der selben Funktionalität.
Sie könnten dann zusätzlich noch mit Einwilligung sammeln, bis zu welcher Stelle ein Artikel gelesen wurde. Das muss dann aber nicht mehr personalisiert geschehen.
So wäre wohl das Maximum an Datensparsamkeit herausgeholt. Das Maximum an Komplexität allerdings auch 😉
Die Daten liegen in einer Postgres-Datenbank in einem Amazon-Datencenter in Irland. Professionell betrieben und aktuell gehalten durch Heroku.
Innerhalb der Republik haben nur Software Entwickler Zugriff auf die Daten.
Vorbildlich wäre, die Daten zu pseudonymisieren, und zwar so, dass keine Querverbindungen gemacht werden können. Dann würde wohl auch ich das Feature nutzen, da mich, neben dem Datenschutz (pseudonymisieren) stört, wenn irgendwann Artikel A33gvb vorgeschlagen wird, weil ich ein gewisses Leseverhalten an den Code gelegt habe (Querverbindungen).
Die Implementation würde mich sehr interessieren. Wurde das Ganze als Library entwickelt oder voll in das Redaktionssystem integriert? Solche Features sind ja in der Regel nicht ganz einfach zu lösen, so dass sie auch zuverlässig funktionieren.
danke dafür. 👍
Wurde direkt in unser Frontend und Artikel-Rendering eingebaut.
Beim Artikel-Rendering wird allen Elementen ausser dem Titelblock Positionsreferenzen gegeben (z.B. <p data-pos="1-1">
). Code: styleguide
/src/templates/Article/index.js
– super spezifisch zu unserem Schema-Code.
Im Frontend wird die Distanz zu diesen Elementen onScroll
gemessen. Code: republik-frontend
/components/Article/Progress
– einigermassen allgemeiner React-Code.
Aber der Code ist noch nicht ganz perfekt. Siehe Kommentar von M. A. 😉
Ich nehme an, ihr könnt nicht beurteilen, ob ein Beitrag nur durchgescrollt wurde oder nicht?
Hm, und ich kriege die 100% nicht voll. Der Stand bleibt bei 98%. ETH Teil 3 auf Englisch, iPhone SE mit iOS 12, neuste Appversion.
Edit
Genauso bei Teil 2.
Danke für die Rückmeldung. Das ist ein Bug. Werde ich mir anschauen.
Ist jetzt behoben. 100% sollten nun in 100% der Fälle möglich sein.
Eine Leseposition hat auch ein Erstellungs- und Aktualisierungdatum, dies würde eine gewisse Abschätzung zulassen. Aber ist nicht absolut eindeutig. Und wir behalten auch nicht alle Scrollvorgänge sondern nur den Höchsten und Letzten.
Beispieldaten:
{
"meta": {
"title": "Wie im Syrien-Konflikt zwei Kleinstaaten die Grossen austricksten"
},
"userProgress": {
"createdAt": "2019-03-29T09:23:39.732Z",
"nodeId": "2-89",
"percentage": 0.9244701351728748,
"updatedAt": "2019-03-29T09:23:43.178Z"
}
}
Ich denke wir werden das anonyme Tracking, welches «Time on Page» aufzeichnet, auch noch mit Scrollposition erweitern. Dies wird dann aber ohne Kontobezug bleiben.
ich erhalte Dein Angebot, mein Lesen Dir zu merken. Nein danke, diesen Service wünsche ich nicht. Das Amazon-Datencenter in Irland soll cool bleiben.
Während eine Funktion intern auf meinem Rechner: dies ist abgearbeitet, jenes noch offen im Sinne des Lesebandes im Buch schon hilfreich sein könnt.
Danke für die transparente Aufklärung auf Augenhöhe, wer wie von diesem neuen Feature profitiert.
Und ja, ihr dürft mehr wissen. Werde das aktivieren, denn als Verleger profitiere ich ja auch von den Erkenntnissen, welche aus dem Benutzerverhalten hervorgehen - und sei es auch nur eine - wie auch immer geartete - „Optimierung“ der Beitragslängen ;-)
Merci!
Republik AG
Sihlhallenstrasse 1
8004 Zürich
Schweiz