journal is hard + sugar and the digital age

[Garrett Goebel]

On Fri, Oct 10, 2008 at 1:53 AM, Albert Cahalan <acahalan at gmail.com> wrote:
> Edward Cherlin writes:
>> On Thu, Oct 9, 2008 at 7:15 AM, Carlos Nazareno <object404 at gmail.com> wrote:
>>>> Could you please elaborate on the difficulties that people have
>>>> when using the journal?
>>>
>>> I've experienced the same problem. Items tend to clutter up in the
>>> journal over time, it's like viewing your entire web browsing history.
>>> Its current implementation simply leads to information overload with
>>> the accumulating number of entries.
>>
>> How about the Gmail method, in which you archive messages when
>> you are done with them, but you can tag messages, set filters,
>> and search easily?
>
> tags: useless
> filters: useful only for automated deletion of incoming spam
> search: useful only for plain text

An alternate positive opinion:

tags++

I use them all the time. I like the idea of being able to apply
multiple tags of varying granularity. And sometimes it is useful to
"file things away" in more than one place. I.e. not just adding more
specific qualifiers... And I'd like give a cscott++ to his proposal
which would allow ordered sets. Because sometimes sets _are_ ordered.


filters++

I often use filters to automatically apply tags. Not just as a kill file...


archive++

I tend to tag what I want to remember, delete stuff I don't, and
archive everything which I don't need to keep immediately on hand.


Long vs short term memory

To me, unarchived = short-term memory and archived = long-term. If is
tagged, then I expect it will remain archived forever... It will be
easy to search and find. If it is archived but not tagged, I'd be
useful to me, if anything older than a month would be deleted. I.e.
Stuff is there long enough that I can trawl though and find it if I
really want to, but not so long as to create the proverbial needle in
a haystack.

cheers,

Garrett

P.S. Congrats on 8.2. Now if only I can find time to get off the bench
on the sidelines...


>
> Fortunately, the vast majority of my email is text.
> The journal is expected to handle lots of non-text data.
>
> The email comparison is a good one. Just like an inbox, there
> is an unrelenting torrent of spam that must be dealt with.
> The main difference is non-text data, which makes the "search"
> and "filters" ideas unworkable.
>
> What you're lacking can be summed up like this: "I put my data HERE,
> where I can expect to find it later." There is no "HERE" in the
> journal. Imagine storing 100% of your household goods in a giant
> concrete mixer that rotates whenever you look away. You'd never
> be able to find anything.
>
> Now imagine that your neighbors like to empty their trash into
> your concrete mixer. (spam problem) If you hadn't given up on
> finding your stuff already, you will now! It's easier to buy new
> stuff (start a fresh document) whenever you need it, and you might
> want to keep your most beloved possessions in your desk at work
> (copy them to a USB key). When the concrete mixer gets too full,
> you toss in a lit match (kids in Uruguay "rf -rf" the datastore)
> to keep the neighbors from complaining that they have no place to
> empty their trash.
>
> None of the recent suggestions, even if perfectly implemented,
> would fix these problems. That's not even considering the issue
> of compatibility with non-Sugar systems and user expectations.
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>