I've already talked about this, but again:
My wife is dropping our daughter off at MNusic class, and I am picking her up a while later.
Compound Event:
Start Driving W: 3pm, alarms -5 minutes, for my wife and daughter
Interval: driving, blocked out for my wife and daughter
Event Start: 3:30pm
Interval: blocked out for my daughter, but not for my wife nor me
Event End: 5:30pm
Start Driving H: 5pm, me. Alarm -5 minutes, for me.
Interval: Start Driving H to Event End: blocked out for me
...etc...
Monday, October 15, 2012
Meet Person at 7:30
A pattern in my usage of calendaring programs: I will often create meetings, events, appointments of the form "Pick up D at 7:30 after Music class"
I.e. I will put the actual target time in the title.
Reason: I will set the actual start time earlier, e.g. at 7pm, to give me time to drive to the music class to pick her up.
And I will have alarms, notifications, set at the usual countdown - 10 minutes, 5 minutes - before.
Q: Why not just set the event for the pickup time, and set an alarm?
A: I need the time to be blocked out, so that no meetings will be set up conflicting.
FLYT Magazine file - IKEA
FLYT Magazine file - IKEA:
'via Blog this'
Most cost effective magazine files I have found, and 40 cents apiece.
Better than Uline, at 1.50$ each.
'via Blog this'
Most cost effective magazine files I have found, and 40 cents apiece.
Better than Uline, at 1.50$ each.
Utility Concepts ...
All organizer facets need security and access control.
Organizer facets = notes, tasks, to do, checklist, calendar ...
All need hierarchy.
All need grouping. Folders. Etc. Labels. Tags.
Heck - just think of them all as objects in a filesystem. Perhaps we want to type the drectoriew, the folders, as MS has done with WinFS - so that a list of tasks = a folder, a directory, that contains nothing but tasks. So you can't put something else in there by accident. But note that you want to be able to add notes, etc., everywhere - i.e. you want to be able to attach notes and calendar items to the folder/directry that cntains a list of tasks, etc.
All need the same edit tools: drag and drop objects to folders/labels, and vice versa. Multiple selection. Etc.
All need the same capabilties. It's just a question of providing convenient defaults. Convenient views. E.g. its most convenient to display calendar items in a grid. But you probably don't want that to be the default way of seeing To-Dos or Notes./ (Althoygh it would be nice to be able to do so.)
--
The biggest differences between filesystems/folders/directores and objects like text notes/calendar items/to-dos are granularity, orderedness, and embeddedness.
Files tend to be relatively coarse grain. (Although the Reiser FS can efficiently support 0 an 1 charcater files.)
Files in a directory/folder do not necessarily have an order. (Although there may be one.)
Once you transition from a list of files in a directory to a text file of notes, you have really transitioned. You are no longer in a file browser anymore. You're in a ext file reader or editor, or an HTML browser. You can transition back, but you have gone through a pahse change.
... For a long time I have been thinking about representing filesystems as XML. Obviously, XML can represent any filesystem. Moreover, XML can also represent the internal structure of the files. XML has the orderedness and embeddedness that a filesystem lacks.
We can imagine an XML browser that can transition from browsing filesystems to browsing objects. Or a family of browsers, some specialized for the filesystem subset of XML, some for the text file, calendar file, etc. But all having the same basic capabilities.
The filesystem may just serve XML up to the browser. Making it essentially transparent whether what is being served is a directory listing, or file contents.
...This is like JSON versus XML. Filesystems are like JSON: hierarchical, but not really ordered. File contents often have more structure than JSON. Orderedness and embeddedness are two standard sch aspects of additional structure beyond JSON.
Organizer facets = notes, tasks, to do, checklist, calendar ...
All need hierarchy.
All need grouping. Folders. Etc. Labels. Tags.
Heck - just think of them all as objects in a filesystem. Perhaps we want to type the drectoriew, the folders, as MS has done with WinFS - so that a list of tasks = a folder, a directory, that contains nothing but tasks. So you can't put something else in there by accident. But note that you want to be able to add notes, etc., everywhere - i.e. you want to be able to attach notes and calendar items to the folder/directry that cntains a list of tasks, etc.
All need the same edit tools: drag and drop objects to folders/labels, and vice versa. Multiple selection. Etc.
All need the same capabilties. It's just a question of providing convenient defaults. Convenient views. E.g. its most convenient to display calendar items in a grid. But you probably don't want that to be the default way of seeing To-Dos or Notes./ (Althoygh it would be nice to be able to do so.)
--
The biggest differences between filesystems/folders/directores and objects like text notes/calendar items/to-dos are granularity, orderedness, and embeddedness.
Files tend to be relatively coarse grain. (Although the Reiser FS can efficiently support 0 an 1 charcater files.)
Files in a directory/folder do not necessarily have an order. (Although there may be one.)
Once you transition from a list of files in a directory to a text file of notes, you have really transitioned. You are no longer in a file browser anymore. You're in a ext file reader or editor, or an HTML browser. You can transition back, but you have gone through a pahse change.
... For a long time I have been thinking about representing filesystems as XML. Obviously, XML can represent any filesystem. Moreover, XML can also represent the internal structure of the files. XML has the orderedness and embeddedness that a filesystem lacks.
We can imagine an XML browser that can transition from browsing filesystems to browsing objects. Or a family of browsers, some specialized for the filesystem subset of XML, some for the text file, calendar file, etc. But all having the same basic capabilities.
The filesystem may just serve XML up to the browser. Making it essentially transparent whether what is being served is a directory listing, or file contents.
...This is like JSON versus XML. Filesystems are like JSON: hierarchical, but not really ordered. File contents often have more structure than JSON. Orderedness and embeddedness are two standard sch aspects of additional structure beyond JSON.
Task dependencies
I know that Kent Beck says that we should not need to record task dependencies in our Agile Scheduling.
But, for my personal tasks, it would be nice to have task dependencies taken into account.
E.g. perhaps hiding or graying out tasks that cannot be done yet because of other tasks they depend on.
(In many ways, a task dependency is like a "start by" date. As in "this task cannot be started until such and such a date. Whereas other tasks can be dome at any time, but you just give them a "tickle date" to remind you to pay attention. I may want to hide the former, although I think that I opreger graying.)
As in, propagating due dates: if Task B depends on Task A, and B has a due date Tb, then A must be done by that date - and possibly earlier, e.g. if you provide a work estimate. (Hmm, work estimates could be "number of days", "number of weekend days", etc.)
But, for my personal tasks, it would be nice to have task dependencies taken into account.
E.g. perhaps hiding or graying out tasks that cannot be done yet because of other tasks they depend on.
(In many ways, a task dependency is like a "start by" date. As in "this task cannot be started until such and such a date. Whereas other tasks can be dome at any time, but you just give them a "tickle date" to remind you to pay attention. I may want to hide the former, although I think that I opreger graying.)
As in, propagating due dates: if Task B depends on Task A, and B has a due date Tb, then A must be done by that date - and possibly earlier, e.g. if you provide a work estimate. (Hmm, work estimates could be "number of days", "number of weekend days", etc.)
Subscribe to:
Posts (Atom)