Outrageously cool. This is a textbook for how to build stuff in the modern way.
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."
Almost but not quite. This is textbook stuff in that it's actually using principals of wayfinding in built spaces. There's a great little research paper that goes into how we locate and orient ourselves in spaces
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.
The paper is interesting, but I'm more interested in hearing your startup story. Can you describe what lead you to start it, what were the problems, how did you find first customers etc.
I was talking about software in general -- not the specific case of google maps and wayfinding. In terms of rapid development and iteration to improve a product to suit the end-user. Monolithic design concepts are rapidly going the way of the dinosaur. Small iterations of "good enough for..." building up to "98% of what the user needs" (with copious feedback to every part of the iteration cycle) is proving itself to be the better way of building software over older, waterfall style approaches.
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.
Yes - it strikes me that this is not so much navigating like someone in India, but navigating more like many (most?) people do in practice. I tend to like knowing which way is north, and using that, but I've found explaining things using compass directions often confuses people. Especially in unfamiliar surroundings it's much easier to get your bearings from significant landmarks.
This clearly means that a "real Indian" would say "sorry, I don't know," but Google would lie. (Actually it's closer to asking whether it is a lie to be too embarrassed to admit to ignorance.)
If it had meant that a "real Indian" lies about it, it would have had a comma after "know" or "does" at the end.
I see where you're coming from, but 'lying' implies maliciousness. Somebody making up directions in cultures where not knowing is shameful isn't malicious, it's wanting to not be embarrassed.
The trick is to make sure the person feels they won't be embarrassed if they don't know the answer.
So how much did it cost U. N. A. Cycle Traders to be listed as a "landmark"?
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.)
I am not sure why this is given as "How an Indian" would give directions , that's how we do it here in London as well. No one says "Go Southeast for 0.2 kms" , you are oriented and directed via a well-known landmark.
Well, in London you might say 'turn left down XYZ road', so we have a system of navigating that's less changeable than things like shop names.
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.
You do say "Turn left down XYZ Road" but if you don't know or can't see which road you are on(happens quite often in the small bylanes in Central London), there is always the very reliable, do you see "name of pub" in front of you - walk towards it.
remember that the article could be written by or targeted at americans. in the us (and a few other places, like santiago chile), people navigate much more by blocks + compass directions. this is possible because the streets are grid-like (and here in santiago it is always clear which was is east because you can see the mountains). in the uk, which is much more "organically" laid out, that doesn't work.
Looking forward to when this comes to the USA: in Pittsburgh, directions are typically given via landmark, as the road system is beyond chaotic because of the hills, rivers, and the fact that downtown is a triangle.
Assuming its a feature conceptualized and implemented by Indians in Google's India office, its a good example of innovation happening in India that might have a global impact.
Just tried a few directions from my house... This is a huge improvement! Though one could do a slightly better landmark selection but this is awesome...
I live in Bangalore and I have always found that asking Google Maps is way better than asking locals. This tweak is a real bonus improvement over that.
"We found that using landmarks in directions helps for two simple reasons: they are easier to see than street signs and they are easier to remember than street names. Spotting a pink building on a corner or remembering to turn after a gas station is much easier than trying to recall an unfamiliar street name."
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.
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."