Sheon Han covers the history of blind programmers buiding assistive technologies for blind and partially sighted users:
Nearly three decades have passed since JAWS for Windows was released, during which possibly tens of thousands of blind and partially sighted programmers entered software development. Just as it was in Henter’s time, it’s a field that is relatively inclusive for people who are blind, as the accessibility barriers are lower than in many hands-on jobs. These days, this is in no small part thanks to JAWS, a piece of software pioneered by a blind programmer.
From Devon Govett and the design system team at Adobe:
This includes a full suite of fully featured components and hooks including calendars, date and time fields, and range pickers, all with a focus on internationalization and accessibility. It also includes @internationalized/date, a brand new framework-agnostic library for locale-aware date and time manipulation.
If you’ve ever worked on the design or implementation of components for choosing dates, I’m sure you’ll appreciate the incredible amount of work and attention to detail this represents.
I’ve been teaching design systems and accessibility courses lately, and there’s an amazing amount of overlap these days. This work from Adobe is a great example of why: building out flexible components which can be reused throughout an organization or even beyond suddenly changes the impact of accessibility efforts for those components.
David C. Brock celebrates the legacy of the earliest attempt to commercialize a personal computer with a graphical user interface:
The people who developed the Alto came to Xerox PARC from universities, industrial labs, and commercial ventures, bringing with them diverse experiences and skills. But these engineers and programmers largely shared the same point of view. They conceived and developed the Alto in a remarkable burst of creativity, used it to develop diverse and pathbreaking software, and then moved out of Xerox, taking their achievements, design knowledge, and experiences into the wider world, where they and others built on the foundation they had established.
The photos accompanying this article are a real treat. If you’re interested in going back just a bit further, Doug Engelbart’s “Mother of All Demos” presentation in 1968 was a major source of inspiration for PARC.
Dan Klammer has done the legwork of putting together a comprehensive and highly usable set of system fonts available on all the major platforms, organized by classification. Using system fonts means no font downloading, which means faster web sites and web apps, and no re-rendering when fonts load.
Accessibility is unfortunately still an afterthought on many projects. User interaction and accessibility requirements are poorly documented, at best. Or forgotten, when handing over designs to developer teams. And fixing it later costs a LOT more than building it right to begin with. Great documentation helps teams implement accessibility requirements the right way. I will tell you why, what and how designers can document different aspects of accessibility and user interactions requirements, to build better more inclusive products.
I had the pleasure of meeting Jukay and his team at Pursuit in 2017 before I left New York, and I was very impressed with the work they were doing to lower access barriers for professional tech education. Here Jukay discusses some of how they make that work:
One shining solution is called outcomes-based financing, a model where workforce development programs tie payment to a trainee’s employment trajectory, rather than charging fees up-front like colleges and universities.
Here’s how it works: thanks to funding from social impact investors through “job bonds,” participants don’t incur any cost during their training – not a single dime up-front. Then, after a graduate secures a high-paying job, they pay a percentage of their earnings for a set amount of time to help repay the bond’s debt service. If someone doesn’t immediately get a job or if their salary is below a certain level, they pay nothing. If they stop working for any reason, their payments pause, too.
There are a lot of people who talk big about “the future of education.” I’m not sure whether the ideas Jukay presents here would make sense outside of the space he’s been working in, but I do think it’s worth paying more attention to folks like him who have been doing the legwork to figure things out.
At some point, I personally hope the community college systems in the U.S. will catch up in terms of serving these needs outside of private foundations and companies.
I love reading about nerdy design processes like this one from Alex Hollander:
In other words, Wikipedia — a major, legacy website (top 10 ranked, for 10+ years) — had an interface that hadn’t been changed for 15 years. And then one day the Chief Product Officer came to our team (1 product manager, ~6 engineers, 1 quality assurance person, ½ a scrum master, ½ a data analyst, ½ a community liaison, and myself), and tasked us with making significant improvements. It might honestly be a once-in-the-history-of-the-internet kind of situation. Exciting, but rather difficult.
This is a great example of the power of storytelling, process, and emphasis on data and results in talking about the effectiveness of design work. If you’re working on a portfolio right now, I encourage you to take some notes on this one.
Bite-size selfie video tips from user experience researchers. As I describe it, I realize it doesn’t sound like it would work nearly as well as it does!
Michelle Ngo recently shared this short documentary on designing inclusively that she worked on. Tight and well-edited, with so many great stories. I especially loved the fashion designs for kids, and the efforts to bring young people into the process of designing for their needs. Great stuff!
Mandy advocates for digging deeper when facing burnout:
So how do we approach that repair? I think we have to first name the experience. Acknowledging your burnout (or that of your teammates) is one step, but the next is to unpack what that means. Maybe (probably) you’ve been working for too hard for way too long. Maybe it’s a loss of faith in the work itself—that something that had seemed important or valuable to you no longer does. Maybe you’ve been doing the same work for a while now, and have grown bored with it. Maybe you feel isolated or unsafe or like you can’t influence decisions. Maybe the way you think about your work has changed, and you don’t know where this job fits in anymore. Maybe it’s all of these things. The point is that each of these subjects—overwork, loss of faith, boredom, isolation, lack of autonomy, etc.—are all more readily addressable than burnout is on its own.
Nadyne Richmond makes a great point about keeping decision-making in focus when planning, conducting, and evaluating user research:
Defining the decisions that will be made as a result of the research can be a powerful tool when a team is using research for the wrong reasons. I’ve seen teams become so risk-adverse that they want to test every single thing. I’ve also seen teams become so beholden to a process that they don’t know when or even how to deviate from it. In those cases, defining the decision that will be driven and why that decision matters illuminates the more important problem that needs to be addressed within the team.
This subset of css that these tools use is based on how websites look today. Or on how they looked in the last ten years — which is the same thing. Websites haven’t changed. This means that with these tools we can design websites that look like websites-as-we-know-them, but it is much harder, if not impossible, to come up with new ideas. If we accept that these are the tools we will use from now on, we accept that the web looks like it looks today. And behaves like it behaves today.
I’m not sure I agree with this. As a teacher, I find it empowering for students that they can use tools like Figma with a fuller sense of confidence about the implementability of their designs. I think it’s equally arguable that the convergence of our tools with how we design is a sign of the maturity of the field.
If anything, I find myself wanting design tools to adopt more of the layout technologies available in rendering engines, not less—especially for things like grid-based layouts and tabular data, which most interface tools handle like a minor nightmare.
Maybe I lack the vision or imagination to dream up web designs that expand far beyond what we’ve acheived so far. That said, it’s not hard to find cases where design tools work so much faster to try out ideas that would feel slow or impossible to realize quickly in code:
interactive data visualizations
explorable explanations
contextual information
I want to see our design, production, and content tools improve, but I don’t think building in CSS-like features is inherently holding us back.
Julia Evans posted some comics about CSS last year:
I’ve been writing a tiny bit more CSS recently, and I’ve decided to actually take some time to learn CSS instead of just flailing around and deciding “oh no, this is impossible”.
CSS feels a little like systems programming / Linux to me – there are a lot of counterintuitive facts that you need to learn to be effective with it, but I think once you learn those facts it gets a lot easier.
Julia’s takes are always genial and practical. Have you ever seen a more appealing breakdown of CSS selectors? No, no you have not.
Ink & Switch offer an overview on the history, current state, and possible new approaches to providing end-users with more power over computation through various approaches of extensibility. From the introduction:
This article tackles the question of why this is so. We’ll start by describing three qualities we think are important for end-user programming: embodiment, living systems, and in-place toolchains. We’ll survey the prior art and try to illuminate what has made this problem so immensely difficult. Then we will document the experiments we’ve done at the Ink & Switch research lab in adding automation and customization capabilities to a digital sketchbook application.
We believe in a computing future where programming is within the grasp of everyone and hope this article can inspire and challenge our industry.
Today another class graduated, and I feel a mix of proud, tired, nostalgic, hopeful, and sad. This time, however, I find myself turning my attention to teachers I work with, more than to students.
This week I learned that two of my fellow teachers are stepping away from teaching to work on curriculum. I am happy for them, and excited to see what they will do, but I pause to reflect on my own past.
After I had been teaching full time for a few years, I moved into a non-teaching role, managing and coaching teachers. I jumped at it despite being unprepared: my school trained me in management (which I enjoyed) and teacher coaching (which I was very skeptical about). I was tired of the grind of teaching, and moving into a management role seemed like a good way to support teachers.
Ultimately school management burned me out in a way that teaching never has. I eventually left that school to take an industry job, only to return to teaching after a year. These have easily been the most productive and effective teaching years of my career—thanks to my time spent observing and coaching other teachers; training sessions I partcipated in to prepare for managing teachers; and collaborations with co-teachers and TAs who have taught, challenged, and inspired me.
At my current school, most of the teachers stay for only a year or two. One promising teacher I worked with burned out after six months and moved into an administrative role; most others have left the school and returned to industry practice. The past year I’ve noticed less turnover of teachers. I think many have simply stayed to avoid searching for a job during a pandemic. (The irony that we prepare students for a job search during the same pandemic is not lost on me.) I find myself wishing that the teachers who have stayed may discover that the job gets easier and more rewarding, and stick with it.
I’m hopeful that my colleagues who are moving to work on curriculum will feel challenged, will learn and grow in new and unexpected ways, and that they will find approaches that help our school’s teachers and students.
But in my heart I hope that they will find their way back to teaching.
This tutorial is meant to be accessible to developers of all experience levels. It can be thought of as “CSS transitions 101”. That said, I’ve sprinkled in some interesting and obscure tidbits — no matter your experience level, I bet you’ll learn something!
Nice shallow-to-deep dive into crossword puzzles from Russell Goldberg in The Pudding:
“Cookie that some people eat with mustard.” Before 2020 got crazy, this little clue from a USA Today crossword puzzle captivated a nation.
Have fun.
When you’re ready for something more sobering, and haven’t had your fill of crossword puzzle analysis, Michelle McGhee has an awesome breakdown of how inclusive various crossword puzzles are, Who’s in the Crossword?:
As a puzzle lover, I wanted to better understand who is being referenced in crossword puzzles — an unexplored piece of this puzzle. I teamed up with The Pudding to see if the people in crossword clues and answers represent the people who could be solving them. To measure this, we looked specifically at clues and answers that include the names of real people.
One of my favorite activities to use in class is a short sequence of “do, pair, share.” Some teacher friends introduced me to the idea, and you can find some version of it anywhere teachers congregate, often going by the name “think, pair, share” or “write, pair, share.”1
I first started using this approach in my design classes in 2015. I was skeptical at first. I had tried a couple of strategies before, recommended to me by teachers who were used to working with kids—like cold calling, and keeping a visible timer on the projector—and these seemed condescending to adult learners. I had the same doubt about “do, pair, share,” and I felt uncomfortable the first several times I tried it. But—I could almost immediately see the benefits, and it motivated me to practice and improve my approach.
Now I use it all the time. It’s the first thing I reach for when I have a doubt about what students understand, or when I want to get everyone participating in a brainstorm. I also find it helpful in meetings, workshops, and retrospectives—it’s a flexible tool. Try it with anything that participants could spend a few minutes doing independently, and get the ideas flowing.
Summary
What
Participants perform a short task alone, then compare with a partner, and finally share with the whole group.
Why
To get everyone involved in a discussion; to discover the current level of understanding of the whole group.
Materials Needed
Writing and drawing tools, plus any materials needed for the task
Difficulty
Easy
Time Required
10–20 minutes
How to do it
Steps
Suggested time
Give participants the short activity or question you’d like them to answer, with a time limit for how long they have to work alone.
1–2 minutes
As participants complete the activity, observe what they are writing or drawing to see how everyone is doing.
2–5 minutes
When time is up, ask participants to get together with a partner to discuss what they did and compare notes.
1 minute
Again, observe each pair as they discuss to check how they are doing.
2–5 minutes
Ask for volunteers or call on pairs to share what they came up with with the whole group.
5–10 minutes
Example use
At the beginning of a lesson on planning user interviews, I like to give students a prompt such as, “Imagine that you will be doing research to learn more about people’s movie and series watching habits. Take 2 minutes to write down at least 3 different things you’d be curious to find out.” After the activity, as partners share their questions, I can collect these on a shared board, to use as a starting point for the next part of the lesson.
Considerations for use
Keep the activity small and manageable in scope
Give clear instructions for the activity; consider showing them in writing where everyone can see
Depending on the activity, it may help to provide participants with a template or worksheet
A visible countdown timer can help keep participants on task during the activity
Considerations for use in person
If possible, arrange the room so you can walk around and observe without disturbing participants
Ask participants to find a new partner, or someone they don’t know well, each time you have them pair
Considerations for use in remote
Do the solo part of the activity quietly together in the primary room, then split into randomized breakout rooms for pairing
Use a shared digital canvas for the activity, where everyone can see everyone’s work
Consider creating a template with a space for participants to put their name and work in the shared canvas
At the end, share your screen to drive the focus of the group toward whichever pair is sharing what they came up with
I prefer “do” to “write” or “think”. Thinking is an active process, but as a facilitator, it’s difficult to observe people thinking. Asking participants to write down ideas or explain something in their own words is a great use of this technique, but I find it equally useful to ask people to draw, diagram, pseudo-code, construct… You get the idea. So the generic “do” it is. ↩