Web

Mar

2017

Managing Passwords – How do you do it?

One of the biggest challenges in my business is the managing of passwords. At any given time I have between 5 and 10 active accounts all with hosting logins, FTP, website logins, and logins for various financial accounts, social media accounts and countless other things.

To make matters even more complicated, I often have 5 logins for the same site (PayPal for instance – which a lot of my clients use as a payment gateway).

My issues with password management are two-fold:

First, how do I collect and keep track of passwords myself, so that I can quickly access the accounts I need and not waste valuable development time trying to track down a login?

Second, what is the best system to recommend to clients for keeping track of their passwords so that when a developer needs them in the future, they can have a quick way to find them?

At the intersection of these two issues is how, when I’m building a new site, can I keep track of all of the passwords in a way that makes it easy for me to pass them back to the client when I complete the work?

Of course, since these logins allow access to some pretty sensitive information, all of this needs to be reviewed with an eye on security. My clients have a range of concerns and levels of concern about security, so I always err on the side of the most secure. I won’t be discussing most aspects of secure passwords here, but there are some great resources out there. Here are just a few:

Heimdal Security: Password Security 101

Huffington Post: 7 Steps to Safer Passwords

The New York Times: Protecting Your Digital Life in 7 Steps

So, here is what I have (and haven’t) figured out:

For my systems, I use Last Pass, which works great for me. I save ultra secure passwords in the system and have one secure password for Last Pass which makes it easier to memorize.

For my clients – I don’t know what to suggest. I package up their logins and send them back, but judging from how hard it is to get passwords from people when I’m starting projects, those emails/text messages/printed documents just go into the trash. Does anyone have any good ideas for password storage for individual clients?

One trend that I’m noticing with larger companies is the ability to “grant access” to your account to another user. In these cases, the original account holder can grant access to me by just entering my email address. I’d like to see more two-factor authentication in these systems, but that’s another story for another day. At least in these cases, I can access account information under my own login, which also allows clients to remove access for people without changing their own login info.

For now, I’m setting a goal to develop a better system than what I’m using sometime in the next 6 months and then implement that for all clients to make this step less of a hassle for everyone.

Nov

2015

When to call in a “pro”

In a world where it seems like a simple Google search can bring you a video or step-by-step guide to almost anything, it can be tempting to try to DIY everything.

I’m guilty of this myself. Fix a running toilet? YouTube it. Make an impossibly complex recipe? Just follow the step-by-step and Google the techniques along the way. Out of carpet cleaner? Make your own from these four common household items.

One of the things I love about working in WordPress is it allows a lot of my clients to DIY their websites to some extent. Once I design it and build the functionality they need, I can hand it off to clients and let them change text and images, add blog posts and videos, and if I’ve done my job right, their website will continue to look and function as it should.

But without that first crucial step of setting up look and functionality, some of which inevitably takes place in the PHP, Javascript and CSS files, these clients wouldn’t be able to run their websites on their own.

WordPress has grown into a complex ecosystem of the basic platform, plugins that add functionality, themes that add styling, and API integrations with various other web services. A person with some basic knowledge of the web and WordPress can still build a basic blog site by themselves, but for more complex websites, you may want to call in a “pro” early in the process. It will save you a lot of work and a lot of headaches in the future.

Nov

2015

Things I Wish I Knew Before I Started My Own Business

I graduated from college 10 years ago, and since that point, I have had a full-time, salaried job, until June of this year when I decided to go out on my own and start my own freelancing business.

Now that I’m about six months in, I have a list of things I wish I’d known when I started. Some of these things are practical, some are philosophical, but all are good advice for anyone thinking about going out on their own.

It’s better to start with systems than to develop them as you go
Pay for the accounting software
Your business name doesn’t matter nearly as much as your business structure
Working for friends can be a blessing, but it can also be the hardest client relationship to manage
Insist on signed estimates and deposit checks before starting a project
Hold on to your free time. Just because you work at home doesn’t mean that you’re always at work
Be confident in your abilities, but know when to ask for help
It’s OK to outsource things you’re not good at (more on that in my next post)
The worst part of any job is going to be billing – dealing with money sucks
Save everything – receipts, business cards, notes, emails, mockups, draft documents, checks, etc. – you never know when you’re going to need to refer back to something

And above all – remember the reason you’re doing this – whether it’s for creative freedom, the ability to work from anywhere, the ability to spend more time with friends or family, remember that reason and hold on to it. There will be hard, horrible days where you’ll wish you could go back to a full time job, or where you’ll want to fire clients, resign accounts, and quit projects. On those days, it’s important to think about why.

For me, there are multiple reasons why freelancing works for me, but one of the biggest is that life is short, and there is so much in this world that I want to see and do, and so when I have a hard day, I remember a raft trip down the Nolichucky river on a Wednesday morning, and how it was a perfect day, and how in my previous jobs, it was a day I would have had to miss, sitting instead in my office while the leaves went from green to yellow to red, and then fell off the trees. Those are the kind of days that make it all worth it.

Nov

2015

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.

Nov

2015

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.

Oct

2015

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.

Oct

2015

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.

Oct

2015

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?

Jul

2015

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.

Web

Managing Passwords – How do you do it?

When to call in a “pro”

Things I Wish I Knew Before I Started My Own Business

Can Design be Hostile?

GitHub for Beginners

Constraining Design

Design at the Speed of Digital

What is it that you do, exactly?

90 Percent of the Time it Works Every Time

Recent Posts

Categories