Tagged to-do's
Zach Paine
lists.
I manage all my to-do's currently using text files and emacs. I like
the flexibility and ease of editing it provides, but I've been thinking
about ways to improve the system.
I've been thinking about extending the idea of "tags" (a la
del.icio.us) to my to-do list.
It seems like one of the most powerful suggestions that I got out of
GTD is the idea of contextual lists. However, the problem is that one
to-do may not apply to only one context.
The idea being that you can apply any number of tags to an item. I.e.
the item "Bounce tagged to-do idea off 43folders" could have the tags
"email", "online" and "low energy".
Then when deciding the proper context for any given moment, you have
can define it with a lot more flexibility.
Comments, suggestions, flames?
-Zach
Edward Vielmetti
it gives me great temptation to put my todo lists on the web in
Socialtext wiki pages and tag them with delicious as is. (or take
pictures of my todo lists and tag with Flickr). the objective of both
is to get some broader audience aware of what I'm up to.
tags are certainly more useful than say categories for the task
because the understanding is that you can create tags on the fly and
use them for as long as you need them and then ignore them.
Have you thought about using Gmail's mail tagging and filtering for
your todo lists? Email yourself reminders, and have Gmail auto-tag
things for you. That handles the intimacy gradient problem of not
wanting to expose your todos to the world, though it doesn't get you
offline todo'ing away from the wifi electrosmog.
tagging this with lazyweb,
Ed
Edward Vielmetti in Ann Arbor, MI 48104
+1 734 276 5910 / skype: edwardvielmetti
edward.v...@gmail.com
edward.v...@socialtext.com
http://vielmetti.typepad.com
http://www.socialtext.com
Zach Paine
> your todo lists? Email yourself reminders, and have Gmail auto-tag
> things for you. That handles the intimacy gradient problem of not
> wanting to expose your todos to the world, though it doesn't get you
> offline todo'ing away from the wifi electrosmog.
scheme is the speed with which I can wrangle my lists. I think the
added layers of complexity that would be inherent in using email might
be less than optimal. I think that a low-threshold of pain in
creating to-do's and editing them is really important to the system.
I have also been thinking that since I maintain my text files in
Markdown, it might be nice to have pages automatically generated.
Maybe I should look into a wiki. I'd like to hear why people prefer a
wiki over other GTD methodologies. Perhaps in a different thread
though ;-)
-Zach
Leland
curious to see how you'll implement it.
What would be especially neat would be if you'd keep it
non-platform-dependent, so the non-mac crowd could use it too. Maybe
the backend in Ruby/perl/python or even Java/C/C++ so it's portable,
but the GUI done up in pretty Mac OS X (aqua?) happiness.
I'm most tempted to do it coupled with SQL, but that brings in a bunch
of added dependencies that are uncool. Since you're already an emacs
user, have you considered doing something in elisp? Maybe you could
couple it with the beautiful EmacsWiki mode. Personally, I think I'll
take a stab at writing something in Java, mainly because I'm trying to
learn it.
I'm just rambling here, jotting down ideas as they come to me. I'd like
to watch this in the making, if you'd do the hacking publicly. Good
luck!
Zach Paine
> non-platform-dependent, so the non-mac crowd could use it too. Maybe
> the backend in Ruby/perl/python or even Java/C/C++ so it's portable,
> but the GUI done up in pretty Mac OS X (aqua?) happiness.
platform-independence turns out to be desirable, I'd like to do
something web-based. Perhaps using some crazy-cool javascript foo to
create a nice interface. I think gmail has shown that web-interfaces
can be as good (if not better.. yes I'm looking at you Outlook) than
traditional GUI's.
> I'm most tempted to do it coupled with SQL, but that brings in a bunch
> of added dependencies that are uncool. Since you're already an emacs
> user, have you considered doing something in elisp? Maybe you could
> couple it with the beautiful EmacsWiki mode. Personally, I think I'll
> take a stab at writing something in Java, mainly because I'm trying to
> learn it.
it, but haven't invested the time in learning about it.
> I'm just rambling here, jotting down ideas as they come to me. I'd like
> to watch this in the making, if you'd do the hacking publicly. Good
> luck!
you. If if this turns out to be something that I actually undertake, I
would like to make it public in some form, perhaps as an open source
project.
-Zach
jo...@joshwand.com
http://joshwand.com/blog/archives/000022.html). Outliner, wiki, tags,
calendar-views, user-scripting, plugins, search-nodes, browser-based,
portable, etc. I would love to put in in "Rich DHTML" as Jon Udell
calls it, for max portability.
I already have a lot of the architecture mapped out for how to make
this work, and some of the hard work has already been done (tiddlywiki,
activerenderer, del.icio.us, etc)... I'm not a professional coder
anymore, but If you are (or know) a coder who could contribute (rich
dhtml + a php backend), please let me know what you can do. I am *so*
up for making this happen, as an open source project, or otherwise.
Benjaloo
has a wonderful built-in system of tags). My tages included contexts,
times (BusinessHours, Anytime, Evenings, Weekends, etc), People (I
listed the people I commonly interact with)--it was very helpful to be
able to filter based on multiple tags on occasion, but it made the
inputting of NAs take just a little longer, and that was enough to make
it too cumbersome. I think someone else, in their reply to this
question, pointed out that it has to be REALLY easy to input your NAs
or else you won't do it.
hth
Ben
Leland
Everything's stored in text files. Format:
short description
more details on the second line
tag tag tag space separated
Presentation is really simple, just store all the entries in some data
structure, show only entries whose tag fits the current view. This
should be really easy.
The harder part is editing your entries, but even that shouldn't be too
bad. Perhaps each task should be assigned a specific id, stored in the
text file. Downside is that now the text file is slightly less
intelligible, upside is ease of locating one task. Wait, nevermind,
each task's short description should be unique. So, when we want to
edit, we search our database (text file) on the short description,
serve up the appropriate info in text fields ready to be edited, then
write the changes into the text file.
Of course, if you're making this publicly available via some server (as
a web app), you'd have to handle security issues, but that's pretty
much a solved problem, right?
Biggest drawback, as I see it, is that database access will be slow.
Maybe that doesn't matter so much for one user running the app locally.
One cool feature would be the ability to search on two tags as an AND.
I could pick "@office" and "lowenergy" and I'd only see the tasks that
have both tags.
If you implement it as a web app, maybe it'd have some implications for
group project planning. Might turn out to be some pretty useful
software.
Josh
Very interesting idea.
Like other people in this thread, I've been thinking about much the
same thing.
I've been working on it from the usability end, trying to isolate
exactly what the simplest set of archetypical behaviors are for using a
contextual system of this sort. (That's partly what the index card
photoset I posted was in aid of.) It's mixed in with some other stuff
that I can't show at the moment, but my goal for this weekend is to get
what I can share separated out from what I can't. We'll see. :)
I'll reply here when I've worked it out a bit more...
Josh
a common view on this group that:
1. When you're using just one computer, or one operating system, it's
easy to pick whatever tool (outlook, tinderbox, etc.) suits your needs
best, and...
2. When you start moving from computer to computer, and _definitely_
when you move around boxes with multiple OS's, that becomes a problem,
and....
3. The workarounds that exist seem to involve managing a pile of text
files, a wiki or two, some webmail, a blog, a del.icio.us inbox, and a
bunch of other stuff that _almost_ meshes together, but hasn't been
designed, to, and so you spend a _lot_ more time than you should
fiddling with your tools instead of working.
Okay. We have vaguely defined a problem (although I'd like to bash at
it a bit more).
Accepting that for the moment, the proper solution for our problem
seems to be something like the following:
* a kind of tag-based "glue" that applies tags to our data and allows
us to hyperlink it together: like del.icio.us for the hard drive,
tweaked for gtd
* a way to access that "glue" via the web (has anyone had a chance to
check out BSAG's GTD On Rails webapp, BTW?), and edit it remotely.
(this could be via export to a wiki from Markdown-formatted text files
via your text editor?)
* It should get the hell out of your way, and not reinvent the wheel. I
*have* a text editor. I'm writing this post in it now. I *have*
Quicksilver; I use it all the time. I use instiki all the time, and
blogging software (LiveJournal in my case).
Like I said, I have some concept work done (no code: I'm a
product/usability designer, not a coder) that I can share, once I've
decided what should and shouldn't be. But since we've all gathered here
and we all seem to have the same itch, doesn't it make sense to
cooperate on scratching it?
My US$0.02, adjusted for inflation.
Cheers,
Josh
Leland
school grad, taking a gap year before starting college next fall), but
what little I've learned about web design has totally turned me off in
regards to anything javascript. Bloody IE...
As for the "get the hell out of your way" approach, I totally agree.
Could we write a back end in <insert favorite language here> that can
integrate with any text editor? I don't know what the capabilites are,
but I thought I read somewhere that software like Textmate can use Ruby
scripts? What about emacs? Can you import other code through elisp? Any
scripting language would do well, especially because of how portable it
would be to a web app.
An added advantage of storing everything in a text file is that anyone
who knows the workings of the app can just add new tasks by appending
data to the file, whether with that quicksilver trick or just from a
command line.
jo...@joshwand.com
tiddlywiki, et al. http://del.icio.us/judell/dhtml
data storage: structured text files are good... you should be able to
dump text in and out (e.g. from a texteditor, to a blogging tool)
relatively seamlessly.
persistence: ideally, should save after each edit. doing this in the
browser is non-trivial (how does JS handle filesystem stuff? security
restrictions?). What about webDAV? XML-Http? If all else fails, manual
save should be possible. I would LOVE to be able to stick the whole
thing on a usb thumb drive and run it from there, on multiple
platforms.
architecture: max cross-platform compatibility appears to be a
priority... The way I see it, it should be able to run locally, and
sync with a backend for backup, or for other functionality
(notifications/reminders, export to wiki or other db, hooks to
whatever). I plan to study the gmail, and google suggest (livesearch)
architectures for clues. But DHTML + XML/HTTP + robust server backend
seems like a good place to start.
what kinds of data nodes are we talking about, by the way? full-fledged
wiki content? todos? something in between?
more thinking out loud....
--Josh (the other one)
PS: the google groups web interface sucks... what's a better way to
read individual threads?
jo...@joshwand.com
why this isn't a good place to be for our tool...
http://koranteng.blogspot.com/2004/10/on-gmail-and-dhtml-architecture-again.html
Michael Sippey
and Outlook 2003 (gasp gasp!). And with this plain vanilla install I
get "tagged" to-dos with Outlook out of the box.
Outlook's "categories" can act like "tags." They're just not called
tags. But most any object in Outlook (contacts, tasks, journal
entries) can be labeled with one or more categories. The category UI
supports both picking from an existing list (hey, projects! contexts!)
or creating single-use categories for that particular item. And
Outlook's "view / arrange / show in groups" command lets me shift from
a date-based org of my tasks to a category-based org of my tasks. Any
tasks that live in multiple categories appear under both headings.
Now, Outlook 2003 out of the box doesn't have decent cross-type
searching. But Lookout (which msft bought) does, so to see all my
journal entries, tasks and appointments tagged with the category
"typepad," all I need to do is do a Lookout search for
"category:typepad".
Not sure if Entourage supports the same stuff. But I hazard a guess
that this is one of the more underutilized features in Outlook...
-m
Josh
what?
Anyway...
This is likely my bias showing, but I'm inclined to worry less about
the technology and more about what this thing would be supposed to
_do_. And that's defined by what the holes are in what we already have.
To determine what those are, we need to know what we have, and what we
do with them, exactly. Then hopefully we can clearly see where we are
working around holes.
What do you have, and what does it do? What are you finding yourself
doing by hand (or by a set of scripts that you still have to use your
brain to manage) that you really shouldn't be doing? I had a fairly
long set of answers to these questions, then I realized that I was just
marching headlong into a gripe of mine instead of working to answer the
question, so I stopped. :) It's 4:30 in the morning here on the east
coast, so it's definitely time to crash.
As to what I'm doing, [I've showed you that][1]. I've determined a
number of problems with it that I have to work around. What are yours?
[1]: http://www.flickr.com/photos/jazzmasterson/sets/48077/
Josh
Yes, Entourage does the same thing. I think the issue here is less the
behavior of tags, and more a solution that is both able to do tags, and
work on multiple, cross-platform machines.
Running two XP boxes, three macs, and a linux box here. Either outlook
or entourage would be a poor choice for that sort of setup.
Right now, there are workarounds (wikis, text files, carefully arranged
folders in a keychain drive) that work. What seems to be needed now
(IMHO) is an add-on to glue these simple, cross-platform tools
together.
An app that a) glues them all together successfully so that the
existing tools' strengths shine through, b) can live either online or
in a keychain drive (a la portable firefox or thunderbird), and c) is
platform and texteditor/wikiflavor agnostic would be simply superb.
Josh
One last post for the night.
If you do decide to go through with this, you could set up a free
basecamp project to manage it, and then we can all play with the shiny
toy. :)
Leland
by gmail, and tiddlywiki is kinda fun and neat, but I'm just not
attracted by tiddlywiki's glitz. Especially since it (last I knew)
lacked the ability to save new tiddlies or whatever the creators choose
to call the entries. My turn-off from DHTML might just be that I feel
intimidated by the lack of standards-compliance. ::shrugs:: Maybe I
just need to bite the bullet and learn the javascripting at some point.
My other concern is that it's starting to sound like people want to do
too much here. I just want a spider to scan my documents, and do it
well. Along the lines of keeping the app out of my way, I don't want it
to integrate with my addressbook, my del.icio.us bookmarks, my
calendar, etc. What's the saying about every app expanding until it can
read email? Sounds like that's already happening here, before any code
has even been written.
Just my thoughts... I'd suggest a task crawler with tags, that includes
little bits of wiki goodness to attach support materials to each task.
Start little and humble, then if anybody wants a gigundo everything you
ever wanted in a GTD app (plus the kitchen sink) thing, it can grow.
//shrugs//
Benjaloo
you really nailed it here. I just posted something before reading this
post of yours, and you'll see substantial overlap between what you
define here (much more clearly) and what I'm asking for. The only big
difference in my specs is that I'd like to be able to download the data
to a Palm for on-the-go access as well. If a web-based (wiki-based)
solution appears, Plucker or some such Palm tool could make it
happen-or if a text-file based approach, there are text file conduits
for the Palm.
Also, it would be nice if a solution could be easy enough for the
non-Unix-speakers among us.
thanks
Ben
PS I don't know what resources I can offer since I'm not a programmer,
but I'd be happy to contribute in any way I can.
Josh
includes
little bits of wiki goodness to attach support materials to each
That's kind of what I was getting at with the "app that glues them
together" thing...
Leland
jo...@joshwand.com described.
Anyway, I'm totally in for helping with this in whatever way possible,
but I'll defer to the pros here. Being a totally green novice, I guess
it's my place to learn what I can while helping out where I'm able.
Josh
Ah, sorry. It's difficult to "see" threads in Google Groups, especially
when you're following it via the Atom feed and the hyperlinks lead you
to a deep-link of the post in question without any context. :P
Jeffrey C. Long
wondered how to do it. he pointed me to two web services, one was
feedburner, which is free, the other I don't remember cost a monthly
fee. i just found a free alternative that y'all might be interested
in. it's http://www.rss-to-javascript.com
you can see an example at
http://www.jeffreyclong.com
Edward Vielmetti
how precisely are you doing this in Typepad? I'm guessing it's with a
single-entry typepad typelist with the javascript pasted into it, but
the last time I tried to get it done that way it confused me at some
point and I stopped.
The typepad people need to get on the stick about native support for this....
Ed
terceiro
feature-creep. I'll go so far as to say that I don't want it to manage
my addresses. Or my email. Or my bookmarks. Or anything approaching my
read-and-review. Those are the fringes of my GTD implementation, are
the lowest priority, but have the highest propensity of making things
messy and complicated.
Evidence: Outlook/Entourage. Boy howdy you can do a lot with those
apps, n'est ce pas? But precisely becuase they're neither fast nor
intuitive, I have chucked them in favor of... paper. Everything else
requires too much futzing with the technology to make it worth my
while. I almost reached the point where I was comfortable with using
solely emacs (and planner.el), but in the end, even that was too much.
(Emacs always turns out to be too much meta-controlling.)
"Outliner, wiki, tags, calendar-views, user-scripting, plugins,
search-nodes, browser-based, portable..." ouch. Makes me feel
nauseated. Just to review: what makes UNIX such a darned good system:
atomization. "ls" does one thing, "pwd" does one thing, "mv" does one
thing, "chmod" does one thing. Et cetera. Why do I dislike Windows?
Because there's nothing worse than a single point of failure which does
just about everything poorly.
Not meaning to start a platform discussion, it's just an example. You
may disagree with my example, but consider my logic. Kitchen-sink apps
suck. Once Quicksilver becomes an email client, web browser, and rich
text (and Word) editor, I'll drop it. Capice?
Josh
> I'm going to add a vote for a little more K.I.S.S. and a little less
> feature-creep.
<pedant>
"KISS" and "feature-creep" are not good or bad in and of themselves.
"As simple as it has to be, but no simpler" is a good, if difficult,
standard to aim for, IMHO.
</pedant>
(no real argument with the content of your message, but I admit to
generalized irritation with the [common?] assumption that complexity is
always unnecessary, and features are always to be avoided.)
The tool-based approach is important, but the tool has to be directed
in the proper direction; it has to solve a problem that another tool
can't solve. Also, we may be looking at a problem that requires more
than one tools: I don't know, because I have yet to see anyone define
the problem precisely.
So let's recap.
It seems that the most common complaint is that we are using multiple
tools, and cross-correlation of all the information in those tools,
within contexts, is a problem. Am I incorrect in stating this?
[For example: I, like terciero, prefer to use paper to manage my GTD.
That has several problems, the most common of which is that it's
difficult to "link" contexts. That is, I have scans of some drawings on
my laptop (or, more commonly these days, on a web server or stored on
my cell phone's SD card). I have a next action in the "sketchbook"
context to revise those drawings. Whether in a text file or an index
card, it takes a certain amount of manual work to link the two, and the
link is brittle ("drawings in ~/& foobar ideation/ on laptop").]
Let's put aside, for a moment, the question of linking paper contexts
with the computer, and focus on text files and their cousins, wikis.
Textfiles are cross-platform. They live comfortably on a thumbnail
drive, and they're directly manipulatable in a good text editor.
Quicksilver-append is quite probably the coolest thing ever.
However, they have the same cross-reference problem as paper. Either
you spend a lot of time keeping your cross-references up to date, or
you do without them, which means you handle it with your "mental RAM."
Neither solution is optimal, and both are contrary to what we are
trying to do with GTD. Many people, myself included, have tried out the
wiki as a "step up" from text files, and wikis have their own problems.
First: text entry. Browsers are the worst text editors known to
humanity. I've lost so much text over the years because I was writing
it in a text entry field that it isn't funny. Also, you're no longer
working on a text file, so you can't use Quicksilver append. I don't
like giving up a useful tool once I've found it, so that's a black mark
in my book.
(I also don't like the minor bit of friction in a wiki against creating
a new page or document: "Edit page, write wikiword, save page, click
wiki word" involves three server back-and-forths. Blah. This may be
less of a problem with wiki packages other than instiki, but instiki
uses markdown, so it stays on my machine for now.)
I'd appreciate it if others would detail their specific problems.
To turn things around for a second, it's interesting to note what
people get from using a wiki, and it seems (to me) that if you're using
it for personal reasons, the thing a wiki does is to interlink things
in an intuitive way, and allow remote editing.
So, were I working to solve *my* specific complaints at the moment, the
first thing I would do is to come up with a tool that I can point at my
existing files and folders, and to interpret those in something
analgous to a wiki, which I can access remotely through a web browser.
It need not be an actual wiki, but something that solves the same
problem with textfiles that a wiki does, without the wiki's drawbacks.
However, this is not the "solve all of Josh's problems" group, it's the
43Folders group. It's entirely probable that I've missed the point in
this essay, so I ask the group: are these problems your problems? If
not, what are they?
Cheers,
Josh
jo...@joshwand.com
todos
tags
portability
FAST data entry - low data-entry cost
extensibility
keeping the data structure flexible will make it easier to add more
stuff down the road, or, rather, easier for *other people* or *users*
to add their own hacks down the road. I want to make sure people can
add their own hacks and scripts to it (as many geeks do:
http://tom.bbcity.co.uk/notcon/dannyobrien.txt) without breaking stuff
or having to fork. That's the only reason why it's vaguely useful to
talk about the kinds of features further down the road-- because it
informs today's development decisions. K.I.S.S. is a good philosophy,
but it means major, painful refactoring down the line if not enough
thought is put into the roadmap.
I don't think we need succumb to jwz's law of software development--
though, in fact, one of my problems is a high data-entry cost in
converting emails to txtfile todo items. That's something that can be
solved by an accessory program/plugin. But the underlying framework
should be there for other apps/scripts/plugins/etc to add and
manipulate data.
Good starting tasks:
1. A data-storage format
2. A library for manipulating gtd data
3. Profit! (j/k)
then, interface, and other goodies.
Some opening questions for data:
-- what kinds of data in each node? Design a gtd object. Title, tags,
what else? Obviously each node should be able to have multiple tags
attached to it.
-- Some have expressed a want for a wiki or other longtext description
field for support materials, or some kind of attachment capability. How
would this be accomplished in a way that is still browseable and
user-editable, with a low data-entry threshold?
-- plain text of some sort seems to be consensus... what would such a
format look like? Robust enough to store enough data to be useful,
human-scannable and brief enough to permit ad-hoc data entry? How? This
is determined in part by how much and what kinds of data we are to
store. I think XML is definitely not the way to go here... though if
the library/interface included a text-dump -> xml/whatever parser, the
data structures could be more complex.
That's my rambling for now. Anyone want to move this to a forum that's
slightly easier to read than GG-beta?
jo...@joshwand.com
--The slowness of the wiki create/edit process, exactly as you
described it, was what drove me back to textfiles. Using PHPwiki and a
bit of plugin code, I got it down to two steps, but I still want
editing and viewing to be zero to one clicks away from each other.
Friction is a good word, I've called it data-entry cost. (also worth
noting... dokuwiki works on plain text files)
-- File linking across contexts would indeed be a killer app, but may
also be beyond our scope unless we start talking attachments, and then
we're not dealing with textfiles anymore...
-- ** If we could link browsers (remote access in general) and
textfiles in a low-friction way, I think that would be a holy grail.***
I have some ideas on this, using textfiles as an _interface_ (kind of
like a really big command line)... but more on that later.
--JW (the other Josh)
Leland
field for support materials, or some kind of attachment capability. How
would this be accomplished in a way that is still browseable and
user-editable, with a low data-entry threshold?
-- plain text of some sort seems to be consensus... what would such a
format look like? Robust enough to store enough data to be useful,
human-scannable and brief enough to permit ad-hoc data entry? How? This
is determined in part by how much and what kinds of data we are to
store. I think XML is definitely not the way to go here... though if
the library/interface included a text-dump -> xml/whatever parser, the
data structures could be more complex."
I absolutely love Emacs Wiki for exactly the above reasons. I'm not an
emacs geek, I've written one line of elisp in my life, and I' NOT
advocating everyone drop what he/she is using for emacs.
However, Emacs Wiki rocks. There's something cool going on there where
entries are stored as plain text, so you can edit them in any text
editor (including emacs), but some magic elf with a lisp is sitting
there and makes any WikiWord you type into a link to that page. Data
entry is easy--just edit a text file. New page is easy--just edit a
text file.
I have no idea how that works, but it sounds to me like it's basically
what we want this app to do. Anyone got some good ideas?
Meanwhile, we should totally get this somewhere less linear than google
groups. Which of the 15+ servers represented in this discussion has
space for us?
sven
see http://www.emacswiki.org/cgi-bin/wiki/PlannerMode
It builds ontop of EmacsWiki and provides a Planning framework that can
fit Planning style between GTD and Franklin Covey.
It integrates (via optional modules) links to most big emacs-apps,
which is a plus if you live in emacs, but can be ignored if you dont.
Jim Tittsler
> --The slowness of the wiki create/edit process, exactly as you
> described it, was what drove me back to textfiles. Using PHPwiki and a
> bit of plugin code, I got it down to two steps, but I still want
> editing and viewing to be zero to one clicks away from each other.
that can export in a variety of ways (including to a web wiki).
<http://www.flyingmeat.com/voodoopad.html>
Adam Rice
playing with pointing bloxsom (a lightweight blogging tool which
'stores' blog entries as text files) at my folder of notes. What you
get from that is simply a weblog view of your note files, ordered by
date created, which can be interesting and even useful if your remote
needs are limited to information retrieval. I think that if your notes
are abundant and organized into categories (contexts? projects?) by
folder, bloxsom can do something smart with that. Among the many
extensions to bloxsom there may be something worth pursuing -- there
may even be some wiki integration going on.
http://www.blosxom.com/
Adam
Benjaloo
-at a minimum:
NA (free text with tags including contexts?)
Project (free text--with tags)
some people like to use dated to-dos, which of course isn't GTD
but we might want to include that capacity
Agendas for people we frequently meet with
?tickler items with dates to resurface?
"waiting for" items with names of who we're waiting?
links could be helpful for linking NAs to projects
Hard landscape (calendar) and contacts may or may not be necessary to
include in this system--everyone needs a calendar and contacts manager
but not sure there's any need to integrate those, as there are many
other tools for those pieces.
links between calendar items, contacts, and NAs or WF items might be
helpful too, but probably not worth the complexity they'd impart
Would we want one big GTD file, or separate files for the different
functions, or a separate file/record for each item?
Jeffrey C. Long
in the notes section. Then under "configure" at the bottom, you select
"display notes as text"
let me know if i can be of further help.
new additions to the website include a free concert by Yonder Mountain
String Band, some new books in my current reading list and some
articles on what it means to be a culture craftsman. enjoy!
http://www.jeffreyclong.com
terceiro
a computer (for our stated goals), the only trouble is that I've never
fully mastered emacs-fu, and so there's a mental studder in the process
every time. Of course, emacs mastery would solve this problem, but I
simply don't have the time to add "master emacs" on my projects list.
One of the foundational priciples of GTD (as written by Allen) is that
you already have the skills to use the system. New processes, yes, but
not skills. Or, perhaps more accurately, existing processes made more
deliberate and formal.
But I'm afraid that I am looking for a solution that doesn't exist. I
want something that requires no new skills, but provides perfect
structure in a way that's immediately and automatically habitual. Ain't
gonna happen, I suppose. Alas.
terceiro
retrieval is even more so, in my book. I simply can't stand to have my
mental processes limited by network latency. I lose things. If it's not
local, I won't (can't) use it successfully.
I think the plain text file consus is correct. That makes it cross
platform, secure (not in terms of privacy, but in terms of application
failure), and fast. And we started out saying we wanted del.icio.us
style tags. So, we've got:
* text files
* tags
* easy in, easy out data manipulation
* Standard GTD functionality.
And, as far as I'm concerned, nothing else.
<disorganized rant>
And I'm not sure I buy the extensibility argument. Yes, "as simple as
it should be, but no simpler" is true, which, in my book, is analogous
to K.I.S.S. In my previous life as a product manager for monstrously
complex software (shudder), I would fight, and fight, and fight, and
fight with my engineers to stop adding damn features. Perform one task
as elegantly and gracefully as possible, *then* move on to others.
There's the argument that short-sighted thinking will box yourself in.
Yes. So what? In terms of a piece of software, I think it's best to
plan out to a logical endpoint (maybe it's two releases out), and then
no further. Don't build in hooks for any future possibility, because
that will distract you from what you're actually building. It's not a
framework; it's an application! Make it *do* what it should, not what
it maybe-someday-could.
My case is proven by Microsoft Office. Sure, you theoretically could
live in Office for almost everything you do, except maybe some code
development. But even some of that could be done in Office. But no one
does (except maybe accountants, but they don't really count, do they?).
Why not? Because it's unpleasant. It does too many things poorly, and
too few things well.
My case is disproven by emacs, which does many things very well, and is
extensible. I even like how it looks and feels. But I have never,
despite years of informal trying, been able to master emacs and become
unconsciously proficient. Which means it also doesn't work for me. But
that it does for some (many?) people means that, in some cases, you can
be successful building an application that does everything. And perhaps
even more than that.
</disorganized rant>
I know, this is too long and you all skipped the middle section except
for the bullet points (which you didn't pay attention to because they
had not context without the text above) and this last paragraph. I'm
blaming this sucky linear forum.
--JW (not a Josh, alas, but them's my initials. Does that mean I can
join the party?)
terceiro
> that can export in a variety of ways (including to a web wiki).
> <http://www.flyingmeat.com/voodoopad.html>
Sorry, one more reply. Then I'll shut up for a while. Promise.
VoodooPad is indeed very, very close to what we're talking about. I
registered because I think it's a great product and I want the
developer to thrive. However, it is not the solution we're talking
about here. Since it's not text files, it can't be
Quicksilver-appended, which is an enormous black-mark against it for
many people (including myself), and proprietary data storage makes it
dubious. Yes, it can be exported in many formats, but that's not the
crux of the issue for me, at least.
Still, it is an excellent product.
TheAlbinoBowler
Quicksilver for some similar functionality...
* VoodooPad - you can use the Services plugin in Quicksilver to type
some stuff in text entry mode then get access to the "Make new
VoodooPad Page" service. However, this isn't appending text to an entry
it makes a whole new page/document. However, appending COULD be done by
making an applescript to take Quicksilver entered text and append it to
your Inbox (or any named page). I haven't been able to get it to work
yet, but it should be possible as the Applescript functionality is
there.
* Hog Bay Notebook - HBNBK provides a similar service, and adds one for
rich text entry This is similar to VoodooPad, though, in that it just
adds a new element to the top structure of the notebooks outline.
However, with the help of the author on the message board, I was able
to successfully get an Applescript working that I call up in
Quicksilver that automatically puts me into text entry mode, and enters
whatever I type in as a new item in the Inbox folder of my notebook.
Works fast. HBNBK also provides a contextual menu item from the dock
icon to paste the contents of the clipboard to any folder within the
notebook. Also, it features WikiWord linking support and great search
features, as well as putting it all within outlinable outlines. Great
program. Also, the author uses it for GTD himself, so he's open to
suggestions for making it even better for that purpose.
* MacJournal - this one surprised me. I just downloaded the recent
alpha build of 2.7 and it supports Wiki linking, notebooks within
notebooks (similar to Hog Bay where you can nest outlines) list
creation in the editing area, as well as a cool service item that let's
you append text into any entry by bringing up a window listing your
entries and letting you choose the one you want it to go into from the
keyboard. Since it's a service, you can type text into Quicksilver,
tab, select the MacJournal append toext to selection service, choose
the entry it goes in, hit enter and you're done. And MacJournal is free.
JoshWand
my model is closer to something like gmail, del.icio.us, firefox, or
even, dare I say, quicksilver?-- all the cool user-contributed hacks
that make the core app so much richer. None of us wants to end up like
office, nor, I think, do we have the resources or the institutional
myopia to screw it up that badly!
I don't think we need a giant API and a scripting host and the kitchen
sink-- just the headroom to add more fields, and a few hooks so that
addons are possible.
re: where to go next: yahoogroups? basecamp? sourceforge? a wiki
somewhere?
Leland
- text files for everything
- category tags for tasks
Proposed functionality:
- wiki-like project pages (still raw text)
- project tag for each task
- aggregator page that shows all of the very next actions for each
project, with filter-by-tag ability (still raw text)
Note that you *must* be able to edit any text from anywhere you can
view it.
Merlin Mann
application menu or, more often for me, via Quicksilver, this has
become my favorite way to move and munge information.
Have to say, if Entourage would 1) unlock data; 2) make everything txt;
3) make it ease to append data via Services, I'd be a happy man. I
guess all three go into the "And if a frog had wings..." department.
;-)
Great thread, by the way, everybody. I've been thinking about a
notional app that does lots of these things for a while now, so this is
esp. interesting to me.
Leland Johnson
--property vpdoc : "Macintosh HD:Users:leland:Documents:GTD.vdoc"
property documentName : "GTD"
property pagetoappend : "inbox"
using terms from application "Quicksilver"
on process text theString
--tell application "VoodooPad" to open vpdoc
tell application "VoodooPad"
try
append text "\n" & theString to page pagetoappend of document
documentName
on error
set failed to true
end try
end tell
if (failed) then
display dialog "File needs to be open - sorry"
end if
end process text
end using terms from
Copy that to a script editor and save it as ~/Library/Application
Support/Quicksilver/Actions/vpin.scpt or something similar. Make sure
to changedocumentName and pagetoappend to your configuration.
It could easily be changed so the first word is the page name, or
"docname pagename", but that's too complicated for most qs folks I
think, including me.
Most of the script is just dealing with the fact that Quicksilver
doesn't seem to like scripts that open stuff. I might get around to
asking them about that.
TylerWeir
he could very well add this feature to VP.
JoshWand
have all their tools (mailing lists, forums, bug tracking, cvs, etc).
When it goes up I'll post the address.
Josh
Merlin:
I've been working on the design for a notional app that does a lot of
these things for a while, also. :) I suspect a lot of us have been
wishing for pretty much the same thing, although expressing the
requirements is difficult, because it's like trying to describe
something in your eye's blind spot.
I suspect that what many of us want is a local way to link atomic
chunks of text (and URI's) together in a tag-based system. Just as
Google Desktop and Spotlight are "google for the files," this would be
"del.icio.us for our text."
Spotlight and the Smart Folders in Tiger's Finder *almost* does this,
but it's for finding your files. Not for being able to read the
contents of seventeen related text files and emails in one page like
you can the links and descriptions at
http://del.icio.us/jazzmasterson/gtd
Or am I wrong? :)
Cheers,
Josh
Josh
cross-platform use is still a pain... :)
JoshWand:
Nifty. I'll watch for the sourceforge page.
Josh
> also be beyond our scope unless we start talking attachments, and
then
> we're not dealing with textfiles anymore...
What if we were using a local, del.icio.us-style database to both sort
and show text files (and if it could interpret the markdown in
textfiles, that would be supersweet!) and other files? That way, you
get automagic not-quite-"cross-linking" between your
"&database_app"-tagged textfiles, omnioutliner documents, and the .gifs
of screen mockups.
If clicking on the "edit" for a textfile opened your text editor and
let you work directly on it, that's as low-friction as I can think of.
Just talking off the top of my head.
Gus Mueller
The main differences are:
It'll open up the document if it isn't already (using the shell
command- I don't know why open isn't working)
I'm using "prepend" instead of append, since I like new items to show
up at the top of a page.
If you prepend the quicksilver text with a ':', it'll look for a
specific page to prepend to. For example typing "this is some sample
text" would prepend it to the inbox page (this would be the normal
way). Typing ":index this goes on the index page" would append "this
goes on the index page" to the index page.
I'm not exactly an AppleScript ninja, so there are probably better ways
to do this stuff:
property documentPath :
"/Volumes/srv/Users/gus/Documents/augiestuff.vdoc"
property defaultPageName : "inbox"
using terms from application "Quicksilver"
on process text theString
try
tell application "VoodooPad"
do shell script "/usr/bin/open " & documentPath
set pageName to defaultPageName
if theString starts with ":" then
set pageName to the first word of theString
set z to ""
-- there has to be an easier way to do this.
repeat with i from 2 to number of words in theString
set z to z & word i of theString & " "
end repeat
set theString to z
end if
prepend text theString & return to page pageName of document 1
end tell
on error errorMessage
display dialog errorMessage
end try
Josh
You *rule*. :)
Thanks.
Leland Johnson
Leland
chunks of text (and URI's) together in a tag-based system. Just as
Google Desktop and Spotlight are "google for the files," this would be
"del.icio.us for our text."
Most definitely. How about something like this:
You have one text file of next actions. Each action is tagged with
multiple categories, including the project it's assigned to.
You have one text file for each project with support materials. Some of
it is just notes that the app merely passes on to the user. Some of it
is a list of next actions, which the app filters in search of the very
next action to be performed. Some of it is a list of supporting
(probably just text?) files locating on the hard drive, which the app
looks at and plugs into the project page with some trickery
(javascript? don't know) to present them in a folded up manner (similar
to how messages in gmail threads are collapsed).
---
Thoughts on editing:
As far as next actions are concerned, I'd really just want to be able
to add a task/project really easily. I wouldn't mind a little friction
in editing the tasks, but I absolutely must be able to add a task the
instant it occurs to me, or I won't ever use the app. This is similar
to del.icio.us.
Creating a new project happens in either of two places: explicitly
create a new project, or just use a tag for a next action to assign the
action to a nonexistant project, which you then create.
Leland
about it coming out looking like my own thoughts, I'm not pirating
other people's writing here. Gotta give credit where it's due.
Josh
TheAlbinoBowler
combined with the strike and move to bottom plugin this is really neat
(and tempting)
Josh
That sounds interesting, although I have many many implementation
questions... no time to ask them just right now, though.
I asked the question I did for a good reason: I've been working on a
design that leverages something very much like what you described... it
isn't designed exactly for GTD, but GTD's contexts and cross-links have
strongly informed it. (Didn't want to make it a GTD-only system.)
Yesterday, just finished the first rough draft of a presentation
outline, but that isn't ready *quite* yet: working on the revisions
today. When my critics deem it "ready," shall I post the link here?
car...@gmail.com
> sounds like fun.
>
> it gives me great temptation to put my todo lists on the web in
> Socialtext wiki pages and tag them with delicious as is. (or take
> pictures of my todo lists and tag with Flickr). the objective of
both
> is to get some broader audience aware of what I'm up to.
This is an awesome thread and you guys are really on to something. I
thought you'd all like to know about something new coming from The
Robot Co-op [http://robotcoop.com/]. The first piece is called
"Twinkler" [http://twinkler.43things.com]. It's meant to be a fun way
to play with your to-do's. It's just a teaser for the real deal, "43
Things" (sound familiar?) There's a beta of "43 Things" going on right
now. Anyone can sign up to be invited to the beta. I'm using it now. In
a nutshell, it's a web service for keeping track of your to-do's
(goals). It utilizes a tagging system similar to Flickr and
del.icio.us. It also allows for collaboration among individuals and
provides a system for exposing your to-do's. So far, I really like it.
Check it out and sign up for the beta: http://hugster.43things.com
Josh
Sadly, the FAQ and terms of service and things are also behind the
authentication barrier. Can you tell us if this service is going to
cost, or is that covered by an NDA?
Carrick
Do I have to pay?
Not today and not in the near future. We think it is important that
people who get value out of a community find ways to support that
community - but we are commited to finding clever ways to make this
happen. Have an idea for supporting 43things.com? Drop us a line:
id...@robotcoop.com
Leland
spitting out features that would make me want to use the app.
Everyone: Has anyone looked at pyGTD (http://96db.com/pyGTD/)? It looks
like it has much of the functionality we're talking about here. Any new
insights?
-The Other Leland
Leland
Josh
> Josh: I have no freakin' idea how to implement any of that. I was
just
> spitting out features that would make me want to use the app.
Oh. D'oh. Sorry. :) I'm dense sometimes.
I have some ideas on how it could work, but they're really vague and
hand-wavey. I'm busily sketching out diagrams (well, I will be... do
have to actually do _some_ work during the day ;)) but I ran into a
problem that I suspect is common: I'm passingly familiar with entity
extraction and entity diagrams for RDBSes, but tags make for all sorts
of crazy ad-hoc crosslinking.
Anybody seen a good visual representation of this stuff?
> Everyone: Has anyone looked at pyGTD (http://96db.com/pyGTD/)? It
looks
> like it has much of the functionality we're talking about here. Any
new
> insights?
I looked at it... to be honest, I'm uncertain how to implement or try
it within TextMate. Anyone with better scripting-fu than I want to give
it a try and report in? :)
Cheers,
Josh
Mitchell Surface
>
> pyGTD link fixed: http://96db.com/pyGTD/
> sorry 'bout that.
>
--
Mitchell
Donald Nordeng
I couldn't resist responding to this.
On Dec 14, 2004, at 2:03 AM, terceiro wrote:
>
> I agree that planner.el is about as close to perfect as you can get on
> a computer (for our stated goals), the only trouble is that I've never
> fully mastered emacs-fu, and so there's a mental studder in the process
> every time. Of course, emacs mastery would solve this problem, but I
> simply don't have the time to add "master emacs" on my projects list.
Indeed.
>
> One of the foundational priciples of GTD (as written by Allen) is that
> you already have the skills to use the system. New processes, yes, but
> not skills. Or, perhaps more accurately, existing processes made more
> deliberate and formal.
Skills. I have been implementing GTD since 1996. Every new year
brings me closer and closer to full implementation, weekly reviews,
perfectly defined project list with next actions. Again, I look
forward to 2005 with hope. But skills you say, maybe this is the
Achilles heel I have been wobbling on.
>
> But I'm afraid that I am looking for a solution that doesn't exist. I
> want something that requires no new skills, but provides perfect
> structure in a way that's immediately and automatically habitual. Ain't
> gonna happen, I suppose. Alas.
>
Yes, such is the elusive search. My wants start where yours leave off
and include software that tells me what the project is, suggests a next
action, and opens a draft email message with suggested text.
Leland
> Leland wrote:
> > Josh: I have no freakin' idea how to implement any of that. I was
> just
> > spitting out features that would make me want to use the app.
>
> Oh. D'oh. Sorry. :) I'm dense sometimes.
>
> I have some ideas on how it could work, but they're really vague and
> hand-wavey. I'm busily sketching out diagrams (well, I will be... do
> have to actually do _some_ work during the day ;)) but I ran into a
> problem that I suspect is common: I'm passingly familiar with entity
> extraction and entity diagrams for RDBSes, but tags make for all
sorts
> of crazy ad-hoc crosslinking.
Um... Gazheudheit? I have no idea what an RDBS is, but that's why I'm
here. I'd like to get this to happen, if for no reason other that just
to learn as much as I can about something new. Please bear with my
complete lack of hacking experience... call me a work-study or
something.
JoshWand
oracle, etc).
I wonder if there are any clues buried in the del.icio.us-discuss
mailing list as to how josh (yes, yet another josh) handles it.
My guess is just a longtext field, indexed, and a (please excuse my
bastard sql, i'm sure there's a proper operator for this) SELET * FROM
rows WHERE rows.tags CONTAINS 'foo'
That said, whether or not we want to use an rdbms here is a question
worth discussing-- i thought we were still in textfile-land....
--Josh Wand
JoshWand
(google it)
Arthur A. Vanderbilt
I'm making an interpreter for my text files. My todo.txt specifically. It's not incredibly useful in the short term, but as the file grows, its usefulness grows as well. It interprets Markdown and then considers the specific structure of the file. It allows you to choose an outline level (for me, usually ## or ###) for categories. Then it looks for bullet list items, which it knows are tasks, and stuff in []'s at the beginning of the line, which it understands as one of two things: priority or "done" if it's [X] or [x]. Right now it filters out the stuff that's done. Eventually, I'd like to make it move stuff that's done to another file and move dated stuff to iCal. I'm also thinking about a system for tags. What I'll probably do is just put them at the end of each entry as {tag 1, tag 2} etc. It doesn't let you edit anything. It's an intelligent viewer for what I am editing. Text files are perfect for entry and storage, but looking through them can be a pain when they get big. I'll add functionality to open the text file to just the right line when you double-click or something.
Right now it's implemented in REALbasic. When I get it just right, it'll become a cocoa app. REALbasic is great for prototyping stuff. What you see here was written in an afternoon.
Arthur A. Vanderbilt
another (linking) table that links the two, with tag id and task id.
When you get a tag on the ui, see if it exists, if it doesn't add it
(spell checking would be nice here) and link. If it does, just link.
This is a pretty normal many-to-many relationship.
Am I wrong?
Josh
Arthur A. Vanderbilt wrote:
> It's not bad. You have a tags table and a tasks table, then you have
> another (linking) table that links the two, with tag id and task id.
> When you get a tag on the ui, see if it exists, if it doesn't add it
> (spell checking would be nice here) and link. If it does, just link.
> This is a pretty normal many-to-many relationship.
Aha.
I was making it too complicated. :) Imagine that.
Thanks, Arthur.
Josh
> I wonder if there are any clues buried in the del.icio.us-discuss
> mailing list as to how josh (yes, yet another josh) handles it.
"Joshua." :)
I'm on the del-discuss list, and have only seen Joshua comment a couple
times that MySQL and like DB's are generally not designed for the
adaptive tagging that del.icio.us uses. But that doesn't necessarily
mean much... a google search later seems in order.
> That said, whether or not we want to use an rdbms here is a question
> worth discussing-- i thought we were still in textfile-land....
My intent was to sketch out a diagram, not to build a database itself;
just trying to outline, visually, how tags relate to data sources.
Stop me if I'm wrong, here: a tag-based system that points at data
saved in external files is going to need a kind of index. You can think
of the tags and that index like an RDBS, because you're creating a
bunch of links. (Groping partly in the dark, here...)
Two things that jump out after having said that:
1) OS 10.4 Tiger is going to have a wonderful index of its files,
complete with lots of juicy metadata. That's Spotlight.
2) Google Desktop Search and Microsoft's own internal search index do
very similar things, more or less (respectively). Supposedly, so will
Avalon (WinFS).
Being a mac person, I'm inclined to want to work with the former.
Spotlight and the Finder's "Smart Folders" will do a lot of what we
would want it to do, but in the end it will show you a bunch of icons
in a folder.
*donstechnofuturisthat*
*wavehands*
Imagine, for a moment, an app that works much like instiki, in that it
contains a small internal web-server. It sits on the shoulders of
Spotlight's giant, and takes text files and HTML and displays their
content in a format not unlike a wiki. You can tag and retag those
files, like your bookmarks in del.icio.us (and the tags are saved as
metadata in Spotlight).
Basically, use the Spotlight engine to create a local del.icio.us.
Better:
Work out a service or quicksilver plugin that lets you select files in
the Finder and tag them, so they show up in the local D.I.U.
Best:
"Export to web/thumbdrive" would crunch all of this and turn it into
something like a wiki on either your USB thumb drive, or a web server
you run, so when you go off to work on that PC at work, you got it with
you. (Synching the changes back might be a bitch, I dunno... anyone?)
Right, so tell me I'm crazy. I'm gonna sit over here and hum "Imagine."
:)
Cheers,
Josh
Josh
> Um... Gazheudheit? I have no idea what an RDBS is, but that's why I'm
> here. I'd like to get this to happen, if for no reason other that
just
> to learn as much as I can about something new. Please bear with my
> complete lack of hacking experience... call me a work-study or
> something.
I'm sorry. :) Very little to no actual hacking experience here,
either... just a fairly diverse education and an unfortunate amount of
exposure to FileMaker Pro.
And about six forests' worth of sketches on this living on index cards.
I'm so not joking. There's going to be a scanner party one of these
days soon.
Leland
applauded. However, I'd argue that this is a slightly special case. As
unbelievably beautiful as OS X is, I think we should stay away from
building an app that relies on something Mac specific. Let's not block
out the Microsoft zombies (i.e.: my mom) and the Linux geeks (i.e.:
me). Oh, and those few Microsoft power-users should probably be invited
as well.
... Alaska can come too.
Josh
True.
It was an idea for a way to keep from having to create an automatic
indexing system, which is ...difficult. To say the very least. Witness
all the work that had to go in to building DEVONthink, Spotlight,
Google Desktop Search, et al.
Probably you're right. It sounded nice, though.
On a related note, here is something that got me excited:
http://www.instiki.org/show/ExportAsFileSystem
Turning an instiki wiki into a mountablle file system so the pages can
be edited in $texteditor, rather than a browser?
File uploads?
*quiver*
I like instiki because a) it's dead simple to install, b)
self-contained, and c) interprets Markdown natively. There are issues
that make it not something you'd want to use as the professional
front-page wiki for your system: TextMate's wiki just switched over to
Twiki. But as a local wiki? Very nice.
So, instead of a local del.icio.us that bookmarks your files within
Spotlight, how about one that lives on top of your $wiki ...and if the
wiki mounts like a filesystem and lets you basically edit a bunch of
markdown textfiles, that sounds like something we could adapt for GTD
in a heartbeat.
I still like the spotlight bookmark idea, but that's probably a whole
'nother thing. :)
Cheers,
Josh
blovett
(http://www.blosxom.com/). It's a blogging tool rather than a wiki,
but:
- it uses text files
- not only can you manage your files with the filesystem, you're expected to.
- it can be extended with plugins.
So you might have a blosxom plugin which allowed you to tag your files
in a delicious sort of way, and run searches based on them. Or you
might just rely on putting things in different folders. Blosxom would
display your folderhierarchy appropriately when you viewed it in a
browser.
Folders become categories or list containers. Files become to-do items
or next actions or project notes or whatever.
Multi user too, if you wanted. You could export your blosxom directory
via webdav.
-bill
kne...@gmail.com
difference in what people are looking for. I think that there are other
people who are looking to tag individual items within a file, which
will require something very different than tagging individual files.
I am trying to imagine an implementation of the really good ideas that
I've seen on this list, but it seems that everyone had a different idea
of what their ideal tool would even look like. It seems that most
people want something that uses plain text files, and it sounds like
Mr. Vanderbilt's idea addresses this, but in a way that is
platform-specific. I do think that his file format is something that I
could work with.
Should we try to agree on a common file format, or is this something
that is so highly personalized that everyone is going to have to roll
their own implementation?
JoshWand
major platform-- I travel a lot for work, and I'm usually working on
other people's computers (sometimes with connectivity, sometimes
without). I really want something I can stick on a thumbdrive and still
have it work, on a PC, or a Mac. FWIW, I am one of those PC power users
(owing to limited funds and a penchant for gaming).
b) spotlight--- sounds like overkill? we don't need to search the
entire filesystem for tags, etc.. just, presumably, a few tens of
textfiles-- something doable on-demand on a relatively fast machine,
or, a small index file (indexing is not rocket science-- it's just
making it fast and scalable that is). Scope, people, SCOPE.
This weekend my work crunch will be over, and I'll try and put some
time into sketching out an architecture...
--JoshWand
JoshWand
items might be a link to a file, or have an attached file, and i'd tag
that, too, but I want a bunch of todos in one file, each tagged
appropriately. Again, I promise more explication and concrete ideas
soon.
Josh
> I am trying to imagine an implementation of the really good ideas
that
> I've seen on this list, but it seems that everyone had a different
idea
> of what their ideal tool would even look like. It seems that most
> people want something that uses plain text files, and it sounds like
> Mr. Vanderbilt's idea addresses this, but in a way that is
> platform-specific. I do think that his file format is something that
I
> could work with.
Sorry, this is partly my fault; it's just instinct, when starting in on
something, to ideate as many variations as possible, just to keep from
latching on to the first idea and falling in love with it. Of course,
at the end of that, you get a few dozen terrible ideas, but maybe a few
good ones, too. :)
> Should we try to agree on a common file format, or is this something
> that is so highly personalized that everyone is going to have to roll
> their own implementation?
Perhaps we should go through the thread and collect the different ideas
and summarize them, so we can decide what is workable and worth
pursuing?
Josh
JoshWand wrote:
> a) a really big point of this for me is to be able to use it on any
Yeah, agreed. See previous post re crazily ideating.
> b) spotlight--- sounds like overkill? we don't need to search the
> entire filesystem for tags, etc.. just, presumably, a few tens of
> textfiles-- something doable on-demand on a relatively fast machine,
> or, a small index file (indexing is not rocket science-- it's just
> making it fast and scalable that is). Scope, people, SCOPE.
<:)
*wavewhiteflag*
> This weekend my work crunch will be over, and I'll try and put some
> time into sketching out an architecture...
Did you get a reply on the sourceforge thing, btw?
Cheers,
Josh
Josh
> You might get some more ideas by looking at blosxom
> (http://www.blosxom.com/). It's a blogging tool rather than a wiki,
> but:
>
> - it uses text files
> - not only can you manage your files with the filesystem, you're
expected to.
> - it can be extended with plugins.
>
> So you might have a blosxom plugin which allowed you to tag your
files
> in a delicious sort of way, and run searches based on them.
I like this. A lot.
Hybernaut http://del.icio.us/hybernaut/ has written a blosxom plug-in
that takes a post, looks at your del.icio.us bookmarks, and puts links
with related tags in the sidebar. And I believe there's a way to use
tags with blosxom, as well.
> Or you
> might just rely on putting things in different folders. Blosxom would
> display your folderhierarchy appropriately when you viewed it in a
> browser.
> Folders become categories or list containers. Files become to-do
items
> or next actions or project notes or whatever.
This is ok... the only problem with folders is the
one-file-can-only-be-in-one-folder problem with hierarchies.
> Multi user too, if you wanted. You could export your blosxom
directory
> via webdav.
This sounds very cool. I agree...
blovett
> > Folders become categories or list containers. Files become to-do
> > items or next actions or project notes or whatever.
>
> This is ok... the only problem with folders is the
> one-file-can-only-be-in-one-folder problem with hierarchies.
pan out in the context of Blosxom. One is to use symbolic links
(presuming a Unix-based environment) but there are some management
issues with that (deleting links when deleting a file, for instance).
Or you could have virtual folders-- something like Gmail labels. If
you had a hypothetical blosxom plugin for tagging, you might extend it
from the application to the filesystem level so that your tags
appeared as folders of symlinks.
Ken Scott
>
> > Folders become categories or list containers. Files become to-do
> items
> > or next actions or project notes or whatever.
>
> This is ok... the only problem with folders is the
> one-file-can-only-be-in-one-folder problem with hierarchies.
>
OS X and Linux, the link looks just like the file is right there; the
link opens the original item for editing, etc. Windows uses shortcuts
which are sorta-but-not-quite the same concept.
I guess if you have something automatically crawling the files and
gathering NAs, you'd have to take care to not create identical NAs,
coming from the links in several places.
Ken
--
<>< Ken Scott opt...@gmail.com http://www.optikos.net/~ken
This is the day that the Lord has made;
I will rejoice and be glad in it! -- Psalm 118:24
blovett
> b) spotlight--- sounds like overkill? we don't need to search the
> entire filesystem for tags, etc.. just, presumably, a few tens of
> textfiles-- something doable on-demand on a relatively fast machine,
> or, a small index file (indexing is not rocket science-- it's just
> making it fast and scalable that is). Scope, people, SCOPE.
tag could be treated as a pointer to a set of files. Or it could be a
pointer plus a member of a hierarchy-- show me fles that match tag X
that are children of tag Y. I think the complexity has more to do
with how you utilize the index than it does with creating it.
But stepping back, this on-demand indexing business would presumably
require an external program to create the index in the first place.
Perl, for argument's sake. No dice there if you put your thumbdrive
into the average windows machine. So to get around that you'd need
executables on the thumbdrive itself, one for each platform. The
advantage of using spotlight or an equivalent product is that it's
already there, built into the OS with nothing better to do.
Text files will be completely cross platform. USB access will probably
be completely cross platform. But above that, not so much.
Josh
> But stepping back, this on-demand indexing business would presumably
> require an external program to create the index in the first place.
> Perl, for argument's sake. No dice there if you put your thumbdrive
> into the average windows machine. So to get around that you'd need
> executables on the thumbdrive itself, one for each platform. The
> advantage of using spotlight or an equivalent product is that it's
> already there, built into the OS with nothing better to do.
For the record, that is indeed what I was getting at; hooking into
whatever index exists on whatever machine type you use.
> Text files will be completely cross platform. USB access will
probably
> be completely cross platform. But above that, not so much.
I suppose a good question is whether we want something that would work
on *any* machine in the world regardless of platform or whether you
have control of what programs will run on it, or if you would want
something that would work on any computer so long as you can install a
client application on it (or an engine such as Ruby or Perl).
The latter is easier than the former, but the former is more useful for
those who travel without a laptop but want access at a cybercafe or an
equivalent.
Josh
> On Fri, 17 Dec 2004 06:27:40 -0800, Josh <jdim...@gmail.com> wrote:
> > > Folders become categories or list containers. Files become to-do
> > > items or next actions or project notes or whatever.
> >
> > This is ok... the only problem with folders is the
> > one-file-can-only-be-in-one-folder problem with hierarchies.
> There are ways around that, although I'm not quite sure how they
would
> pan out in the context of Blosxom.
It's difficult to talk about it without having tried it, I guess. I'm
pretty sure there are tag plug-ins for blosxom, so that would prevent
hierarchical lock-in on the web interface. If so, then as you say, it
may solve itself.
I guess the next action is to check to see if blosxom will run locally
on OS X.
Leland Johnson
plugins.
There is a tag plugin. Version 3 is much better at it, but is also
alpha or something.
Wiki here: http://wiki.oreillynet.com/blosxom/
JoshWand
days. I expect to hear next week, when, naturally, I will be out of
town.
Michael Grant
> -- File linking across contexts would indeed be a killer app, but may
> also be beyond our scope unless we start talking attachments, and then
> we're not dealing with textfiles anymore...
File:// URIs are pretty easy to use as long as you're just talking
about files on the local system. Here's a simple AppleScript I wrote to
go grab a file and put its URI in the clipboard:
set frontApp to the name of (info for (path to frontmost application))
tell application "System Events"
set aFile to (choose file with prompt "Choose a file to link:")
set fu to URL of aFile
set the clipboard to fu
end tell
tell application frontApp
activate
display dialog "The file URI is on the clipboard." buttons {"OK"}
default button 1
end tell
Michael
--
<http://globalocal.blogspot.com/>
The government doesn't want you to know... e-mail doesn't work. At all.
It's a scientific impossibility.
Josh
I'm experimenting with basecamp right now... it seems a rather good
project management system for creative project.
JoshWand
without file storage). CVS and bug tracking are indispensable for doing
any coding.
Josh
I kind of figured. :) Likewise, sourceforge isn't much good for
ideation sketches. However, the projects + to-dos structure seems
adaptable to the GTD method, which is nice.
Jack Mottram
http://www.feedroll.com/rssviewer/
Easy to set up, easy to tweak the look of it with CSS (as an example
- the 'Related' section of my, um, dormant weblog about a coffee
table: http://www.submitresponse.co.uk/drift/ )
Jack