Domino 9 und frühere Versionen > Entwicklung

To Do - Datenbank Features

(1/5) > >>

TMC:
Ich habe die Aufgabe eine To Do - Datenbank für eine Abteilung zu erstellen.

Allerdings ohne weitere Vorgaben.

Was macht Eures Erachtens Sinn, dort als Features anzubieten?

Ich habe mir mal in R6 die Standard - ToDo's im Mailfile angesehen - und auch schon mal das meiste übernommen - macht ja auch Sinn.

Ziel und Zweck:
Die Abteilung soll ToDo's zentral in einer DBs pflegen. Ziel u.a. ist es, wenn ein MA krank ist, dass man sofort sieht was ansteht.

Ich denke was man braucht (jetzt mal zusätzlich zum R6 - Mail ToDo):
- Agenten im Mailfile, um Mails in ToDo's zu übernehmen
- Erinnerungen falls gewünscht (optional: per Reminder Mail oder Kalender-Reminder)
- Leserechte, evtl. Verschlüsselung(?)

Habt Ihr weitere Ideen, was für eine allgemeine ToDo - DB noch sinnvoll wäre?

Und wie würdet Ihr Dokumente einbinden (z.B. EMails)? Als Antwort-Dokumente zum To-Do - Dokument oder direkt in das ToDo-Dokument in ein RTF kopieren?

Ich frage, weil bestimmt das schon der/die ein- oder andere umgesetzt hat.
Mich würden Eure Erfahrungen interessieren.
Und: Wie stellt Ihr transparent dar, wenn mehrere Leute was gemacht haben.
Also User 1 hat schonmal Part1 erledigt, User 2 hat auch was gemacht, etc.

koehlerbv:

--- Zitat ---Und wie würdet Ihr Dokumente einbinden (z.B. EMails)? Als Antwort-Dokumente zum To-Do - Dokument oder direkt in das ToDo-Dokument in ein RTF kopieren?
--- Ende Zitat ---
Wegen Ordnung und Sauberkeit im Schlachthaus: Als eigenes (Antwort-)Dokument.


--- Zitat ---Agenten im Mailfile, um Mails in ToDo's zu übernehmen/quote]
Wie das ? Alle Mails werden ToDos ? Oder wie ?


--- Zitat ---Erinnerungen falls gewünscht (optional: per Reminder Mail oder Kalender-Reminder)
--- Ende Zitat ---
Jo !


--- Zitat ---Leserechte, evtl. Verschlüsselung(?)
--- Ende Zitat ---
Leserechte erscheinen mir adäquat. Wenn Du Verschlüssleung brauchen solltest, dürfte es bei einer ToDo-DB um mehr gehen. Verschlüsselung erscheint mir sinnlos in diesem Zusammenhang.


--- Zitat ---Und: Wie stellt Ihr transparent dar, wenn mehrere Leute was gemacht haben.
--- Ende Zitat ---
Haariges Problem. Auf jeden Fall never-ever ins ToDo-Doc zurückschreiben wegen Replizierkonflikten. Das gehört typischerweise in ein ResponseDoc. Das Prinzip Parent-Responses muss dabei möglichst aufgeräumt sein (da wir es beide kennen: Die Notes BP-Discussion ist da ein Anti-Beispiel).

Da ich mit sowas schon ziemlich beschäftigt war: Sag weiteres an, ich bin da gerne behilflich.

Servus,

Bernhard
--- Ende Zitat ---

TMC:
Danke für Dein Feedback Bernhard.


Zu Antwort 1 und 2 (Mails übernehmen / werden zu Response oder nicht):

Ich denke wenn man sich entscheidet, Mails etc. als Antworten zu übernehmen (und nicht ins Hauptdokument), sollte man einen konsequenten Weg gehen:
Es gibt ein übergeordnetes ToDo-Dokument mit Basisdaten (due date, Beschreibung etc.). Darunter hängt man dann die einzelnen Sachen (Mails, Aktionen, etc.)

Zu Verschlüsselung:
War nur so ein Gedanke, werde ich aber wieder verwerfen, ist nicht die Personalabteilung für die ich das mache, von da her sollte Lesezugriffs-Management ausreichen.

Zu: "Wie stellt Ihr transparent dar, wenn mehrere Leute was gemacht haben.":
Deine Antwort bestätigt mir einmal mehr, dass man mit Response Docs arbeiten sollte.

Bernhard, danke nochmal. Ich werde mir das nochmal alles durch den Kopf gehen lassen.

Und bin über alle weiteren Anregungen / Erfahrungen dankbar.

TMC:
Noch was:

Man könnte natürlich jetzt sehr weit gehen:

User erhält eine Mail -> sie/er stellt fest, das ist ja ein To Do. Also schnell mal ein neues ToDo-Dokument anlegen, und eMail per Mail-Agent zum ToDo-Dok als Response-Doc kopieren.

Nun muss eine Aktion in Form einer E-Mail folgen.
Jetzt könnte man ja ermöglichen, dass die E-Mail direkt aus der ToDo-DB erstellt wird (damit eine Kopie automatisch auch zum ToDo als Response angelegt wird).

Ist das übertrieben oder wird das gewünscht ?
Ich denke dabei auch an die Anwender. Es soll für den Anwender so einfach wie nur möglich sein, er soll aber auch intuitiv vorgehen können.

Umständlich würde ich finden, wenn Anwender nachträglich aus der $Sent - View das Dokument per Agent in die ToDo-DB kopieren müsste. Zumal da die Gefahr besteht, dass Anwender diesen Step einfach vergisst im Alltagsstress.

animate:

--- Zitat von: TMC am 14.05.04 - 23:02:45 ---Ich habe die Aufgabe eine To Do - Datenbank für eine Abteilung zu erstellen.

Allerdings ohne weitere Vorgaben.

Was macht Eures Erachtens Sinn, dort als Features anzubieten?


--- Ende Zitat ---

Ich kann die nur raten, einige Mitarbeiter der Abteilung zu interviewen (oder natürlcih auch andere Erhebungstechniken einzusetzen), um herauszufinden, was sie sich von der neuen DB erwarten und was nicht.
Was dieser und jener in diesem Forum hier gut oder schlecht findet, interessiert die, die später damit arbeiten müssen, wahrscheinlich herzlich wenig.

Navigation

[0] Themen-Index

[#] Nächste Seite