The short-short explanation is that:

• There are multiple members of my family whose disabilities have worsened in the last 12 months.
• While most of us picture “caregiving” as handling the basic activities of daily living (ADLs) like eating or dressing the person involved, it’s actually the instrumental activities — managing medical appointments, managing the household, etc. — that eat up a ton of time.
• Those same activities mostly have to be done during “standard work hours” because the specialists we see work the same hours we do.

I’ve reached a point where it’s more important for me to project manage the Gibson house than it is for me to project manage a design system or a financial product.

But people gotta eat, right? The bills won’t pay themselves and the Mega Millions is stubbornly not picking my numbers.

Over the next few months you’ll see activity ramp up here, as I take on (and look for) what I call “odd jobs”.

Get in touch if…

• You want someone to consult on a startup you’re building, or provide (light!) design work.
• You’d like me to present a talk based on An Alphabet of Accessibility to your organization.
• You need someone to thoughtfully content audit or migrate some content from A to B for 10 hours a week.
• You haven’t touched your portfolio in two years and your employer’s hinting at layoffs.
• You want to migrate off of WordPress. (I’m still working on this one! Large learning curves ahead!)
• Something else! Let me know!

I’ve been doing freelance design and development work on occasion since the Geocities days, so when you reach out, you’ll know that you’re speaking to someone who cares about quality, accessibility, and common sense design. I look forward to it!

Turns out deck.blue won’t do that either (is there a tweetbot for bluesky yet?) but while discovering that, I also discovered it has, well, janky scroll animation.  I’m not sure I want to call it scrolljacking since this whole app (and all the other social media apps) is steeped in so much scripting that they all seem to write their own scrolling, but I digress.

When I asked them to stop it they asked me to clarify and I took a video of my screen and, well, here we are.

Hi! Sorry I’m posting this on my blog but deck.blue won’t let me upload a .mov file or an .mp4 file of my screen so I’m posting here.

I wrote:

You replied:

So let me clarify a few things because I’m not sure we’re talking about the same thing and even if we are, I’ve done enough tech support to know me setting context will help you.

I’m on Safari 16.6 on a MacBook Pro running the latest Ventura update.

I’ve got active accounts on twitter, Facebook, LinkedIn, tumblr, three Mastodon instances, Blue Sky, tiktok, Instagram^[1]technically, it’s so damn annoying to use I avoid it and probably a few dozen come-and-gone social media accounts.

With the exception of tumblr^[2]because tumblr’s threading mechanism is much more thorough than anyone else’s, mostly, plus I’m not reading the news on there, and tiktok ^[3]which doesn’t have anything one could call an “order” it’s just chaos you can flip through I read all of them in chronological order. Not reverse chronological order, actual chronological order.

In Tweetbot, on twitter that was easy because when I closed the app, it remembered what tweet I was looking at, and when I reopened the app I was still looking at that tweet, just with a lot more new tweets loaded “above” the screen that I had to scroll up to.

Since Tweetbot’s demise, my usual routine is to open a site, scroll down my feed until I recognize something, then slowly scroll up reading each post in turn, until I reach the top again. That way the posts make sense and I get to see everyone I’m following. (I don’t follow a lot of people on any given service because I learned on twitter that I’ve only got the time to read about 200 people worth of posts a day.)

What’s the issue?

The problem with deck.blue isn’t scrolling down, it’s my slow scroll up. I’ve got all the most recent skeets loaded loaded in memory I presume, because i just scrolled past them to get to my starting point. And as I scroll up, things seem smooth for a bit. Then suddenly the feed will jump down like half the distance of the column.

Alt text for video: Video of the column scrolling smoothly, then jumping position, then scrolling smoothly, then jumping position again. No audio. Sorry this alt is so pants, I’m still trying to figure out how to get wordpress to cooperate some days. Similar apologize if the video is taller than your browser.

So why’s this an issue?

First, as Nielsen-Norman point out about scrolljacking:

When it comes to scrolling, users have strong mental models: they expect to scroll vertically, at a consistent rate that is related to how they are physically interacting with their input device.

In most computer operating systems, the default scroll speed can be manually adjusted to be more sensitive or less sensitive, but it is always consistent. Users expect a consistent scroll rate across all the applications on their devices.

When a website alters the default scroll functionality, it “hijacks” the user’s control over their device and can generate disorientation.

So right off the top this is a usability issue because it breaks the user’s mental model, and when my mental model is broken I get grouchy and annoyed.

Second, there are a lot of people who find it easier to read when they have a strong visual anchor that they can associate with the line of text they’re currently reading. For example, people with dyslexia  often find it easier to read printed (paper) text when they have a reading ruler to help them focus on a single line of text at a time.

A reading ruler works by reducing visual distractions and increasing focus. People with dyslexia often experience visual stress when reading, which can make it difficult to concentrate on the text. A reading ruler can help to reduce this stress by blocking out surrounding text and highlighting only one line at a time.

Now, I don’t have dyslexia, but I do find it much easier to read when I can reduce visual distractions and increase focus. I’m pretty sure everyone does. Over the (many) years I’ve worked on computers and the web, I’ve made it a habit to pick a specific location — usually the top of a window, but sometimes further down, with my pointer right next to the text — that marks the line I’m reading. Instead of reading down the page, I use the scrollbar to move the line of text I’m reading to my “reading ruler” point.

So when I’m reading something and then because of inconsistent scrolling speed a totally different set of content has moved to my “reading ruler” point, I get really damned frustrated. Now I have to scroll down, find what I was reading, move it back to my reading ruler point, and then continue reading — until it happens again. ^[4]This is also why sites that play hide-show games on scroll with their global headers can get in the fucking sea. Looking at you, Medium.  STOP MOVING MY READING RULER YOU BASTARDS.

As a designer, then, I find this technical “glitch” to be bad design because it undermines the user’s mental model. As an accessibility professional, I have concerns that it increases difficulty and/or destroys the ability for someone with a reading disability like dyslexia to follow the content. As an armchair developer I have no idea why something would unevenly scroll when the content’s already loaded. ^[5]I suspect it has something to do with the skeet height? But have no idea why?

And as a user, well, I’m really hoping this is something you can fix, because I think it will give you a much more effective application. Bonus points if you can do the same thing as  Tapbots and let me read in chronological order without having to find my place every time I launched the app or walked away for a few minutes.

Anyway, all of this isn’t to name-and-shame, it’s to say hey, here’s the problem I’m having, I can’t post my video on the app so please excuse me for using my blog, and maybe the people following along will learn some stuff about scrolljacking and accessibility and dyslexia while they’re here. Thanks for listening!

I bought this book when it came out because I saw Mike give a presentation about being a good designer, probably at An Event Apart. I then stuck it on a shelf. That was about 10 years ago, when I was still an arrogant snot-nosed designer raised in the Philly area who thought she knew it all. Considering Mike’s reputation for much of the same (including the Philly) someone should have shoved the book in my hands, chained me to a chair, and said “LEARN.”

Now I’m 15+ years into my career as a UX Designer and knowledgable enough to know that if I want to to keep being an arrogant know-it-all designer I have to do better at knowing it all, and I have to work on my delivery. There’s only so many times in your life that you can get away with having “Must work on communication skills” will show up on your review before everything else about your growth won’t matter. Fortunately, I learned that a few years ago, and now I’m actually listening to people and, damn, that makes work easier.

This book will teach you those lessons faster, if you’re willing to learn. If you’re willing to learn, this will teach you how to work with a lawyer, what belongs in your contracts, how and why to talk about money, and how to present. If you’re not willing to learn, this book will present reasons on why you should be willing to learn, which hopefully would have penetrated my younger thick skull.

Mike’s examples are clear and concise, truthful while still keeping everyone’s privacy appropriately, and constructive. Also, he’s funny.

Talking to teens about sex is a lot like talking to designers about contracts. “We’re being careful. We’re in love. We trust each other. They have an agile process. He promised there wouldn’t be any backend development.

More than anything else, what Mike brings to this book is his desire to see you succeed as a designer, whether you’re working inside a big corporation or as a consultant or at an agency or on your own. He emphasizes treating our peers in the industry with respect, so that we can all raise the quality of design in the industry and, presumably succeed even more.

If you are any kind of designer, content strategist, product manager, or even engineer, read this book. You’ll find ways to improve your working relationships with others as well as ways to produce and execute better ideas, wherever you are.

“Someday, that will be you,” they said. “You should write a book.”

I was shocked years later to find out that not all UX teams or leaders believed it was our responsibility to pass on what we’d learned. Still, I knew enough people who, like me, felt that passing on our knowledge was one of the responsibilities of a good designer, so I found myself writing a column on a design-related site, then launching my own design-related site with some friends, then giving talks about the things I’m passionate about. But finding time to write a book? Hah.

Now I’m in a situation where the time has been thrust upon me. I don’t particularly like public speaking, and I’d much rather not attend a mess of conferences in our not-quite-post-COVID 19 world. Writing a book seems like a reasonable choice. Still, I am not usually a person to take big risks.

You Should Write a Book by Katel LeDû and Lisa Maria Marquis is a critical book for people like me, who don’t want to move forward without some guideposts and who don’t want to bug their friends for hints or tips.

It does not go into depth about every single step. (There are lots of resources that will provide that for you, and they are dependent on the choices you make on how to write, polish, and publish your book.)

It does give you the map of the process, the understanding of why each of the process steps is there, what differentiates one choice for another, and a pretty deep appendix of next-step sources.

It is also intentionally written to encourage both non-marginalized and marginalized writers. The authors acknowledge in the beginning that they are “college-educated, able-bodied, cis white American women whose direct book-publishing expertise derives mostly from a single organization: A Book Apart. While we hope our perspective is useful, it is also bound to be limited in certain respects.” These authors essentially say that the process for publishing a book is the same for both marginalized and non-marginalized authors, except that that marginalized authors have to do it on hard mode.

This book will not tell you how to choose whether to self-publish or not. It will tell you about self-publishing and what the differences between it and traditional publishing are. It won’t tell you where to find editing or marketing services. It will tell you what they are and why you want them. It won’t tell you what to write about. It won’t tell you what anything costs — those numbers go out of date too quickly anyway. It will gently laugh at you if you think that you can retire on the money from one book.

Because the authors are deeply and intimately familiar with the publishing house A Book Apart, where they both work, they are able to not only give you insights into ABA’s publishing methods but also give you insights from ABA’s authors, who they’ve spoken to about the publishing experience.

In short, all models of the publishing industry are wrong, and this one is useful.

It’s a big undertaking. ^[3]Building a design system, I mean, not the book. Although I think the book will be a big undertaking too — it’s just that books tend to be finite creatures that you can finish, and design … Continue reading

It’s an undertaking that I’ve been involved with for three different companies now — as a consumer of the system at Vanguard, and as a designer at both Boomi and Vertex.

But really, I wouldn’t have made the jump from consumer to designer successfully at all if Jeremy Keith hadn’t given a talk in 2018 called The Way of the Web. ^[4]It is not one of his best-known talks and for that matter if I hadn’t found these sketchnotes I’d really be wondering if I made it up right now.

In that talk, Keith summarized the concept of pace layers, presented by Stewart Brand. It surmised that culture builds from a bottom layer of nature (which changes very slowly) through multiple layers until it reaches fashion (which changes almost too rapidly to track), and that by understanding the relationships between the layers, we can better understand how and where to effect change.

Keith’s suggestion in his talk was that a similarly-structured pace layer could be built from TCP up through Javascript and other scripting libraries, from the slowest changing layers of the internet through the fastest.

At the time I was prepping for my own talk so the idea kind of grabbed on to the back of my brain… and there it started gnawing on things.

Building a design system is often challenging and frustrating because some things about it (such as, for example, the organization’s voice and tone, or the corporate font) change rarely, but have huge impacts. Others, such as the fashion of flat design or the implementation of specific interactions, change frequently but only impact small subsets of the full design system. As a designer, I’ve found that understanding the difference between scheduling a change to the corporate font and scheduling a change to the 4th carousel owned by the 2nd subdivision of importance in the organization is the key to ensuring that the design system is given the budget to grow — and the key to ensuring that the design and development partners don’t want to string me up.

But to explain all of that, first I had to be able to explain pace layers. And while I was pretty sure I did understand them, if one wants to start writing a book it’s a really good idea to read the source material before running one’s mouth.

Then I bought the wrong book.

See,  my brain is a muddled mess of memories from various conferences and web events. Learning about pace layers is definitely one that sticks out. Another that sticks out is discussion of the Long Now Foundation.

This foundation is dedicated to taking the long view on time. The very long view. Like, a clock that runs for ten thousand years long. People who place bets that take a minimum of two years to prove out true long. Storing a sample of all the world’s languages in nickel long.

And while The Clock of the Long Now does, indeed, discuss pace layers in chapter 7, the bulk of the book is about taking the long view on what we put into the world. In the case of web design and development this can mean everything from choosing HTML as your primary markup language (and not coding everything in JavaScript) to deciding which companies and projects you’ll still be proud to be associated with 20+ years into your career.

(I also remember a lot of conversations about how future forward design is progressive enhancement from older technology, and a lot of men getting their pictures taken in a space helmet, but once again the terminology to find proof of these things eludes me tonight.)

It turned that reading The Clock of the Long Now was not a mistake on my part (more of a lucky accident) because it’s helped me understand and maybe even figure out how to explain that one of the biggest challenges with a design system is that it’s a system. You’re designing a system that, if successful, cuts design and development time for the whole organization. But that means you’re also designing a system that will require time to develop, time to adopt, time to grow, time to stress-test. It is not a short-term two-quarter project with a payout at the end.

In other words, it works in long time, but in corporate-driven show-me-the-returns time, it may be hard for our Product people to buy into.

One of the amusing things about the book is that the edition I read was published right after the turn of the millennium (or the year 2000 for you pedants, don’t @ me about when centuries start), which is itself a millennia in web years. The Long Now Foundation still exists, which is a bit of a relief because basing my ideas on design systems on a long vision that subsequently died in the 20 years since the book was written would’ve been embarrassing.

Brand did seem to go out of his way to not make predictions about what the future would bring, outside of the fact that it 10,000 years from now life will likely be very different from today.  Still, there was more than one point where something said would pull me out of the book. Brand seemed quite optimistic, that the web would have the power to prevent people in power from spreading lies, for example, at which point I almost spat my drink across the room.

The book’s thesis, that we should take a long view if we want to work together to solve problems, is still valid 20 years later, and has helped me better shape the kinds of discussion points I’ll need to get the funding necessary for a quality design system. (I’m pretty sure Brand didn’t see that coming, but then, he probably wouldn’t be surprised either.)

So it’s a good, relatively short read, not directly about the web but definitely about the underpinnings of being a developer or a designer, and I recommend it to anyone interested in the longer view.

I’m recommending the book, however, because it illustrates that sustainability is one more excellent reason to run an efficient, cleanly-coded, performant website.

An efficient site lets a user do the task they arrived to do in the fewest possible understandable steps, and with the fewest possible distractions.

A cleanly-coded website has less code cruft, takes up less server space, takes up less time to transmit from place to place, and has fewer errors.

A performant website also takes up less server space and less time to transmit from place to place. Additionally, it makes the web feel “snappy” and increases user confidence and satisfaction.

All of those things help us burn less electricity (both as the web consumer and — more importantly — as the web producer), and as a result, increase the sustainability of the internet. Considering that the internet is, as Tom Greenwood puts it, a coal-fired machine, any increase we can make is progress.

Sustainability is important, but sustainability isn’t my passion in UX (at least right now). My passion is seeing that coal-fired machine become more accessible to people with disabilities and users in general.

Turns out that efficiency, clean code, and performance <i>also</i> increase accessibility. Especially when we’re talking about things like “yo how about you remove those eleventy billion javascript frameworks that aren’t accessible, eat a ton of server space, and make loading times agonizing, and try plain static html instead?”

We all have our passions in UX, and that’s good. It helps to keep the larger culture balanced. But it’s also excellent when we can places where our different goals can be met together using common techniques.

Whether you’re passionate about sustainability, accessibility, or just plain great UX, whether your interest is in software, hardware, or managing data centers, whether you are a lifelong tech geek who remembers when everything had to fit on a floppy disk or you’re new to the web and don’t remember a time before Amazon.com, Tom Greenwood’s book will have suggestions for how you can make your products, and our planet, more sustainable. And probably hit a good number of your other life goals on the way.

I am thrilled that this book emphasizes rigor in the craft of creating and presenting designs.

So many times I’ve sat through reviews where the designer couldn’t tell me what the business problem was, why the user needed the changes, how the user would get from place to place, or what the unhappy paths looked like. They failed to take notes (sometimes showing up without even a note-taking device, like, say, a pencil or a laptop), gave me a tour of our components on the page instead of telling me how someone would use it, and thanked everyone when done — but never followed up to let us know what they’d decided. Then, later, they complained that the product manager steamrolled their input on designs or ignored their feedback.

This book demands a lot of the person who wants to be successful. You have to think about your audience, practice presenting, take notes (or find someone who will), understand the problem you’re building against, understand the feedback you’re given, and be rigorous in your feedback decision-making process.

It also works. It works so very well. And it garners trust between us and our business and engineering peers way better than any less-rigorous process is capable of doing.

As soon as I started reading it, I started messaging people I know mentoring designers and said “yeah this book? this is the one you want.”

That’s not an accident — I’m reading more than I have in decades, and I do my best to review good books because reviews are a driver for sales, and good authors deserve to be rewarded for being good authors.

But it’s also an acknowledgement that I’m not talking about much else in UX right now. Even on The Interconnected, which is my usual ranting locus, the site was virtually silent last year.

Last year, I think we can all agree, was rough.

This year so far is better but that doesn’t mean much. When I walk the half marathon in Virginia Beach, mile 11 over the damned bridge is hell, but it being stupid hard doesn’t suddenly move the finish line closer.

Still, I think there’s a finish line around the corner, so I shall trudge on until I can fall onto the beach and soak my feet in the ocean.

Things that are looking up:

• I have a new job at Vertex, Inc. where we design software that calculates sales tax and VAT. I am pro-fair-taxes and also pro-make-taxes-easy, and in a lot of places (for better or worse) sales taxes fund lots of important local initiatives, so at least at the moment it feels like a good fit. I’m two months in and I haven’t seriously pissed anyone off yet, but the day is still young.
• I’m seeing more and more people in our industry concerned about accessibility and making things more equitable for all, regardless of disability. I refuse to say that the pandemic has any silver linings with 500,000 dead in my country alone. I will say that hard-earned lessons are still lessons, and hopefully we’ll come out of this with more accessible jobs, more accessible websites, and more people giving a damn about their own impacts on their neighbors’ ability to survive in an increasingly technical world.
• While we’re on the subject of survival, there’ll be a review coming up sometime soon on Sustainable Web Design by Tom Greenwood. I’m about halfway through now and already recommending it to coworkers. Many of the goals in the book align with accessibility goals and good information architecture goals, so I think it could become an asset in convincing our higher-ups (especially in enterprise product design) that good web design = good business, both on the surface and within the code.

I’m also working (slowly) on my own accessibility website, trying to bring together information from the WCAG and the Deque online training classes I’m taking, articles that I rely on, other books, etc.. The ultimate goal is somewhere that people can navigate through a list of components and find something that says “Oh, buttons? Here are all the WCAG guidelines, info on how to hit them, and info on how to test them, all in one place.”

That’s taking longer than I thought it would because

1. pandemic;
2. constant exhaustion;
3. I am the world’s worst estimator.

May you also be within sight of the next milestone, and may your strength hold out until you get there.

It is short. When they say on the cover it’s a 30 minute read they are not kidding you. The book is 62 pages. You can read it between meetings and still finish it in a day.

If you’re not familiar with the concepts of physical, emotional, and psychological safety as precursors to communication and collaboration, this book might not be compelling enough to convince you to pursue changing your behavior. Crucial Conversations or Radical Candor or one of the other big names in this topic line might be better for convincing the person with huge communication issues that they, in fact, have huge communication issues.

But I find Crucial Conversations is better for specifically conversations and tbqh I got nothing from Radical Candor except an emotional breakdown by trying to follow it. A Culture of Safety is much more down to earth (much less “my-bad-worker-left-and-started-a-coffee-shop silicon valley”).

This book would make a great companion to Burnout: The Secret to Unlocking the Stress Cycle if you were the manager of a burned out team (and especially if you were burned out yourself).

A Culture of Safety is technically aimed at managers, but many of the activities and directions can be approached successfullyby anyone who facilitates one or more regular meetings.

I’m not a big fan of “activities” in self-help books because so many of the popular books seem to delight in suggesting the kinds of activities that make my introverted thrice-burnt-out neuroatypical brain want to crawl under the desk. The activities in this book are not like those.

The activities in this book, for the most part, are light touch. “Ask everyone how they’re feeling at the beginning of a meeting” or “schedule a venting day when people can sign up to just go off about something bothering them and your job is to listen and understand.”  These are things that I can do as a product designer just as well as a people manager can. And because I’m a designer, the people on my team generally won’t even know I’m doing it to foster a culture of safety, they’ll just think it’s one of my quirks. I like that.

All told 100% win. Read book. Enjoy.