Opened by flowdy at 2014-12-20 15:00
User since
2012-08-03
45 Artikel
BenutzerIn
2012-08-03
45 Artikel
BenutzerIn
Hallo,
Ihr fragt euch vielleicht, noch ein ZM-Tool, es gibt sie doch schon wie Sand am Meer? Ja, meine ich, denn die Abdeckung zwischen »schön einfach, leider zu einfach für meine Anforderungen« und »viel zu kompliziert und überladen« ist in meinen Augen noch recht lückenhaft.
Vor allem die Anordnung der Aufgaben nur nach der Frist und/oder nach der Priorität, das mag ja manchem genügen. Mir reicht der geringe Mehrwert gegenüber einer Todoliste in einer simplen Textdatei, die ich nach Gutdünken ordnen kann, in anständigen Texteditoren ist das mit ein paar Tastendrücken getan, nicht aus.
Zumal die Anordnung nach der Frist schon mit dem ersten längeren Urlaub verfälscht ist. Nehmen wir an, man hat Urlaub von Montag bis 4.1. Eine Aufgabe sei zu bearbeiten vom 19.12. bis zum 5.1. Sie wär daher, würde das Tool bloß auf die Systemsekunden bis zur Frist abstellen, zu gestern Mittag signifikant weniger dringlich gewesen im Vergleich zu einer gestern schon fälligen, einfacheren Aufgabe.
Nicht mal taskwarrior – es sei denn, ich hab da was übersehen, Programmieren macht mir Nerd zugegeben doch mehr Spaß als sorgfältige Konkurrenzanalyse ;) – kann hier punkten.
FlowgencyTM hat dagegen seine eigene Zeitebene, die zwischen der lokalen Systemzeit auf der einen Seite und dem anwenderdefinierten Arbeitszeitmodell auf der anderen Seite vermittelt. Der Anwender benutzt einmalig und zum Ändern jederzeit ein entsprechendes Formular, wodurch dann folgendes in sein Profil gespeichert werden könnte:
Das Tool parst den JSON-String und weiß also, dass eine mit dieser Zeitschiene »default« verknüpfte Aufgabe bei localtime(1419084048), also in diesem Augenblick, pausiert und ihr Zeitfortschritt bzw. ihre Dringlichkeit seit gestern 16:59 bis zum 2. Januar 9:00 "eingefroren" sei. Während dieser Zeit kann sie nicht im Ranking aufsteigen, aber andere, nicht pausierende, da mit anderen Zeitschienen verknüpfte Aufgaben können sie natürlich überklettern.
Und zwar weiß es das nicht erst jetzt, sondern von Definition an, weshalb der Dringlichkeitsanstieg vonvornherein steiler ausfallen kann, aber dafür linear. FlowgencyTM ist quasi ein Antagonist zu unserem (d.h. meinem, keine Ahnung ob euren) Bauchgefühl, für das Dringlichkeit eher quadratisch bis exponentiell ansteigt.
Nicht nur was den Zeitfortschritt betrifft, sondern auch in die saubere Berechnung des Erledigungsfortschritts habe ich Mühe investiert. Eine wichtige Teilkomponente der Dringlichkeit ist, wie weit die beiden Fortschritte auseinander gedriftet sind und in welche Richtung, Kurzdenke kann da also tatsächlich die Wirklichkeitsnähe der Anordnung nach Dringlichkeit einschränken.
Aufgaben lassen sich strukturieren in einzelne Schritte und Unterschritte, die Strukturtiefe hat keine technische Grenze. Nun könnte ich als fauler Entwickler natürlich einfach sagen, alle Einzelschritte treiben, wenn erledigt, den Gesamtfortschritt zu gleichen Teilen weiter, egal wie zeitaufwendig sie im Einzelfall sind im Verhältnis zur insg. für die Aufgabe veranschlagten Zeit. Es sollte klar sein, warum der FlowgencyTM-User die Möglichkeit haben sollte, zu sagen "Einzelschritt X ist meiner Schätzung nach n-mal so zeitaufwendig wie a) der übergeordnete Schritt, b) die beigeordneten bzw. c) die direkt untergeordneten Schritte."
Ich habe die Verhältniszahlen dabei absichtlich über drei Achsen verschränkt: Zum Einen soll der Anwender hier eh nix aufs Geratewohl einstellen, wenn er sich nicht sicher ist, kann er jeweils die Voreinstellung von einem Aufwandsanteil belassen, das hierarchische Level des Schritts wird so zumindest berücksichtigt. Zum Anderen darf die nachträgliche Manipulation zu Gunsten des inneren Schweinehunds ("Sieh, jetzt ... *wertefrisier* ... haben wir doch schon 90% geschafft, machen wir erst mal ne Pause") besonders bei tiefstrukturierten Aufgaben ruhig erschwert werden mit dem dadurch nötigen Wiederaustarieren.
Eine Aufgabe kann im Ranking natürlich geöffnet werden. Im geöffneten Zustand wird angezeigt: Beschreibung, soweit vorhanden; die letzte Annotation; Schritte zum abhaken, aber weder erledigte noch diejenigen, die erst nach ihnen erledigt werden können, da abhängig.
FlowgencyTM auf GitHub
Fragen dazu:
Wie kann ich eine öffentliche Demo-Installation hosten, damit das Konzept von Interessenten mit Spieldaten getestet werden kann? Shared Hosting kommt nicht in Frage wg. Mojolicious, oder? Selbst wenn Mojo ohne Abhängigkeiten auskommt – wie sollte ich es starten? Und selbst wenn auch das irgendwie geht, bräuchte ich ssh-Zugriff für git-pull. Also führt eigentlich nichts an einem virtuellen Host vorbei, der mir aber zu teuer ist für den Zweck, oder?
Gut, könnte vielleicht ja meinen Raspi dafür nutzen. Das aber ist nur der Notnagel, denn in mein Heimnetzwerk möchte ich die Welt ungern einladen.
Last edited: 2014-12-20 15:01:05 +0100 (CET)
Ihr fragt euch vielleicht, noch ein ZM-Tool, es gibt sie doch schon wie Sand am Meer? Ja, meine ich, denn die Abdeckung zwischen »schön einfach, leider zu einfach für meine Anforderungen« und »viel zu kompliziert und überladen« ist in meinen Augen noch recht lückenhaft.
Vor allem die Anordnung der Aufgaben nur nach der Frist und/oder nach der Priorität, das mag ja manchem genügen. Mir reicht der geringe Mehrwert gegenüber einer Todoliste in einer simplen Textdatei, die ich nach Gutdünken ordnen kann, in anständigen Texteditoren ist das mit ein paar Tastendrücken getan, nicht aus.
Zumal die Anordnung nach der Frist schon mit dem ersten längeren Urlaub verfälscht ist. Nehmen wir an, man hat Urlaub von Montag bis 4.1. Eine Aufgabe sei zu bearbeiten vom 19.12. bis zum 5.1. Sie wär daher, würde das Tool bloß auf die Systemsekunden bis zur Frist abstellen, zu gestern Mittag signifikant weniger dringlich gewesen im Vergleich zu einer gestern schon fälligen, einfacheren Aufgabe.
Nicht mal taskwarrior – es sei denn, ich hab da was übersehen, Programmieren macht mir Nerd zugegeben doch mehr Spaß als sorgfältige Konkurrenzanalyse ;) – kann hier punkten.
FlowgencyTM hat dagegen seine eigene Zeitebene, die zwischen der lokalen Systemzeit auf der einen Seite und dem anwenderdefinierten Arbeitszeitmodell auf der anderen Seite vermittelt. Der Anwender benutzt einmalig und zum Ändern jederzeit ein entsprechendes Formular, wodurch dann folgendes in sein Profil gespeichert werden könnte:
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// aus dem Datenbankfeld user.time_model
{"default":{
"label":"Büro",
"week_pattern":"Mo-Fr@9-16",
"variations":[
{
"description":"Weihnachtsurlaub",
"from_date": "22.12.14",
"until_date": 1, // ja, daraus schließt das System d. ,1".1.15
"wp_from_timetrack":"private"
}
],
...
},
"private":{
"label":"Task deaktiviert",
"week_pattern":"Mo-So@!0-23"
}
} // Ende Datenbankfeld user.time_model
Das Tool parst den JSON-String und weiß also, dass eine mit dieser Zeitschiene »default« verknüpfte Aufgabe bei localtime(1419084048), also in diesem Augenblick, pausiert und ihr Zeitfortschritt bzw. ihre Dringlichkeit seit gestern 16:59 bis zum 2. Januar 9:00 "eingefroren" sei. Während dieser Zeit kann sie nicht im Ranking aufsteigen, aber andere, nicht pausierende, da mit anderen Zeitschienen verknüpfte Aufgaben können sie natürlich überklettern.
Und zwar weiß es das nicht erst jetzt, sondern von Definition an, weshalb der Dringlichkeitsanstieg vonvornherein steiler ausfallen kann, aber dafür linear. FlowgencyTM ist quasi ein Antagonist zu unserem (d.h. meinem, keine Ahnung ob euren) Bauchgefühl, für das Dringlichkeit eher quadratisch bis exponentiell ansteigt.
Nicht nur was den Zeitfortschritt betrifft, sondern auch in die saubere Berechnung des Erledigungsfortschritts habe ich Mühe investiert. Eine wichtige Teilkomponente der Dringlichkeit ist, wie weit die beiden Fortschritte auseinander gedriftet sind und in welche Richtung, Kurzdenke kann da also tatsächlich die Wirklichkeitsnähe der Anordnung nach Dringlichkeit einschränken.
Aufgaben lassen sich strukturieren in einzelne Schritte und Unterschritte, die Strukturtiefe hat keine technische Grenze. Nun könnte ich als fauler Entwickler natürlich einfach sagen, alle Einzelschritte treiben, wenn erledigt, den Gesamtfortschritt zu gleichen Teilen weiter, egal wie zeitaufwendig sie im Einzelfall sind im Verhältnis zur insg. für die Aufgabe veranschlagten Zeit. Es sollte klar sein, warum der FlowgencyTM-User die Möglichkeit haben sollte, zu sagen "Einzelschritt X ist meiner Schätzung nach n-mal so zeitaufwendig wie a) der übergeordnete Schritt, b) die beigeordneten bzw. c) die direkt untergeordneten Schritte."
Ich habe die Verhältniszahlen dabei absichtlich über drei Achsen verschränkt: Zum Einen soll der Anwender hier eh nix aufs Geratewohl einstellen, wenn er sich nicht sicher ist, kann er jeweils die Voreinstellung von einem Aufwandsanteil belassen, das hierarchische Level des Schritts wird so zumindest berücksichtigt. Zum Anderen darf die nachträgliche Manipulation zu Gunsten des inneren Schweinehunds ("Sieh, jetzt ... *wertefrisier* ... haben wir doch schon 90% geschafft, machen wir erst mal ne Pause") besonders bei tiefstrukturierten Aufgaben ruhig erschwert werden mit dem dadurch nötigen Wiederaustarieren.
Eine Aufgabe kann im Ranking natürlich geöffnet werden. Im geöffneten Zustand wird angezeigt: Beschreibung, soweit vorhanden; die letzte Annotation; Schritte zum abhaken, aber weder erledigte noch diejenigen, die erst nach ihnen erledigt werden können, da abhängig.
FlowgencyTM auf GitHub
Fragen dazu:
Wie kann ich eine öffentliche Demo-Installation hosten, damit das Konzept von Interessenten mit Spieldaten getestet werden kann? Shared Hosting kommt nicht in Frage wg. Mojolicious, oder? Selbst wenn Mojo ohne Abhängigkeiten auskommt – wie sollte ich es starten? Und selbst wenn auch das irgendwie geht, bräuchte ich ssh-Zugriff für git-pull. Also führt eigentlich nichts an einem virtuellen Host vorbei, der mir aber zu teuer ist für den Zweck, oder?
Gut, könnte vielleicht ja meinen Raspi dafür nutzen. Das aber ist nur der Notnagel, denn in mein Heimnetzwerk möchte ich die Welt ungern einladen.
Last edited: 2014-12-20 15:01:05 +0100 (CET)
package MyClass; sub new {\b\b\b\b\b\b\b\b\buse Moose;