Re: Some (usage) questions I used to wonder about

Ooooo, wide open questions ... I just *love* those!! :)

Try, to remember ... you *asked* for this!

--- In [email protected], Jeff Mitchell <skeezix@...> wrote:
>
> 
>   	Heres a couple (of many more) questionsw that've been floating 
> around in my head since pretty much day-one. (Really :)
> 
>   	- do you like having files, or do you care?

As a metaphor for grouping, yes.  Physically, not so much.

A hierarchical note system as a detailed extension of a hierarchical file system has a very seamless feel.  Being able to disassemble the hierarchy at will for transfer/exchange becomes part of the metaphor, not part of the forced physicality of the file system.

If you remember (way back when), we were clamoring for you to write us a mechanism to build (and even maintain) a "master" list.  This, had you implemented the full blown dynamic "master" list, would have given the Palm a hierarchical file system (with regards to Shadow).

Besides, why do you think file systems are hierarchical!  (For those too young to remember, "PC" file systems were one big list of files in the beginning).

So, for purely practical purposes, there is a strong argument to be made for storing the lists in a hierarchical file system that mirrors the metaphor internal to Shadow.  That way, you get some of the management of list structure available to you (the user) from *outside* Shadow.  Assuming, of course, Shadow is built to absorb external rearrangement of the hierarchy.

<snipped presumptions about my state of consciousness. ;) >
> 
>   	- do you like/prefer/dislike entering a filename (and optionally 
> some up front settings) for a list, or would ytouhave preferred 'instant 
> on' -- hit 'new list' and boom, you're in a default list and with an item 
> open for data entry?

To me a "filename" in Shadow is a subcategory of my well maintained Master list, and thus is not a "file" at all.  Except in the sense that the content under it is a (portable?) "unit of thought" for me.

So, with this presumption, I would expect, not a "default", but rather an inheritance from its parent.  Inheritance is a powerful thing (the "boom" you speak of).  However, being able to overload is also essential.

(Note: Currently, I keep a set of lists in a category as "templates" for my lists and simply copy the kind of list that I want)

So, maybe, the point of divergence from inheritance (overloading) *is* the "file" metaphor.  I guess it would depend on the extent and nature of the divergence, though.  And if that is the case, then it is always a thoughtful act.  (Maybe that's why "files" seem somewhat natural even to the uninitiated.)


>   	- do you tend to keep all items of one 'type' in a list, or would 
> you like to have a total mixed bag of any old thing in there?

<snipped some wonderful musings, and refer the reader to the original>

OK, now you've asked for it! :D

One 'type' of thing in a list, yes and no.  Mostly no, partly yes.

I construct 'type' sets, and even name them with the same prefix to be sure I use them consistently in constructing an outline.  Though there are some "universal" types, like "note".  Though even those I will 'sub-type' consciously, for example, to "annotation" ("post-it") or "body" (normal text of a document).

So, if it were easier, I would probably cast that 'note' type into one which matches one of my sets of types.  Its just too easy not to bother since the context of its use generally defines that for me. 

Take the (relatively) clear case of a project breakdown.  I usually divide things into "objectives", "milestones", and "tasks".  This is largely a subdivision by their independence.  Thus, in that sense, the list is "uniform", it represents only "division of labor".

But it is generally made up of five types of entries: Project (level 1), Objectives (2), Milestones (3), Tasks (4), Annotations (branches for all levels) ...  enough said?

Thus its pretty clear that, no, there is no way, given the dynamic attributes implied at each level of that (time sums, doneness, etc), that these could be considered the same 'type'.

A more direct answer to your question?

I would love an object oriented approach.  A collection combining fields, manual entry (requiring an entry form), and "methods".  The "methods", for the most part, would be functions over children which have a representation for display in the parent.  Those would require a "screen" presence, but no "entry" per se.

I could muse for hours about the potential for inheritance here, and its consequences (both good and bad) ...
... but I'll save you from that. ;)

>   	It would make searching and reporting more complex though, since 
> you'd have to cherry pick which fields you wanted and so on.
> 
>   	Always a trade off..

Ah, yes ... Oh, what a tangled web we weave ...

> 
>   	Anyway, curious what you think :)
> 
>   		jeff
> 
> --
> If everyone would put barbecue sauce on their food, there would be no war.
>