Permaculture Database

[christophe mckeon gonzalez de leon <chromatophore@gmail.com>]

hi,

just some more thoughts, lets keep the dialogue going.
i think some ideas are starting to take shape.

>  I wanted a system that would facilitate sharing those suggestions.
>  So apart from the nerdy stuff (authentication and privacy etc)

on that subject. i was thinking if we quickly coded up a
proof of concept system a lot of that kind of stuff could be
left out on the first iteration.

i do think that as much as possible should be kept public, at least
by default, and that keeping things public and open should be
encouraged. maybe there could be both public and private parts
of a project? the more open the more useful.

> it would need to handle projects, each of which would include a place
>  to dump images (a JS etch-a-sketch wasn't important),

agreed, images important, js etch-a-scetch overkill. people will
be using more capable non browser based software or paper.
it might be nice to be able to make comment boxes on images
a la flickr though.

> a forum slash mailing list to manage the discussions about same,

this could tie in with my idea of a diary for a site design (which you are
calling a project). maybe diary isn't the right name for it, anyway,
just to recap:

after the site design is finished there would be a handy diary which already
knew quite a bit about the design so that the user could easily fill in
relevant info, like how some pattern or guild is holding up. the relevant 
fields
would be there ready and waiting possibly with a view onto the
previous user entry
for that pattern for example. the diary entries could just be like
posts in a forum
where users involved in the design get to post full entries, and users not
involved but with permission to post, just get to do so with
regular comments, not fancy detailed entries with pattern info etc.
that way more experienced mentors can give input in the same forum.

the same diary idea could be extended to also be used as the project
is being designed as well, i think fulfilling the role that you describe. that
way there is only one UI to learn on the part of the user. would there be
some kind of transition though where it behaves slightly differently
before/after
the design is 'completed' and is being implemented? my gut would say that if
the UI were exactly the same before and after would be best, to reduce
complexity
for us and users, and because maybe the assumption of the 'completed design'
might be flawed to begin with.

(i'm still using ~ to denote a potential model/entity)

in that case we have to think of the design as continuously evolving and
things starting to be implemented at different times, and also removed.
maybe a ~feature is what is needed with start/end timestamps. patterns
used in the design could automatically have a ~feature created to handle
their temporal aspects. this would also allow multiple features
being created per pattern if it were being used multiple times. or maybe
everything in a design is a feature, and features can have patterns associated
with them?? that might go against the holistic nature of patterns
though, as patterns
cut accross 'features' so it's a hard one. maybe the design *is* a
tree of features,
that might be a good way of handling all of scale, physical encapsulation, and
time via the timestamps? patterns are then associated with nodes in the tree.
but now i'm starting to get cloudy on the UI.

features would also make the pre-population of diary fields possible. if
a feature had been marked as 'begun' by the user, then in the diary
entries, the relevant fields for reporting on progress of that feature and
associated patterns would show up, else not.

>  perhaps a manually aggregated summary page (wiki) purely for the 'customer'
>  to be able to see the distilled, net result of ideas presented
>  in one place, a way of tagging the project partly for future
>  reference (searching) but also to more easily categorise the
>  information about the project (aspect, scale, climate) that could
>  be summed up in v.short phrases or just single words.

what is being aggregated, what kind of structure do you envisage
a project having from the user's point of view?

> Obviously  you'd need more descriptive stuff to describe soil types,

how to deal with microclimates, and variation in soil types on one site?
maybe a tree of ~sites, which inherit properties from parents, so
if a user wants to indicate a little subsite differing only in pH, all
other properties are inherited from the supersite. how would this
idea be related to the tree of features? is this all getting
overdesigned/overspecified?

>  the requirements of the owner insofar as plant / fruit preferences,
>  amount of disruption they'd be happy with, what they wanted to
>  keep in the existing landscape, amount of time they'd have to
>  do maintenance, etc.  Some of that stuff (maintenance effort)
>  might be quantifiable, but for the most part I was happy to have
>  the bulk of the descriptive data kept textual.  I didn't expect
>  there'd be ever such a volume of projects that it'd be impossible
>  to find one close to what you were working on at the time.

yeah all that stuff seems pretty hard to model. there could be
some predefined structure for the textual data though, so that
it wasn't all in the same place, and hence easier to search through
meaningfully.

cheers,
_c