pcplantdb

[Bear Kaufmann <bear@ursine-design.com>]

> Bear Kaufmann wrote:
> > I think as a start we can try to re-factor the advanced search into 
> > the
> > inputs-outputs model.
>
> Use arrays of nested (cascading) options checkboxes.
OK, at a more basic level, what are the inputs and outputs?
In the previous email, I was trying to find how values in the current 
database that can map to the input-output model.
"Uses" generally map to outputs, "fodder", "nectar", "fruit", 
"soap"...we'd need to start thinking of these in this manner first.

>  Fill out form, perform search, save entire results to a user session 
> cache. Fill out
> form again & do search, save results to another cache - when done
> perform an inputs-outputs report based on comparison of data in results
> in all the separate caches.
I think I see what you're seeing, but I'd rephrase it. Instead of a 
"session cache", lets start adding objects (plants for now) to a 
"Guild", which could be saved by the user.
In my discussion with Stephanie around the Rich Client, we were 
thinking of Guild "Wizards" (pardon the Windows term). A set of say 5 
objects. They start prefilled with basic search terms. There's the 
n-fixer object, you click it, and a search is preformed, with nitrogen 
fixing required (plus "global" items like your hardiness zone, or 
location that apply to the whole guild). You find a plant you like, and 
save it into that object (now the plant itself), and continue on 
through the tree, vine, etc recommended plants for a guild (of which 
there could be a variety that are built).

That make any sense, or should I try and build a mockup?

> Discover guilds or compatible groups, design systems, go and plant with
> plan in hand.
Emphasis on discover. Find, get recommendations. We can't assume the 
computer will get it all right, and give us a prefer guild, but yes, we 
can help people discover potential.

Cheers,
Bear