As a digital product designer, my go-to Mac status bar app for this is Contrast: https://usecontrast.com
1,103 karma · joined June 7, 2011
In 2017 there were zero reported accidentally deaths [1]. Compared to 1972, one of the most dangerous years to fly, where more than 2,300 accidental deaths occurred on commercial flights.
How did we go from thousands of deaths to zero? Primarily through crashing. Then working to evaluate what went wrong and improve the design, processes, and programs around commercial aviation.
As one pilot explains [2]:
"One of the ways we’ve become so safe was to realize that our efforts were never going to be good enough."
So yes, I think technologies like autopilot will save lives. But it won't be able to do it magically, unfortunately some harm will occur because we—in all our human wisdom—just can never accurately predict all possibilities. It's the same problem most self-driving companies are facing today, and the reason promises of self-driving being here today have fallen short. The world is far, far more complex than we realize... especially when we put a computer out into it and tell it to "go forth."
https://www.reuters.com/article/us-aviation-safety/2017-safe...
https://www.usatoday.com/story/travel/columnist/cox/2018/01/...
I started coding long, long ago in order to build my web portfolio (back before site builders were a thing). As a result I saw how empowering coding can be.
I've always felt being able to code software gives you an ability to solve a lot of your own problems with technology. e.g. I have a lot of private tools I've designed and coded to help me in my day job (such as this simple one I recently open sourced: https://tannerchristensen.com/spf).
If you're a designer who works on digital products, I think it's only advantageous to know some programming. It gives you empathy for your engineering peers, gives you more insight into how what you design will actually get built (and the constraints/advantages of the technology), and helps you see problems in different—often more linear and logical—ways.
Learning to code is not for everyone, but learning a little can go a long way. At least learning the basics of code structure, loops, memory allocation and management, etc. would be my suggestion.
I made a comment elsewhere here (and updated the article to state) that downloads currently are around 40 each week, with an occasional bubble of a few thousand when a blogger or news site re-discovers the app.
I would often change the price to 1. See if I could squeeze a few more dollars out of the work and 2. Generate more downloads.
A fun "trick" for getting more downloads is to temporarily make a paid app free, as many, many people follow "Apps Gone Free" type of bots or directories and if your app has any substantial numbers behind it more people tend to notice when it switches to free.
I’m surprised anyone here thinks something like Snaplight would take more than an hour to build (no repos, testing on device but otherwise no tests, simple permissions, uncomplicated UI that only improved post-launch, etc.).
But does that mean it truly will "never" happen? I imagine saying we'll never see flying cars reach mainstream is akin to those who once thought attaching a motor to a horse carriage would never work (though, to your point, the triumph of the motorized vehicle has brought disastrous outcomes along with its benefits)[1]. It's hard to see the future when all we've got is the past and present to evaluate it by.
And yet, we've had private aircraft for hundreds of years and that's gone reasonably well. Scaling that private fleet up and including car-like vehicles doesn't seem too far off, though the challenges are numerous and daunting. Flying cars will likely not include the same amount of training and preparation as private planes. The gamble seems to be software can help take on much of the burden, only time will tell if that's going to pan out.
1. What about those who could never fathom a globally connected network of information? Or the precedence of touch-based interfaces? Or the reliable, safe electric car?
An example of how to get around the Economist paywall is already elsewhere in this thread.
EDIT: Why is this being downvoted?
As a designer, being able to easily jump between code and design for complex prototypes makes my workflow dramatically faster. Love seeing the continued evolution of Framer X.
One demo, for example, had a prompt to ask the machine something about a photograph. "What color is the table?" or "What animal is sitting on the floor?"
No matter how you asked the question or what types of questions you asked, the demo would comically never get it right. "What color is the cat on the floor?" would return "A mug!" in response.
A strong setup can certainly pull readers in. The problem is often most inexperienced writers use such a setup to clear away their "mind fog" and get to the point. And once the words are on the page it's hard to remove them (nobody wants wasted effort).
My guidance to new writers is always this: start with two bulleted items. First is a question or priming sentence. Second is the conclusion the reader will takeaway after reading what you've written.
Once you have those two bullet points you make them part of your first paragraph AND use them to structure the entirety of the piece (just add more bullet items between the first and second points).
"If it seems strange that nerve signals coming from the back can represent vision, bear in mind that your own sense of vision is carried by nothing but millions of nerve signals that just happen to travel along different cables. Your brain is encased in absolute blackness in the vault of your skull. It doesn’t see anything. All it knows are these little signals and nothing else. And yet you perceive the world in shades of brightness and colors. Your brain is in the dark but your mind constructs the light." — David Eagleman in his book Incognito.
Without the nerves connecting your toe to your brain, you are unlikely to feel the otherwise agonizing pain of having had stubbed it against a coffee table.
Vision is just one small piece of the puzzle, and while it's extremely difficult—particularly when considering the complexities of navigating a busy city street—the other parts are just as challenging. This is where claims like that of Ford's CEO really stem from.
Looking at the problem and some of the existing approaches to solving it, it's become apparent the way forward is not at all clear. Realistically companies are making progress, but as an industry we may not have a straight path toward a feasible solution for some time.
1. https://venturebeat.com/2018/11/28/udacity-cuts-125-employee...
2. https://techcrunch.com/2018/09/28/online-education-unicorn-u...
I agree generally, scrappy businesses should prioritize shipping (and validation, market fit, etc.) above almost all else at the start. But even if you're leveraging existing patterns and design elements, there's really no reason /not/ to spend a fraction of a fraction of your time to understand the differences between a checkbox and a radio button; especially when such fundamentals are already laid out for you online and your team can easily leverage them both in design comps and code.
Quality design doesn't require infinite budgets or unlimited time for research. A little effort to understand the work goes a long way!
It's the same thing with programming: copy+pasting something from SO might get you 75+% of the way to success, but relying solely on that approach without understanding the code also means you'll inevitably run into issues with things like memory management, technical debt by locking into approaches, etc. in your product sooner than later.
(fwiw I've also started several businesses myself, created my own products independently, and consulted with many startups; I haven't solely functioned in the deep pockets of silicon valley, if that's what my original comment came across as.)
But what makes leveraging those existing designs so effective isn't simply seeing and copying them (that'll do in a pinch, but ultimately may lead to misuse).
What makes standard patterns from platform sources so effective is that you don't have to wonder whether they'll meet your needs or not: they're already standard, customers will understand them, and if you're so inclined you can look behind them to better understand their rationale via material.io for example.
But, again, without understanding what you're copying you're likely to run into small problems. Such as: when should you use a modal dialog over a sheet? When should a button be hollow vs. filled? When to use radio buttons vs. checkboxes? Should a transition animate from the bottom, left, or right of the screen (and how do those each help the user orient themselves in the experience)?