R.J. Steinert

Hosting the file on Archive.org is a good idea. They'll convert it into many different formats and give us a reader that we can embed on a Farm Hack wiki page. I've actually been building things with their API and communicating directly with one of their developers lately so building some kind of Farm Hack / Archive.org integration is in the cards. I'll keep thinking about it. I'm also thinking about ways we might be able to automate a conversion of this book into Markdown format. In Markdown format we could host in on GitHub and/or the Farm Hack wiki pages. For an example of markdown being used on GitHub, check out this README.md file. Because I gave the extension .md, GitHub converts the Markdown formatted text into HTML. You can click on Raw to see the Markdown source of the HTML.

Let's definitely get that document on A.o for starters. Then, if I can't figure out how to convert one of the formats that A.o converts to, I'll figure out an efficient manual workflow that we can then divvy up to some volunteers.

Just checked it out. It looks like that tool is sandboxed. Uncheck the sandbox checkbox if it should show up in the public tool list.

Agreed. I've sort of been holding off on this because working with images on wikis has always been tricky, I want to find something that everyone can use AND doesn't require a ton of development work. Trying to "fix" wikis is perhaps the wrong way to go about it. Perhaps we should give users another option other than wiki, an another option like using a Google Document. I'll talk more about this later, but for now, I think it's worth adding an existing solution for "inline images" in wikis ASAP.

Hi jbd. Thanks for the heads up, the site is actually supposed to perform as you assumed it would. For now, any Tool's Wiki can be edited as long as you are logged in, edit the Tool Template wiki, copy the text, and then paste it into your tool's wiki.

Haha, woops, I thought I had missed the Ithaca event but apparently it has not happened yet. Perhaps I will be there for this design charrette after all. :)

Bravo to Jeff for brainstorming this. I've taken a stab at his 3 questions. But before I do, I just wanted to paraphrase what he wrote to make sure we're all on the same page.

Problem: Managing information as a farmer is a big job and having the right info at the right time is difficult.

Solution: We could develop a tool that provides convenient, affordable and up-to-date access to a variety of information and expertise, when and where you needed it, presented in a ready to use format supporting informed decision making and innovation throughout the day or season, year after year.

What kinds of information and communication are most helpful? Financial, business, crop, pest, customer communications...

To get data from many sources and make sense of that data, two factors need to be considered when evaluating a potential data source.

1. data availability - The Internet has done a great job of making a lot of data available. If the data is on the Internet, it's generally considered to have high availability.
2. data accessibility - Accessibility describes how usable a piece of data data for the sake of making sense of it. For example, a table of data in a PDF document is not easily usable by a computer program where as a table of data in a comma delimited text document is very easily usable by a computer program that may be used to visualize the data for the end user.

Here are three sets of data that I think we could focus on.

Opening existing data sets (The Open Data Movement)

The Open Data movement, which the Obama administration has championed from a federal level (http://sunlightfoundation.com/blog/2012/07/06/open-data-creates-accountability/) while it still has a strong DIY movement at events like International Open Data Day, seeks to solve help solve these issues. The hope is that any data that has been collected for the pulic will be published as a "consumable" data format, AKA in a format that computer programmers like myself can easily import into any program I might be writing. With a consumable data format of say, listings of available farming land for sale, I could create an HTML map widget that you could copy and paste onto your own HTML homepage/dashboard that would pull the land data from that consumable data source's feed.

Opening real time data

So far I've talked about making existing data sets open, we are now entering a new realm of possibility with the emerging "Internet of Things". This is a concept where the objects around us are collecting data for us and saving that data on the Internet in a consumable data format. The Fido project (http://www.farmhack.net/tools/fido-greenhouse-monitoring-text-message-alerts) that Louis Thiery is still working on is one example of a device that could be used to publish your greenhouse data to an Internet service like CoSM.org which would then give you an HTML graph widget that you could copy and paste onto your own HTML homepage/dashboard that would pull the sensor data from your Fido's data feed. These are exciting times!

Opening up the crowd

The third set of data to focus on is data that we generate by collaborating with each other. Jeff's description of "knowledge ecosystem" is a decent description of what we do in open source communities such as Farm Hack. I think it's important to also point out the economic incentive of participating in this collabaritive process, the incentive being that the value you give up for the community (your time) is a good investment because the advice you get back is even more valuable than your investment. I'm simplifying the value of Open Source immensely here, if you are interested in reading more about the economics of it check out the essay that changed everything in the 90s, The Cathedral and the Bazaar (http://www.catb.org/esr/writings/homesteading/).

Where do (or would) you access that information (e.g. field, vehicle, home, market)?

Ideally.. everywhere! Up until recently the idea of a Web App has been tied to devices only when they have an Internet connection. If your Internet connection goes down in the field, you lose access to your Web App. In the example of doing documentation on FarmHack.net, it's perhaps much more convenient for a farmer to document a problem with a tool in the field while they are actually experiencing that problem. If they do not have a reliable Internet connection on their smart phone while out in the field, then they lose that opportunity and others miss out on hearing about a problem that they also might be suffering from. The good news is that recent advances in browsers now make it possible to take a Web App offline if that Web App takes advantage of the new browser features. Did you know you can use Google Docs and Gmail offline? Check out my demonstration http://youtu.be/bB515UsfnFA That's all thanks to the fancy new data storage features in your web browser. Next year the company that I'm CTO for will be launching an Offline Web App for sharing educational resources in 20 schools in Ghana (http://www.ole.org/ole-ghana-receives-usaid-“all-children-reading”-grant-award). I'm hoping to take what I learn from developing and deploying that Web App to the Farm Hack Web App someday.

When do you need it -do you need answers at a moments notice, in real time, or months in advance as you make plans for the season ahead?

This goes back to the data accessibility issue. Just because the data is available does not mean you can find it or make sense of it easily. I like this idea of giving farmers their own dashboard that they can use to arrange HTML widgets to their liking. Having a dense display of information that a person tailors to their own interest has obvious benefits.

I would be interested to hear more about the outcome of this design charette. I'm imaging the following was discussed:

1. What are some examples of useful widgets for farmers? Any low hanging fruit?
2. Where can we implement a dashboard feature so people can start collecting these widgets?

My own RSS Reader (http://reader.rjsteinert.com) is a similar to the Dashboard concept we are talking about except that each widget is just consuming an RSS feed from a third party and does not have HTML widgets from other third parties. We could enable dashboards for users on FarmHack.net, we could also build a seperate Web App just for Farmer Dashboards. I'm open to both options. I could probably prototype this in a weekend if anyone wants to get together for a Hackathon. We might be able to roll it into a larger event for programmers looking to build apps for farmers...

Hi Dorn, I just added an insert button to images attached to wikis. It's definitely not a great solution but it's a step in the right direction. That eventual direction is being able to edit the wiki directly on the page without having to know markdown syntax (example, click on any of the content, it's editable: http://aloha-editor.org/demos/aloha-world-example/) . I already have a working copy of the Farm Hack site on my computer but it still needs more polish (it's too easy for people to make an edit and not REALIZE it :P) and it doesn't have support for adding images.

+1

Inspired by the discussions in this group, I created a presentation on how to use forums and wikis to collaboratively design solutions. It's still in draft form and any suggestions would be much appreciated :).

Agreed. At the moment we can attach a forum and wiki to Tool entities but my long term development goal is to be able to attach forum and wikis to other types of entities. Above you mention two types of possible entities, business document and concepts. The reason why business documents don't work well as tools is because they don't fit the meta data model that we are using with Tools, ie. the stages of a business document does not necessarily fit Concept->Prototype->DIY->Commercial. Perhaps the Tool entity would be better defined as the "Physical Tool" entity.

On this site, right now, we can easily define new entity types and add meta data models. The trick is upon creating an instance of an entity type, also create an associated wiki/forum and attach them visually to the entity's page. We also need to be able to define on a per entity type basis, when a forum is created, where it should be placed in the Forum structure. It's a simple concept and I can reuse much of the work done on the Tool entity type but it's still 3 or 4 days of work. The nice thing about it is that as soon as that work is done then we can go wild with new entity types knowing they'll have attached forums and wikis.