I am incredibly excited about the future of voice-based user experiences, but I also fully recognize that we’ve got a long way to go. This post from Zach Holman does a great job illustrating the issues we are currently dealing with. And it’s a fun read to boot!
In this fascinating paper, David Dubois, Derek Rucker, and Adam Galinsky explore the interplay between socioeconomic status and selfishness (or cheating). In the course of their study, they discovered that people at both ends of the spectrum cheat, but for different ends:
[S]ocial class positively predicted unethical behavior; however, this relationship was only observed when that behavior was self-beneficial. When unethical behavior was performed to benefit others, social class negatively predicted unethical behavior; lower class individuals were more likely than upper class individuals to engage in unethical behavior. Overall, social class predicts people’s tendency to behave selfishly, rather than predicting unethical behavior per se.
The second thing they discovered was that the cause of selfishness came from an individuals’ sense of power:
Evidence for this relationship was provided in three forms. First, income, but not education level, predicted unethical behavior. Second, feelings of power mediated the effect of social class on unethical behavior, but feelings of status did not. Third, two distinct manipulations of power produced the same moderation by self-versus-other beneficiary as was found with social class.
Fascinating stuff!
Christian Heilmann is dead-on in this post. It’s a long one, but worth reading. Here’s my favorite bit:
What is an application? To me, it is a tool that allows people to reach a certain goal in the most effective fashion. What matters is not what language or technology you build it in. What matters most is:
- that it is the right tool for the right audience,
- that it does what is expected of it and not more,
- that it is safe to use,
- that it works in the environment it is most used in,
- that it can be easily maintained without dependencies that only a few people know how to use,
- that it is built with components that are reliable to use and not a “alpha” or “beta” or “not production ready” experimental technology
- that we know how to maintain the thing, how to add new functionality and above all, fix security issues in the future without replacing it as a whole.
These are the things we should concentrate on. To find the answer as to what format this “application” will be, we need a mixture of skills of people working on the product:
- researchers,
- designers,
- UX people,
- content writers,
- trainers to show people how to use the tool and how to put content in it afterwards and,
- yes, of course, developers.
And this is the scary part: this costs money and a lot of effort. It also means that we have to think about communicating and building teams that are good at bouncing ideas off one another and find a good consensus. It also means it will take longer to build this.
All of this is anathema to people who have to show off to venture capital companies and stakeholders. We have to move faster, we have to be better. Less people, more products, quicker iterations, more features. It doesn’t matter what the product does: the most important part is that you show that it evolves and changes constantly.
We’re all aging. There’s no way to avoid it, no matter how much HGH you consume. And as we age, our eyesight typically worsens, we lose some motor control, and our brains often don’t process data quite as fast as they did when we were 18 or even 30. As designers, we need to be cognizant of the needs of aging computer users.
Ollie Campbell has put together a great read on creating digital products that accommodate the aging population (estimated to top 19% of the US population by 2030). In it, he discusses things we should consider with respect to
It’s pretty exhaustive. You should definitely give it a read.
Passive aggression at its best:
console.log('Google, please make sure your obfuscator does not change class names, so our patch continues working (or stop browser-sniffing as we both use and contribute to Blink!) - love, Opera.');
Lots of great stuff here from Anne Gibson:
We need to change the way we talk about accessibility. Most people are taught that “web accessibility means that people with disabilities can use the Web”—the official definition from the W3C. This is wrong. Web accessibility means that people can use the web.
Not “people with disabilities.” Not “blind people and deaf people.” Not “people who have cognitive disabilities” or “men who are color blind” or “people with motor disabilities.” People. People who are using the web. People who are using what you’re building.
We need to stop invoking the internal stereotypes we have about who is disabled.
Anne goes on to offer a lot of practical and helpful advice around how to change the way you think about accessibility and how to act upon that change. You should definitely read it.
For similar content on this site, see my keynote from A11yQC and my post on egalitarianism.
I agree with Tom Dale. Yup, you read that right: I agree with Tom Dale. Well, he finally said something sensible:
Say what you will about server-rendered apps, the performance of your server is much more predictable, and more easily upgraded, than the many, many different device configurations of your users. Server-rendering is important to ensure that users who are not on the latest-and-greatest can see your content immediately when they click a link.
You might remember Tom as the guy who declared progressive enhancement dead in late 2013. He’s apparently seen the light and has been hard at work to get Ember ready for server side rendering.
I’m shocked, but glad he finally came around. Progressive enhancement FTW!
This is a great post from Simon St. Laurent on how isolated Web “platforms” have come and go while the “tangled mess” that is HTML, CSS, and JavaScript soldiers on. It’s a must read.
The web bends with the wind, supporting incredibly diverse use cases across a wide variety of environments. Your code should, too.
This is a beautiful and exhaustive survey of heading level usage before HTML5 and in HTML5. Sadly, no one implements the HTML5 scenario yet. But it’s nice to dream. Maybe one day.
For more:
Another beautifully-eloquent post about the potential perils of Web Components:
HTML has a problem. As implemented in browsers many interactive elements cannot be styled as desired by web developers, or developers as directed by designers, marketing or any of the numerous others whose wishes code cutters must abide by.
…
Now in 2015 we have web components re-inventing native HTML buttons, radio buttons and checkboxes, for relief from the scourge of divitis, perpetrated upon us by the as shipped inability to style a native HTML element as desired.
Is it just me, or are new web UI technologies continuing to try to solve the wrong problems?
Now, the Shadow DOM (and associated pseudo-elements) should allow us to control the style of these elements. The deeper problem is functionality. Take the datalist for predictive typing. What if you want fuzzy search instead of initial search when someone types. That’s not supported. This is where Web Components get interesting.
Note: I no longer use “native” in this context, but it remains in quoted material.