Aaaaah buttons nice.

The 4 directional buttons plus select button allows basic control...

Keypads take up a lot of pins (which one were you thinking about using?), so with buttons on an RGB LCD Shield Kit and some (a lot?) programming, we might be able to drop the keypad altogether. In the interrupt mode the left and right buttons would move across the LCD and the up and down button would change the value of the number.

Anyways, cool ideas but the most important thing right now I think is getting a minimum viable product built whichever way is easiest. We can iterate later to improve things like cost, usability, and ... "buildability". So with that in mind, the reasons I suggest an RGB LED are as follows.
1) The RGB LED helps out with the pin issue.
2) The RGB LED + Keypad combo might be easier to program than the LCD + Keypad combo.

how do they know if they're reprogramming the bounds or the phone number or something else?

Inspired by decades of crappy electronics with one singular red light blinking out a primitive version of Morse code, we could deploy a similar technique with an RGB LED. The directions might go like something as follows.

To set the Phone number

1. Hold # until the LED blinks green.
2. Enter the phone number you would like to be sent text messages.
3. Hold # again and the LED will stop blinking green. Fido will now send you a confirmation text message.

To set the upper bounds

1. Hold * until the LED blinks red.
2. Enter the temperature you would like to be the upper bounds.
3. Hold * again and the LED will stop blinking.

To set the lower bounds

1. Hold 0 until the LED blinks blue.
2. Enter the temperature you would like to be the lower bounds.
3. Hold 0 again and the LED will stop blinking.

To see the current temperature

1. Hold 1 until the LED turns on.
   If you defined your upper bound as 95 degrees and your lower bounds as 75 degrees, you will see corresponding colors across the RGB spectrum for the following temperatures.

Red (95) - Orange (90) - Yellow (85) - Green (80) - Blue (75)

If implementing something like what I've just proposed sounds more difficult than what you had in mind, then don't worry about it. I'm not familiar with programming LCDs and using them in combination with keypads to do input so it's tough for me to estimate which way is more difficult. Maybe we'll come back to this idea at some later date if the cost/benefit of this starts to seem appealing.

Good catch. I didn't even know that "IN THE FORUM" was as link. I'll look into fixing that.

For those who aren't sure what a PTO is (I wasn't at first), it's a Power Take-Off.

So if I am arriving at Farm Hack because I heard it could be a good place to find a solution to a problem on my farm, the default tool organization that I want to see would be tools by category, so I can find tools that are relevant to my farm or my problem (fruit growing tools aren't much use if I'm a dairy farmer, etc.).

I agree. It's also in the interest of Tool developers that the maximum amount of interested eyeballs find their tools quickly. According to Raymond's version of Linus's Law, "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone." So if we focus on building the search tools for Farm Hackers like myself who are interested in seeing where the action is, then a whole bunch of potential contributors might not be seeing what they are looking for. I think metrics like "# of wiki edits" and "# of forum posts" for a Tool are not first priority but second priority. After the user has somehow generated a list of results they are interested in, the participation metrics let the user know which ones are healthy.

At the moment though and probably for the next few months, I think most people visiting the Tools section will not find anything necessarily useful to them. I think it's important to prove to those folks that if they have a Tool idea and make the effort to post it, that there will be an active community ready to jump in. So for now I'm kind of happy just having the current sort mechanism of "Last Tool Wiki Update" and perhaps when we do get more participation metrics on the Tools page we sort by one of those. Again, this is my thinking for a short term strategy while we are bootstrapping this community. I could be convinced otherwise, prioritizing long term is not that crazy of an idea :P.

In response to

...it would be helpful that the first few tools people see are well documented with a lot of activity around them...

Check out my comment in the Maintainer discussion.

[It looks like a good way to start might just be a loose "Volunteer as a maintainer" function on each Tool page that allows users to say who they are and how they plan on contributing. This can be accomplished by just pencilling yourself onto the Tool's Wiki page but it could be massively helpful when sorting Tools to be able to have that extra metadata that shows where people have volunteered to answer questions and where no one has.](http://www.farmhack.net/comment/102#comment-102)

I also just added a "Last Tool Wiki Update" column on the Tools page. Now the Tool with the most recently edited documentation floats to the top. That is at least some kind of indication of activity. Another metric we could publish there might be "# of Tool's Wiki Updates" and "# of Tool's Forum topics". I started with what we have because that was a quick fix. The other two metrics will require an hour or so of coding.

Done, done, and done :).

I think that's a great idea Dorn. Using the same Wiki-Forum format we are using for physical tools can also work for our process tools. I vote for moving ahead on this and I want to mention two things to consider as we move ahead.

Before getting into the two considerations for this, a quick clarification on the functionality behind Tools. The "Tool" Entity, the thing with metadata like "Stage" and "Type", is the glue that holds together the relationship between a Forum and a Wiki page. In addition to Tool's holding metadata on the Tool and relationships to a Forum and Wiki, there is code I wrote to display all three things on a single page if you go to any one of those three things. Note that we could create a Forum and a Wiki page separately, put a link at the top of each to their counterpart, and the only thing we would be missing out on is the presentation of the Wiki and Forum on the same page.

• A "Best Practices" Wiki page and Forum may not be findable on the Tools list
  Perhaps it would be better suited to be in the General category of the Forum. We could reassign the "Best Practices" Forum fromt the Tools category to the General category.

• Does the data model (metadata like "Stage" and "Type") for our "Tools" concept fit something like this?
  Right now I don't see this as a big deal and it's not necessarily a big deal if we decide otherwise in the future. If down the line we decide that "Best Practices" is not a good fit for the Tool data model, then we delete the "Best Practices" Tool, the Best Practices Forum and Best Practices Wiki page stick around because they are separate entities, and then we create some other alternative to the Tool Entity type that we use to glue the Best Practices Forum and Best Practices Wiki together.

My analysis could be seen as a green light to shoehorn whatever we want into the Tools section right now, because after all, if decide something is not a Tool, we don't lose the Forum and Wiki page when we delete the Tool.

Sweet! I pasted that doc into a wiki page. I encapsulated the pasted text with the HTML "pre" tag to get all of the formatting you did with spaces.

Ok, I found what might be a temporary fix. I turned off the "Convert URLs into links" filter for the "Markdown Syntax and HTML" text format. There might be a way to make the "Markdown" filter and the "Convert URLs into links" filter work harmoniously but for now we'll role without the "Convert URLs into links" filter. We'll look into some WYSIWYG like buttons down the road that will help folks create the necessary markup without needing to remember all of the syntax quirks. For example, there could be a button that you press that then prompts the user for a URL and text and then inserts the proper syntax. It's not true WYSIWYG but this technique makes the learning curve for the syntax easier to climb.

If this is the first time you've heard of WYSIWYG, it's a program that sits inside of a text box on a webpage that makes the text box act like Microsoft Word. Unfortunately it creates nightmares when used for documentation. Things like diffing (comparing) versions of a Wiki page become incomprehensible, you can never get what's in the WYSIWYG to look like what it actually spits out, and if you ever change the settings on a WYSIWYG you risk breaking every piece of documentation when you go back to edit it. WYSIWYGs do however work really well for writing blog posts that you only (theoretically) edit once and then is set in stone.

WYSIWYG example using the LATEX syntax from Wikipedia's page on WYSIWYGS:

Tim from Oxbow Farms inspired me to bring it back. It's not the most catchy name (any suggestions?) but I think it's pretty useful. I also added a notice when creating a "loose" Wiki page, "You are creating a loose Wiki page that nothing links to. You will need to link to this Wiki page from somewhere after you save it if you want anyone to find it."

That's a legit issue on my radar. Thanks for reporting it.