Skip to Content.
Sympa Menu

pcplantdb - [pcplantdb] new comments on 0.2.3

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb@lists.ibiblio.org, Stephanie Gerson <sgerson@stanfordalumni.org>
  • Subject: [pcplantdb] new comments on 0.2.3
  • Date: Thu, 21 Jul 2005 14:25:49 -0500

Stephanie Gerson writes:
> hi Chad,
>
> So I played with 0.2.3 this morning, and have attached another doc.
> Please let me know if there's any comments you'd like me to enter
> into the issue tracker.

I'd send this stuff to the list. I think it's good stuff for other
people to see as well. I'd also prefer if you could just past it as
text inline, but I can get over it.

> I plan to switch to Firefox tonite (big move for me), so I'll
> hopefully be able to access the issue tracker then. Also, I have a
> list of comments that I'm not sure if they're for you or Bear - but
> I'll discuss them with Bear tonite anyhow.

Good move, you might consider using the Thunderbird email client as
well (companion to Firefox).

> thanks!
> *Stephanie


> Dev.permaculture.info
> Release 0.2.3
> 7.21.05
>
> Search Engine Comments
>
> Can the characteristics in advanced search (i.e. annual, biennial,
> perennial) be presented a bit differently? They're smushed together
> and hard to read. Perhaps as a list going downwards, and have
> different columns for different characteristic categories? Also, it
> would be nice to have an `interaction' that's something more
> beautiful/exciting than checking boxes, like clicking and dragging
> preferences into a palette (Laszlo-style) or something like that. or
> would this come later??

This is all Bear. I'm not good at making nice forms even if I try for
a very long time. I made them all checkboxs, but I'm sure Bear will
come up with something neater.

Note to Bear: For many of the checkboxes it's just the occurrence of
the name in the search that counts, the values are
random/ignored... hope that doesn't confuse you. This can change too,
but most of the items/names are not exclusive so the input methods
need to accomodate this. I'm open to changing the input to names with
multiple values if you wish.

Another note to Bear: Can you do a Reset/Clear Form button too?

> Why is bamboo a habit?

No idea, except it's really a grass the size of a tree and there is no
habit that is tree/grass.

> Still having the same problem with sorting/relevance, I should be
> able to get exactly what I'm looking for. For example, if I search
> ``corn,'' I want sweet corn to be of a higher relevance than corn
> salad even if all else is equal in my search criteria.

Sorry, just specifing corn in the common name will place equal value
on all plants that have corn in the common name. I'm not sure I agree
that it should be different. Specify 'sweet corn' if that's what you
want, or add in some botanical info.

> Doesn't user hits determine relevance in a normal search (like
> google), and wouldn't there have been more people searching for
> sweet corn than corn salad?

This could be done, but it would take a while to build up these
popularity stats. Try searching for other common names as well and
see if (providing it exists) doesn't serve you well.

> Or is there any way to attach one-word common names (i.e. corn,
> lemon) to certain objects (so that you get sweet corn, lemon fruit
> instead of corn salad, lemon verbena)?

This could maybe be done with tags? I'm not really following you
here.

> This string is a bit ugly: ``Found 6154 matches for 'corn edible
> plant_9 plant_8 plant_fast plant_annual plant_cultivated ''' can we
> make it intelligible so that it's useful to users?

This is a good issue to add. I was working quickly while building the
advanced search method and I just handed back the direct internal tag
as part of the search query.

> Characteristics to add
> o
> Season to plant/season it bears fruit

This is locale dependent. There does exist some information that is
not currently utilized because it is in a very inaccessible format.
months_in_leaf, months_in_flower, months_seed_ripe are all single
columns with stuff like 3-5, ? - 9, etc. My plan was to [post schema
finalization] break these into starting month and ending month
columns. Ken Fern has stuff to say about time to plant in the
Propagation notes comments, but it's not something you can easily
create a checkbox search for.

> How deep it goes into the soil

Root habit is something I've missed as well... also part of the schema
question (above).

> Companion plants, at least by family? Hmm, too difficult. But when
> are we planning to implement relationships?

Soon see below.

> I did an advanced search for tamarind, including common name, zones,
> tree, nitrogen-fixer. I got 5,112 results, and no tamarind! (Only
> tamarisk?) I couldn't figure out why I got so many results, yet no
> tamarind, until I remembered that it brought up all results that
> matched ANY (vs. ALL) of my criteria (so I got every single
> tree?!). This is a little overboard. I know I mentioned this last
> time, but there has to be some way to limit this, either with
> grammar (Boolean features), being able to sort results by different
> criteria, choosing some relevance quota (only return results with
> 50% relevance or more), or otherwise.

I did an advanced search for 'tamarind' (just common name) and got
nine results with Dipploglottis australis 'native tamarind' outscoring
4 to 1 the second place result. Sometimes less is more ;-)

To answer your question. You would like to be able to formulate
queries with AND instead of the implied OR. This is part of the
search grammer discussion. I also think this would be good to have/do
but for the moment I don't think it is essential to have, because for
very complex searches AND won't match anything while OR will have the
things that matched the most on top. For simple queries the results
are the same, but OR generates a lot of extra hits of low scoring
stuff.

> Make another set of check boxes (i.e. medicinal, edible, etc.) for
> plant uses, instead of just having a blank to fill in.

That would make 270 checkboxes! In this context 'medicinal' is not a
use category. Medicinal uses are listed by their specific use,
diuretic, etc.. Edible is the same way, the use is what part is
edible.

> You capitalized all the letters in the characteristic? I just meant
> capitalize the first letter (Edible, vs. EDIBLE) so that it would
> match the other words.

Sure, done. Everyone else ok with the change?

> Can plant descriptions show the advanced characteristics of the
> plant? I.e. if you click on Zea mays, it would tell you Genus
> species, Genus species synonyms, Family, Common Name, hardiness,
> habit, prefers, etc. (all elements of advanced search)? If this
> means we gotta get in there and assign them (which I doubt, because
> they are already assigned, right?), we could just let users do
> it. But this would be helpful. Because a lot of times the user
> doesn't know these characteristics, that's why they want to search
> that plant in the first place!

Yes, the summary paragraph is exactly that in a semi readable form.
Some of the clunkiness is a result of that. If you aren't seeing as
much as you expected it's because the data doesn't exist. I can see
lots of holes that could be better... one of my reasons for wanting to
get to add/edit plant soon.

> Can there be a `keyword in plant description' blank in the advanced
> search? So users can add words like California, naturalized,
> etc. into their search (as you could in a normal search)?

Exists: Sounds like you mean Habitat in Other Characteristics.

> In returning results, is there a hierarchy of the importance of
> different characteristics or is it simply a matter of how many
> characteristics a plant has? For example, does relevance rank common
> name above zone and habit (so a plant with that common name would be
> ranked above another one which has a different common name, but has
> both zone and habit), or does it rank greater quantity of
> characteristics over lesser (so the plant with zone and habit would
> be ranked above the one with only common name)? And how does it sort
> results with the same amount of relevance? Then does it sort
> alphabetically?

Every item except for names has pretty equal weight. Most of the name
categories are searched for exact matchs and then for substring
matches so names are the quickest way to find a specific plant if you
know it. All this can be changed if necessary. So far I've thought
it worked out pretty well.

> Can search results return the plant communities that the plant is
> found in? this would be extremely helpful, and
> relationship-oriented! And we could include info on the plant
> community, so users could get an idea of the role the plant plays,
> get ideas for substitution?I assume this will happen in the future?

Short answer, Yes. Search results are set up to return any object in
the database. Currently this consists of plants, comments, users, and
references with lots more to come (only plants and comments show up at
the momement).

We still haven't settled on a relationships implementation, but
communtiy objects could be it. I still don't feel satisfied in my
understanding of "When a user goes to create a relationship this is
what the users does and this is what it looks like." and "When a user
uses a relationship this is what it looks like" as well as a concrete
connection between these two things. The closest thing I've seen so
far is the Graphical Elements from the RichClient doc
<http://www.permaculture.info/wiki/index.php?n=Spec.RichClient>, but
this doesn't really help me understand how relationships, the dataset,
and the user interact. At the moment I can see several different
possible implementations, but I'm not sure any of them are getting at
the thing wanted. My loose tagging idea is one that I'm afraid is not
what you're talking about.

> Other Website Comments (for Bear or Chad?)
>
> Homepage &UnknownEntity; normal search (not advanced)
> &UnknownEntity; broken link

I'm not experiencing this...

> The advanced search is missing from most pages except the
> homepage. For example, after using the normal search (from a page
> other than homepage) or even after using the advanced search.

Yes, the advanced search is a prototype form that implements most of
the features. It needs to be added to the Eden/client/head.html but
I'm waiting till Bear makes [better] changes in the header.php.

> Shows ugly code on page:
>
> When you login incorrectly, it shows you all this info you don't
> want to see (password, etc.)

What page? Starts with Cookie? If so, that's debug info that can
easily be turned off, but is SUPER helpful for bug reports in the dev
version. All the complex error messages will go away in 1.0 to be
replaced with short sweet Internal Server Error messages that don't
help at all.

> Below search results
>
> Below registration for password page
>
> Can there be a lost-your-password function, so we can email
> passwords? (I know I forgot mine.)

Yes, that's probably a good idea. Add it as an issue so I don't
forget.

> the normal login form shouldn't appear o the create new login page
> it is confusing

Add this as an issue.

> Advanced should be in a color that's easier to see, Bear can add
> Loving touch

All Bear.

> Prefs page
>
> Broken links
>
> Prefs &UnknownEntity; create an account &UnknownEntity; broken link
>
> Prefs &UnknownEntity; change button &UnknownEntity; broken link
>
> Normal search from prefs page &UnknownEntity; broken link
>
> Prefs shouldn't tell you to create an account if you already have
>
> Prefs perhaps should be at bottom of advanced search? Or in search
> box? Since it goes along with search. This is an awkward page.

Prefs can just go away for now I think.

Cheers,
Chad

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




Archive powered by MHonArc 2.6.24.

Top of Page