Direction for search results

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?

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.

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.

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

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

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

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

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!

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

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

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!

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

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

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…

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

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.

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?

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.

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

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

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.

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.

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

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

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