I’m just getting started on a new project nicknamed Kestrel.
The basic idea a simple and user-centered web app that helps facilitate ordering, billing and member management for CSA’s. Things are JUST getting started and I am soliciting help in doing some feasibility research as well as a basic evaluation of existing CSA management applications.
A CSA, (for Community Supported Agriculture) is a way for the food buying public to create a relationship with a farm and to receive a weekly basket of produce. By making a financial commitment to a farm, people become “members” (or “shareholders,” or “subscribers”) of the CSA. Local Harvest
So far were in stage zero: Over the holidays I was brainstorming with some of my agri-geek friends in North Carolina, notably tes thraves. (I like to say that tes is to poverty + agriculture issues as Jay-Z is to hip-hop — a badass producer who just makes things happen.) :) So far there’s been a lot of excitement about it from both consumers and producers.
- Stage zero is lots of talk over drinks around the New Year’s bonfire, basically. Check.
- Stage one is research about what real CSA’s need.
- Stage two is getting a few CSA’s to pilot test a first iteration for a season.
- The rest is iterating and improving based on real feedback. This is the hard part. And the fun part.
The only real spec so far is an application that is incredibly simple and driven purely by a real understanding of the users’ needs.
There is no timeframe yet. I imagine things could take a year or so; nobody’s getting paid by Kestrel.
Codewise, I’ve done some simple scaffolding of the application, but really I think the requirements for this type of thing are simple — the codebase is not really the issue. Just a few forms, login/out and billing. So I’m not looking for help from coders as much as I am trying to garner some interest from A) the users of the application, farmers and consumers and B) people with experience in user-centered application design and user testing.
The goal is a management tool that would simplify the process of ordering food from your CSA, but also serve as an educational model of CSA best practices.
Right now I’m thinking a hosted solution, almost certainly built in Rails. And of course completely Open and Free.
The basic use case comes from my mom : she doesn’t like very much lettuce in her box. Last year she got six heads of lettuce at a time. So ideally mom could just login and set her preference, pay her bill, update her address, give notice that she’s out of town for a month, etc. The farmer then knows exactly how many heads of lettuce to harvest, and can keep the rest in the ground until going to the market on Saturday.
It’s not a new idea, I know. There are several in San Francisco. I haven’t seen them yet. But I am sure that they’re not as good as they can be and I want to put the users at the front of developing a new open source solution.
CSA’s are great for environmental, social and economic reasons. And they’re really just a lot of freaking fun. So if you are a consumer or producer with opinions about what you’d like to see in this type of software, let me know in the comments or unthinkingly-at-gmail.com.
There has been a lot of excitement recently around a couple of developments in touch screen interfaces: First there was the insane presentation at TED 2006. Secondly, of course, the iPhone made everyone all hot in the pants for it’s touchable goodness.
In Malawi, the NGO Baobab Health Partnership … adapted Linux to $100 touchscreen Internet appliances, then wrote a program for Opera to run in full-screen kiosk mode. The resulting terminal can easily manage the nation’s health data and is scalable wherever a web connection can be made.J. Goodman at Vestal
Fundamentally I think that touch is intimate and intuitive, and clearly touchable interfaces have incredible potential, especially for the folks that haven’t been brow-beaten into adapting to 20th-century conventions of computer interfaces like the QWERTY keyboard.
(i.e., the billions of people that will be introduced to “desktop” computing the next decade. See the OLPC, just launched for reals in Uruguay.)
So I’m excited about a new project at work that involves designing a web application for use with a touch screen interface. When I first heard about it from the client I was coffee-though-the-nose excited because I have been infatuated by a recent project I read about on Vestal: Malawi, Linux, & The Fight Against HIV. I knew immediately that I was going to rip off the idea. (In the best open source sense, of course.)
Unfortunately the iOpener touchscreen used in the project is no longer for sale (it had a lovely $100-$200 price tag b/c it came with some money-making software — there’s a funny story about the linux hack), so I was hoping someone might have some idea about how to implement this as cheaply as possible.
A few criteria:
- As open-source as possible
- Durable
- Replicable
- Low Power
- Low CPU resources (The machine will be cheap, with flash memory, prob.)
- Beautiful (in a Platonic way )
Basically I want to avoid wire splicing and flaky homegrown drivers in favor of something that is replicable and extremely flexible. I want to be able to develop a web application with an appropriate UI and let it rip. (Which will be greatly facilitated by the work of the Baobab programmers’ “touchscreen toolkit“). This might not be easy given the limitations of cheap machines.
So far I’ve got anEboxPC in the office (a nice, fanless machine with CF and VESA mounts for the back of the monitor) with some form of embedded Linux (we’ve built a tiny Linux distro for our rural wireless network that might be usable if we can get the drivers to work with the touch screen). Looks like we can get screens for about $100 and then we’ll have to put a touch screen on top. Regardless, this is still in the brainstorming phase, so that’s all likely to go out the window.
Anyway, what good is a touch screen like this?
Well, combined with the right software, I think you can really leverage usability to do a hell of a lot:
- Make a huge impact in developing world healthcare like Baobab has done.
- Collect data easily from a kiosk at a disaster area.
- Setup a database-driven check-in desk at your next nonprofit conference.
- Collect survey data remotely (anywhere in reach of the net).
- Setup a small store without an incredibly expensive, proprietary POS system.
I think there are lots of possibilities given that the interface could just be so much more usable. Just looking into it briefly I found an open source POS system for use in cooperative markets. Brilliant. This is software that could really benefit from an inexpensive stable touchscreen implementation.
Does anyone have any experience or ideas?
I’ll be posting my findings here, along with the software design considerations that I run into.
I make websites, and I manage a few web servers. Making sure that pages load quickly is a pretty fundamental part of my job.
Lately I have been thinking a lot about how much more important this concern is for people who are in low-bandwidth environments (my house in rural NC), and especially in what you might call “ultra-low bandwith” places, where issues like cost or a lack of reliable power compound the issue by an order of magnitudes.
I am thinking about how web developers can become more invested in the ultra-low-bandwidth user experience.
When it comes to bandwidth, international bloggers are talking about something totally different compared the “optimization” issues that web developers are fussing over.
For example, the Yahoo User Experience blog has just posted a really interesting analysis of page load time optimization techniques. But it occurs to me that the audience that they are writing for is largely the elite of the internet — they are trying to save a few tenths of a second. They are tuning a product, not really thinking about ultra-low-bandwidth situations. Which is fine, that’s why they exist I guess.
I mean, It’s web development 101 that you need to make you pages small. Load time is the number one element in usability. Even with that fancy DSL line, you appreciate pages that function in 1/10ths of a second instead of 2 or 3 seconds. I’ll take it. And I am glad that they Yahoo folks are doing this great research.
For example, the a November post made me think about my techniques a bit differently — they pointed out that having a low-weight page is nice, but the speed experience is much more greatly affected by the number of elements on the page. An understanding of latency vs. bandwith makes this point even clearer, once you consider it.
Today they published an even more interesting look at the browser, focusing on the fact that browser caching appears to only be utilized in about 20% of browsers! As a developer there is no way to force a user’s browser to cache data, which could easily reduce page load times by about 3x, depending on the content being served, mostly because of the point above: you save the most time by reducing the number of http requests altogether.
For me this immediately made me think that this is a technique that should be built into any browser that gets used in a low-bandwidth environment … but I bet that there are innumerable browsers installed in that do not take advantage of this feature, even where connections are extremely slow. Hopefully the browsers that ship with the $100 laptop (and its kind) with be caching as much as possible. …
There are very few web design books that have any currency after about 2 years. Very few.
And half of these are notable because their very outdatedness is instructive. The rare remaining 50%
of this minority of web design books is the “on-every-designer’s-shelf” collection. Among them is certainly Steve Krugman’s “Don’t Make Me Think: A Common Sense Approach to Web Usability.”
It is, he writes, a book for “people in the trenches — the designers, the developers, the site producers, the project managers, the marketing people, … and the one man band people who are doing it themselves.”
The rule, “don’t make me think” is an obvious principle, but it can be translated many ways.
One great translation is the user’s maxim ‘the more difficult it is to use, the less I will use it.” You must design for users, not yourself. Always second guess your new aesthetic vision, and, if at all possible, conduct a usability test with real users.
Another reformulation of the main theme is “no one cares as much about your site as you do.” And really, it *doesn’t matter* to users if they understand everything about your site. (This is difficult for many developers, who are intensely interested in how online stuff works.) Users want to know how to use it to do specific tasks. This is the age-old (ie 1990s) principle of “satisficing” — being satisfied and sacrificing. If you expect more than 10% of your web page to be read by a single user, you have high expectations.
The corollary to this principle is that, if a user can make your site work for them, they will stick with it. Secondly, you must respect a counterintuitive fact: it is _difficult_ to make a site simple and _easy_ fill it with confusing design. I am fond of saying that web design is a process of subtraction. There are a number of helpful hints for building subtrative process into your design method:
- Create a clear hierarchy from the beginning.
- Use conventions.
- Spend a lot of time on the navigation. Harness the power of links by focusing your design energy on that navigation bar.
- Remove words: Take out that useless banter.
Steps designed to ensure hierarchy, conventionality, easy navigation and conciseness are the basic rules of content development for the web.This is what it means to write for the web.
Krug also poses the wonderful “Trunk Test of Web Usability”:
1. Print your page.
2. Hold it at arms length and circle:
a. The site name
b. The sitewide search box
c. The sitewide navigation
d. The page name
Does your site pass the test? Can you easily identify the most usable, important parts of your website? Yes, this is common sense, but, again you have to be sure: can your users really use your site easily?
There is also great chapter devoted to designing your home page, the most important page of your site. In brief, here are a few things that your colleagues (or inner slacker) may offer as excuses to creatign a truly usable site.
There is also great information about working with teams of developers. Namely, stay away from “religious debates,”
in which people are “expressing strongly held personal beliefs about things that can’t be proven.” Contrast, for example, opinions about Macromedia Flash, the web’s animation format. Some people (namely graphic designers and CEO’s) love Flash. Some (namely me) don’t care for it in most situations. Arguments begin. People waste their time going round and round with the religious debate about Flash. The way out of this cycle, Krug explains, is to ask: does this use of Flash in this situation, on this site, with this content and our users work?
Lastly, it must be recognized that Krug always carries to flame for testing: you must test your website, Krug writes. Stop thinking that usability tests cost $50,000. They cost closer to $100, if you have a tape recorder and a computer. Get a few of your potential users and let them tell you what is really happening on your web site.