On this edition of Cognition Roundtable, we ask: “Does every site need to be responsive?” This question has been an undercurrent topic for conversation in the web industry ever since RWD was introduced, but our own work as well as others’ continue to spark it again and again. Design Director Michael Johnson leads a discussion on the differences between adaptive, responsive, and dedicated sites with Senior Designer Yesenia Perez-Cruz and Developers Anthony Colangelo and Sam Hernandez. Tune in for this half-hour discussion that also covers:
Lately, the web industry has been focusing on ways to improve performance—specifically, by applying the idea of a “performance budget.” A performance budget involves establishing a target page weight (usually in kilobytes), and then making sure no single page exceeds that value. While sticking to this number may seem like a developer’s burden to bear, as Mark Perkins puts it, “performance is everyone’s problem.” As a designer, it’s important to keep your budget in mind throughout your entire process—all the way from discovery through implementation. When both designers and developers work closely to set and stick to a budget, a sweet spot will emerge where neither performance or design will be compromised.
As a designer, my involvement in projects’ front-end development varies. Sometimes, I spend most of my time in code; other times, I work solely in Photoshop. But, there is one part of every front-end engagement that I always love to jump into the browser for: to create hover animations.
Hover animations are a site design element just like typography and color, so it’s important that designers take ownership of this step. Not only do hovers add to the look and feel of a site, but they also add an extra layer of usability for users with a mouse. A finished site may “work” without them, but these nuanced touches add polish and really reinforce a site’s personality. I like to think of their addition as “bonus design”—it’s an opportunity to better what’s being built.
“What’s in a name? that which we call a rose / By any other name would smell as sweet; / So Romeo would, were he not Romeo call’d” (Shakespeare, Romeo & Juliet, 2.2).
In the world of project management, naming conventions are often the source of miscommunication. You have to call your work something, but if you assume everyone interprets a name the way you intended, you’re likely to stub your toe during the course of the project. As managers, minimizing risk and setting expectations is an everyday task, yet something as simple as a name or label can fly under our radar. We live and breathe our work, and we are passionate about it. It’s a good practice to never assume labels are understood out of the gate. Here’s a few tactics to help you make naming conventions work for you.
A couple of years ago at Happy Cog, I transitioned from my position as a designer to a developer full-time. Up to that point, I had been a hybrid designer and developer, splitting my time between the two responsibilities. The truth is that it was a long-overdue transition. My passion lies in the development side of the spectrum, so I am glad to be in a role where I get to express that passion full-time.
I no longer design all day every day, but my experience as a designer taught me that developers should learn and practice design. The trope is often that designers need to learn to write code, but in working as a developer on the web, I’ve learned that the value of a design education pays dividends beyond being able to mock up a page in Photoshop.
The article’s title is borrowed from Malvina Reynolds’ song, “Little Boxes.” No doubt, many of you have heard the lyrics, though sung by a different artist than the original songwriter. Malvina wrote the song to protest the mass conformity of home development taking place in a suburb of San Francisco in the early 1960s. If you have ever driven through the area, you can still see all the ticky-tacky, little boxes dotting the hillsides and throughout the area. Though Daly City provided the inspiration for the song, Suburbs of Sameness are prevalent throughout the country.
When I graduated college with an English and Fine Arts Degree, my school’s career services office didn’t know what to do with me. They handed me a giant book of jobs for English majors. Nothing interested me, but I wasn’t going to let some lady in a university office dash my dreams. I went to Monster.com and found what seemed to be my dream gig at a startup. I applied, selling myself as a creative type eager to learn anything and everything.
I got that job over 15 years ago, and I’m happy to report that that description of me still hasn’t changed. I’ve always wanted to learn on the job, and I still do. Somehow, I’ve made a career in an industry perfect for learning while working.
Almost four years ago, I wrote a Cognition post about my Rule of Threes. In it, I explained that pushing a design effort far enough often resulted in stronger, better-conceived, and more thoroughly vetted solutions. If you didn’t read the article, let me give you a quick recap:
At the conclusion of the information architecture phase, multiple designers worked in unison to evolve three unique design concepts. Each effort was aimed at different, but agreed upon goals. By varying art direction, user-interface interpretation, and content prioritization, the Rule stressed designing a “range” of static mock-up solutions to present to a client. Whichever concept garnered the most attention became the “base model” that was iterated on and drove the overall look and feel moving forward.
It’s easy to get caught up in the daily grind of researching and strategizing wonderfully thought out websites. Sometimes, it’s nice to cut loose and create things just for fun, away from the computer screen. Thus, our monthly Happy Cog Handcrafted Challenge (HCHC) was born.
February was its inaugural month, and I led the effort. I wanted to take things back to elementary school and do an anonymous valentine exchange (though, I used the term “valentine” loosely—really just any card stuffed in an envelope would do).
Off the top of my head, I can tell you that I’m afraid of flying, public speaking, and savory foods that contain hidden fruit. I’m also afraid of starting a new project. But, I dive into new projects just like I risk biting into mango every time I go for the summer roll, because I know that fear of the unknown isn’t a bad thing.
Fear is a natural reaction to the unknown, but as a society, we don’t really like to talk about it. Not many people will openly admit they’re afraid, because, well, it’s uncomfortable. Admitting your fears makes you vulnerable. It also makes you human. When it comes to the world of digital projects, admitting fear is sometimes likened to admitting defeat. It’s not. It’s a normal reaction to the various unknowns that exist at the start of a project.
We’re back with another Cognition Roundtable—a casual conversation about process and the web industry recorded by Happy Cog folks. This time, CMO Greg Storey leads a discussion with designer Sophie Shepherd, developer Brandon Rosage, and VP of Technology Ryan Irelan about how and why we’ve started experimenting with a more development-focused project process. In under a half hour, they cover topics like: