Matt Asay does a great job dispelling some of the myths frequently spouted in the Web vs. native debate. It’s definitely worth a read.
The Best of the Internets
Charles Morris wrote a lengthy post about the germination of Microsoft’s new browser rendering engine. If you ever wondered where
babies come from, this is full of insights.
On a side note, this is one of the most exciting aspects of the new browser (and new Microsoft) for me:
Our mission to create a Web that “just works” won’t be successful without your help.
My old friend Jason Garber—who I, sadly, haven’t seen in probably a decade—came up with a great list of “professional self-improvement tips for anyone working on the Web today”. I’ll give you the synopses, but you should do yourself a favor and read the full post for the background:
- Know Your History
- Know Your Medium
- Respect Those Who Came Before You
- Respect Your Audience
- Get Involved
I would absolutely echo these to anyone looking to become (or improve as) a web professional.
Astute observations (as always) from Tim Kadlec. I’ll let Tim set the scene:
Over the past year I conducted performance audits on a handful of sites that all used client-side MVC’s, typically Angular but not always. Each site had their own optimizations that needed to take place to improve performance. Yet a pattern emerged: client-side MVC’s were the major bottleneck for each. It slowed down the initial rendering of the page (particularly on mobile) and it limited our ability to optimize the critical path.
Obviously Tim knows what he’s talking about.
He goes on to bring in the voices of the Filament Group and PPK (both of whom I’ve linked to previously for the same reasons): lots of smart people have come to the conclusion that relying on client-side generation of web pages is a bad idea. Tim goes so far as to say “if your client-side MVC framework does not support server-side rendering, that is a bug” and I can’t help but agree.
His post is great, you should read it. Frankly, I wish I’d written it.
This is, by far, the best implementation of a toggle slider checkbox replacement I’ve seen.
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.
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:
- 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
- vision and hearing,
- motor control,
- device use,
- life stage,
- experience with technology,
- attention, and
It’s pretty exhaustive. You should definitely give it a read.