Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] new comments on 0.2.3 - advanced search

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Bear Kaufmann <bear@ursine-design.com>
  • To: pcplantdb <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] new comments on 0.2.3 - advanced search
  • Date: Wed, 27 Jul 2005 14:19:57 -0700

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.

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.
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 terms.
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).
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.
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.


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.

Cheers,
Bear





Archive powered by MHonArc 2.6.24.

Top of Page