Hey, I'm not a developer/coder/programmer, so I honor and respect the work you've put in to things in the past. But if you've been tying yourself to a "unified GUI look" across platforms, you've long been dooming your products and yourself.
As a UX person, I can throw data at you all day long that shows device/OS specificity and familiarity are key elements in making something work for the user. I'm sure you don't literally mean you chose either a menu bar in all app windows on every platform or a top-of-the-screen menu bar on every platform, but the obvious reason why that would be wrong also holds for controls, colors, placement, text sizes, and so on to the last turtle at the bottom.
So what factors were and weren't considered in your decision to ignore existing regulations in many of the cities you operated in? Did you assume local governments would change laws retroactively, or would not attempt to enforce? Or did you have legal counsel advise you that your operations did not fall into the regulated category (which Uber now seems to admit it does)?
Basically, what was the process?
Yes, and cities also ask private and Uber cars to stop at red lights and stop signs. And obey the speed limit signs. And small and large companies to follow published pollution, hiring, and health & safety regulations.
If you can't make your smartphone-enabled car service make a profit while following the same public, published, long-established safety and other regulations that taxi companies have to and found a way to follow, to all our benefits, then maybe you should rethink things. At least don't whine about it.
"What do you mean, _I_ can't own a slave? You're stifling innovation! And my business model didn't account for paying salaries!"
Citation, please? Peer-reviewed sources preferred.
(Conservapedia and Mies fan blogs do not count.)
In the last few days he's posted two highly biased, agenda-driven things on Slashdot's main page. Both take the perspective that it's eeeevil guvmint trying to crack down on plucky, innovative, honest corporations who just wanna do right by you. In the way he presents these highly questionable narratives, there's no no room for the facts that city governments have had long-standing regulations for cab and ride services that require adequate levels of insurance and other means of covering liability when Bad Things Happen.
One such case of Things happened New Years's Eve here in San Francisco, when a ride-service (yeah, it's not "sharing" if you exchange a service for a fee) driver ran over and killed a child. The company in question, because it had been throwing tantrums and refusing to comply with existing regulations (not to mention publicly ranting that the city was trying to "kill innovation"), didn't have coverage and refused all liability, putting it all on the driver.
If these companies cannot afford to comply with existing safety regulations, the way cab companies have and do, maybe they aren't a viable business model and need to innovate all over again.
a. Anecdotal evidence ahead, though a lot of it
b. Yeah, I'm one of those "I've lived here for ages, whippersnapper" guys
But I've seen first-hand that 20somethings and newly minted millionaires-on-paper actively go to landlords and work with them, often funding the legal costs of evicting long-term tenants (the techies gets the "authentic" place, the landlord gets to raise the rent). See more context here: http://www.kqed.org/a/forum/R2...
Also, a large part of the housing stock in the SF areas in question (the Mission, Noe Valley, Hayes Valley, etc.) is multi-unit small buildings. Often houses converted into multi-unit. The same people as mentioned above come in and buy the building for a few hundred thousand dollars over its last listing and do an owner movein; this also can displace the other tenants in the building (esp if it's done as a TIC); it at least gives them the change to reset or raise rents.
So, it's not as simple as you make it out to be.
Citation, please. Snark aside, I'm not sure why you are "pretty sure" of this.
There were rich and high-profile Jews, to be sure. As there were rich and high-profile Christians, Austrians, etc., at the time. But if you even took a few seconds to look up what Kristallnacht was, you'd realize that the thousands and thousands of Jewish businesses that were targeted were shops: small commercial places such as storefront butchers, shoemakers, bookstores, etc. Just in that, you'd realize that these people who were hauled away, often to death camps, were not the 1%, but working class.
Hey, I'm not just irritated at your "pretty sure" statement because this happened to my own family members. Go look things up before you make a public statement. Don't be a Perkins.
Sounds like you could use some Twine (http://supermechanical.com). Full disclosure: I'm friends with the inventor. Still and all, it's pretty cool. Other friends use it with a moisture sensor to know when basements are starting to flood, etc.
Funny, in the UX world, the opposite is a well known issue. That is, most "UX" job listings will say that the requirements include coding (not just front-end stuff like CSS and HTML, but you should have built your own kernel from scratch just for the love of it, and please include your github), a full range of user research experience (and show you process), proficiency is three prototyping tools (and this better look polished, though... prototypes), and mastery of Creative Suite (and show your elegant, gorgeous interfaces).
In reality, nobody does al this. And if they did, how would they fit in to your team and workflow? I suspect most recruiters and hiring managers, especially in startups, don't really know what "UX" is. And especially in startups, they think it means, "I have this wizard idea – you just have to build it." (This often correlates with the "I don't need to learn about users; I took this class in B School so I know the market.")
Good point, and that could be the case in many examples (though I can't imagine it being so widespread; perhaps there's a systemic effect that some such postings set a format that others have copied).
My data point (anecdotal, of course): I've seen this happen in the design world, where a U.S. company really wanted to hang on to a Canadian intern, but had to post the job as open for U.S. citizens. There was a lot of joking about wording the job posting to require left-handness, a certain prescription for glasses, and short, spiky hair.
And by that I mean non-SF fiction (what's called in the article I'll link to "literary fiction"). Research has suggested that reading this sort of thing, as opposed to man pages, SF, or journals, improves empathy and communication skills: http://www.theguardian.com/books/booksblog/2013/oct/08/literary-fiction-improves-empathy-study
Also, learn about different types of intelligence. Daniel Goleman's books are a good place to start.
Basically, don't neglect non-STEM topics in your, your friends', or your children's education. You may think that you'll never need to learn how to diagram a sentence, or the history of philosophy, or art theory, for work, and so you ignore them because programming shows your big brain to its advantage, but: you have to work with people, share ideas, listen to other ideas, if you really want to do something great. Or, you know, be a human.
In theory, you're right, but in practice that's so, so not the case, especially here in the SF Bay Area, which seems to be neck-deep in the "build-first" mentality of freshly minted MBAs.
Over the last year I've talked with so many startups, mostly "founders" and "entrepreneurs" with Bschool degrees, who seem to be taught that all they need is an "idea/vision". They just need to get someone to build it, because, you know, they've run the numbers and they "know the market" (actual, real-life quote from an actual situation). When I ask, "What problem does this solve, for whom, and how do you know this?", they scoff and tell me that they don't need to do any user research and besides, that'd slow things down.
Now, there may be actual pressures on startups to start building without ever observing a single potential user. Certainly if you're going to present at Y Combinator, they want to see code, a product, and tons of "confidence" (again, actual quote from actual situation). Showing them serious research on populations, data on engagement, prototypes... that'll get you laughed out.
But, side note: 75 to 90% of all startups fail. Go figure.
As a UX professional, this really grinds my bacon, six ways to Sunday. It's like seeing a kid whinge that the test was hard when you know they didn't do any of the homework. Perhaps they think that user research means months, and 100s of pages of specs (and, to be fair, it could), but I think a lot of this comes not just from stakeholder pressure but a misreading or Ries's "Lean Startup". Sure, it helps to get something in users' hands quickly, but this is based on research first. Know who your users are, what problems they face, how they think. At least an idea of it. You can rapidly prototype, GOOB, test, iterate, all within cycles of days or weeks. But you HAVE TO KNOW THE USER (who is NOT YOU) first.
There's a great example of how this can be done for $40, to save $10Million: http://vimeo.com/24749599
You're missing something (no discredit to you; a Google project manager recently made basically the same mistake). You can conduct many kinds of user research (UX) that are far more insightful and reliable than "asking customers what they want".
I'll agree with you that it's a loser's game to ask customers and potential customers what they want. First, people will try to help you, and thus give you bad data (examples: "I love what you did" focus groups, asking people what TV shows they watch). Second, they may not really know what would solve their problems. Third, if you just translate this to feature requests, you end up with Microsoft Office.
Real UX observes populations, seeing what real-world problems they actually face, where their face frustrations, how they think about themselves, their tools, their problems. This informs the process of discovering user needs and use cases. Science!
Usability testing of prototypes bends itself into knots trying to correct for these natural propensities of people. And still, it requires some n of testers, evaluation of the qualitative and quantitative info generated from this, and expertise. And it can still get things wrong.
But it's so much better than marketing-driven design (Facebook pushing ads, fill in your example) or engineering-driven design (a Google engineer builds a "cool" tab feature, or finds how Gmail can share all your contacts with all your other contacts).
Mod parent up... as a UX person, I can never seem to remind people often enough that they are not the user. Sure, you know what everything does and why, because _you built it that way_. Every other person, not so much.
You have to laugh at how the core of Ferriss's time- and effort-saving plans all seem to involve variations on, "have other people do it", "have expensive devices that can do it for you", "take advantage of other people" (in this example, ruining a hotel's iron so that nobody else can use it) -- all, basically, "first step: HAVE LOTS OF MONEY".
Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec