openfarmcc / openfarm Goto Github PK

For whatever reason your landing page is rendering all weird in Firefox.

Can we get a group of active devs together on hipchat, skype, irc or something to bounce questions/ideas/current tasks around?

I'm seeing all sorts of icons on a bunch of pages. Can we put all of those together in a font so that they're easily re-usable, easily accessible, etc?

IcoMoon does this as a service for free, as long as we have vector graphics to put it up.

As we head into the realm of a constantly updating project, we probably need a blog and email list with regular (bi-weekly?) updates about the project and where it's headed. We can use some service like tumblr for a quick blog, and probably something like mailchimp (first 2000 emails free per week), or sendy when we get beyond that.

Being in regular touch beyond kickstarter is important I reckon, and we need a way to contact people who aren't in the mood to pay for kickstarter.

[enhancement] Just saw the new OpenFarm mockups on kickstarter and wold like to get involved.

The new UI looks fairly sophisticated. I suggest splitting OpenFarm into a client side & server side application - or at minimum, use a js framework instead of rails views. Anyone open to Angularjs?

Would you guys consider using a client-side framework like angular js instead of using server generated pages? Yeoman (yo, bower, grunt) is a nice front-end tool suite that could help stream line the process.

Screenshot: http://imgur.com/zhzsumC

When an alert is active, it's surrounded by white.

Hello! I was wondering if there had been a discussion of architecture yet? I saw that the repo was setup with PHP. I personally don't know PHP, so I had imagined using Rails or a JS MV* sort of framework for myself and to help keep things in-line with the other side of the project slash make it approachable to everyone on the project.

As I said, I don't know PHP so I could be missing out on its advantages, but I think Rails would especially lend itself well to this project, especially to get things up as quickly as possible. Just my two ¢ents!

I was installing Devise this morning and noticed we don't have an alert / notice section on our layout. I put one in with some

tags for now (devise requires it), but we will need to style it at some point. Leaving this issue here as a reminder.

I saw USDA hardiness and AHS heat zones mentioned in the Guide wireframe so I thought I'd bring it up for discussion.

USDA hardiness zones are a mostly U.S. specific metric (some other systems are in use to model climate factors in other countries like Australia and Canada) based on minimum winter temperatures and give a very approximate indication of the ability for a plant to survive in a given climate. It does not indicate a plant will prosper and because it only measures minimum winter temperatures, locations with similar winter temperatures but different summer temperatures will be given the same hardiness zone. Nonetheless it's a useful indicator when used appropriately especially for perennial plants like fruit trees. For the most part, it's irrelevant for annual crops where summer temperatures are usually the most important metric.

AHS heat zones give the average number of days a particular location experiences temperatures of over 30ºC. It's a proprietary system with, to my experience, almost no practically useful data available. Most flowering plants do not mature any faster over 30ºC, so I'm not sure why this metric exists.

Growing degree days are a cumulative tally of hours of average daily temperatures. They can be used very reliably (and is used in industrial agriculture) to indicate when a crop will flower, when fruit will mature, etc. There is a decent amount of data available for various species and specific varieties commonly grown in industrial agriculture, but not much data available for less common garden crops. It's relevant to growers in both indoor/controlled and outdoor environments.

In short, I think OpenFarm should definitely include USDA hardiness zones where possible, with some way to clearly indicate it's only relevant in regards to minimum temperatures, and absolutely include a growing degree days value where data is available, ideally with a way to educate people on this system and provide them with information on the average growing degree days in their area, since it's mostly unknown to hobby/small gardeners.

Add setup instructions

Getting the project up an running, it is not entirely clear what the purpose is. Does anyone have thoughts on the UI features? Is a CSS framework alright like Bootstrap or Foundation? Any preferences?

I created an analytics account, here is the code that needs to go in every web page we want to track:

I want to start defining the visual style for open farm, as I'm coming across several places where I'm deferring to the Foundation styles, and I'm not sure that's a good thing long run.

Example:

http://style.codeforamerica.org/ (the styles here would just power the entire site).

I've been taking some steps to think about the creating guides steps.

Here's an initial design (bonus - also exploring a visual direction for openfarm).

Here's my reasoning for splitting things into a couple of steps:

Steps 1 & 2 are gathering basic information from the user, stuff we want them to definitely include in a guide.

Step 3 I was seeing similar to how you mentioned seeing it @roryaronson. The box could expand in width, and start looking like the actual guide. I like the idea of consistency there, but that might be something we need to try and actually build, and see how it works in action (this is one of the reasons I want to try VWO). The current edit page is actually a step towards that - pretty WYSIWYG.

I'll explore that a bit and show it here when I'm done with it. I'd love feedback/input on visual style as well - don't consider myself a visual designer at all.

Heya folks, I've just had a look at the Drive, and can't seem to find an over-arching information architecture for the site.

From discussions on this site it looks like people have a fairly strong understanding of how the site will be built, and what the structure would look like, but in the interest of making sure that everyone is on the same page, and making it easy for newbies to jump in, I was wondering if such an IA should be put together, talked about, etc.

I'm happy to put what I understand into a diagram, and see if people agree, but wanted to make sure that something similar didn't already exist.

Hey all, wondering what structure everyone is imagining for the Guide models. As far I understand things so far, Crops have many guides and guides belong to a User. Guides can be grouped via a common crop name (eg. "Tomato") or a specific variety (eg. "Cherry Tomato").

As far as the architecture for the Guide model, how should the data be structured?. Straight up as strings for now? Enums? Tables of values such as soil type?There's a lot of data to store from dates, to hardiness types, to watering amounts.

Forgive me if this discussion has already been had elsewhere and earlier! 🇺🇸

HTML bookmarks: #prerequisites, #timeline, #instructions

No place to communicate with the contributors of this project to prevent overlap of backlog. Also backlog doesn't appear to contain any work ready to be carried out in bite sized chunks..

When you sign up (create user) there might be a good idea to add a option list with different "Soil Types" that the new user can select from. And a link to a guide how to determine ones soil type.

Add a couple of suggestions to the "Preferred Growing Method" to get the new user think in the right direction.

It makes sense to create a series of code style guides for HTML/JS/CSS.

We can make our own, or just steal some from others.

CSS options: http://css-tricks.com/css-style-guides/
JS the Airbnb one is pretty good: https://github.com/airbnb/javascript

These could just be pages on the wiki for people to refer to, and could evolve as the codeset progresses.

It would also be a good place to define styles on top of the Foundation presets.

Thoughts?

I thought I'd share what I learned while researching naming conventions for Practical Plants.

A binomial is composed of the genus name and species epithet: e.g. Brassica oleracea (binomials should always appear in a contrasting style to the surrounding text, most commonly italics). This is not enough information to refer to the majority of cultivated plants, since there are almost always numerous varieties, sometimes representing very different plants with entirely different needs. For example, the single Brassica oleracea species represents the thousands of cultivars of Cabbages, Broccolis, Kales, Coliflowers, Brussel Sprouts and so on. Advice and data for one species can be entirely irrelevant for another.

There are several systems of sub-species categorization used for plants, used often interchangably, and equally often incorrectly. Browsing plant data online you'll often see epithets like var. convar. ssp. etc.

In my research I found the following is generally seen as 'correct': use var. when referring to a naturally occurring species variety. There are some cases when one should use ssp. (subspecies) for some subtle botanical distinction which I don't remember. Most relevant for Open Farm is ICNCP which should be used when referring to a registered cultivated variety. It also provides a means to refer to cultivars which share characteristics as a group, which is crucial.

E.g. Cabbages are a member of the Capitata group Brassica oleracea Capitata Group, and Brocolli are grouped as Italica Brassica oleracea Italica Group.

and one may refer to one of my favourite winter cabbages, January King by any of the following:

• Brassica oleracea 'January King'
• Brassica oleracea (Capitata Group) 'January King'
• Cabbage 'January King'

The cultivar name must always be enclosed in single quotes, and capitalised. The group must be enclosed in brackets if present, but it is not required, and should be capitalised. The last example is informal and useless for categorization.

On the opposite end of the scale, it is not uncommon for a plant common name to actually refer to an entire genus of plants made up of many very similar species with the same requirements and care conditions, and so the binomial is actually too specific.

Accordingly, I recommend a subset of these properties exist in order to categorize which plant a guide belongs, the only mandatory entry being taxonomic rank and genus:

• taxonomic rank (genus, species, subspecies, variety, cultivar group, cultivar)
• genus
• species
• cultivar group (optional even when cultivar name is set)
• cultivar name
• subspecies
• variety

Since common names are so variable, not just from language to language but between regions, I think these are best represented as their own document rather than attached to a guide. That way a user can search by the common name they know and find all relevant guides. It would also allow the guide author to simply enter the common name they know and, if it has already been entered by someone, the remaining taxonomic information could be auto-filled.

The search box at http://openfarm.cc/ cuts off the characters of the font.

Using Firefox 31.0

Here's a screenshot where I have typed "corn":

Nothing at http://OpenFarm.cc domain. Where is this deployed?

I bet Jquery got messed up in the asset pipeline. Will investigate when I finish what I'm working on right now. If someone else wants to investigate this one, go nuts.

For the following elements:

• Guide rating: "4.1 out of 5 stars from 37 reviews"
• Compatibility elements: "60% match because ____"
• Timeline vertical bar for today: "Today is Feb 21"
• Timeline horizontal bars of time: "95 days"
• Timeline vertical bars for major events such as last Spring frost: "Estimated last Spring frost: Mar 14"
• Growing Instructions unit conversions
• Growing instructions bar graph value: "Water 14 Liters/Plant, every day"

Sections for first release are: Overview, Prerequisites, Timeline, and Growing Instructions

When opening the landing screen in Ubuntu, we get "deprecated" warnings. Different ones in Firefox and in Chromium.

In Firefox:
Use of getPreventDefault() is deprecated. Use defaultPrevented instead.

In Chromium:
event.returnValue is deprecated. Please use the standard event.preventDefault() instead.

Here's a screenshot of my 3 monitors (didn't feel like cropping the screenshot :) ):
http://i.imgur.com/CwZ75a1.jpg

Middle screen is Firefox, right screen is Chromium.

Perhaps we should have an ajax search box that finds crops by ID rather than by name to prevent duplication of records in guides.

NOTE: It looks like simon already started this feature.

Do we want to use a frontend framework such as Bootstrap or Foundation? Lots of users may be accessing the site from mobile when at the nursery or in the garden, so a responsive design is imperative.

The Guide page mockup was designed on a 12 column grid, so it could port well to soemthing like Foundation in that regard.

You know a thing or two about color, right @warpling? ;)

Should we have a development branch alongside a proper release cycle?

I say this because it makes more sense to focus on specific parts of the application and release them one by one through the master, rather than just keeping the current website on the same branch as the development is going.

It might also make sense to instate semantic versioning for any API we decide to build?

The black one would look nice below the header: https://github.com/blog/273-github-ribbons

Background remains gray if user is not logged in or has not given us data to compare to

Add license. Any preferences?