I work with lots of different teams and different developers. I usually know innately, as does the team around me, whether the teams we’re working with are good or not. We rarely disagree on the evaluation.
But what does good mean?
I find that the most valuable web developers interact with each other along a kind of implicit contract, the tenets of which are based upon web standards and proven ways of doing things that we’ve cobbled together collectively over the years. Most of the time, good isn’t generated by an individual in isolation—it’s the plurality of tandem efforts that hum along to a shared, web-driven rhythm.
When things are ticking along smoothly among devs, I find we have a common underlying way of talking and thinking about the web. We fit together in human and technical ways, upholding a shared understanding about how best to make pieces of the web fit together.
In contrast to the tired stereotype of genius coming in the form of a lone, intense hacker, much of the effective work done on the web is done within the bounds of a certain kind of communal conformance. In a good way.Working together
A heap of obvious things goes into making an individual web developer seem good: An innate understanding of time and effort. An indestructible drive to self-educate. A lick-smart, logical mind quick to spot and take advantage of patterns. I think we look for these talents naturally.
And yet when devs work together, those skills fade back just a bit. In a (grossly oversimplified) way, as part of a larger team each developer is a miniature black box. What comes fiercely front-and-center are the interfacing edges of the people and teams. The way they talk to each other and the timbre of what they build, what they disclose and what they don’t think they need to mention.
When something unexpected pops up between healthy teams—which happens, because this is a complicated world—a communication like, “Hey, when I poke this service in this way, it throws a 500 at me” as often as not is enough information for the recipient to go off and fix it, because we have have similar scars to reference and a shared vocabulary built on common ground.
A common vernacular and communication style is an echo of a common thinking style. Underneath the chatter are cognitive technical models of the metaphors at hand, based on each team member’s perception of how the web fits together—REST, modular patterns, progressive enhancement, etc.—and how those components apply to the current project. Happy days when those internal archetypes align.
When you run into misaligned teams it is obvious. There’s a herky-jerky grating to communication. Seemingly dashed-off emails that don’t quite dig into the problem at hand. Teams where you can tell each member’s mental context differs. Code that feels weird and wrong.A common ground engenders brilliant ideas
Unless it is the actual goal of the project, I don’t care too much if you can come up with a Nobel-worthy new implementation of a basic CRUD feature. In most cases, I’ll happily accept something predictable and expected.
This is not an argument for ignorance or apathy. Ideally, everyone should be pretty good at what they do—those individual technical skills do of course matter. I mean, part of the contract here does involve boots-on-ground time—to understand the lay of the land, to break HTTP into bits and pieces, leak some memory, screw up DNS a few times. We break and heal frequently as we gain deeper web mastery.
But having a web set of conceptual building blocks—standards, patterns, conventions—upon which we can frame and build gives us the freedom to focus on where we really need to be creative: the particular task, product, or site at hand. Common components, shared notions.
After all, the best chefs in the world don’t reinvent carrots. Instead, they identify what other remixed food components might plug into a carrot to make it divine.
Likewise, good developers are mixing up agreed-upon technical ingredients into the soup of the day. And just as a talented cook knows how to explain to the waitstaff the nuances that thyme brings to the potato, good devs know how to talk to those around them, team members both in the kitchen and beyond, about why today’s menu includes OAuth or moment.js.It’s not just touchy-feely
It used to be that I would think, “Hey, these people seem like they’re on the same wavelength as my team; that’s cool,” but now I realize it’s likely that what seems merely like good vibrations saves prodigious time and money on projects.
In damaged teams, mental reference dissonance carries through to the outcome, manifesting itself in jarring technical mismatches, poorly-thought-through integration seams and, frankly, bugs. It’s as if people are thinking about the web in different internal language systems.
So? Things take longer, often a lot longer. Teams become frustrated with each other. Meetings and discussions are drawn-out and less fruitful. The results suffer. Things break.
I’m not suggesting we all link arms and plow out code from a single hive mind. In fact, I’d argue that the constraints imposed by a common perspective help to drive a certain kind of unique brilliance.
A couple of years ago, I was asked to help put together a code of conduct for the IA Summit. I laughed.
We need a code of conduct here? The IA Summit is the nicest, most community-friendly conference ever! Those problems happen at other conferences! And they want me to help? There are sailors jealous of my cussing vocabulary—surely I was not PC enough to be part of such an effort. But the chairs insisted. So, being a good user-centered designer, I started asking around about the idea of a code of conduct.
I found out design conferences are not the safe meetings of minds I thought they were.
One woman told me that she had been molested by another attendee at a favorite conference, and was too scared to report it. “No one will ever see me as anything but a victim,” she said. “I’ve worked too hard for that.”
At another conference, a woman was woken up in the middle of the night by a speaker demanding that she come over. When she told the organizer in the morning, he said, “We were all pretty drunk last night. He’s a good guy. He just gets a bit feisty when he’s drinking.”
Then there was my own little story. Years ago at the IA Summit, I went to talk to a speaker about something he’d said. I’m a tall, tough lady. But he managed to pin me against a balcony railing and try to kiss me. I started wondering, what if there had been a code of conduct then? What if I had had someone to talk to about it? What if I hadn’t said, “Oh, he’s just drunk”?
Maybe I wouldn’t have spent the past seven years ducking him at every event I go to. And maybe he wouldn’t have spent those same years harassing other women—women who now were missing out on amazing learning and networking opportunities because they thought they’d be harassed.
The idea of a code of conduct didn’t seem so silly anymore.A wicked problem
Unfortunately, it still seems silly to others. Recently I was talking to another conference organizer about setting up codes of conduct, and he said, “That doesn’t happen at our conferences. People know me, and they know they can talk to me. A code of conduct will make people nervous that we have a problem. And we don’t.”
I wonder how he knew that, since most victims don’t come forward. They don’t want to be seen as a “buzzkill,” or be told that what they wore or what they drank meant that they asked for it. This is not unusual; every day we see examples of women whose reputations are trashed for reporting rape and harassment. On Twitter, women who talk about sexism in games or even think a woman should go on a stamp are given death threats. Reporting carries consequences. Reporting is scary.
In order to feel safe enough to come forward, attendees and speakers need to know that the conference organizers are paying attention. We need a guarantee that they’ll listen, be discreet, and do something about it.
In her recent piece, “Why You Want a Code of Conduct & How We Made One,” Erin Kissane frames precisely why codes of conduct are absolutely necessary:To define a code of conduct is to formally state that your community—your event or organization or project—does not permit intimidation or harassment or any of the other terrible things that we can’t seem to prevent in the rest of the world. It’s to express and nurture healthy community norms. In a small, limited way, it’s to offer sanctuary to the vulnerable: to stake out a space you can touch, put it under your protection, and make it a welcoming home for all who act with respect.
A code of conduct is a message—not a message that there is a problem, but a message that there is a solution. As much as a label on a button or a triangle with an exclamation point in it, a code of conduct tells you how a conference works.Tweaking the UI
We are designers.
That means we make choices about the interface that sits between the people and the thing they want. We mock interfaces that aren’t clear. We write books with titles like Don’t Make Me Think. Yet when we hold conferences, we seem to assume that everyone has the same idea of how they work.
Why do we expect that people will “just know” how to use this complex build of architecture and wetware? There is a lecture; that means professional behavior! There is a bar; that means drinking and flirting! There is a reception; that means…alcohol plus speakers…network-flirting? A conference can be a complex space to understand because it mixes two things that usually have clear boundaries: social and work. If one person is working and another is looking to get social, conflict will happen.
These fluid boundaries can be particularly hard on speakers. Attendees often approach speakers with questions inspired by their talk, which could start a conversation that leads to work…or a date. It’s hard to tell; cautious flirting and cautious networking often look the same. People can feel uncomfortable saying no to someone who might hire them—or keep them from being hired.
Sometimes after giving a talk, I’ve mistaken admiration for flirtation, and the other way around. A wise speaker stays neutral, but it can be hard to be wise after a few glasses of wine. A code of conduct is useful because it spells out parameters for interaction. Some codes have even gone so far as to say if you are a speaker, you cannot engage in romantic activities like flirting. Clarity around what is expected of you leads to fewer accidental missteps.Set expectations
A good code, like a good interface, sets clear expectations and has a swift feedback loop. It must:
First we will listen.
Then, we will help you to determine the options that we have based on the situation. We will also document the details to assure trends of behavior are uncovered across locations.
Lastly, we will follow the situation to a resolution where you feel safe and you can remain anonymous if you wish to be.
A code of conduct is a little like a FAQ or a TOS. It’s clunky, and I hope someone comes up with something better. But it’s instructions on what to expect and how to behave and, most importantly, what to do when something breaks. Because, as we keep seeing, something will eventually break. It’s better if it’s not people.
A lot of conferences are adopting codes of conduct now. The Lean Startup Conference one mentioned above is heartfelt and crafted based on their values. The art and technology festival XOXO has an excellent one, based on the template from Geek Feminism. Yes, there’s a template. It’s not even hard to write one anymore. It doesn’t even take a long time.Meet (or exceed) expectations
Any good experience designer knows that setting expectations is worthless if they aren’t immediately met. Beyond writing a code of conduct, conference organizers must also train their team to handle this emotionally charged situation, including making sure the person reporting feels safe. And there needs to be a clear, established process that enables you to act swiftly and decisively to remove violators.
So how should a conference handle it when the code is violated? There are a couple of telling case studies online: one from Elise Matthesen at the feminist science fiction conference WisCon, and another from Kelly Kend at XOXO.
In both cases, these women were immediately supported by the people they spoke with—a critical first step. In Kelly’s case, she brought her situation directly to the organizers, who listened to her and made it clear they weren’t going to blame her for the incident. Once the organizers had made her feel safe, they removed the harasser. It was improvised action, but effective.
In Elise’s case, it’s clear that WisCon was well-prepared to handle the incident. The first part of the story is exemplary:
Unfortunately, WisCon fell down when it came to acting on the report. Eventually the harasser was banned, but only after a slow and onerous process. And the ban isn’t permanent, which has infuriated the community.
It is hard work to get the poison out of the apple. Elise writes, “Serial harassers can get any number of little talking-to’s and still have a clear record,” which has been my experience as well. Since I started writing about conference harassment, a number of women have spoken to me about incidents at various design conferences. Two names keep coming up as the abusers, yet they continue to get invitations to speak. Until more people step forward to share their stories, this won’t change. And people cannot step forward until they are sure they won’t be victimized by the reporting process.
If you are a conference organizer, it is your job to make sure your attendees know you will listen to them, take them seriously, and act decisively to keep them safe.
If you are an attendee who sees harassment, stand up for those who may be afraid to step forward, and act as a witness to bad behavior.
And if you are harassed, please consider coming forward. But I can’t blame you if you choose not to. Keep yourself safe first.A promise
John Scalzi, author of several best selling sci-fi novels, made a pledge to his community that he would neither speak at nor attend any conference without an enforced code of conduct.
I will make the same pledge now. I will honor any commitments I’ve made previously; all new ones are subject to the pledge.
I will neither speak at nor attend conferences that do not have and enforce a code of conduct. This may prove hard, as many conferences I’d love to speak at do not have a code yet. But change takes sacrifice. Integrity takes sacrifice.
If you believe, as I do, that it is critical to make a safe place where everyone can learn and grow and network, then leave a comment with just one word: “cosigned.”
When it comes to turning your big idea into a proposal that you want to submit to a conference, there are no real rules or patterns to follow beyond “just do your best” and perhaps “keep it to 500 words,” which makes the whole process pretty daunting.
I’ve worked with a number of people submitting proposals to events over the past few years. I’ve been racking my brain trying to identify a strong pattern that helps people pull together proposals that provide what conference chairs and program planners are looking for, while at the same time making the process a bit more clear to people who really want to find their way to the stage.
I’ve found that it’s best to treat the proposal-writing process as just that—a process, not just something you do in a half-hour during a slow afternoon. One of the worst things you can do is to write your proposal in the submission form. I’ve done it. You probably know someone else who has done it. Most of our proposals probably sucked because of it. Hemingway advises us that “the first draft of anything is shit,” and this is as true for conference proposals as it is for just about anything.
When you write a proposal in the submission form, you don’t give yourself the time that a proposal needs to mature. I’ve found six solid steps that can help you turn that idea into a lucid and concise conference proposal that paints a clear picture of what your presentation will be about.
As I walk through these steps, I’m going to share my most recently created conference proposal. I’ve recently submitted this to some conferences, and I don’t yet know if it will be accepted or if I’ll have any opportunities to give this presentation—but following these steps made writing the proposal itself much easier.
Let’s get to it.Step 1: Write down the general, high-level ideas that you want to talk about
This is a very informal step, and it should be written just for you. I use this step to take any notes I’ve stored away on post-its or in Evernote, and turn them into something resembling a couple of paragraphs. It’s an exercise in getting everything out of your head.
You don’t need to worry about being factually accurate in what you’re writing. This is the opportunity to go with what you know or remember, or assume you know or remember, and get it all into some other medium. You can fix anything that is inaccurate later; no one is going to read this but you.
For example, I’m writing a proposal for a presentation about creating “skunk works” projects (essentially, where small teams work on secret/necessary endeavors) to get things done when you’re busily leading a team and don’t really have time to get all the things accomplished that should be in place.
Here’s what I started with:
Something About Skunk Works Projects
The overall premise is that teams are really busy and if you’ve recently grown one (in-house or otherwise), you know that all the bodies go to the work, and little goes to the stuff that helps make a team purr along nice and smoothly, such as efficient on-boarding processes, sharing of thinking, processes, definitions, etc. Skunk Works projects can help you continue to increase the value to your team (and others) and also provide the team with an outlet for growth.
Is there a formula? There sure is, and I can trace a lot back to Boeing, and other places like Atari & Chuck E. Cheese, and my own current “stuff.” It dovetails nicely into the guerrilla stuff that I’ve done in the past, and the leadership I’ve been doing recently.
That’s the idea—how to get stuff done for your team when you’ve got so much stuff to do that you don’t have time.
This is an extremely rough draft, and should be for your eyes only—despite the fact that I’m sharing mine with you here, in its poorly written and somewhat inaccurate state.
At this point, you’ve earned a break. You’ll want to be fresh for the next step, where we start to build a supporting backbone for your free-flowing words.Step 2: Break your content into topic points
Review what you’ve written and begin to break that content into topics. I create bullet points for “Pain,” “Solution,” and two rounds of “Support.” I also add a bullet point I call “Personable,” so that I have a place to add how the idea is relatable to my own experience (though this sometimes ends up being covered by one of the Support points).
This isn’t final content; go ahead and lift sentences from your previous paragraphs if you feel like they’re relevant. Grammar still takes a backseat here, but do make sure that you’re addressing the topic point with some clarity. Also, spend a little time doing some fact-checking; tighten your points up a bit with real and concrete information.
As I was working through this step, I did a little more homework. I cracked open a few books and hunted down articles in order to refresh myself and feel like I was on more solid ground as I pulled the points together.Pain
When you think about your presentation’s topic, what is the common point of pain that you believe you share with other people? What prompted you to feel that this is a strong idea for a presentation and worthy of sharing? Pain is something we all share, and when you can help someone else feel like their pain might be alleviated, they start to nod their heads, mentally say “yes!” to themselves, and begin to relate to you and your message.
Pain point: Work has to get done; organizational good “stuff” often comes last, which means it never gets done because the bills have to get paid and people get booked on project work first.Solution
After you’ve identified that common point of pain, what’s the general, high-level solution? If you are the person who found the solution, you should say so; if not, you should identify who did, and explain what you learned from it. Give enough information to assure people there is a solution. Don’t get hung up on feeling like you’ll give away the ending; people will show up to your presentation to hear more about the journey you’ve taken from that common point of pain, not just to hear you recite the solution itself.
Solution: Don’t worry, others have used skunk works to have some great successes. Companies such as Google, Microsoft, Ford, and Atari have done amazing work with skunk works. So have I, and I’ll show you how I’ve done it so you can put it into practice for yourself based upon my loose framework.Supporting points
Once you’ve worked through the pain and solution, it’s time to provide a little more information to the reviewers and readers of your proposal. Merely telling people that there is pain and a solution is great to lead with; however, it’s not enough. You’ll still need to convince people that this idea applies to a broad range of other contexts, and that this is a presentation that they need to see so that they can benefit from your wisdom. What are a couple of key points that you can use to support the validity of your proposal and the claims that you may have made?
Support 1: Origin in the 40s with Lockheed. They used it to create a jet fighter to help fend off the German jet fighter threat in 1943. Kelly Johnson and his team designed and built the XP-80 in only 143 days, seven less than was required.
Support 2: Kelly had 14 Rules & Practices for skunk works projects—we don’t need them all; however, we can learn a lot from them.Something personal and/or humorous (optional)
If you’re able to pull something personal into your proposal, you can help reviewers and audiences members further relate to you and what you’ve been through. It can shift a proposal from appearing to be “book report-ish” to one that speaks from your experience and perspective. I like to leave this as optional content because you may already be adding something similar in the Pain, Solution, or Supporting points sections.
It’s important not to overlook the value—and the risk—of humor. Humor is tough to do in a conference proposal. You may have a line that you find hilarious; however, great comedy relies heavily on nuances of delivery that are difficult to transmit in a written proposal (and sometimes even harder for the readers to pick up on). Take caution, and when in doubt, skip anything that could be misperceived when creating your proposal.
Personal: I’ve pulled together skunk works teams and busted out some skunk works projects myself!
Humor: The results smell pretty damn good. (Wah wah wah.)
Together, these provide the foundation for the next step, which is where we start to get more serious.Step 3: Turn your topics into a draft proposal
This is where we take the organization and grouping of your thoughts and turn them into a few short paragraphs. It’s time to turn on the spell checker and call the grammar police; this is a serious activity and the midway point to having a proposal that’s ready for submission.
You’ll be writing the best, most coherent sentences that you know how to craft based on your topic points. You should use your topic points as the outline for your proposal, hitting the ideas in the same order. As a refresher, here are my topic points, in the order they were created.
Pain: Work has to get done; organizational good “stuff” often comes last, which means it never gets done because the bills have to get paid and people get booked on project work first.
Solution: Don’t worry, others have used skunk works to have some great successes. Companies such as Google, Microsoft, Ford, and Atari have done amazing work with skunk works. So have I, and I’ll show you how I’ve done it so you can put it into practice for yourself based upon my loose framework.
Support 1: Origin in the 40s with Lockheed. They used it to create a jet fighter to help fend off the German jet fighter threat in 1943. Kelly Johnson and his team designed and built the XP-80 in only 143 days, seven less than was required.
Support 2: Kelly had 14 Rules & Practices for skunk works projects—we don’t need them all; however, we can learn a lot from them.
Personal: I’ve pulled together Skunk Works teams and busted out some Skunk Works projects myself!
Humor: The results smell pretty damn good. (Wah wah wah.)
Once you’ve reviewed your topic points, put your writing skills to work. I did more gut-checking and fact-checking to make sure I wasn’t completely full of crap and to generally tighten up my thinking.
The Science of Skunk Works — Making Sure the Cobbler’s Kids Get Shoes
We’ve all worked at places where there’s never enough time to make sure that things are operationally done the “right way”—bills need to get paid, client or product work needs to get done and takes priority, and hey, everyone deserves to have a little bit of a life, right? There is a bit of a light at the end of this tunnel! Several companies, including Atari, Chuck E. Cheese, Ford, Microsoft, and Google, have pulled of some pretty great things by taking advantage of skunk works teams and projects. I’ve been fortunate enough to see a little bit of success with those teams and projects, as well, and will share how you can apply them to your own practice.
Way back in the 1940s, Kelly Johnson and his team of mighty skunks used their skunk works process to design—and build—the XP-80 prototype jet fighter to compete with the Germans. In 143 days—seven days less than was needed. Kelly created 14 Rules & Practices for skunk works projects in order to help articulate the most effective way for his team to successful in the projects that they worked on. We can learn from Kelly’s rules, adapt them to our current times and perhaps more digitally dependent needs, and find some ways to put some shoes on the cobbler’s kids. And the results might just smell pretty good, if you’re patient enough.
Notice that I didn’t just take the topic points and copy and paste them into paragraphs. Instead, I put on my editing hat and tried to establish the flow of what I was writing, keeping the paragraphs limited to 2–3 sentences for the sake of concision.Step 4: Phone a friend
You know that friend you can always count on to tell you when you’ve got a booger on your noise or spinach in your teeth, or who will tell you when you were just a completely out-of-line jerk and you need to get your head on straight?
That’s the friend you want to send your proposal to. If you’re fortunate enough to have more than one of these friends, send it to all of them. Explain to them—clearly—what they’re about to read and what the purpose is. Give them enough background so that they can provide you with actionable feedback. Tell them about the conference, the expected audience, your topic, why you’ll be good presenting on this topic, and what your proposal is about. Finally, give them a deadline of a day or two so they can review it with the focus that it deserves.
I sent my proposal off to my friend Gabby Hon, because she’s that friend who will tell me all those things I listed above and because she’s a words-and-grammar nerd who kicks my work as hard as it needs.
She sent me feedback, and, for once, my confidence was a bit higher than it should have been. I really like my topic and really felt strongly that I’d pulled together a solid proposal. Gabby’s feedback was essentially:
Not only did Gabby provide some great things for me to think about and improve on, she was also gracious enough to let me know that I didn’t entirely stink up the page when I’d written my proposal:
Once you’ve had time to process the feedback, sit back down with your proposal and make adjustments. Don’t be shy about killing your darlings; the feedback you’ve received is meant to help you focus on the important parts and make them better. If something doesn’t fit, move it to a parking lot or remove it entirely.
Here is my final revision that I’ll be submitting to conferences:
DesignOps Skunk Works: Shoes for the Cobbler’s Children
We’ve all worked at places where there’s never enough time to make sure that things are operationally done the “right way”—bills need to get paid, client or product/project work needs to get done and takes priority, and hey, everyone deserves to have a life, too. There is light at the end of this tunnel! Several companies, including Atari, Ford, Microsoft, and Google, have pulled off some great things by taking advantage of skunk works teams and projects. I’ve been fortunate enough to see some successes with those teams and projects, as well, and will share them so you can see how to apply the approach(es) to your own practice.
Way back in the 1940s, Kelly Johnson and his team of mighty skunks used their skunk works process to design—and build—a prototype jet fighter in 143 days. Kelly established 14 Rules & Practices for skunk works projects in order to help articulate the most effective way for his team to be successful in the projects that they worked on. Not only can we learn from Kelly’s rules and adapt them to our current methods of working, we can also create our own skunk works teams and projects to ensure that the cobbler’s kids—the operational areas of our design practices—get some shoes put on their feet. And the results might just smell pretty good, if you’re patient enough.
There’s a bit of a method to my madness, believe it or not. Here’s a micro-version of the change log of my proposal:
You likely had a conference in mind when you started trying to pull together your proposal. Each year, I start contemplating my primary presentation for the next year as soon as I can. Generally, starting around March through April or May is when I really start to try and think about what I’ve learned and what is worth sharing with others, and then I start collecting information—notes, articles, books, and so on—so that I can support my thinking as best as I can.
When I go through this process, then I know that I’m ready with a pretty solid proposal. I copy and paste the final, vetted version into the form and hit submit, confident that I’m not just winging it.
And sure enough, that’s when I find that last typo.
In 2005, my husband and business partner Drew McLellan had an idea for a website. He emailed friends and colleagues, we filled in the gaps, and 24 ways was launched: 24 articles in the run-up to Christmas, advent-calendar style. As I write this article, we are on day six of season 10 of that project. By 24 December, there will be 240 articles by 140 authors—many of them well-known names in web design and development. As a fun holiday season retrospective, I thought I would take a look at what 10 seasons of 24 ways can tell us about how our industry has changed—and what hasn’t changed.Hacking our way to CSS complexity
By 2006, Andy Budd was teasing us with the rounded corner possibilities brought to us in CSS3 and in 2007, Drew McLellan helped us to get transparent PNG images to work in Internet Explorer 6. The article titles from those early years show how much of our time as designers and developers was spent dealing with browser bugs and lack of CSS to deal with the visual designs we wanted to create. The things we wanted to do were relatively simple—we wanted rounded corners, nice quote marks, and transparency. The hoops we had to jump through were plentiful.
The introduction to the 2013 archive of 24 ways notes that 2013 was the year that the Web Standards Project “buzzed its last.” By 2013, browsers had converged on web standards. They were doing standard things in standard ways. We were even seeing innovation by browser vendors via the established standards process. My article for the 2013 season described the new CSS Grid Layout specification, initially developed by Microsoft.
Since 2005, the CSS that we can consider usable in production has grown. We have far more CSS available to us through browser support for the new modules that make up CSS3. The things that CSS can do are also far more complex, expressive, and far reaching. We’ve moved on from spending our time trying to come up with tricks to achieve visual effects, and are spending a lot of time working out what to do with all of this CSS. How do we manage websites and web applications that are becoming more like complex pieces of software than the simple styled HTML documents of days gone by? Topics in recent years include new approaches to using CSS selectors, front-end style guides, Git, and Grunt. The web has changed, and the ways in which we spend our time have changed too.We all got mobile
In the 2006 edition of 24 ways, Cameron Moll explained that,
The mobile web is rapidly becoming an XHTML environment, and thus you and I can apply our existing “desktop web” skills to understand how to develop content for it. With WML on the decline, the learning curve is much smaller today than it was several years ago. I’m generalizing things gratuitously, but the point remains: Get off yo’ lazy butt and begin to take mobile seriously.
The iPhone wasn’t launched until 2007, a move by Apple that forced us all to get off our lazy butts and think about mobile! In December 2007, Brian Fling explained the state of the mobile landscape half a year after the launch of the iPhone. It wasn’t until responsive design was brought to life by Ethan Marcotte on A List Apart in May 2010, however, that articles about mobile really became numerous on 24 ways. The 2011 season had four articles with the words “responsive design” in the title!
By 2012, we were thinking through the implications of designing for mobile, and for mobile data. Paul Lloyd took a look back at the two approaches for responsive images discussed in the 2011 season and the emerging proposals for picture and srcset in Responsive Images: What We Thought We Needed. Tim Kadlec reminded us that,
… there’s one part of the web’s inherent flexibility that seems to be increasingly overlooked: the ability for the web to be interacted with on any number of networks, with a gradient of bandwidth constraints and latency costs, on devices with varying degrees of hardware power.
As we rushed to implement responsive sites and take advantage of new platforms, we had to take care that we weren’t excluding people by way of bandwidth limitations. Whether it is IE6 or mobile data, some things never change. We get excited about new technologies, then come back to earth with a bump as the reality of using them without excluding a chunk of our audience kicks in!The work of change
I’m too old to be launching websites at midnight.— Drew McLellan (@drewm) November 30, 2014
In these 10 seasons, we can see how much the web has changed and we have changed, too. Every year, 24 ways picks up a new audience and new authors, many of whom would have still been in school in 2005.
Always, 24 ways has tried to highlight the new, the experimental, and the technically interesting. However, it has also addressed more challenging aspects. Whether an old hand or a newcomer to the industry, we can all feel overwhelmed at times, as if we are constantly running to keep up with the latest new thing. In 2013, Christopher Murphy wrote Managing a Mind, a piece that starkly illustrated the challenges that constantly keeping up can bring. This year, we are given a reminder that we need to take care of our bodies while performing the repetitive tasks that design and programming require.The business of web development
Often, 24 ways has featured articles that deal with the business of being a web designer, developer, or agency owner. In 2007, Paul Boag gave us 10 tips for getting designs signed off by the client. As the recession hit in 2008, Jeffrey Zeldman wrote up his Recession Tips for Web Designers. We’ve seen articles on subjects ranging from side projects to contracts and everything in-between.
The business archive contains some of the most evergreen content on the site, demonstrating that good business knowledge can serve you well throughout a career.The industry that shares
Another thing that hasn’t changed over these 10 seasons is the enthusiasm of each 24 ways contributor for their subject, and their generosity in writing and sharing their thoughts. This reflects our industry, an industry where people share their thoughts, research, and hard-earned experience for the benefit of their peers.
On that note, I’ll close my final A List Apart column of 2014. Best wishes to all of you who are celebrating at this time of year. I look forward to sharing my thoughts on the business side of our industry throughout 2015.
I’m trying to be learn more about accessibility these days. Thinking about it more, reading about it some, and generally being aware as I write code what I should and shouldn’t do in that arena.
I am grateful for the folks in our community who work tirelessly to make sure that I can easily find information about it online. The A11Y Project is constantly getting updates from the community to help me understand what are best practices. I just read Heydon Pickering’s book, Apps For All: Coding Accessible Web Applications, a short, but really good book to remind me of how I should be writing HTML.
I’m also speaking up more in meetings and on my project teams. When I see something that just doesn’t quite jibe with what I’ve been learning about accessibility, I bring it up. I also ask trusted friends about it too, to make sure I’m not crazy, but that it’s actually a best practice; because it matters. Sometimes the little things, such as removing an outline on focus or using empty links instead of button, are the things that can add up to a bad experience for people using the site with a keyboard or screenreader.
Unfortunately, sometimes I get pushback—especially when working on a minimum viable product or a quick project. There is always the answer of, “we’ll fix it later.” But will you? I’ve been working on applications and projects long enough to see that going back to refactor can be even tougher to make time for.
I try, when getting that pushback, to remind people of the fact that it’s hard to make the time for code refactors. Taking a little bit of time to do things right the first time around saves time in the long run. Eventually, I usually share the consequences some companies have faced when they don’t take accessibility seriously. I don’t always win the battles, but often reminding colleagues that there will be a wide range of people using the site—some of whom may not use it exactly as we do—is worth it. Hopefully, next time they’ll be more willing to take the time necessary up front.
I know this has been said before, but as I’ve started reading more and more on accessibility and trying to learn more about it, I’ve found it to be rewarding. Working on a project where all users can access and use it well, that’s satisfying. One of my most satisfying moments professionally was hearing from a blind user who was thankful they were able to use our app. And if you don’t think about accessibility, well, that can just lead to a world of hurt.