pcplantdb

[Stephanie Gerson <sgerson@stanfordalumni.org>]

I agree with everyone else's comments, plus:

-can the tabs be equal sizes?  i.e. "Vision" is smaller than "Get Involved"
and it might look nicer if they were equal.  (actually is "Vision" written in
smaller font?  it looks like it.)

-can all the logos not be smushed in the center, but spaced evenly accross the
footer?

-can "advanced" be written in a font that you can see it (not light blue if
the background is darker blue - something that stands out a bit more)?

-and what's the arrow next to advanced for?  if you can click on "Advanced"
why have the arrow?  the layout of the search feels awkward to me...I'll think
about why.

-for some reason, I don't like the little spotty rays of the sun in the upper
left.  they look messy.  can they be bolder, more defined instead of wishy
washy?

-did you take that photograph?  it's beautiful.  have you showed off your
photography to the group?  if not you SHOULD.  actually I wanted to ask you
something (since no one is probably reading this anyway) - a friend of mine is
doing her medical school rotation at oakland children's hospital and she's
doing a presentation there soon.  she wants some imagery to go along with her
presentation (about embryology of the heart) and I sugggested that she talk to
you.  I feel like you'd probably have a photograph of something (water, sap)
that mimics the bloodflow phenomenon she's discussing.  anyways, we can talk
more...

back to piw...this more recent iteration looks really nice, Bear.
thank you!
*s

------ Original Message ------
Received: 02:20 PM PDT, 07/27/2005
From: Bear Kaufmann <bear@ursine-design.com>
To: pcplantdb <pcplantdb@lists.ibiblio.org>
Subject: Re: [pcplantdb] new comments on 0.2.3 - advanced search

>> 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

_______________________________________________
pcplantdb mailing list
pcplantdb@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/pcplantdb




+++++++++++++++
Stephanie Gerson
sgerson@stanfordalumni.org
(c) 415.871.5683


____________________________________________________________________