1) Start with a design
2) Get feedback
3) Improve design
4) Goto Step 2
This would also be fantastic in other places with roadnames. For example, walking direction around a city like D.C. "walk away from the Washington Monument and Towards the Lincoln Memorial."
These are the same principals that people use when designing signage for environments like airports and hospitals. I started a company (that I recently sold out of) whose product was touchscreen kiosk software for wayfinding. We used landmarking (and in the case of Malls, paid landmarking) to help people find their way from A to B.
People often lament that "software engineering does not produce the kind of reliable engineering as does traditional engineer, if bridges were built like applications, nobody could use the bridges because they might fall down". But this misses one the core unique point of software. It's cheaper to tear parts of it out and "renovate" it to make it better than a bridge. The marginal cost of software is almost entirely labor. While a bridge is likely worth far more in materials cost than labor cost (what's the cost of 2 million tons of high-grade steel on the market?). Thus the analogy (and the subsequent lament) don't really work. You are going to keep your F/T staff employed anyways, why not have them rev. the software and make it better?
And as it turns (at least in my experience), greater time spent in software design before implementation rarely leads to a perfect product -- the fact that pretty much every piece of software ever written, no matter how small or utilitarian, reinforces that concept.
But spend a little time designing (which usually results in a little design), with an eye towards future revisions, build a minimal version, solicit user feedback, push feedback into the next iteration of minimal design and repeat ad infinitum seems to result in the following:
- The software begins to better fit the users' needs quicker.
- Fast release cycles build relevance to the users, if they thought your software was 10% relevant on v1, it might be 70% relevant by v3 and 90% by v4. And you can go from v1-v4 in 12 months if you release quarterly.
- Your software will be wrong. Get over it. Instead of lamenting it, take it as an opportunity to turn users into stake holders.
- The users feel that they are participating in the software design (since they are), it makes them implicit stake holders. And it also can foster a sense of partnership. If you do it right, the users are basically contracting you for your services without having to go through the hassle of setting up a formal agreement that they probably wouldn't have set up in the first place. The danger is that when something goes wrong, you try and leverage blame on the user for not knowing how to design software. I've found that simply going back and saying "well, what can we do to fix this by the next iteration?" seems to work miracles.
- Happy users spread happiness through your user community. A happy user community grows. A growing user community means your business is growing. Before we adopted this philosophy, our user community was shrinking at about a 10% rate/year following another development philosophy. We are currently growing at around %200 as soon as we switched development philosophies.
- Changing the development philosophy also implies changes to the rest of the business, for example it gives sales and marketing more reason to touch the users, and gives them better product to show. It also implies a different sales model, rather than charging $x per rev, charge $x+y dollars for new customers, and each rev is $x-z dollars. Or charge $x/years and $x*.40 per year after to build lock-in.
- Waiting 2 years for an overwrought design to produce something that maps poorly onto most users' requirements does not usually result in happy users, the post release exercise turns into damage control and not maintenance. For example, which is the better software, Windows Vista or Windows 7? Vista was a monolithic design that developed in the rarefied vacuum over the better part of a decade and the result was rubbish. 7 was a rather fast (for Microsoft) iteration based on user's requirements and people find it rather unobjectionable. The better product was the one that followed this model.
- Faster releases tend to be smaller releases, which tends to make testing the software easier which tends to produce more solid software.
- Bigger features can wait. Users see delta in software, if you delay your release by 6 months to push out one big feature, your users may loose interest. If you push out a smaller, feature packed release, full of small features and bits of polish, every 90 days, your big feature can come out in 2-3 release cycles and nobody will be wiser to it.
- If you slip a release date, it's better to be 2 weeks late on a 90 day release schedule than 6 months late on a 24 months release schedule.
This may sound like more the Rapid Development Lifecycles that are current coming into vogue, but it's really just common sense coming from lessons learned seeing lots of projects not pan out and burn through lots of investment and contract money to produce substandard product. It's more a manifesto than a development model. Google has largely internalized this kind of model as well, which is why their software seems to sit in beta forever, and they never seem to have big new releases -- going from chrome v2 to v3 was about as dramatic as loading another web page. Big features, like plugins, have been delayed for several release cycles while they push out smaller releases quickly.
But I guess you cant beat the mothership - even with a headstart.
If it had meant that a "real Indian" lies about it, it would have had a comma after "know" or "does" at the end.
The trick is to make sure the person feels they won't be embarrassed if they don't know the answer.
This Indian feels no shame in saying "I don't know".
It brings up a mildly interesting machine vision problem: using the Street View data to confirm that the "landmark" business has a highly visible sign which is visible from eye-level when you're walking (and to confirm that the sign is written in Latin alphabet, if it's an international user trying to get directions). Maybe they'll give reduced advertising rates for better signs (e.g. highly contrasting colors, prominently lists the street address, etc.)
Apparently they have been busy collecting Street View images for India:
But as a technology this is fantastic.
Not that it isn't a neat system to have, but I'm guessing it's pretty labour-intensive to get off the ground, and needs a lot more maintenance to keep it reliable.
I was indicating the latter.
The Third and Most important reason would be that most of the time, you won't find a board with a road name :). I don't mean it in a bad way, and it has never stopped me from going where I want in india.
The best way to find a route in india (and i guess in most of the fdeveloping countries) is to just stop and ask. and if you are in luck, people will even travel with you to show you the place.
But wonderful thinking from google. they clearly know what they are doing.
Responsible for user experience research and usability of Google Geo products within the USA and internationally