The Best of the Internets

Social Class, Power, and Selfishness: When and Why Upper and Lower Class Individuals Behave Unethically

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!


The “Web Application” Myth

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.


Designing for the Elderly: Ways Older People Use Digital Technology Differently

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

  • vision and hearing,
  • motor control,
  • device use,
  • relationships,
  • life stage,
  • experience with technology,
  • cognition,
  • memory,
  • attention, and
  • decision-making.

It’s pretty exhaustive. You should definitely give it a read.



Reframing Accessibility for the Web

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.


You’re Missing the Point of Server-Side Rendered JavaScript Apps

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!


Power of the Platforms

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.



Emulating Failure

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.


Accessible Timeout Notifications

I’m not generally a fan of session timeouts, but if you have to do it, Léonie Watson has outlined a pretty good route to go. My only nit might be using a role of “alert” or “alertdialog” instead of “group”, but that’s because it would trigger an audible chime and get read by assistive tech. But that’s pretty minor.

Pay particular attention to the keyboard focus stuff too.