pcplantdb

[Chad Knepp <pyg@galatea.org>]

Bear Kaufmann writes:
 > >> Never personally been a fan of fixed width. Having just got myself a  
 > >> 19"
 > >>   screen I want to use it.
 > >
 > > I think I was initially less excited about the new layout based on the
 > > narrow display.  It only takes up 50% of my browser window and I think
 > > it I would rather it be closer to 75% (relative width or
 > > interchangable style sheets?).  This is the only thing I don't think I
 > > can live with as is.
 > OK, good. I was putting the thing out there, thanks for the feedback.  
 > The width I used is quite narrow for a fixed-width.
 > Try now:
 > http://permaculture.info/test/
 > Back to fluid full width and logo.
 > We could return to the full page, flush to the edges of the screen too,  
 > though I think using the solid color bars looks better if contained  
 > within a column.
 > What do you think of the plant images in the top right? Better then the  
 > drawings?
 > 
 > >>> We might want to use the fixed width on content pages, and search
 > >>> results get returned with a sparser, full page layout.
 > >>> Note the integrated advanced search.
 > >>>
 > >> Nice, I'd make the search box bigger. I prefer the old PIW logo, the
 > >> round sphere does nothing for me.
 > >
 > > I prefer the old one as well, but I'm fairly certain that it's a
 > > copyrighted (in the worst way) image and we would either need to
 > > license it or get official permission from Tagari, Bill, and the
 > > illustrator...  Hey, lets host a logo contest like a *real* open
 > > source project ;-)
 > Which logo are you referring to Chad? Bill's infinite snake (Orobus...?)
 > Our current logo is back up. I actually found that orb from a while ago  
 > when playing with designs, it is henceforth dismissed.

I miss-spoke, I was actually referring to the drawings that look like
they where scanned in from the designers manual.

 > >> Also I'd really like to see a Plants For A Future logo on the front
 > >> page, something like incorperating data from Ken Fern/Plants For A  
 > >> Future.
 > >
 > > Agreed, I think it could go footer and appear on all the pages.  Does
 > > Plants For A Future have a small logo?
 > Right. Any small logo available? Should PFAF get a mention in the index  
 > page text and/or footer image?
 > PIW content based on the Plants For A Future dataset.
 > 
 > >> Like the way you've arranged the Habits. We'll want a lot more fields  
 > >> on
 > >> an advanced search.
 > >
 > > I also like the drop down format for advanced search on every page.  A
 > > definite 0.3.0 feature.
 > One thing to consider is that though it may be hidden a lot of the  
 > time, it looks like the full advanced form (between <form></form>) runs  
 > 8K. Not a huge amount, but we may want to place it wisely.

8k and growing ;-)

 > >>> Also, see this:
 > >>> http://www.permaculture.info/test/piw2/search_improved.php
 > Now see:  http://permaculture.info/test/piw_folksonomy.php
 > Which might make the answers below more clear. (Note, I'm just using  
 > Uses as tags, with 5 plants in the "database").
 > > I've got some questions.  I'm assuming that in this example vine, poor
 > > soil, neutral ph, and Rosaceae are the search ter ms.
 > Correct.
 > >  What would
 > > clicking on the x-button link next to these terms do?
 > It would remove that term from the query (generally resulting in a  
 > larger result set).

Easy.

 > > What would the
 > > filter+shrub and filter+tree do?
 > It would add shrub or tree to the query. Their size tells you that with  
 > the current result set, there are a lot of vines, some shrubs, and not  
 > many trees that match the other conditions.
 > > Also how do you go from vine to
 > > suggesting shrub and trees as filters?
 > Click the link.

I guess what I meant to ask is how did you decide to suggest shrubs
and trees as filters.  I understand from the above that the result set
returned a lot of plants that had habits of trees and shrubs which is
how the suggestion is made.  Getting this sort of information will
take additional implementation.... currently I'm wondering how to
generalize about result sets and not try to focus too much on schema
details at the user/client level.  Imagine two methods.  The first
returns the highest levels of intersection, which would include the
search terms themselves to the extent they intersect, but possibly a
term/tag with a higher level of intersection than any of the search
terms!  This would have suggested shrub and tree.  The second method
would provide terms of divergence/difference.  These would be tags
that might be helpful to select against in order to create a more
cohesive set.

 > > Why not annual for example?
 > I made this a very short example, it would ideally include many of the  
 > properties that are similar to tags....annual, perennial, locations,  
 > habits, zones, etc.
 > > I'm assuming that edit search would take you back to your search form
 > > in it's former state.
 > I was thinking the link would pass the variables to the advanced search  
 > form, which could run through the GET values, and set the values if  
 > they are in the url.
 > > Is there anyway we can do this without having
 > > to do insert selected="sdf" stuff into a dynamic version of the
 > > form... for example is there any way to fool the browser to pass on
 > > the info to the hidden advanced search form?
 > Yeah, if we wanted to include the terms, we could dynamically load them  
 > into a hidden edit-search box, which would require similar coding to an  
 > independent search form page with values passed to it.

Probably not worth adding the 8k+ though huh?  I'm think we might do
better keeping state on the search terms/query and then working hard
when necessary to insert stuff into forms.  We might not have to do
this if we keep track of everything and add/subtract terms via
filters.  

 > >
 > >>> Playing with a folksonomic search browser like layout for habit
 > >>> (text-size represents percentage of tag hits in the result set).
 > >>> It might be best used as 2 different search modalities...
 > >
 > > I think we could put this as a new format ('folksonomic'
 > > maybe)... Relative sized fonts sounds like a good way to visually and
 > > textually represent info.
 > >
 > > BTW in the process of making it possible to add/edit plants I
 > > converted the plant_locations table to a tagged format:
 > >
 > > describe plant_locations_II;
 > > +----------+--------------------+------+-----+----------------+-------+
 > > | Field    | Type               | Null | Key | Default        | Extra
 > > +----------+--------------------+------+-----+----------------+-------+
 > > | plant_id | int(10) unsigned   |      | PRI | 0              |
 > > | author   | varchar(25) binary |      | PRI | Ken Fern       |
 > > | location | varchar(30)        |      | PRI | in cultivation |
 > > +----------+--------------------+------+-----+----------------+-------+
 > >
 > > select distinct location from plant_locations_II;
 > > +------------------------+
 > > | location               |
 > > +------------------------+
 > > | along a sunny edge     |
 > > | in a woodland garden   |
 > > | in cultivation         |
 > > | near a wall            |
 > > | in the canopy          |
 > > | in deep shade          |
 > > | in dappled shade       |
 > > | in a hedge             |
 > > | in the secondary story |
 > > | in the ground cover    |
 > > | in a meadow            |
 > > | along a shady edge     |
 > > | in the lawn            |
 > > | in a bog garden        |
 > > | in a pond              |
 > > | in a hedgerow          |
 > > +------------------------+
 > >
 > > The previous table was as follows:
 > > describe plant_locations;
 > > +-----------------+----------------------+------+-----+--------- 
 > > +-------+
 > > | Field           | Type                 | Null | Key | Default |
 > > +-----------------+----------------------+------+-----+--------- 
 > > +-------+
 > > | id              | smallint(5) unsigned |      |     | 0       |
 > > | woodland_garden | char(1)              |      |     | N       |
 > > | canopy          | char(1)              |      |     | N       |
 > > | secondary       | char(1)              |      |     | N       |
 > > | sunny_edge      | char(1)              |      |     | N       |
 > > | dappled_shade   | char(1)              |      |     | N       |
 > > | shady_edge      | char(1)              |      |     | N       |
 > > | deep_shade      | char(1)              |      |     | N       |
 > > | other_habitats  | char(1)              |      |     | N       |
 > > | cultivated_beds | char(1)              |      |     | N       |
 > > | ground_cover    | char(1)              |      |     | N       |
 > > | lawn            | char(1)              |      |     | N       |
 > > | meadow          | char(1)              |      |     | N       |
 > > | hedge           | char(1)              |      |     | N       |
 > > | hedgerow        | char(1)              |      |     | N       |
 > > | pond            | char(1)              |      |     | N       |
 > > | bog_garden      | char(1)              |      |     | N       |
 > > | walls           | char(1)              |      |     | N       |
 > > +-----------------+----------------------+------+-----+--------- 
 > > +-------+
 > 
 > Hmmm....
 > using varchar(30) for each plant use seems like a lot of space, and  
 > rather hard to play with.
 > I'm thinking that it might be better served with locations: [plant_id |  
 > author | date | locationID].
 > LocationID relates to the plant_location_names table with the fields  
 > [locationID(uid) | shortname | description | author?]
 > Description uses the long form (in a bog, etc) and shortname uses the  
 > more tag like field names in the old plant_locations.
 > This would make it user expandable if a location doesn't exist yet, but  
 > checking what location terms exist doesn't require running through the  
 > whole plant_locations_II table and finding unique values (just look at  
 > plant_location_names), and we can use either the long form, or short  
 > form, depending on the content.

In the loose tagging model plant_locations_II is expandable in that
it's not constrained to existing values/columns as in the original
plant_locations.  Adding a description/notes column as you suggest may
be worthwhile though...  Two tables aren't really needed unless you
constrain plant_location_names.short_names to unique values.  Loose
tagging needs to be ok with a little bit of redundancy.   Your example
is correct in the classic sense, but I'm not sure the additional
complexity is worth it.

 > Cheers,
 > Bear

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'