Jul
31

Ask Dr. Web with Jeffrey Zeldman: If Ever I Should Leave You: Job Hunting For Web Designers and Developers

Source: A List Apart

In our last installment, we discussed what to do when your boss is satisfied with third-party code that would make Stalin yak. This time out, we’ll discuss when, why, and how to quit your job.

When is the right time to leave your first job for something new? How do you know you’re ready to take the plunge?

Wet Behind The Ears

Dear Wet Behind:

From frying an egg to proposing marriage, you can never know for sure when it’s the right time to do anything—let alone anything as momentous as leaving your first job. First, search your heart: most times, you already know what you want to do. (Hint: if you’re thinking about leaving your job, you probably want to.) This doesn’t mean you should heedlessly stomp off to do what you want. Other factors must be carefully considered. But knowing what your heart wants is vital to framing a question that will provide your best answer.

So ask yourself, do I want to leave? And if the answer is yes, ask yourself why. Are you the only girl in a boys’ club? Perhaps the only one with a real passion for the web? Are other folks, including your boss, dialing it in? Have you lost your passion for the work? Are you dialing it in? Is the place you work political? Do your coworkers or boss undervalue you? Have you been there two years or more without a raise or a promotion? Most vital of all, are you still learning on the job?

Stagnation is fine for some jobs—when I was a dishwasher at The Earth Kitchen vegetarian restaurant, I enjoyed shutting off my brain and focusing on the rhythmic scrubbing of burnt pans, the slosh and swirl of peas and carrots in a soapy drain—but professionals, particularly web professionals, are either learning and growing or, like the love between Annie Hall and Alvy Singer, becoming a dead shark. If you’ve stopped learning on the job, it’s past time to look around.

Likewise for situations where you face on-the-job discrimination. Or where you’re the only one who cares about designing and building sites and applications that meet real human needs, and of which you can truly be proud. Or where, after three years of taking on senior-level tasks, and making mature decisions that helped the company, you’re still seen as entry-level because you came in as an intern—and first impressions are forever. Or where you will never be promoted, because the person above you is young, healthy, adored by the owner, or has burrowed in like a tick.

Some companies are smart enough to promote from within. These are the companies that tend to give you an annual professional development budget to attend conferences, buy books, or take classes; that encourage you to blog and attend meet-ups. Companies that ignore or actively discourage your professional growth are not places where you will succeed. (And in most cases, they won’t do that well themselves—although some bad places do attain a kind of financial success by taking on the same kinds of boring jobs over and over again, and hiring employees they can treat as chattel. But that ain’t you, babe.)

It’s important, when answering these questions about your organization and your place within it, to be ruthlessly honest with yourself. If you work alongside a friend whose judgement you trust, ask her what she thinks. It is all too easy, as fallible human beings, to believe that we should be promoted before we may actually be ready; to think that people are treating us unfairly when they may actually be supporting and mentoring us; to ignore valuable knowledge we pick up on the job because we think we should be learning something different.

If there’s no one at your workplace you can trust with these questions, talk to a solid friend, sibling, or love partner—one who is brave enough to tell you what you need to hear. Or check in with a professional—be they a recruiter, job counselor, yoga instructor, barista, or therapist. But be careful not to confide in someone who may have a vested interest in betraying your confidence. (For example, a recruiter who earns $100,000 per year in commissions from your company may not be the best person to talk to about your sense that said company grossly undervalues you.)

Assuming you have legitimate reasons to move on, it’s time to consider those other factors: namely, have you identified the right place to move on to? And have you protected yourself and your family by setting aside a small financial cushion (at least three months’ rent in the bank) and lining up a freelance gig?

Don’t just make a move to make a move—that’s how careers die. Identify the characteristics of the kind of place you want to work for. What kind of work do they do? If they are agencies, what do their former customers say about them? If friends work for them, what do they say about the place? What’s their company culture like? Do they boast a diverse workforce—diverse psychologically, creatively, and politically as well as physically? Is there a sameness to the kind of person they hire, and if so, will you fit in or be uncomfortable? If you’d be comfortable, might you be too comfortable (i.e. not learning anything new)? Human factors are every bit as important as the work, and, career-wise, more important than the money.

If five of your friends work for your current employer’s biggest competitor, don’t assume you can walk across the street and interview with that competitor. The competitor may feel honor-bound to tell your boss how unhappy you are—and that won’t do you any good. Your boss might also feel personally betrayed if you take a job with her biggest competitor, and that might be burning a bridge.

Don’t burn any bridges you don’t have to. After all, you never know who you might work for—or who you might want to hire—five years from now. Leaving on good terms is as important as securing the right next job. Word of mouth is everything in this business, and one powerful enemy can really hurt your career. More importantly, regardless of what they can do for or against your career, it’s always best to avoid hurting others when possible. After all, everyone you meet is fighting their own hard battle, so why add to their burdens?

This isn’t to say you don’t have the right to work for anyone you choose who chooses you back. You absolutely have the right. Just be smart and empathetic about it.

In some places, with some bosses, you can honestly say you’re looking for a new job, and the boss will not only understand, she’ll actually recommend you for a good job elsewhere. But that saintly a boss is rare—and if you work for one, are you sure you want to quit? Most bosses, however professional they may be, take it personally when you leave. So be discreet while job hunting. Once you decide to take a new job, let your boss know well ahead of time, and be honest but helpful if they ask why you’re leaving—share reasons that are true and actionable and that, if listened to, could improve the company you’re leaving.

Lastly, before job hunting, line up those three months’ rent and that freelance gig. This protects you and your family if you work for a vindictive boss who fires employees he finds out are seeking outside jobs. Besides, having cash in the bank and a freelance creative challenge will boost your confidence and self-esteem, helping you do better in interviews.

A good job is like a good friend. But people grow and change, and sometimes even the best of friends must part. Knowing when to make your move will keep you ahead of the curve—and the axe. Happy hunting!


Read the full article

Jul
29

2015 Summer Reading Issue

Source: A List Apart

Summer is halfway over. Have you hid out for a day of reading yet? Grab a shady spot and a picnic blanket (or just park it in front of the nearest AC unit), turn off your notifications, and unwrap this tasty treat: our 2015 summer reader.

Refresh your mind, heart, and spirit with this curated list of articles, videos, and other goodies from the recent past—from A List Apart and across the web.

Which web do we want?

Is the web “a place to connect knowledge, people, and cats,” or do “hordes threaten all that we have built for one another”? Where will native-versus-web fights end up? And why are we all here, doing this work, anyhow?

From us

From elsewhere

Toward an inclusive industry

This web is what we make of it. We can use it to insult strangers in a comments field, or to fight for greater fairness and opportunity in our world. We are inspired by those who choose the path of inclusion:

From us

From elsewhere

Trying out new techniques

Today’s code is so complex no individual can master it all—but that also means there’s always something new to learn…like these new, niche, or just plain cool techniques.

From us

Speeding up

Big, lumbering websites, endless load times, and crappy experiences on mobile? No, thanks! Here’s to those in the trenches of performance, fighting the good fight.

From us

From elsewhere

Accessibility for everyone

“The power of the Web is in its universality,” Tim Berners-Lee once said—and that means working for all kinds of people, with all kinds of abilities. Let’s stop leaving accessibility for last, and instead start from a place that embraces the needs of all our users.

From us

From elsewhere

Working better, together

What comes after static comps and toss-it-over-the-wall processes? We’re still figuring that out—but one thing’s for sure: people are at the center.

From us

From elsewhere

Becoming mentors

The more we teach, the more we learn—and the more our industry benefits. Discover the joys of mentoring and the future of web education.

From us

From elsewhere

Getting content right

In the beginning was content—and it’s the core of every experience we design and build. Connect the right person to the right content at the right time using strategy, design, and writing.

From us

From elsewhere

The evolution of type

If not yet ubiquitous, sophisticated typography on the web is now at least possible. It continues to evolve apace—virtually anything we could do in print, we can now do on screens.

From us

From elsewhere


Read the full article

Jul
29

This week’s sponsor: Squarespace

Source: A List Apart

Make a beautiful website with our sponsor, Squarespace. Keep it simple, or customize your HTML, CSS, and JavaScript with the Developer Platform—you can even get all your content through the JSON API. Get started today.


Read the full article

Jul
23

Developing Empathy

Source: A List Apart

I recently wrote about how to have empathy for our teammates when working to make a great site or application. I care a lot about this because being able to understand and relate to others is vital to creating teams that work well together and makes it easier for us to reach people we don’t know.

I see a lot of talk about empathy, but I find it hard to take the more theory-driven talk and boil that down into things that I can do in my day-to-day work. In my last post, I talked about how I practice empathy with my team members, but after writing that piece I got to thinking about how I, as a developer in particular, can practice empathy with the users of the things I make as well.

Since my work is a bit removed from the design and user experience layer, I don’t always have interactions and usability front of mind while coding. Sometimes I get lost in the code as I focus on making the design work across various screen sizes in a compact, modular way. I have to continually remind myself of ways I can work to make sure the application will be easy to use.

To that end, there are things I’ve started thinking about as I code and even ways I’ve gone outside the traditional developer role to ensure I understand how people are using the software and sites I help make.

Accessibility

From a pure coding standpoint, I do as much as I can to make sure the things I make are accessible to everyone. This is still a work in progress for me, as I try to learn more and more about accessibility. Keeping the A11Y Project checklist open while I work means I can keep accessibility in mind. Because all the people who want to use what I’m building should be able to.

In addition to focusing on what I can do with code to make sure I’m thinking about all users, I’ve also tried a few other things.

Support

In a job I had a few years ago, the entire team was expected to be involved with support. One of the best ways to understand how people were using our product was to read through the questions and issues they were having.

I was quite nervous at first, feeling like I didn’t have the knowledge or experience to adequately answer user emails, but I came to really enjoy it. I was lucky to be mentored by my boss on how to write those support messages better, by acknowledging and listening to the people writing in, and hopefully, helping them out when I could.

Just recently I spent a week doing support work for an application while my coworker was on vacation, reminding me yet again how much I learn from it. Since this was the first time I’d been involved with the app, I learned about the ways our users were getting tripped up, and saw pitfalls which I may never have thought about otherwise.

As I’ve done support, I’ve learned quite a bit. I’ve seen browser and operating system bugs, especially on devices that I may not test or use regularly. I’ve learned that having things like receipts on demand and easy flows for renewal is crucial to paid application models. I’ve found out about issues when English may not be the users’ native language—internationalization is huge and also hard. Whatever comes up, I’m always reminded (in a good way!), that not everyone uses an application or computer in the same ways that I do.

For developers specifically, support work also helps jolt us out of our worlds and reminds us that not everyone thinks the same way, nor should they. I’ve found that while answering questions, or having to explain how to do certain tasks, I come to realizations of ways we can make things better. It’s also an important reminder that not everyone has the technical know how I do, so helping someone learn to use Fluid to make a web app behave more like a native app, or even just showing how to dock a URL in the OS X dock can make a difference. And best of all? When you do help someone out, they’re usually so grateful for it—it’s always great to get the happy email in response.

Usability testing

Another way I’ve found to get a better sense of what users are doing with the application is to sit in on usability testing when possible. I’ve only been able to do this once, but it was eye opening. There’s nothing better than watching someone use the software you’re making, or in my case, stumble through trying to use it.

In the one instance where I was able to watch usability testing, I found it fascinating on several levels. We were testing a mobile website for an industry that has a lot of jargon. So, people were stumbling not just with the application itself, but also with the language—it wasn’t just the UI that caused problems, but the words the industry uses regularly that people didn’t understand. With limited space on a small screen, we’d shortened things up too much, and it was not working for many of the people trying to use the site.

Since I’m not doing user experience work myself, I don’t get the opportunity to watch usability testing often, but I’m grateful for the time I was able to, and I’m hopeful that I’ll be able to observe it again in the future. Like answering support emails, it puts you on the front lines with your users and helps you understand how to make things better for them.

Getting in touch with users, in whatever ways are available to you, makes a big difference in how you think about them. Rather than a faceless person typing away on a keyboard, users become people with names who want to use what you are helping to create, but they may not think exactly the same way you do, and things may not work as they expect.

Even though many of us have roles where we aren’t directly involved in designing the interfaces of the sites and apps we build, we can all learn to be more empathetic to users. This matters. It makes us better at what we do and we create better applications and sites because of it. When you care about the person at the other end, you want to write more performant, accessible code to make their lives easier. And when the entire team cares, not just the people who interact with users most on a day-to-day basis, then the application can only get better as you iterate and improve it for your users.


Read the full article

Jul
23

Mark Llobrera · Professional Amateurs: Memory Management

Source: A List Apart

When I was starting out as a web designer, one of my chief joys was simply observing how my mentors went about their job—the way they prepared for projects, the way they organized their work. I knew that it would take a while for my skills to catch up to theirs, but I had an inkling that developing a foundation of good work habits was something that would stay with me throughout my career.

Many of those habits centered around creating a personal system for organizing all the associated bits and pieces that contributed to the actual code I wrote. These days as I mentor Bluecadet’s dev apprentices, I frequently get asked how I keep all this information in my head. And my answer is always: I don’t. It’s simply not possible for me. I don’t have a “memory palace” like you’d see onscreen in Sherlock (or described in Hilary Mantel’s Wolf Hall). But I have tried a few things over the years, and what follows are a few habits and tools that have helped me.

Extend your memory

Remember this: you will forget. It may not seem like it, hammering away with everything so freshly-imprinted in your mind. But you will forget, at least long enough to drive you absolutely batty—or you’ll remember too late to do any good. So the trick is figuring out a way to augment your fickle memory.

The core of my personal memory system has remained fairly stable over the years: networked notes, lots of bookmarks, and a couple of buffer utilities. I’ve mixed and matched many different tools on top of those components, like a chef trying out new knives, but the general setup remains the same. I describe some OS X/iOS tools that I use as part of my system, but those are not a requirement and can be substituted with applications for your preferred operating system.

Networked notes

Think of these as breadcrumbs for yourself. You want to be able to quickly jot things down, true—but more importantly, you have to be able to find them once some time has passed.

I use a loose system of text notes, hooked up to a single folder in Dropbox. I settled on text for a number of reasons:

  • It’s not strongly tied to any piece of software. I use nvALT to create, name, and search through most of my notes, but I tend to edit them in Byword, which is available on both OS X and iOS.
  • It’s easily searchable, it’s extremely portable, and it’s lightweight.
  • It’s easily backed up.
  • I can scan my notes at the file system level in addition to within an app.
  • It’s fast. Start typing a word in the nvALT search bar and it whittles down the results. I use a system of “tags” when naming my files, where each tag is preceded by an @ symbol, like so: @bluecadet. Multiple tags can be chained together, for example: @bluecadet @laphamsquarterly. Generally I use anywhere from one to four tags per note. Common ones are a project tag, or a subject (say, @drupal or @wordpress). So a note about setting up Drupal on a project could be named “@bluecadet @drupal @projectname Setup Notes.txt.” There are lots of naming systems. I used this nvALT 101 primer by Michael Schechter as a jumping-off point, but I found it useful to just put my tags directly into the filename. Try a few conventions out and see what sticks for you.
Notes naming system screenshot

My file naming system for text notes.

What do I use notes for? Every time I run into anything on a project, whether it’s something that confuses me, or something I just figured out, I put that in a note. If I have a commonly-used snippet for a project (say, a deploy command), then I put that in a note too. I try to keep the notes short and specific—if I find myself adding more and more to a note I will often break it out into separate notes that are related by a shared tag. This makes it easier to find things when searching (or even just scanning the file directory of all the notes).

Later on those notes could form the basis for a blog post, a talk, or simply a lunch-and-learn session with my coworkers.

Scratch pad

I have one special note that I keep open during the day, a “scratch pad” for things that pop into my brain while I’m focusing on a specific task. (Ironically, this is a tip that I read somewhere and failed to bookmark). These aren’t necessarily things that are related to what I’m doing at that moment—in fact, they might be things that could potentially distract me from my current task. I jot a quick line in the scratch pad and when I have a break I can follow up on those items. I like to write this as a note in nvALT instead of in a notebook because I can later copy-and-paste bits and pieces into specific, tagged notes.

Bookmarking: Pinboard

So notes cover my stuff, but what about everyone else’s? Bookmarks can be extremely useful for building up a body of links around a subject, but like my text notes they only started to have value when I could access them anywhere. I save my bookmarks to Pinboard. I used to use Delicious, but after its near-death, I imported my links to Pinboard when a friend gave me a gift subscription. I like that Pinboard gives you a (paid) option to archive your bookmarks, so you can retrieve a cached copy of a page if link rot has set in with the original.

Anything that could potentially help me down the line gets tagged and saved. When I’m doing research in the browser, I will follow links off Google searches, skim them quickly, and bookmark things for later, in-depth reading. When I’m following links off Twitter I dump stuff to Pocket, since I have Pinboard set to automatically grab all my Pocket articles. Before I enabled that last feature, I had some links in Pocket and some in Pinboard, so I had to look for things in two separate places.

Whatever system you use, make sure it’s accessible from your mobile devices. I use Pinner for iOS, which works pretty well with iOS 8’s share sheets. Every few days I sit down with my iPad and sift through the links that are auto-saved from Pocket and add more tags to them.

Buffers: clipboard history and command line lookup

These last two tips are both very small, but they’ve saved me so much time (and countless keystrokes) over the years, especially given how often cut-and-paste figures into my job.

Find a clipboard history tool that works for you. I suggest using the clipboard history in your launcher application of choice (I use Launchbar since it has one built in, but Alfred has one as part of its Powerpack). On iOS I use Clips (although it does require an in-app purchase to store unlimited items and sync them across all your devices). Having multiple items available means less time spent moving between windows and applications—you can grab several items, and then paste them back from your history. I’m excited to see how the recently-announced multitasking features in iOS 9 help in this regard. (It also looks like Android M will have multiple window support.) If you don’t use a launcher, Macworld has a fairly recent roundup of standalone Mac apps.

If you use the command line bash shell, CTRL+R is your friend: it will allow you to do a string search through your recent commands. Hit CTLR+R repeatedly to cycle through multiple matches in your command history. When you deal with repetitive terminal commands like I do (deploying to remote servers, for instance), it’s even faster than copying-and-pasting from a clipboard history. (zsh users: looks like there’s some key bindings involved.)

Finding your way

I like to tell Bluecadet’s dev apprentices that they should pay close attention to the little pieces that form the “glue” of their mentor’s process. Developing a personal way of working that transcends projects and code can assist you through many changes in roles and skills over the course of your career.

Rather than opting in to a single do-it-all tool, I’ve found it helpful to craft my own system out of pieces that are lightweight, simple, flexible, and low-maintenance. The tools I use are just layers on top of that system. For example, as I wrote this column I tested out two Markdown text editors without having to change how I organize my notes.

Your personal system may look very different from the one I’ve described here. I have colleagues who use Evernote, Google Docs, or Simplenote as their primary tool. The common thread is that they invested some time and found something that worked for them.

What’s missing? I still don’t have a great tool for compiling visual references. I’ve seen some colleagues use Pinterest and Gimmebar. I’ll close by asking: what are you using?


Read the full article

Jul
22

This week’s sponsor: Bushel

Source: A List Apart

If you manage and protect Apple devices at work, our sponsor Bushel is here to help make it easier.


Read the full article

Jul
21

Inspiration for UX Design from the Arts and Sciences

Source: UXMatters

By Janet M. Six

Published: July 20, 2015

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

In this edition of Ask UXmatters, our panel of UX experts discusses some other professions that have inspired their UX design work. Our experts have taken inspiration from such diverse fields as music, dance, philosophy, theater, and gastronomy. Have you taken inspiration from another profession and applied it in your UX design practice? If so, please share the source of your inspiration in the comments. Read on to learn about some of our experts’ sources of UX inspiration.

Every month in Ask UXmatters, our panel of UX experts answers our readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: ask.uxmatters@uxmatters.com.
Inspiration for UX Design from the Arts and Sciences

Jul
21

Simplify Your UX Through Reduction

Source: UXMatters

By Brady Bonus

Published: July 20, 2015

“Creating a simple experience that looks easy, feels easy, and actually is easy is quite complicated.”

Creating a simple user experience requires a method. It’s not enough to say that you’ll create a simple design, that you’ll design like Apple, or that you’ll just remove enough stuff until it feels right. Creating a simple experience that looks easy, feels easy, and actually is easy is quite complicated.

My search for a framework for simple design started when I began studying the work of John Maeda, a computer scientist, graphic designer, and former President of Rhode Island School of Design. Maeda’s book The Laws of Simplicity presents ten laws that constitute simplicity, and he expounds on how each law contributes to things feeling simple. Inspired by his work, I took a few of his laws and created a three-step method that you can apply to design thinking. I can only hope that my distillation of his ten laws down to three steps would make him proud.
Simplify Your UX Through Reduction

Jul
21

Why the Work Doesn’t Stop When the Lights Go Down

Source: UXMatters

By Traci Lepore

Published: July 20, 2015

“The story begins anew with each and every interaction you engage in when on stage—and the same is true in UX design.”

Rehearsals are over. You have survived tech week. The dress rehearsal has happened.  Now its opening night: the lights go down, the audience quiets, and the show begins. But that doesn’t mean the work is over. In fact, it is only beginning.

While this may sound a little strange to you, it’s true. There are many factors that go into a live performance that can be difficult to manage or anticipate ahead of time. Biggest of all is the unpredictability of human beings—who can and will make mistakes. The energy of a particular audience can drive or deplete your supply of adrenaline. Technical or wardrobe malfunctions could occur. A lot of stars have to align to ensure that you deliver an amazing performance.
Why the Work Doesn’t Stop When the Lights Go Down

Jul
21

When a Design Does Not Hold Up in Actual Usage

Source: UXMatters

By Baruch Sachs

Published: July 20, 2015

“Sometimes … a design is found wanting in actual usage … [and] there are still significant user-adoption issues after the design gets implemented.”

Sitting where we do within a consulting organization for a software vendor, my team and I often feel like mediators between two warring factions. On one side, we have Design and, on the other side, user’s actual usage of an application. Sometimes, both meld fantastically well. In such cases, the design is almost always well thought out, slick, and crafty. At other times, though, a design is found wanting in actual usage, especially at the higher end of the scale. It is at such times that, although a design seems great, all parties agreed to it, and we put it through rigorous testing, there are still significant user-adoption issues after the design gets implemented. How does this happen, and how can we address this problem?

During this golden age of design that we are experiencing, it is becoming increasingly important to address such situations. Even though the profession of User Experience is rapidly maturing, many executive sponsors of our efforts still look at User Experience as some sort of magic pixie dust. UX experts come in, sprinkle it about, and all is well. This mentality does not leave a lot of room for UX folks to fail to hit the mark the first time out. Such expectations may be unfair, but more and more, this is becoming the reality. Design, especially Web page design, is now becoming a commodity. Business leaders understand that User Experience is critical, but there is also a growing sense that what we do is totally repeatable.
When a Design Does Not Hold Up in Actual Usage

Older posts «