Loomio
September 23rd, 2014 01:03

Direction for search results

DU
[deactivated account] Public Seen by 33

I'm not sure whether this is a discussion or just an enlightenment session:

https://github.com/FarmBot/OpenFarm/issues/132

Rory Aronson

Rory Aronson September 23rd, 2014 03:16

Haha I think it was mostly an enlightenment session up to now, but if anyone has more ideas for search results, they can be shared here.

I was thinking of more ways to rank Guides in results. So far we have discussed:

  • Compatibility Score
  • Overall Rating (originally proposed as a 5 star rating, then leaned towards a thumbs up/down rating. Now considering only a thumbs up button to keep the vibe more positive and because folks might rate the Guide poorly if it is incompatible with them, not realizing that... of course it isn't good advice for them!
  • Completeness Score (ie: does it have an image, an intro, etc)
  • Popularity (number of comments, views, times added to user gardens)

What about:
* Written originally in your native language? Should this matter if we have good site translation?
* Age (How new or old the Guide is)

Rory Aronson

Rory Aronson September 23rd, 2014 18:51

I'm just going to drop this here for reference:

The current UI design is that we display all the Crops matching the search term up top, and below that are all of the Growing Guides written for those Crops.

We have two mockups made for this (attached)

The 'Generic Search Results' has a 'carousel', featuring multiple Crops and prompting the user to pick one. If a user were to click one of the images, they would be taken to a search results page with that more specific search term. See 'Specific Search Results'.

Please share thoughts on this user flow and interface here as well :)

MB

Mike Beggs September 24th, 2014 03:29

The design of the generic search results leading to the more specific ones when a result is selected looks like a good flow. I also think the ideas for ranking the results are good as long as I can select the different criteria for the ranking. I get annoyed when the options for sorting are limited and I have to accept some algorithm's idea of what is most relevant.
On the subject of search features, something I like to see with a search is a list off to the side with a hierarchy of the subcategories to filter the results (shopping sites such as Amazon sometimes show these filters on the left side of the page for example: "All results (52)", "Free shipping (10)" "Nikon (12)", "Sony (8)", "Canon (28)", etc.) I especially like seeing the number of hits that each filter encompasses so I can gauge the specificity of the search terms and can click them on and off to narrow in on the results. For tomatoes, such filters could be things such as Heirloom varieties, Hybrid varieties, Disease resistant varieties, Early bearers, Late bearers, Alternate colors, Quick tips, Specific to your area, etc. The list of filters would be dynamic based on the results returned and thus are probably based on keywords that they results contain. Reading such a filter list also helps summarize the results for quick perusal to know if the search terms were appropriate.
Anyway, just my thought about search functions. The site colors and graphics are looking cool. I'm looking forward to this site.

Rory Aronson

Rory Aronson September 24th, 2014 04:03

I like the idea of the search ranking filters to be able to, for example: turn off the importance of 'popularity' when ranking guides, or some other criteria.

You bring up good points about filters for finding the right crop. These filters would not filter out guides, but rather filter down the crop selection in the carousel. This would be super useful!

Ryan

Ryan September 27th, 2014 21:15

Hey guys, I've been working with Rory a bit to refine the search experience. We're trying to accommodate users of the site who have specific goals in mind and those who are just exploring with the goal of getting everyone to a specific crop and guide as painlessly as possible while still fostering exploration.

This currently flow isn't too different from what we have, but the organization of information is what's different. There's technically only one "search results page" with the "specific results page" now being the crop page, which features both crop info and all relevant guides with filters.

Ryan

Ryan September 27th, 2014 21:20

These are new mock-ups for the search flow, a good number of features are missing and we're still playing with the look and feel of different elements. Please leave any and all feedback including what immediately sticks out to you as missing or confusing. Also we're messing with various ways to show "guide compatibility." You'll notice that there are several styles in the following mock-ups. What do you think?

Below: Search Results (desktop, mobile, and mobile with filter modal)

Ryan

Ryan September 27th, 2014 21:23

If the user chooses a crop from this page instead of a guide, they'll be presented with this page with full crop info and a list of all guides (again filterable, but that element currently isn't show—please comment on the type of filters you'd think should be most prominent).

Below: Crop Pages (desktop, and mobile)

DU

[deactivated account] September 30th, 2014 06:37

Hey Ryan, sorry that this has been so long in waiting for a response.

Architecture

I'm not 100% clear on how we're going to differentiate a search for "cherry tomatoes" from one for "tomatoes". I think that's going to have to be thought out a bit more - can we consistently make that distinction? Can we guarantee that we know what the user wants, and then return "cherry tomato" crops, without showing possible other crops? Maybe there's a way to handle this within the "specific crop" result page, similar to the way Google says "did you mean ____". Also, if we show results for "Tomatoes" and it's lots of crops, what happens to the user who just wanted to grow tomatoes without wanting to know what specific variety? Do we have a "best tomato for you" section?

Search Results

I'm a bit confused by why there's twice the same results for the first search result image you added. Is that meant to be two different Crops? (pretty sure it is - just wanted to clarify)

Specific Crop Chosen

I like the Desktop results, but I'm a bit concerned about the imbalance that's inevitably going to happen with lots of guides versus the fairly limited search result in the top right corner. I'm guessing that the idea is to have the crop be fixed and the guides scrollable underneath? Does that translate to mobile? Seeing the actual crop collapsed on Mobile would be kind of neat. Maybe the space underneath the Crop can show similar crops in case the user didn't want a Cherry Tomato really?

Visual

I like the overall style. It's subtle and still colorful.

I prefer the empty circles as a compatibility guide I think it -keeps the colors a bit less in your face. I suspect that the "compatible" at every section is a bit redundant, and can be solved by a tap and expand (or something like that).

I would also tone down the drop shadows a little bit in the mobile pages? I think they're a bit too intense on some of the boxes, though they seem good on the guide page.

Filters

Filters can be tricky - is the best bet to have a filter like Github's search Issues box (eg is:open, label:Growing Guides, etc), or is that too complicated? What if a user just types something (anything) into the search box, and it live updates with results, with specific things to look into (cause we know). Other than that - specific things that would interest me to filter on are: "location (near me)", "time commitment (low)", "sowing time (now)", "sun/shade preference (sun)". Can we filter by requirements?

Let me know if all of that makes sense, and whether it's helpful!

Kind of wish this column was a bit wider to show those images better.

Ryan

Ryan September 30th, 2014 07:22

No worries! I'll try to respond in an organized way:

Architecture
I sort of assumed we'd use a typeahead for search with results for specific crops as well as general ones. General ones and things we can't match would go to the normal results with crops going straight to that crop's page? Did I understand the question correctly?

As far as not knowing what tomato to grow, I agree. That's hopefully where the compatibility scores come in. I imagine we'll show the top x guides for each crop and then sort crops based on guides available and compatibility. Not the best solution, but it's pretty good.

Search Results
I kept customizing all of them but then just got lazy using symbols to repeat things :P

Specific Crop Selection
Can you clarify? Are you talking about mobile? Sorry, some of the mocks a bit confusing since they got saved as transparent pngs.

Visual
Thanks!…and good to know I agree. I also agree on repeating "compatible"—meant to get that out. The drop shadows are looking a lot more dramatic here than they did when I made the mocks—maybe it was flux. They're meant to be subtle and I'll be sure to tune them down.

Filters
I really like the idea of having big easy filters and more advanced hidden filters. GitHub's are too techy for our audience I think. I agree that graph search for OpenFarm would be fantastic, but is probably in a far flung future :P Who knows! Happy to be wrong.

I wish it was wider too :[ This is definitely not the best way to showcase all the design ideas/changes/etc, but eh.

DU

[deactivated account] September 30th, 2014 08:15

Architecture

I think so! So within the typeahead we'd list crops within the database, and if the user selects none of them, we'd go for general?

Specific Crop Selection
I'm talking about the image named "Crop Page.png". I guess "results" was the wrong word to use. Basically, the specific Crop result page, with the crop information on the left, and the guides on the right. I'm concerned about all of the empty space underneath the crop, and think that it could be used to fill with "related crops" appearing underneath it.

Re sharing designs, there a are a number of tools for that specific purpose, and we could try using one of them, with appropriate links laid here to them? I'll have a look around.

Ryan

Ryan September 30th, 2014 19:38

Yep! Those are my thoughts for architecture.

Ahhh yea I should have explained: I'm assuming crops will have more info to display than that. If not we can come up with a different design or like you said show some related crops, maybe even seed ads, etc.

I don't have a particular tool for sharing designs in mind, besides cl.ly :P Do you know any good ones?

Andru Vallance

Andru Vallance October 1st, 2014 12:36

Looking good visually. Having some way to collaboratively annotate these screenshots would be super useful.

I think the left-right split on Crop Page.png isn't ideal. Sure, the user doesn't have that initial scroll hit to get past the crop info and down to additional search results, but once a user does scroll, there's now a big portion of the screen permanently taken up by crop info (assuming the crop info is position:fixed) making that process less efficient.

I guess it comes down to our assumption about compatibility. The screenshots demonstrate a couple of highly compatible entries quickly giving way to low compatibility.
I imagine, especially for a crop like Tomatoes, that if the user has high compatibility with one guide for outdoor grown Tomatoes, then a lot of the other Tomato guides are going to have high compatibility.
That assumption shifts the emphasis from "the user only needs to see the top few" to "the user needs to be able to efficiently hunt through the guides to find the one that interests them".

On a functional level, I think these screens fail to deliver enough information. I think they over emphasize the importance of a compatibility score and an author-composed title and description.

I think we need to let the user know why their compatibility score is high or low. Otherwise if I have 5 fairly equally compatible entries for heirloom tomatoes, how do I choose without laboriously navigating to each one in turn?
Maybe some key ticks and crosses? Like a pro's and con's list:

✓ Organic
✓ Indeterminate / Vine type
⨯ Clay soil

I also think that basing the ordering solely on the compatibility score could we a mistake. We should factor in how popular the guide is, how many people favourite it, how many people comment it, etc. Moreover, I think we should expose this information to the user.
All this information is crucial to deciding which guides are worth my time investigating.
The compatibility score might be low because my prerequisites are not a match, but if it's a really well written popular article with lots of comments, it could still an awful lot more valuable to me than a poorly written article with a high compatibility rating.

It could be argued that this kind of information is clutter, but I would argue that on a search results page you need to present the user with as much information as possible to help them make sense of a potentially confusing array of options.

Andru Vallance

Andru Vallance October 1st, 2014 12:54

I'm also not sure I see a benefit to grouping search results by crop in 'Search Results.png'. I think showing matching crops in order to filter down to display only that crop is useful, but why separate compatible guides by crop on the right?

If the user doesn't know or care what variety of Tomato they want to grow then all this is doing is increasing the number of incompatible articles in the valuable above-the-fold spot. If they do care, then the crop navigation to the left provides them with the functionality they need.

Ryan

Ryan October 1st, 2014 21:56

All good points. I had a similar concern on the crop page being split, but thought most users trying to get to a good guide from this page would benefit from having a bit of crop info and a full list of guides. We could split these off though.

We can always show more guides per crop, the question is do most people care what the variety is? Are users coming with a variety of tomatoes in mind? Do they not know a variety and are trying to find one? Or do they simply not care? Catering to all of these makes choosing a definite direction in the design hard.

I completely agree on showing why a guide is "compatible", but think we could put it in a popover for the score to avoid having repeated icons and stats everywhere, not overwhelm less experienced gardeners, and still provide the information. What do you think?

To me, as problematic as it can be, I think the author title/description, and compatibility scores can be valuable, more so than stats. Where quantified information gives the user everything, an more qualitative title and description can provide a wealth of more human-friendly information and the compatibility score attempts to interpret otherwise potentially meaningless stats into something more meaningful. That said I have my concerns about resting everything on the score and agree that we should show some of popularity/comments/use metrics somehow.

Good point about popular guides with low compatibility.

I think this kind of information does very quickly become clutter, and it's up to us to help the user make a choice without lazily throwing up guide and crop metrics. Things like the compatibility score are heading in this direction, despite not being perfect!

I don't think there's any reason not to group by crop. That's one of my biggest gripes with the current design. I do think the different sections could take up less space though, and can play with that if you think that'd help?

So TL;DR: I like author info, would like to try guide metrics in popovers, we should show guide comments/favorites, crop page should not be in search, and we might need to rethink sorting by crop variety.

(Loomio needs a way to thread conversations out into mini-discussions! This is getting overwhelming, want to try Influence?)

Ryan

Ryan October 1st, 2014 21:56

Thanks for the markdown loomio ¬_¬
(Apparently it's opt-in (that little grey 'A') and can't be turned on after the fact lol)

DU

[deactivated account] October 2nd, 2014 04:10

Sure, I was going to recommend invision. Whichever you choose, you should be able to upload an image and we can comment on them.

Ryan

Ryan October 2nd, 2014 04:33

Hey look at that! Some of my friends are on the homepage :) Sounds like a good choice :P

Rory Aronson

Rory Aronson October 3rd, 2014 13:31

Hey all, sorry for chiming in so late on this (was fulfilling Kickstarter rewards and then travelled to Spain and got massively jet-lagged/internetless)

I always like putting stuff in context: Ryan and I came to the split screen idea from Airbnb's search results page: https://www.airbnb.com/s/san-francisco?source=bb In their page, the map on the left is in a way the most important "filter" - location. And on the right are all the results with extra filters.

For us, arguably the most important (or at least, fun) filter is to choose a Crop, but this really depends on how one is using the site.

The reason for grouping results by crop was to provide context for each Guide. Looking at the original mockups I had made, there wasn't an easy indication what Crop each Guide was written for other than being in the title.

I'm still on the fence about the grouped results. I like the context the grouping provides, but I worry about there being a really great Guide that would normally be #1 in results, but it is written for the 20th crop in the list, therefor I never see it. Perhaps the right side of the screen could have two views that can be toggled by the user: Grouped results and straight list view?

Hmmm... ok, now I am leaning towards the list view rather than grouped results. I imagine two users: 1) User knows what Crop they want, they choose it and go straight to the list view - no groupings 2) User does not know which crop they want and wants to see all Guide results for all the crops. They probably want to see the top results across the board based on compatibility, popularity, etc, rather than having to scroll through groupings.

The list view has to be built for the MVP (I suppose it already is to some extent, there is just no ranking), so how about we focus on just that for now and use it on both single crop and multi-crop pages? The grouped view for multi-crop pages could be an A/B test down the line, or a toggle-able option. What do ya'll think?

Regarding search ranking:
I agree that we do not want to overwhelm the user, we want to provide valuable information that will help them make a decision as to which Guides to open, and we want to avoid throwing meaningless metrics at them in favor of something easier to digest. I think we all agree the compatibility score is a good idea, though it is not the end-all solution. I proposed on GitHub that in addition to this, we provide a unified "popularity score" based on pageviews, comments, etc https://github.com/FarmBot/OpenFarm/issues/195 and also a Guide completeness score https://github.com/FarmBot/OpenFarm/issues/194. I also think that a general rating of quality is a good idea. Originally I had thought a 5-star rating would do, but this seems to be a bad choice. Perhaps a better choice is only allowing users to "like" the guide by giving it a "green thumbs up"? Users could then feasibly look at all of the guides they have liked/favorited via their profile.

We could also show a badge of some sort for Guides that are popular, have a lot of forum activity, or are new. I like this option because it draws the eyes to the Guides that are highlighted with badges rather than showing a zillion icons and numbers that the user must actually interpret for each guide.

I like the idea of a tooltip over the compatibility score displaying the ticks and crosses you mentioned @andruvallance.

I agree Guide filters are going to be important and we'll want to make them easily usable. I love the sowing time (now) idea!

PS, this narrow column blows!

Ryan

Ryan October 3rd, 2014 19:03

Hahaha I was thinking the same thing on the column! (another argument to maybe not have fixed crop info?)

Thanks for providing some context Rory. I should have explained the conception of the idea more. With the Airbnb example, all the of amenities of a listing are crucial to look at and evaluate a place on (in a high-level, initial search), but of course location is king; in this example the user moves the map, re-evaluates the results and either chooses one, more moves the map again. We thought something similar would work well for the crops, with the user choosing a crop, seeing detailed crop info on the left, and evaluating the guides on the right, or going back to see all results and choose another crop.

What do you all think of reducing the limit on guide results per crop and either keeping them organized by "crop titles" or interleaving them and labeling the guides with the crop they're made for? (this later option takes up more space with repeated text and takes away a level of organization, but does allow for sorting based on some measurement regardless of crop type. I'll work on some mock-ups in the meantime.

Still not sure what's best to show as far as ratings and stuff… I think letting users bookmark guides is great, and it's really helpful to double up the feature as a vote (like, thumbs up, etc). Maybe comment counts aren't that helpful initially and we just show hearts (or whatever else) and compatibility for now (with some details for compatibility on hover)?

Ryan

Ryan October 3rd, 2014 19:15

Off-topic: Install Stylebot Chrome Extension and use this css to make everything full width :P Only the teensiest bit jank.

Rory Aronson

Rory Aronson October 4th, 2014 17:22

I think if the user really wants to see the Guides for a single Crop, they will use the filter. And if they want to see Guides for many Crops, they will want to see them interleaved and ranked purely with the ranking factors, without any other organization. So in this case, each Guide would have to specify with text, which Crop it is written for.

How about allowing the user to choose how things are sorted? By default, it can sort by "magic" which is our ranking algorithm that takes into account all factors. There could be a dropdown with the options to sort by: "compatibility", "popularity", "activity", "newness", and "completeness".

This sorting option could also be for Crops. Default would probably be "magic", taking into account not only the number of guides available for the crop, but also on average how compatible they are. Other options could be: alphabetical, compatibility, and popularity.

Sorting options combined with filters could be really powerful and efficient.

Ps, love the css hack!

Rory Aronson

Rory Aronson October 4th, 2014 17:36

Another thought: What if when a user is creating a Guide and filling out the Title, we automatically append the Crop's name? - and the user is well aware of it. This would force the user to use words describing their plant or process and prevent them from stating the Crop's name themselves and then it double showing up in places where we want to display it (such as in search results or on the Guide page itself) It would also force it to be there when we do want it! Examples of what we want:

Juicy Heirloom Tomatoes by Nancy
Big, Colorful, and Tasty Heirloom Tomatoes by Nancy
Dry Farmed in a Greenhouse Heirloom Tomatoes by Nancy

What we don't want:

Juicy Heirloom Tomatoes Guide for Heirloom Tomatoes by Nancy
Juicy Guide by Nancy

Rory Aronson

Rory Aronson October 4th, 2014 18:19

Messin around, what do you guys think?

Link to play with it/comment on it: https://docs.google.com/a/roryaronson.com/drawings/d/1Bm-FcSiF0NZL4_8vq4zlq9q30n3zmr0oZsc3vbXQnTY/edit

Ryan

Ryan October 4th, 2014 18:22

Pretty much! Messing with some quick filter ideas right now…
I really like that idea of forcing the title style. Helps us know how we can display/format it down the line too. …trying to think of times that would be annoying though…

Ryan

Ryan October 5th, 2014 00:00

I've been playing around with how simple filters might work and am understand that there are a lot of ways (more complex than this) one might want to filter by and that if crop isn't a priority filtering method then it doesn't belong as it's whole sidebar view. I was under the assumption that this was important to people, but I'm realizing that maybe it isn't. This all said, I think it'd tough to sort by things like "sow time" without showing on each guide card how they're being sorted (ie. showing sow time), which I think could be straying into showing too much info, but maybe not?… maybe there should be a little row of stats icons with seasons icons for sow time, etc (although I imagine for a crop, each variety would vary in more specificity than season).

Rory Aronson

Rory Aronson October 5th, 2014 10:24

I see two types of filters that each serve a separate purpose: crop filters and guide filters. Crop filters help the user find the appropriate plant for their area and needs. I think a lot of people will want to filter by crop first (I know I would) to find things like:

  • Native?
  • Invasive/aggressive?
  • Is the fruit good for eating raw, preservation, or cooking?
  • Is the plant hardy or delicate?
  • Does it look good? (Think about people using OpenFarm for flowers and trees, ornamentals, or making decisions based on the pictures)

Guide filters help the user find the best growing advice for the selected crop. Maybe some people just want to use the guide most compatible with them, they don't really care about the variety so much.

  • Is the method organic, biodynamic, hydroponic?
  • Is the plant ready to be planted now based on the method?
  • What type of soil do I need?
  • Do I have the time required to grow this?
  • How much water?

So, I think the Crop sidebar is a great idea.

Showing sowing time could be fine, I think, as long as that info was only shown on the card when that sorting option is active.

Also, I want to make a distinction between filtering and sorting. One would filter for sow: now or sow: within 1 month, thereby limiting the number of guides shown to those fitting that criteria. One would sort to list all the guides in some specific order, for example starting with sow time: now, then within 1 week, 2 weeks, etc.

MB

Mike Beggs October 6th, 2014 15:40

I've not read all the past posts on Loomio or GitHub, so I may be writing this out of ignorance. As I read this thread on search results, I think this discussion of search, filtering, and sorting would benefit from a list and/or diagram of the terms and data fields being considered and their hierarchy and definitions. I'm not sure we're all thinking the same things with words like "crop", "plant", or "variety". And what about "cultivar" and "type"? Also, when I see a distinction made with certain words such as "heirloom" for tomatoes, I think it refers to such a broad grouping that the many varieties (or is that "cultivars"?) it encompasses would make their growing guide very generic and likely not much different from a general "tomato" guide as a whole. I'm assuming that a search has to begin at a high level yet will also allow very specific terms to be added or filtered upon, and defining the hierarchy of those terms may help our discussion of the search function and results presentation design. In the tomato example, I think searching for the word "tomato" should include results that can be filtered based upon "determinate" or "indeterminate", "Beefsteak-type", "Roma/paste-type", "Cherry-type", "Virus resistance", "Time to maturity" etc., which can lead to very specific varieties or cultivars. Then there are all the attributes related to the growing process mentioned by Rory. What is the current thinking for how all that information will be organized and how they relate to each other? Is there a list and/or diagram that lays it all out?

Ryan

Ryan October 6th, 2014 19:06

Rory and Mike, good points, definitely oversimplified at the moment. What would be the best way to collaborate and figure out this list of filters and sorts? Google doc perhaps?

Rory, I think sorting on top of filtering isn't necessary if we do it right, especially with combined filters. A lot of times we can intelligently sort based on the filters used (ie. if sow time + appearance are used as filters we should probably sort by nearest sow time and best appearance.

MB

Mike Beggs October 6th, 2014 20:31

Ryan,
Google docs should work if we make the files editable.

DU

[deactivated account] October 7th, 2014 01:31

Just wanted to link to these github issues just to give some background to what's already been raised.

(I say raised because it's more like @andruvallance raising concerns about classifying things in certain ways, and everyone else kind of just like "this is complicated, i dunno").

A diagram might be of help. I also think that maybe we just have to decide that we're inserting crops into our database by their binomial names, and then going to have to map localized names to those binomial names, and let users supply such a name if it doesn't exist (we can, for example just say "we notice that you're dutch, what's the dutch name for Amaranthus retroflexus?" and then we add it to our list of common names for that plant).

MB

Mike Beggs October 7th, 2014 04:46

Thanks for the github link. I figured this topic had to have been addressed and I'm not surprised that the general response was “this is complicated, I dunno”. So maybe that is our call to action: simplify what could be a complicated and unacceptably complex situation into a straightforward and useful arrangement. If we can identify a useful mapping that cross references the different names and which can expand as users add their own local or common names, then we can build a powerful database. I think what is most important to OpenFarm (at least as I think of the site) is to keep in mind the point that @andruvallance raised on github: "a means to refer to cultivars which share characteristics as a group, which is crucial." To me, it is indeed crucial to identify plants at the level of shared characteristics, especially cultivation characteristics, for OpenFarm to be most useful. If we need to get to the cultivar level to guide someone on how to grow 'Iceberg lettuce' successfully vs. 'Oak Leaf Lettuce" then we'll need to be at that level with the guides. Whereas, with something like spinach, the cultivation of one cultivar or another is not really that different, so maybe there can be one guide for spinach. So maybe we start with the list of every way a plant may be referred to, and then pick the level where the cultivation details are most useful and channel the search and filters toward that level. For example, I think pointing to a guide on "heirloom tomatoes" is not going to be that helpful because "heirloom" encompasses great diversity in growing habit and cultivation needs. Such a guide would be interesting as a source of tomato hybridization info, but it's not going to be very straightforward to describe growing a determinant early season tomato in the same guide as an indeterminate late season tomato, even if they are both considered "heirloom". Thus, I would say we group tomatoes by growth habit, then link to open pollinated vs. hybrid discussions in each one if needed to help someone pick a specific cultivar.

Rory Aronson

Rory Aronson October 8th, 2014 09:15

As I understand it now, every "Crop" in our database is/should be a unique type of plant that is at the most specific level possible so there is no ambiguity. Every Crop name should refer to only one Crop in the database, and there may be many names (localized, language specific names) pointing to the same Crop.

All of the Crops will belong to larger groups based on... things (cultivation techniques, gene lines, etc). For instance, there might be several dozen Crops that all fall in the category of Heirloom. What the Heirloom category or classification is called (Cultivar, Species, Sub-Group) is where I get confused but I know somebody has the answer ;) - probably @andruvallance in here: https://github.com/FarmBot/OpenFarm/issues/60 At a very high level, everything will fall into the Kingdom category of Plantae, until we allow mushrooms 'n stuff on OpenFarm ;)

So when a user searches for Heirloom Tomatoes, they would see results of all the Crops that belong to that category.

If a user searches something generic like "Tomatoes", one of the filtering options for Crops could be "Filter by Cultivar: Heirloom" (I don't know if that is a correct example, but I hope you get the point!)

Each Crop page should list all of the different names it goes by, as well as all of the different groups it belongs to.

MB

Mike Beggs October 8th, 2014 14:06

@roryaronson I think the hierarchy you propose makes sense. There will likely be several situations where a particular term, such as "heirloom" could be considered as a different category type from different perspectives. I suppose then an administrator gets to make the call under what level it falls and then rely on cross-referencing and keywords, etc. to be sure it can be found, filtered, and sorted.
A thought I had about "Each Crop page should list all of the different names it goes by, as well as all of the different groups it belongs to" is that for some crops, that list might get very long and take up a lot of space. I think either a popup windows or a link to an "aliases" page where all the different names can be listed and a tree-like diagram or outline could show the different groups, might be good. A few of the more common names or most helpful groups ( limited to maybe the top 3 or 5) could be listed on the Crop page with the rest being found one-click away.

Rory Aronson

Rory Aronson October 8th, 2014 15:13

@mikebeggs, yes sounds reasonable that the actual implementation/design should be more elegant than simply listing them all. For instance, one likely does not care to see the same Crop name in 100 other languages, unless they specifically click to see it!

Ryan

Ryan October 9th, 2014 05:27

Here's the naming information Wikipedia carries. Not exactly sure how we'd handle using these as filters down in search results, but we could definitely have results pages for each species cultivar etc.

For the question at hand, I'm still pretty confused as to what we want as filters. I've made a basic Google Doc in the folder listing sorts/filters that come to mind (try to underline what should definitely be in the MVP). Please check it out and fill and glaring holes I overlooked :P