|
You can now log into FarmHack.net with your Google or Facebook account |
R.J. Steinert |
Wednesday, March 20, 2013 - 6:18pm |
|
You can now log into FarmHack.net with your Google or Facebook account |
R.J. Steinert |
Wednesday, March 20, 2013 - 6:11pm |
|
Organization Profile wireframe from Dorn. RJ's quick prototype. |
R.J. Steinert |
Sunday, February 17, 2013 - 4:44pm |
|
Feature: Ability to mark Topic as a "Call To Action" |
R.J. Steinert |
Monday, February 11, 2013 - 4:20pm |
|
Full Text Search enabled |
R.J. Steinert |
Monday, February 4, 2013 - 2:10pm |
|
Give organizations their own page on Farm Hack |
R.J. Steinert |
Monday, February 4, 2013 - 10:52am |
|
Anyone planning on going to the Feb 16/17 NOFA VT Winter Conference? |
R.J. Steinert |
Thursday, January 31, 2013 - 6:11pm |
|
Ideas for School Garden Curriculum in Ghana? |
R.J. Steinert |
Wednesday, January 2, 2013 - 1:30pm |
|
Types of Email subscriptions that are both powerful and simple |
R.J. Steinert |
Saturday, December 29, 2012 - 4:47pm |
|
The Farm Hack Tools App, a prototype |
R.J. Steinert |
Saturday, December 22, 2012 - 4:29pm |
Could you add the above syntax to the Quick Tips?
Good idea.
Any objection to using html color in forum posts?
Nope. No objections. I think the general consensus on the web is that color can be useful if used in a predictable way. It's when people start using color differently that it makes it hard to understand.
I can also add some code to this website to make sure that every time pound signs are used for sectioning content that they get a specific color of our choosing.
One advantage of using "#" to mark off headings is you can indicate subheadings using "##" and even deeper using "###".
This:
# 1 - Section 1 Some text. ## 1.1 - Subsection 1 Some text. ## 1.2 - Subsection 2 Some text. ### 1.2.1 - Sub-Subsection 1 Some text. ### 1.2.2 - Sub-Subsection 2 # 2 - Section 2 Some text. ## 2.1 - Subsection 1 And on and on....
Turns into this:
1 - Section 1Some text.
1.1 - Subsection 1
Some text.
1.2 - Subsection 2
Some text.
1.2.1 - Sub-Subsection 1
Some text.
1.2.2 - Sub-Subsection 2
2 - Section 2Some text.
2.1 - Subsection 1
And on and on....
I think so. I'll look into it.
I think over here works well.
I'm no lawyer, but I know that Linux got in trouble back in the day for not trademarking their brand name "Linux". Some smart ass decided to trademark Linux and then threaten suing every company with a product with the word Linux it its name (magazines, linux distributions, etc.).
So looking at the limited documentation that was originally added:
Perhaps by "Food Fractal is copyright Holocene systems, LLC" the person who added this tool meant trademarked. If that is the case and the design is released under AGPL then I do think it's a good fit for a Tool page.
Check out the new Tool "Tool wiki template" http://www.farmhack.net/tools/tool-wiki-template
I bet Loius would be interested. http://www.farmhack.net/users/louis
I'll email him about this thread.
I haven't decided what I think yet but these two statements stand out to me.
From Louis...
From Dan...
Since none of us are patent lawyers (yet :-P), feeling it out is perhaps the best we can do it seems. It will be interesting to see how this plays out in other communities. For now, as for dropping CC-BY-SA for CERN Open Hardware License 1.1 across the board, perhaps we don't have to do that and can instead state "CERN Open Hardware License 1.1" or "Public Domain" on the Wiki pages where we want it to apply. I could be wrong though and it's worth finding someone with enough knowledge on this topic to try and poke some holes in that idea.
Hi David, I've thought about doing that even for the Tool Wikis themselves. I think what we might be going for is having the tool's profile, the tool's wiki, and the forum all "below the fold". Below the fold is a term used to describe everything you see before you have to scroll down. So everything "above the fold" is the dream, but your suggestion is a good place to start until we have time to do a serious redesign of the tool pages. -RJ
Hi Eric, Thanks for reaching out! We're definitely interested in some remote collaboration. I know that Louis is busy designing and building the first prototype so when he settles on the parts list and gets the code up on GitHub then we'll be working on the documentation for assembling Fido. That would be a great place for you to jump in and we can iterate from there. You can stay in the loop by subscribing to the forum and wiki for this tool. I'm looking forward to working with you!
RJ
A now related discussion is the topic on Tool Wiki Template. I just suggested we have a "Problem" header.
Given the conversation on the importance of what problem a Tool is trying to solve, perhaps we also have a "Problem" heading. I started a "Tool Wiki Template" wiki that we can start building out as an example.
The Tool Wiki Template wiki can also include formatting examples. Something like making a table for the bill of materials first comes to mind.
Also check out the Tool Wiki Template conversation that we're having in the Farm Hack Website Ideas Forum.
Amen to that. I'll keep my eyes open for a good image/document uploader.
The "Stream of Wiki Edits" on the "Farm Hack River of Activity" page gives us a place to track activity on the wiki pages even if they are not linked to from a Tool, Forum topic, or comment.
See http://farmhack.net/activity
How do folks feel about implementing David's suggestion of parameters in the same fashion that I implemented the Tool Type parameter?
Given Ben's point of
I added a quick feature so we now have faceted search on the Tools page by one parameter, the Tool Type parameter.
What does everyone think? It could probably use some styling and more parameters but I think having it as-is is better than not having it right now.
Good catch Dorn. I actually just made a whole bunch of improvements to the Tool form. Go ahead and update the Annie's All In One and let me know if it the changes make sense to you.
Correction: Preview comment is working, preview forum post is not so I disabled it.
If you want any advice/help documenting please feel free to ask. I'm volunteering time to help get this website working. You can contact me directly on my contact form http://farmhack.net/user/8/contact.
I take from that suggestion that one should first ask, "What is the impact that I would like to improve and in what ways would I like to see that impact improve? This point carries a lot of weight to me because I have first hand experience with the fall out in situations where folks define the software before they've fully defined the problem.
As the current Farm Hack website stands, we're trying to tackle a knowledge vs. wisdom issue. The Internet is a very effective place to make knowledge available but there is no internal mechanism on the Internet itself that takes all that knowledge and turns it into wisdom. I'm hoping that the functionality of this website will help people aggregate knowledge in each Tool's Forum and then refine that knowledge into wisdom on each Tool's Wiki. But alas, the labels this method uses suggests that we start with a tool before we have the problem defined. Perhaps we should start with Problem Wikis that have associated Problem Forums...
Talking with Dorn Cox in the past few months and after a presentation by Ben Falk on Resilient Food Systems at the NOFAVT Winter conference, my eyes have been opened to the importance of healthy soil. Falk quoted someone in his presentation to the effect of, "Society has always been a struggle to keep its nutrients on the land and out of the sea."
An online Fido configuration service, that's a really great idea. Building the online form to generate the proper string is the easy part (1 hour), integrating with an SMS gateway so the website can send text messages is the tricky part. The easiest route to send a text message using an SMS gateway is to use a "web service" like Twilio that provides one easy to integrate with service point that works no matter what cellphone carrier the number you are sending to may be using. The downside here is that a service like Twilio costs a penny per text message while you can send text messages for free if you integrate with each carrier individually. I'm not going to worry about costs though because having so many people using a online Fido configuration service to the point it's costing us a noticeable amount of money is a problem we would like to have.
I think it makes sense that the online Fido configuration service generates the string and then gives the option to send the string to your Fido as opposed to just sending it right away. This leaves open the option to text the string yourself which can be seen as a learning experience. We can start by building the online Fido configuration service form as soon as we settle on a messaging protocol and then build the "Text this to your Fido!" option later.
It looks like we've settled on this issue for now. I've found it's best practice to summarize the status of an issue in it's original post when it has reached a good stopping point. @Louis You could write something like...
ConclusionWe've decided to drop the dependency on a keypad and lcd screen in favor of interfacing with Fido using a separate cellphone. See the comment that inspired this and check out our new conversation Program your Fido by sending it text messages .
@Louis I apologize if you proposed this before and I forgot. I figured I'd write it down here while I was thinking about it.
Hehe :) That's fun.
Aaaaah buttons nice.
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.
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
To set the upper bounds
To set the lower bounds
To see the current temperature
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.
Come to think of it, I think my first priority will be to set up a redirect from youngfarmers.org/forum to farmhack.net/forums.
Good catch. I didn't even know that "IN THE FORUM" was as link. I'll look into fixing that.
The Adafruit RGB LCD Shield Kit is pretty cool in that it reduces your pins needed on the microcontroller to just 2 (6 are required on the LCD unit right?). As a last resort, what do you think of dropping the LCD display and incorporating an RGB LED like the Public Labs folk did with the Thermal Flashlight? In the interrupt routine a blinking green light would indicate it's ready for input of the phone number, a blinking red light would indicate it's ready for input for the upper bound, and a blinking blue light would indicate it's ready for input for the lower bound. When the unit is told to display the temperature, it would take the upper and lower bounds and display it somewhere between red-green-blue depending on where the current reading is in the upper and lower bounds. Am I missing anything else the LCD could be used for? The advantage here is that one RGB LED ($1.95 at the high end) is cheaper than an LCD screen but the drawback is user friendliness. My "advantage" is definitely in the spirit of "How cheap can we get this?" but the cost/benefit analysis may not hold up on this suggestion.
For those who aren't sure what a PTO is (I wasn't at first), it's a Power Take-Off.