pcplantdb

["John Schinnerer" <john@eco-living.net>]

Aloha,

> 1.  neither of us know where each other are from!

Whattaya mean by 'from?', earthling?  ;-)
Born in Berkeley, CA; grew up next door in Albany, CA; a year in Sweden; some
winter seasons in Utah (2) and NW Montana (3); four years in Hawai'i; last
seven (!! :-p) in Seattle; moving my "home" base back to Hawai'i this winter.

> So how to approach this?  Perhaps we can decide together on an interface
> for creating this database (which I will briefly go into below)_and then
> split into groups on a regional/country basis, and BUILD.

I suggest we bear in mind the Permaculture principle of protracted and
thoughtful observation rather than protracted and thoughtless labor.

> (Of course,
> each region/country could use their own interface, but I think it would
> be more fruitful for cross-pollination purposes if they were
> consistent...)

If we keep good separation of data (content), logic and presentation in
developing this we can have it all these ways.  Otherwise not.

> The task forces could be separated into:
>
> -programmers
> -UI/HCI designers
> -people experienced with interactive education
> -people experienced with environmental education
> -expert Permies--obviously, seek the expertise of local Permaculturists
> and guild designers throughout the process

Let's not forget testing (it's the most consistently neglected aspect of most
software projects).  I volunteered to be chief test curmudgeon back when this
list got spun off - an offer which still stands.

> I appreciate Rich's
> template, but I Love the visual aspect of ThinkMap, and feel that the
> user experience would be much much richer with a tool like this one...I
> am willing to discuss this, but I almost have too much to say to go into
> here).

Again, if we practice good separation of data, logic and presentation you can
create a graph-based interface and others can use that or something else.

> 3.  and now for the actual interface.

It may help to start sorting out elements here.

> Basically, the guild-builder/plantdb serves to:

"serves to" is a clue that most of what you list below are functional
specifications.  They do not imply a specific presentation (UI) or a specific
data structure.  They are what we might want the system to *do*.

> -help people in designing guilds for their specific locale,
> circumstances, and preferences
> -allow practitioners to enter information, ask questions, find references
> (people, books, websites, etc.) relating to guild design--
...etc.

Some more examples - this is functional spec:
> -add

This is data spec:
> photos, contact info, and references

More functional specs:
> ...the program be able to
> suggest guilds.  ...The program would learn based on
> the information we provide it.

> p.s.  John S.-- when I suggested brainstorming the ultimate plant db- it
> wasn't so we could BUILD the ultimate one now- just an exercise in
> setting goals to aspire towards.

There's what's known in software development land as "feature creep."  Meaning
more and more desirable features become seen as necessary.  Many a promising
project has been bogged down and/or done in by feature creep.  Something to be
aware of...

> And also, where can you do an MA in
> Designing Whole Systems?!  sounds super intruiging....

Antioch University Seattle - WSD program info is here:

http://www.antiochsea.edu/wholesystem/index.html

cheers,
John S.

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Cultural & Ecological Designing
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net