#dusk $DUSK @Dusk
Ich habe beim Erstellen von Projekt-Material einen ziemlich dummen (aber festen) Tick: Ich schaue nicht zuerst auf Twitter und zähle auch nicht zuerst die Kooperationspartner. Stattdessen suche ich direkt in den Dokumenten nach den „Fehlerszenarien“.
Wenn es reibungslos läuft, wirken alle wie Profis. Ob ein Produkt wirklich ausgereift ist, erkennt man meistens erst dann, wenn ein Nutzer daneben tippt, die Netzwerkverbindung abbricht oder eine Transaktion hängen bleibt – also daran, wie das System dich auffängt.
Nehmen wir @Dusk als Beispiel: Beim Durchgehen der Entwicklerdokumentation hat sich für mich ziemlich klar gezeigt, dass die Informationsdichte auf der Engineering-Seite nicht gering ist. Aber sobald man den Blick von „wie man als Entwickler anbinden kann“ auf „wie kommt ein normaler Nutzer sicher durch den kompletten Prozess“ wechselt, werden die Details deutlich weniger ausführlich.
Ich achte besonders auf diese Punkte:
① Wallet: Gibt es nach einem Verbindungsfehler eine klare Diagnose-Route? Wie werden Gerätewechsel, Netzwerkwechsel und die erneute Autorisierung jeweils behandelt?
② Konto: Welche Berechtigungen gibt es genau, lässt sich die Autorisierung fein granular aufteilen, und welche Zustände können aktiv widerrufen werden?
③ Transaktionen: Was bedeuten Pending, Fehler und Timeout jeweils? Soll der Nutzer warten, erneut versuchen oder die Transaktion neu anstoßen?
④ Cross-Chain: Was passiert, wenn Assets im Zwischenstatus stecken? Wo kann man sich nach einem Fehlschlag den Geldfluss anschauen?
⑤ Privatsphäre: Welche Teile der Transaktionsdaten sind sichtbar, welche nicht? Wie kann der Nutzer bestätigen, was er tatsächlich offengelegt hat?
⑥ Wiederherstellung: Wenn Browser-Cache weg ist, das Gerät gewechselt wurde oder die Wallet fehlerhaft ist – gibt es für den Nutzer eine klare Selbsthilfe-Route?
Das wirkt vielleicht alles wenig „sexy“, aber es erklärt viel eher, ob ein Produkt wirklich in die Phase der echten Nutzung eingetreten ist, als noch eine weitere Folie/Poster zu einer Ökosystem-Kooperation.
Ich würde sogar eine ganz einfache Beobachtungstabelle dafür anlegen:
Vollständigkeit der Entwicklertutorials: hoch
Lesbarkeit der APIs: eher hoch
Abdeckung von Ausnahmefällen: mittel bis schwach
Hinweise zur Wiederherstellung für Nutzer: noch zu prüfen
Erklärung der Berechtigungen: noch zu prüfen
Fehlerbehandlung bei Cross-Chain: noch zu prüfen
Selbsthilfefähigkeit normaler Nutzer: noch zu verifizieren
Natürlich heißt das nicht, dass die technische Roadmap von Dusk grundsätzlich problematisch ist. Im Gegenteil: Gerade umgekehrt. Je mehr es um Privatsphäre, RWA, Compliance und On-Chain-Assets geht, desto weniger darf man nur darauf schauen, „ob es funktioniert“. Man muss auch sehen, „ob man Probleme danach noch beherrschen kann“.
Was meine Bewertung wirklich nach oben gebracht hat, ist nicht, dass plötzlich Dutzende Seiten mehr in die Doku geschrieben wurden. Sondern an einem bestimmten Tag habe ich gemerkt: Selbst in den Ecken, die kaum jemand schreibt – bei gescheiterten Transaktionen, fehlgeschlagener Autorisierung oder blockierenden Assets – erklärt es jemand ernsthaft und sorgfältig.
Ich habe beim Erstellen von Projekt-Material einen ziemlich dummen (aber festen) Tick: Ich schaue nicht zuerst auf Twitter und zähle auch nicht zuerst die Kooperationspartner. Stattdessen suche ich direkt in den Dokumenten nach den „Fehlerszenarien“.
Wenn es reibungslos läuft, wirken alle wie Profis. Ob ein Produkt wirklich ausgereift ist, erkennt man meistens erst dann, wenn ein Nutzer daneben tippt, die Netzwerkverbindung abbricht oder eine Transaktion hängen bleibt – also daran, wie das System dich auffängt.
Nehmen wir @Dusk als Beispiel: Beim Durchgehen der Entwicklerdokumentation hat sich für mich ziemlich klar gezeigt, dass die Informationsdichte auf der Engineering-Seite nicht gering ist. Aber sobald man den Blick von „wie man als Entwickler anbinden kann“ auf „wie kommt ein normaler Nutzer sicher durch den kompletten Prozess“ wechselt, werden die Details deutlich weniger ausführlich.
Ich achte besonders auf diese Punkte:
① Wallet: Gibt es nach einem Verbindungsfehler eine klare Diagnose-Route? Wie werden Gerätewechsel, Netzwerkwechsel und die erneute Autorisierung jeweils behandelt?
② Konto: Welche Berechtigungen gibt es genau, lässt sich die Autorisierung fein granular aufteilen, und welche Zustände können aktiv widerrufen werden?
③ Transaktionen: Was bedeuten Pending, Fehler und Timeout jeweils? Soll der Nutzer warten, erneut versuchen oder die Transaktion neu anstoßen?
④ Cross-Chain: Was passiert, wenn Assets im Zwischenstatus stecken? Wo kann man sich nach einem Fehlschlag den Geldfluss anschauen?
⑤ Privatsphäre: Welche Teile der Transaktionsdaten sind sichtbar, welche nicht? Wie kann der Nutzer bestätigen, was er tatsächlich offengelegt hat?
⑥ Wiederherstellung: Wenn Browser-Cache weg ist, das Gerät gewechselt wurde oder die Wallet fehlerhaft ist – gibt es für den Nutzer eine klare Selbsthilfe-Route?
Das wirkt vielleicht alles wenig „sexy“, aber es erklärt viel eher, ob ein Produkt wirklich in die Phase der echten Nutzung eingetreten ist, als noch eine weitere Folie/Poster zu einer Ökosystem-Kooperation.
Ich würde sogar eine ganz einfache Beobachtungstabelle dafür anlegen:
Vollständigkeit der Entwicklertutorials: hoch
Lesbarkeit der APIs: eher hoch
Abdeckung von Ausnahmefällen: mittel bis schwach
Hinweise zur Wiederherstellung für Nutzer: noch zu prüfen
Erklärung der Berechtigungen: noch zu prüfen
Fehlerbehandlung bei Cross-Chain: noch zu prüfen
Selbsthilfefähigkeit normaler Nutzer: noch zu verifizieren
Natürlich heißt das nicht, dass die technische Roadmap von Dusk grundsätzlich problematisch ist. Im Gegenteil: Gerade umgekehrt. Je mehr es um Privatsphäre, RWA, Compliance und On-Chain-Assets geht, desto weniger darf man nur darauf schauen, „ob es funktioniert“. Man muss auch sehen, „ob man Probleme danach noch beherrschen kann“.
Was meine Bewertung wirklich nach oben gebracht hat, ist nicht, dass plötzlich Dutzende Seiten mehr in die Doku geschrieben wurden. Sondern an einem bestimmten Tag habe ich gemerkt: Selbst in den Ecken, die kaum jemand schreibt – bei gescheiterten Transaktionen, fehlgeschlagener Autorisierung oder blockierenden Assets – erklärt es jemand ernsthaft und sorgfältig.