Most of the gang at Bolt | Peters went to BayCHI tonight, and I was really impressed by a presentation from Yahoo about BOSS (Build your Own Search Service).
Turns out that, once you get beat badly by Google, you start to get really open. Nice.
Basically BOSS (bad name, great tool) means that, with a minimal contingency of programmers, you can get a completely custom search running, and apparently you can even manipulate the rankings algorithm. Currently Yahoo is running it without requiring ads or anything. Exciting.
What a great way for a big conservative company to innovate — just let hackers go to town on your fancy database and algorithms. I can’t wait to see what comes out of it.
I was never super into Alan Cooper (of Inmates are Running the Asylum fame) until I read this hilarious argument with Kent Beck, the godfather of Agile programming. (pssst. don’t click on that flaky wayback machine link. I’ve republished the article here, probably completely illegally, for your convenience. But it’s pretty depressing that this doesn’t exist anywhere except for the zombieweb.)
Here’s a couple of the best bits.
Oh, and it’s all about Agile programming and Interaction Design. If you don’t care about such things then this is all really boring probably.
It might be boring regardless.
When an architect begins to define a building, he or she works very closely with the people who are buying the building to understand what the requirements are, and translate those requirements into a sketch of a solution. Then there’s a lot of give-and-take between the occupants of the building and the architect in coming up with a viable solution. Usually, the architect at the sketch level will know enough not to design something that’s an engineering problem.
And if the architect does detect that there might be problems, he or she will consult with an engineer to make sure that he or she is not painting himself into a corner, technically speaking. At a certain point, the architect and the customer are going to achieve common ground. At that point, the architect turns those sketches into detailed drawings. Now, during the detailed-drawing phase, there’s a lot more intense interaction between the architect and the engineer. The architect, you know, draws a span and calls in the engineer and says, how big a girder do I need to support this span? And there’s a lot of detailed interaction between the two. This is precisely what happens in the world of good interaction design.
I think XP has some really deep, deep tacit assumptions going on, and I think the deepest tacit assumption is that we have a significant organizational problem, but we can’t fix the organization. Essentially, the crap rolls downhill and ends up rolling right into the programmer’s lap. When the product or the program turns out to be unsatisfactory, the fingers point to the programmer. XP is very well-intentioned; it’s the software-development community beginning to say, “Hey, this is not only unfair to us, but it’s not productive as a discipline and we can do a lot better.”
“I applaud that sentiment and I agree with that sentiment, but then XP says, “OK, so, I can’t change the organizational failings, so, I’m going to build my own internal defenses.” I suppose this is probably better than nothing, but I’m interested in changing the way organizations are constructed. I believe that in order to create quality software, you have to change the organization. We can change the organization, and it strikes me that the assumption underlying XP is that the organization’s structure is a given.”
Building software isn’t like slapping a shack together; it’s more like building a 50-story office building or a giant dam.
Beck: I think it’s nothing like those. If you build a skyscraper 50 stories high, you can’t decide at that point, oh, we need another 50 stories and go jack it all up and put in a bigger foundation.
Cooper: That’s precisely my point.
Beck: But in the software world, that’s daily business.
Cooper: That’s pissing money away and leaving scar tissue.
Just a quick open invitation, if you are in San Francisco this weekend:
UPDATE: Changed the time to 4pm.
I’m meeting with designer-researchers Niti Bahn and Dave Tait on Saturday, April 19th, at 6pm 4pm at Atlas Cafe in San Francisco (in the Mission). Come have a beer with us! We’re talking generally about designing and researching technologies for the poorest people in the world (the “bottom of the pyramid“). Africa, Asia, mobile phones, sustainable change, environmental technologies, research methodologies, product design, application development, user experience … lots of stuff.
Niti is a researcher, strategist and international rock star; Dave is an award-winning product designer and researcher based in South Africa. Developing world cell phone geeks, too. Check out this article they co-authored for a feel for what they are into: Design for the Next Billion Customers.
If you’re interested, email me, or just show up!
Oh and, we’re doing some planning for a BarCamp unconference of the same themes this summer. Let me know if you would be interested in attending or supporting an event like that. Probably Late June or July.
Photo by meanestindian via flickr.
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. …