Vor etwa zwei Jahren kam mir die Idee, und ich arbeitete rund drei Monate lang als Side Project daran, musste es wegen meines Hauptjobs aber einstellen.
In letzter Zeit ging die Umsetzung jedoch mit Coding-Agenten, mit denen ich Entwicklungsspezifikationen festlege und vorantreibe, viel schneller als noch vor zwei Jahren.
Also konzentrierte ich mich darauf, die Spezifikationen zu verfeinern, und konnte mit diesem Schwung den Service in nur zwei Wochen launchen.
Der Auslöser für die Entwicklung von Velprium war das Problem, dass meine Alltagsaufzeichnungen an vielen Orten verstreut waren.
Kalender, Notion, Obsidian und verschiedene Kollaborationstools …
Ich habe sogar ein Bullet Journal auf Papier ausprobiert, aber jedes Mal, wenn ich Notizen zwischen digitalen und analogen Formaten übertragen musste, war es umständlich.
Also kam ich auf den Gedanken: „Was wäre, wenn man Kalender-Events um die Funktionen von Notion ergänzt?“
Herkömmliche Kalender sind so aufgebaut, dass auf der x-Achse die Zeit und auf der y-Achse nur Titel und Beschreibung angezeigt werden.
Deshalb habe ich Event-Eigenschaften hinzugefügt, um die y-Achse inhaltlich zu erweitern.
Dabei wurde mir klar, dass eine dritte Achse nötig ist, also eine z-Achse, die die Perspektive darstellt.
Selbst wenn x- und y-Achse gleich sind, kann dieselbe Information je nach Perspektive – Tagebuch, Arbeitsprotokoll, Schlafprotokoll, Trainingsprotokoll, persönliche Termine usw. – völlig anders aussehen.
Genau daraus entstand das Konzept. Seiten sind die z-Achse (die Betrachtungsperspektive), Bereiche sind die parallelen Zeitachsen, aus denen eine Seite besteht, und Event-Eigenschaften bilden die y-Achse.
- Ich habe außerdem Beziehungen zwischen Events hinzugefügt. Wenn man zum Beispiel die heutige Aufgabe nicht abschließen kann und sie auf morgen verschieben muss, bleibt nach dem Drücken der Verschieben-Schaltfläche das heutige Event bestehen und für morgen wird ein Folge-Event erstellt.
Dadurch lässt sich der genaue Zeitpunkt der Verschiebung nachvollziehen, und da der Änderungsverlauf jedes Events gespeichert wird, kann man auch sehen, wann genau die Entscheidung zur Verschiebung getroffen wurde.
Eine Funktion, die es in der Version von vor zwei Jahren noch nicht gab, ist die AI-Query-Funktion. Seit letztem Jahr entwickle ich beruflich mehrere Text-to-SQL-Chatbots, und dabei kam mir der Gedanke, dass auch ein Kalender eine Chatbot-Funktion haben sollte.
Zum Beispiel kann man darum bitten, auf Basis der im Kalender erfassten Schlaf-Events zu analysieren, wie sich das Schlafmuster im letzten Monat verändert hat.
(Zur Info: Ich nutze Auto Event Maker, eine von mir selbst entwickelte iPhone-App, um auf dem iPhone erfasste Gesundheitsdaten mit Kalender-Events zu synchronisieren.)
-
Diese App ist derzeit kostenlos, und wenn die Nutzerzahl steigt, plane ich die Einführung eines kostenpflichtigen Plans.
Die Serverkosten sind zwar gering, aber wenn viele Nutzer die AI-Funktionen verwenden, werde ich wohl die Token-Kosten tragen müssen. -
Ich bin mir nicht sicher, ob dieses Modell für andere nützlich und leicht verständlich ist oder ob ich einem Kalender damit zu viele Konzepte hinzufüge.
Genau das ist der wichtigste Punkt, den ich überprüfen möchte. Natürlich habe ich diese App selbst gebaut, bin sehr zufrieden damit und nutze sie gut.
Ich würde mich über Feedback zu zwei Punkten freuen.
- Finden Sie, dass die Konzepte Seiten, Bereiche und Event-Eigenschaften gut zu einer Kalender-App passen?
- Haben der Onboarding-Prozess (und die vorbereiteten Seitentemplates) geholfen, diese Konzepte zu verstehen? Ich wäre dankbar, wenn Sie sie direkt ausprobieren und mir mitteilen könnten, wo es Schwierigkeiten gab.
Besonders interessiert mich die Meinung von Menschen, die hauptsächlich Kalender-Apps nutzen und gerne ihren Alltag dokumentieren.
1 Kommentare