HN user
I don't have anything to add to many of the comments already posted but I'm reminded of Cyanide and Happiness very poignantly making a similar point: https://www.youtube.com/watch?v=fAKQ7ouQqgA.
The choice is about releasing version 1.0 vs constantly adding features that are better suited for versions 2, 3, 4+. What can be done now, at reasonable cost and technology level? My position is that we could have a system right now that would alleviate traffic congestion and offer greater safety. Advancement on the harder problems comes with real-world experience in the field.
The doing is the learning.
I don't think any of those examples are edge cases. The first set are normal traffic conditions that in the context of self-driving cars are easy to solve, especially in narrowed conditions such as on a highway. Moreover, mid-range cars already have collision warning and automatic braking systems. As to your example of traction issues, pretty much every modern car that I'm aware of has had computer assisted traction control systems for a while now.
The edge cases that are difficult essentially boil down to entity recognition; unexpected and moving obstacles, road sign changes, traffic light outages or alternate signal pathways and the like. Some of those definitely would require government level coordination which is about a lot more than technology.
I think a more fundamental problem here is that self-driving cars are as much an infrastructure problem as they are a technological one.
As an analogy, consider hybrid vs electric vehicles. In places like North America with large, open spaces, electric vehicles really only serve a specific type of urban driver. The culture, infrastructure and geography dictate 600km distances which really aren't practical at the moment with current battery tech. Whereas hybrid vehicles can (or could) quite easily reach that range with options to recharge once you get to your destination or have a longer stopover and still use existing infrastructure. The focus on purely electric is a lost opportunity for anyone who needs power or long distance.
Similarly, cars could be designed to be self-driving in the easy cases; highways, certain urban thoroughfares, particular times of day and the like where existing vehicle and pedestrian flow patterns eliminate the edge cases. coordinating systems along the aforementioned types of roads could be installed as was done for cellular service and GPS and other protocols could be developed to ensure safety and reliability as well as fallback in case of emergencies.
Instead, we've decided on all-or-nothing bets which don't move things forward--or at all--and my worry now is that we'll lose an opportunity to pick the low-hanging fruit and solve the harder problems incrementally over time.
Well done!
Plain and easy to understand interface and excellent use of colour and space. Two suggestions:
1. While I doubt it'll be used very much, consider adding calories for completeness if nothing else:
1000 kcal -> joules 1000 Cal -> joules2. Change Variables to Constants. I think this is more in keeping with standard jargon.
[1]: cal is based on the gram while Cal or kcal is based on the kilogram.
Even if true, why do you assume it was the US? There are many actors with the willingness, capability and motivation.
Interesting.
As far as I can tell though, it doesn't seem to account for humidity, pollution or wind patterns. The former is especially important for hot climates (or times of the year) since when it comes to comfort, hot dry >> hot humid.
The suggestions themselves are decent but I have a hard time taking UI recommendations from someone who insists on using low contrast text: http://www.linowski.ca/. I can barely read his copy. Why and how anyone thinks that usability isn't made worse by using medium grey on white or light grey backgrounds is baffling to me.
It's been a while but the next time I hire a design firm, my first test will be to see if they use low contrast text.
EDIT: I just found this http://contrastrebellion.com/.
Whoohoo! I can finally dump Apple Maps in my iCrap folder.
That's true, but you only have to do it once.
Not really. While I agree that the link should not be followed, the button should still return to its normal pre-mouse-down, pre-hover state. Only the focus should remain with the button.
Small bug: If you click and hold and then drag outside the borders of the button, the button stays in its ':active' state until you click somewhere (anywhere) else.
Whoo-hoo! Time for the Perl port.
A unique alias is fine in circumstances such as the one you've given--my point is about account creation and logins. There is no reason you can't use an email as a login and then require the user to give a unique alias to use in their URL. FogBugz (On Demand), to cite one example, does things this way. You login with an email but when you sign up, you have to give a unique corporation name and the app generates a subdomain of fogbuz.com; e.g., mycorp.fogbugz.com.
Anyway, I really like the idea of what you're doing, but as time marches on I am becoming increasingly zealous over this issue. Retooling your app at this point is probably too much work given that most users don't have the same conviction as I do but since you asked for feedback, I'm giving you my 2¢.
UI issue: Why do I need to come up with yet another username? I've never understood why websites don't just let username == email with an optional alias. I understand that OpenID or ClickPass might not be worth implementing but in my view, this username thing has got to stop. To this end, I refuse to sign up for any service that requires me to login via username (other than email). It's too bad too, because this looks very cool.
Where's Linux Hater (linuxhaters.blogspot.com) when you need him?