Author: Megan Jonas

Can Design be Hostile?

This is the sixth in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

Sometimes when you’re at a conference, you go to a session where you think you’re getting one thing, and what you get is totally different. This is that session.

Hostile Design, a talk given by Shopify Lead UX Designer Cynthia Savard Saucier, was one I was looking forward to. In her session preview, she used the phrase “bad design can kill” and I thought she was going to talk about how poorly designed sites and projects can be painful to use (metaphorical pain here).

Her actual presentation… more of a tirade really… was about how a company’s clever promotion or user experience can actually hurt people (not metaphorical pain here) and how the poor design of her building’s evacuation alarm would lead us all to burn in a fire (not metaphorical fire here). Having trouble following her line of thought? So was I.

But there were a couple of key takeaways that I can get behind.

She started off with “the best designs don’t require instructions.” That is something I’ve been preaching for many years when it comes to web design. I had a client once who wanted instructional overlays for new users. Instead, I advocated for using standard web icons with tooltips, along with a simplified user experience.

The other thing I loved was the explanation of Dark Patterns, which are essentially web practices designed to trick a user into doing something that is in the company’s best interest, but not necessarily the user (Savard Saucier would be so mad about my repeated use of ‘user’ but that is what I do…). An example of this is opt-out email signups on checkout forms, or opt-out subscription services on a free trial signup.

This is the kind of hostile design that I’d originally thought of, and one that we can actually effect change on.

Open Source is Ugly

This is the fifth in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

One of the themes of the design track at All Things Digital this year was how to add design to Open Source projects. Apparently, design has not been a priority for Open Source in the past, but is becoming an important part of a lot of projects.

The session called Open Source is Ugly on the UX/UI track gave a good overview of why design is important for projects. All projects have users. Sometimes these are the general public, but often in Open Source, these are internal, or specific users, like developers who work in a specific technology, or users who are already using another project that can be extended.

For this reason, developers often don’t think about design as a top priority, but user experience is very important, from Branding to User Interface.

This speaker, Garth Braithwaite from Adobe, talked about choosing a styling platform, integrating design to your project, and giving developers a crash course in design using free online tools, which I plan to check out soon.

You can check those tools out here: Speakerdeck

(Garth and I, incidentally, had a very funny twitter interaction the next day about why my four hour drive should take precedent over the after party. You can check that out and follow me onhere.)

Women in Code

This is the fourth in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

One of the unofficial themes of the conference this year was how to ensure that women, non-cis-gendered people, and people of color feel comfortable in the open source community or the code community at large. There was a fantastic documentary film shown the first day called Code: Debugging the Gender Gap followed by a panel discussion.

The film shows women of all ages, from small children to women who were pioneers in the industry. It talked a little bit about how to improve all parts of the pipeline, from encouraging girls to stay in STEM education paths to making the work environment more welcoming to non-male employees.

As a woman in tech myself, albeit on a more female-friendly side (marketing, advertising, and journalism all tend to skew female), I have felt like an outsider at some conferences and jobs, and am likely a product of the world that says that girls shouldn’t love math and science (I still love you Science!!).

I also feel like my public school system did not encourage computer science as a career path, possibly because when I graduated High School, it was just beginning to be a growth area for jobs.

I am encouraged, though, by the prevalence of this conversation among technology industry groups and conferences. I felt totally welcomed at the All Things Open conference, and felt like the speakers and keynotes represented a wealth of diversity in the industry. Hopefully that will continue to grown in the future.

GitHub for Beginners

This is the third in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

The second session I attended at the conference was called “How to Start an Open Source Project” and it dealt with the nuts and bolts of GitHub and open source licensing and all those other intimidating things that keep people from starting and contributing to projects. The presenter, Don Schenck from Rackspace, gave a great overview of the process, from getting an idea, naming it, creating the repository (repo) and starting with the first file.

One of the key things he said to us was “once you publish your code to GitHub, it’s not your code anymore,” which is a way of saying that open source projects belong to the community. When starting a project, you need to be starting it with that in mind. If you want to control every aspect of it, then open source may not be right for that project.

He also talked about the need for a development plan: what needs to be done, in what order, and how to get people to contribute.

I’m still not sure I’m ready to create my own project on GitHub, but I’m at least a little more confident that I might contribute to one.

Constraining Design

This is the second in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

The first session I attended at All Things Open was in the UX/UI/Design track. The speaker Shay Howe from Belly described how design constraints can actually free a designer to do what they’re best at. Good constraints include a grid, font/typography choices, color choices, and any existing branding for the site, if it’s available.

“Narrowing your options can clarify challenges,” Howe said, and allow a designer to use fewer resources while maintaining consistent styling across iterations.

As someone who is working on a system to create design as good as my development, this really hit home. It is the reason I always suggest to clients that they should start with a style guide, or even a mood board, to give me constraints to work with. Taking away the basic decisions of font, color, and button styling allows me to spend my limited design resources on interesting elements that really customize a site.

Getting clients to see the importance of these style constraints is also an important part of the process. Clients want to jump right in to seeing a website in progress, and sometimes feel like developing these standards is a waste of time. Done correctly, however, it makes the development process much smoother and faster than the code first method.

“Constraints do not equal sacrifices,” said Howe.

Conference Notes: All Things Open 2015

Last week, I attended my first All Things Open conference. The conference focuses on Open Source software and includes speakers from major industry players like IBM, Microsoft and Red Hat.

This conference was a reach for me. I am not a backend developer and know very little about server-side technology or app development. But it was an important reach for me for a few reasons.

First, working from home means not having people to bounce ideas off of and not having those informal conversations that allow you to get new ideas and see cool things that other people are working on in person. Conferences can fill some of those holes for me.

Second, while contributing to open source software can seem intimidating (WordPress is Open Source), it shouldn’t be. The community is overall supportive of new people joining projects and wants to find new ways to include people who believe in the mission of open source.

Third, and possibly most importantly, spending time with people who are passionate about what they do, whether it’s the same thing I do, or something completely different, is energizing and regenerative. I came home from this conference convinced that I can build that app, finish this project and do something new.

For more on what I learned at the conference, check back in a couple of days.

This is the first in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

Design at the Speed of Digital

The web changes quickly and clients expect us to keep up. In this always on age, clients often want design projects turned around within a few days, if not hours.

The traditional agency is used to having a lot longer to do its work. Print deadlines are set many weeks in advance and work is signed off on a weekly basis, not hourly. But when you’re talking about small graphics projects for digital properties, or even iterative web design, those timelines may no longer work for your clients.

But how can you continue to produce excellent design work while working within these newly compressed timelines? Sometimes you just have to wait for inspiration to strike, and sometimes that doesn’t happen overnight (or over the next hour – whatever the case may be).

First, be honest with your clients about your workflow. Especially if you are single-person shop, like I am now, you need to let them know not only that it takes time to produce design work at the quality that they hired you for, but also that you have other commitments, and, at least in my case, you can’t rush the process or you’ll get flawed work that makes no one happy. No one, NO ONE is less happy with flawed work than I am. Not even the client who is paying for it.

Second, you need to re-evaluate your processes and see where efficiencies can be found. Some clients don’t need three mood boards, let alone six. The curse of digital can also be the benefit. You can check in with clients more often which means you don’t have to do unnecessary steps to hone in on a design.

What is it that you do, exactly?

How many times in the past three months have I heard that question? So, so many times. What’s worse, I don’t really have a good explanation for it. My career services counselor from grad school would be so disappointed that I haven’t perfected my elevator pitch yet, but there’s a reason for that.

This excellent article from CSS Tricks explains exactly why it’s hard to explain what I do.

Working in the web industry, my job title and job description is ever changing. Add to that the fact that I have experience and interest in doing a vast number of things and you’ve got the problem outlined in that article.

According to his descriptions, I am mostly a “front end developer” with some “content strategist” and “SEO specialist” elements mixed in. But I also do digital advertising, social media, and other tasks on a fairly regular basis.

How about you? What job title do you give to people?

90 Percent of the Time it Works Every Time

Repeat after me: When in doubt, it’s almost always a plugin conflict. It’s almost ALWAYS a plugin conflict.

You know how sometimes, when you’re having a problem at work and you can’t figure it out, you just need to step away for a bit and the answer miraculously comes to you?

I have a very complex site I am working on, and for some reason, a perfectly coded membership system was generating 404 pages for all member profiles. The pages existed, the code looked good, but there came the 404 page, all the same.

Since the site is complex, with multiple layers and plugins to generate forums, a membership system, a link to an email service provider, and other items, I assumed that the code was the problem and started to dissect the files that were creating the profiles, to no avail. I couldn’t figure out what was causing this 404 response.

So I did what most developers would do, I googled it. And it was at that point that I was reminded – here it comes – when in doubt, it’s almost always a plugin conflict.

I turned off all the plugins except the membership forum system and voila! a working profile page. Then I turned the plugins back on, one by one, and discovered that the plugin that was generating the 404 page was the plugin that had the conflict (this should probably have been my first idea, right?).

So… a problem that caused me a sleepless night and several hours of work could have been pretty easily fixed by just remembering that – when in doubt, it’s almost always a plugin conflict. Despite the complexity and customization of the site, it’s almost always a plugin conflict. Despite my growing fluency in the code, it’s almost always a plugin conflict.

Because – all things being equal, the simplest explanation is almost always the right one.

Don’t Always Do The Easy Things First

Like any web developer just starting out, sometimes I have days where it seems like nothing works. Today is one of those days. I have one site where all of the out of the box solutions are failing in one way or another, forcing me to dig into code that I had no intention of changing. I have another site where, try what I may, I can’t seem to access the FTP servers. I have googled. I have changed settings. I have contacted support at the hosting company. Nothing is working.

On days like today, my inclination is to set these items aside and do the “easy” things first. Starting new projects, writing blog posts (procrastination alert!), and sending emails sounds like a better option than trying to figure out these issues.

But it’s not always a great idea to set aside the hard things. They need to get figured out at some point and that point needs to be soon for at least one of those sites. So I will continue to plug away at these issues and hopefully at least one of them will get solved.

Loading...
X