Starting a new remote or work from home gig, be it a contract project or a full-time job, can be a little intimidating if you’re used to going into an office day after day.
I’ve successfully worked remotely using these tools for years now on projects of various scales and durations. With this post, I hope to enumerate some of the best practices that I’ve picked up for working in a variety of situations. The remote and work-from-home guide here ranges from specific recommendations for software and hardware to tips for hitting your team’s deadlines.
The Remote or Home Office Setup
I can’t stress enough the importance of having the right office setup. It will both make you more productive and appear more professional. For example, a headset is crucial for avoiding echo during online calls; little things like this go a long way when working as a remote.
Here are some tools for working remotely that I consider essential in my own home office:
Headset. I really like wired headsets in particular because they don’t run out of battery at critical times. You’ll be wearing it a lot, so make sure you get something comfortable. I have two iMicro headsets: one for my desk and one that I pack in my laptop bag. As a laptop bag headset, it has two great qualities: because it’s USB powered, I don’t have to worry about keeping the batteries charged, and it’s very cheap to replace if it gets broken in my bag. Actually, I find this particular headset a little uncomfortable for long conference calls; if you’re doing a lot of those, then I recommend the Corsair Vengeance 2000: a comfortable, wireless headset with battery capability, allowing you to work all day. (By the way: none of these are referral links.)
Quiet place to think, with a door that shuts–especially if you live with other people, and especially if you have a family.
Stable Internet connection, or good backup connection. For example, I have DSL and have setup tethering on my phone if the DSL goes out. If you’re constantly having Skype issues or dropping calls, you’re becoming both less reliable and less professional in the eyes of others who might be trying to manage several remote employees.
Skype. This is good for ad-hoc conference calls, instant messaging with clients, or even creating low ceremony chat rooms.
SkypeOut, which lets you take and make calls from your phone to Skype contacts. This is awesome, especially for times when you’re away from your computer and (you’ve miscalculated a time, client has an emergency, etc.).
Electric kettle. Sometimes I want hot coffee but, don’t want to disturb my flow to get some.
Gallon jug of water. For the kettle, or for drinking. For long coding sessions, or long conference calls.
Some of these sound obvious, but you’d be surprised at the number of remotes who don’t hit all the marks here. As developers, we need a quiet space to think, uninterrupted. And as remote workers, we need a quiet place to host conference calls, meetings, pair programming sessions, etc., uninterrupted. Just working on your couch is probably not a good long-term remote work solution.
Software Tools
There are a bunch of good software tools out there to supplement your typical development environment and help you overcome the challenges associated with remote work. Here are a few that I really like:
AwayFind, which is good for urgent emails, particularly last minute messages from an attendee of a meeting, as it forwards their messages to you via SMS.
Chat/IRC rooms for everyone on the team. This could be formal (e.g., a Campfire room) or just a Skype chat room (in Keep It Simple, Silly) style.
Bug tracker–this deserves its own section, so see below.
When planning meetings, always confirm both time zones. And when you get an invitation, you should always do the math backward and make sure you come up with the same numbers. If the meeting involves multiple time zones, I like including the UTC time also. Since everyone should know their offset from UTC, this is yet another check to make sure everyone’s on the same page.
I was on a decently-sized Rails team a few years ago. Several team members worked remotely for at least part of the time, and the team culture was that much work would be done in the evenings. I proposed setting up a chat room through the official team leader at the time, pointing to Campfire or some other paid chat service. Several weeks went by with no action and I decided to setup a Skype chatroom with just the developers, to test my theory that a chat room would be an asset for the team. This experiment proved very successful – so successful that we just kept using Skype chat instead of another solution. This Skype chat room was still in use when I left the project almost a year later. Sometimes, simple can be the best option.
Later on, during a critical deadline for the same project, we set up a Skype chatroom that included the developers, business analysists, the project managers and the client, so questions could be addressed quickly by the general group. While not as active as the developer-only chat room, it still worked really well. Skype chats can be moderated and controlled by some group chat commands, setting chat roles and setting access permissions, which allows you to really customize the chatroom to your use-case. Even a setup of such simplicity can improve remote productivity.
Remote Work Best Practices: Bug Tracking
I like to know three things from a bug tracker I’m using:
What am I working on right now?
What’s on my plate for the next release of this software?
What are the entire team’s deliverables for this release of the software?
Each of these has a purpose.
First, “What am I working on right now?”: When you work in a traditional office, you have background chatter–this gives you have a general idea of what everyone else is doing. An explicit marker in the bug tracker system stating, “Yes, I’m actively working on this right now”, can introduce a similar pattern and feel to remote work.
Secondly, “What’s on my plate for the next release?” means, “What bugs I’m responsible for” or “What bugs I’m handling”. There’s certainly some back-and-forth in every team, but it’s also good to know who to ask if you want to grab a bug, or need some help with finalizing your bugs for the release.
It’s also possible your team doesn’t work like this at all: for example, your workflow might be where each developer is only assigned one bug to start with and picks off the unassigned pile when their one bug is done. This can be productive as well.
The “Next release of the software” doesn’t have to be anything big–I’ve been on teams where the “next release” meant, “3 days from now, we’re going to release a new alpha build for the client”. But it’s still good for everyone to know what’s coming up in this new release. Especially if you pick off unassigned tickets when your current ticket is complete.
I’ve included some recommendations for specific bug trackers at the bottom of the post.
Remote Work Best Practices: Team Communication
For some, team communication is the most intimidating part of working remotely or from home. But this will only be an issue if you let it be.
In an office, as you stroll by everyone on the way to your seat, there’s a bit of banter, people saying “Hello”. Your coworkers know you’re at work because they see you, over there, at your desk, working.
Remote workers need to be slightly more explicit–nobody knows that you’re working unless you tell them. But if you establish the right communication practices, your colleagues will be available at the press of a button, rather than a stroll across the office, down the elevator, etc.
These tips apply more for a remotely managed employee as part of a bigger team, but may be useful if it’s just you as the sole developer.
At the beginning of the day, get on IRC (or whatever tool your team uses) and say “Hello”, chat about how people’s days are going, etc., etc. Even if it means getting on IRC and asking about kids, weekends, sports teams, or weekend hacking. When people know you’re currently hard at work at home, you don’t become invisible. Build a relationship and let people know that you are there.
Chat with people on chat and make sure you stay involved with your colleagues. This is different than when you bump into people in the coffee room, etc., etc. You need to explicitly reach out and stay in touch so that when you commit code or need assistance, people are ready.
‘Starting day’, ‘Lunchtime’, and ‘Be back’ Messages
Along with making your presence felt, you should also let your remote teammates know when you’re not working. Just like in a traditional office setting, you don’t want to disappear for the rest of the day and leave your colleagues hanging.
If you’re on a team with a number of other developers or managing remote employees, it makes sense to check in when you start your work day. A simple “Good morning, everyone” to let people know that you’re at your desk ready to start work on the project, and no longer at home or in bed.
Sending “Be back in 1 hour” messages for lunch or work breaks during the day is nice too. Remote work is great for many things, but one worrisome scenario is that you ask your colleague a question and receive no response. Are they not responding because they’re away for 30 minutes? Or because they are deep in the zone and not listening to chat? Maybe in a meeting? “Be back in…” messages can alleviate these concerns and smooth out the workflow.
When you’re done for the afternoon, let people know when you’ll be back. Maybe it’s “See you all in the morning”, or “Be back later this evening to get [x] done”. But like the “Back in 1 hour” messages, they set a certain expectation to which your team can adapt.
There’s an interesting startup called Sqwiggle that may solve some of these problems (although I haven’t tried it myself yet). In addition to taking a picture of you every few seconds, it also lets team members click on your picture to start video/audio chatting, as well as providing a text chat component. The idea behind the picture is to see, at a glance, if you’re at your computer or not. (There’s nothing worse than trying to chat with someone online and not hearing back quickly. Are they caught up with something else? Deep in the zone? Don’t see the chat notification? In the bathroom right now?). I heard about Sqwiggle on the Wide Teams Podcast Episode 83.
On Projects Where You Can Setup the Best Practices
Remote freelancing gigs are always different. (That’s part of the appeal!) Sometimes you’re brought into an existing team of developers purely as staff augmentation. Maybe this team has been together for some time and, in that case, they’ve already established communication practices.
On the other hand, sometimes you’re the only developer on the project, working with a non-technical client. You can setup your own software development best practices and have some control over how to run the operation. Below are some best practices from my decade or so of remote work experience. Mostly, these are targeted at half-week (20 hours/week) or full-week schedules (40 hours/week).
Standup Meetings
There’s something to be said about holding standup meetings to talk about the state of the project. These are very common in traditional offices, but there’s no reason why they can’t be productive for the remote team: they’re just another way to enforce communication between the two parties: client and developer.
A traditional stand-up meeting asks what you were working on yesterday, what you’ll be working on today, and if there are any obstacles in your way. This format may or may not work given the size of your team: if it’s a single developer project, then these actual questions make no sense.
How often you should have a standup meeting is really dependent on team size and culture. However, here are my recommendations:
1-3 developers: 2 standup style meetings a week
4+ developers: daily standup meetings
With 1-3 developers, these questions are mostly self-evident: you know what each developer is doing because it’s easy to track their individual work as they plow through tickets: everyone knows what everyone is doing, because there’s just not that many people doing work.
With larger remote teams, there are more parts in motion: you want to make sure that nobody is stepping on anyone’s virtual toes by replicating work, or making incompatible changes.
Given Toptal‘s per-week payment structure, two meetings a week gives the client enough time to express concerns about the project before they feel cheated out of a weekly rate. Just having one meeting a week could mean that the client is unhappy about the quality of work, and the developer has no time to adjust the deliverables.
Advanced remote teams may have other methods of keeping all the stakeholders on the same page without scheduling an actual meeting while they work from home. I still like getting on the phone/Skype/Hangouts with someone and having a meeting that way.
For small teams, two standup meetings a week works really well: course corrections are made quickly, but developers still have something substantial to report during each meeting.
Delivering on the Next Release Remotely
Depending on the size of the project, I like deliverables sent to the client weekly for small (1-2 developer), and bi-weekly for larger (3+ developer) projects. This rhythm gives developers enough time to complete sizable chunks of work, including an interface (or improved user experience) for the client to see.
For non-technical clients, the only metric by which they can guage progress is what they can see on the screen.
It’s important for developers to remember, especially with non-technical clients, that progress you can visualize with a user interface is often the only thing that matters to the client. Non-technical clients don’t care that you pushed out 500 lines of code this week, or that you had a hard time interacting with some web service; the only metric by which they can gauge progress is what they can see on the screen. That’s not to say that doing good work on the back-end is irrelevant, but rather that you need to make all this good work tangible in the eyes of the client.
Which is why I like weekly or bi-weekly deliverables. Anything shorter than that often puts the developer in a hard place: maybe they get stuck doing back-end work for two days and don’t have time to finish the interface, so they have nothing to show the client.
Depending on the type of software project, not all of these client releases will be released to the public. For example, if you’re working on a Rails project, you may want to deploy approved changes immediately; on the other hand, with a mobile app, you may call a release “1.3a10”, but the current release is just part of the bigger feature set of a new 1.3 version of the software that will be deployed later.
This is where the remote bug tracker best practices come into play. With bug tracking, the client knows:
What’s on the team’s plate for this deliverable
If it’s been completed
If the work has been approved by the client.
The client knows what to expect from this release, and developers know what work is ahead of them.
If your remote team is mature enough to use continuous deployment and/or Kanban then that’s fine. However, these are both very advanced techniques that are more suited towards organizations with a strong, developer-based culture. Most organizations, where custom software development is seen as necessary but costly, are probably not ready for either of these techniques. Why’s that? Two things I’ve seen is that the client can’t keep up with the number of changes developers want them to review, or priorities change too rapidly for development to get any one thing done.
Recommendations
If you do happen to walk into a team where you’ll be establishing the best practices, I’ve listed some tools below for managing your remote work. Keep in mind that these are just my recommendations: certainly, this guide isn’t for everyone; and if you don’t like these tools, there is probably a tool that fits your needs better.
Planscope.io, in weekly mode. This is a time tracker + bug tracker + project estimation tool that sends clients daily emails when you work on their project and lets them see how things are going in terms of progress and budget. This is great for projects of 1-4 developer/months in size.
App Trajectory is a bug tracker for small teams with a focus on estimating and breaking the project down into one-to two-week chunks (iterations). App Trajectory can tell you how much work you’re completing in an iteration, and how many iterations until all the known work is complete. This is great for projects 2-12 developer/months in size.
Pivotal Tracker is a bug tracker tool for clients with a focus on Agile methodologies. This is great if you are doing formal Agile iterations or have a project size measured in developer/years.
FlowDock for chat. Flowdock offers some advantages over plain IRC or Skype chat: in addition to integrating with popular services, it also lets you tag conversations for quick reference later. FlowDock also keeps a list of status activities (code checkins, etc.) which are separated from general chats. (I.e., in the web interface, automated status updates are on the left, while chats are on the right.)
Getting started with remote or work from home can be quite an adjustment, both for you and the client. I’ve had it go very right, and very wrong. But, when it goes right, it can be an excellent way for clients or employers to solve the “talent crunch” problem, and create a wider range of opportunities for developers who live outside major technological centers or “startup” hubs. There’s a whole world of efficiency to be gained from developers working together remotely with the right best practices in-place.
In this tutorial, we’re going to learn how to draw the Facebook ‘love’ heart emoji in AdobeIllustrator.
1. Create a New Document.
2. Select the Ellipse Tool, Left-click anywhere on the artboard and hold Shift to draw a circle. Give this circle a black Fill and remove any Strokes.
3. Turn on Smart Guides by going to View > Smart Guides. Select the Pen Tool, and Left-click on the right-centre anchor point on the circle created in Step 2.
4. Hold Shift and Left-click below the anchor point that we created. This is going to be the base (lowest point) for our heart icon.
5. Left-click just above the left-centre anchor point of the circle, and Hold to drag out the curve. If done correctly, you should now have created half of the heart icon. With both shapes selected, go to Window > Pathfinder, and select Unite to combine these shapes into one object.
6. With the half-heart shape selected, go to Edit > Copy, and then Edit > Paste in Place. Next go to Object > Transform > Reflect, and reflect along the Vertical Axis. Drag this reflected shape over to the right until it snaps in place alongside your first half of the heart.
7. Select both halves of your heart icon, and go to the Pathfinder Palette, and select Unite to combine into one complete heart shape.
8. With your heart shape selected, Double-click the colour picker in the Toolbar, and specify a 6 digit hex colour of #F25268. This is the colour of the Facebook heart emoji.
9. If the ‘dip’ in the centre of your heart (at the top) is too low, then you can redraw it using the Pen Tool to be more shallow. Draw the first half of the dip using the Pen Tool, and then repeat Steps 6-7 to create the other half and merge into one symmetrical shape.
10. Once you have your new, slightly shallower ‘dip’, select everything on the artboard and in the Pathfinder Palette, select Unite to combine everything into one complete shape.
11. Adjust the Width and Height of your heart to make it taller, shorter, narrower or wider as desired. Try not to adjust these values too much however, as this will skew your heart out of shape – this step is more about making any minor corrections to the overall size of your heart, without distorting it too much out of shape.
Let’s say that co-owners of a business who know nothing about creating a website (except that they need one) are in the market for a website.
They need a site that gives potential customers all the info they need about the boutique and includes an e-commerce section, too. And ideally, they’d like the project to be wrapped up sooner, rather than later, if you please.
These business owners are going to consider the offerings of the first four readers of this article.
You’re one of the four, of course…
You create websites. You have great experience and know you’ll be able to deliver exactly what the business owners need. You charge a fair price—one that adequately values your labor and experience—and always deliver an end product that’s up to spec.
The reader next to you produces a website that meets all of the owners’ requirements – but charges half your price. The next reader in line creates a website (that also meets basic requirements) at half your turnaround time. And the person who came before all three of you offers a faster turnaround and lower price on a website that—yep—still meets all of the owners’ requirements.
Whose work is better?
Let’s say that you have a strong hunch your competitors are cutting corners. You’re pretty sure at those prices and turnaround schedules, they’ve got to have subpar practices in place. They put in zero effort to optimize the site for search. They have no strategy to the sites they create. Or they just have (ugh) crappy, generic design.
You could try to secure the boutique owners’ business by pointing out all of the many, many ways your work is the best. You could stress your years of experience. You could tell your potential customers again and again that you create great websites. The best websites. Better than all the websites of all the other designers they’re considering, though, of course, you really have no surefire way of determining exactly who they’re considering or what your competitors’ final products are like.
Unfortunately, your competitors are probably doing the same thing.
And your potential customer doesn’t know who to believe. But whatever. They need this thing done. They choose the designer with price that is lowest and turnaround that’s fastest, since to them all competitors’ experience and final sites are on-par.
How are you supposed to make yourself stand out?!
If you can’t do it cheaper or faster and so. many. customers. don’t understand why your techniques or practices are better than other companies’, how the hell are you supposed to stand out in such a crowded field?
I see two big opportunities to set yourself apart:
Option 1: Find a niche and burrow deep. Like, really deep
This one’s all about zeroing in on your customer.
Maybe it’s crafting strategy and producing websites for food trucks serving woodfired pizza. Maybe it’s oral surgeons’ offices. Maybe it’s California boho-chic boutiques and fashion designers. General contractors. Elementary schools. Veterinarians.
Whatever it is, find your niche.Narrow it down. Then narrow it down some more. Learn all the ins and outs of maxillofacial surgery, or the precise message that boho-chic boutiques are trying to send. Orient your tone, sales pitch, and offerings to cater to that niche. Reach out to trade groups. Conferences. Professional networks.
Focusing in on a specific niche doesn’t mean that you’re closing yourself off to other customers. Instead, it’s a way to create a stronger connection with a specific subset of buyers. And that connection can raise you above your competitors in the eyes of your customer.
Option 2: Play to your differences, not just your strengths
This one’s about focusing in on you.
When you offer a final product, as we web designers do, you’re replaceable. People all around the globe can create websites. And an endless array of competitors can beat you in price, efficiency, or other commodified measures.
The one thing that your competitors can’t beat you in is being you. Only you are you.
I know that sounds pretty cheesy, but it’s true. There’s something that makes you you, and not someone else. There’s something that makes your team your team, and not any other team. There’s some quality that catches the attention of others and piques their interest—oh, that’s different.
Stand out.Engross them with your you. Find that unique point of difference, explore it, emphasize it, solidify it. When you zero in on what makes you different, not just what makes your skills strong, or your process solid, you stand out.
A few weeks ago, I showed you some of the best fonts for use in grunge style design. Creating grungy designs can be fun, but sometimes a site requires a cleaner approach, one where artsy design elements take a back seat to clear presentation of content. Typography plays a big role in this type of design. If you have been struggling to find the right font for your clean designs, here are 40 of them that are both clean and beautiful.
Scalable Vector Graphic (SVG) is emerging as the preferred graphic format to use on the web today. Are you abandoning the icon font or replacing old pg, gif and png graphics for the well-supported SVG, too? Let’s see how this will impact users of assistive technology (AT) and what is needed in order to ensure a great user experience for everyone.
Graphics and Alternative Text
Before getting started with accessible SVGs, a few quick things to consider regarding graphics, accessibility and alternative text.
1. Does the graphic in question need alternative text?
If a graphic is purely decorative, it does not need to have alternative text.
All tags need the alt attribute to be valid, but the attribute can be left empty (no space) and still validate. ?
2. What is the context of the graphic and the text surrounding it?
If there text/content surrounding the graphic that provides the alternative text, it does not need additional additional alt text. For example:
What is the most appropriate alternative text for the graphic when it needs an alt attribute (see example 4 for more information)? Depending on the content of the image, it can handled differently:
Let’s check our browser usage stats to see if we need to do anything further. If the site’s users are on latest version (Safari Desktop Version 9.1.1 or iOS Version 9.3.2) or newer we can stop here.
However, if the majority of the users are still on older versions of Safari or iOS, we need to add role="img" to the .
This example is fine to use as just a basic image replacement, but it doesn’t allow for us to access to contents of the SVG for either AT or CSS/JS. So, if we want more control over the SVG, we’ll need to inline the SVG directly in the HTML.
2. Inline SVG
Inlining the SVG provides more predictable results and control than if it is added with or because the SVG source is directly available in the DOM which is exposed to the accessibility API that is used by AT.
Let’s take the same basic SVG from the example and say we want to add movement to the eyes. We can do that via JS if we inline the SVG directly into the HTML.
Since this SVG does not contain any visible text that describes the graphic, we need to add the alternative text (invisible) by:
Inside the , add:
A short title of the SVG
must be the first child of it’s parent element
will be used as a tooltip as the pointing device moves over it
A description can be added if needed
a description – note this is not read by narrator (bug filed)
According to the W3C specification, we shouldn’t have to do anything extra for SVGs beyond providing the </code> and possibly a <code></code> because they should be available to the Accessibility API. Unfortunately, browser support is not quite there yet (bugs reported for: <a target="_blank" href="https://bugs.chromium.org/p/chromium/issues/detail?id=231654&q=SVG%20%20title%20attribute&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified">Chrome</a> and <a target="_blank" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1151648">Firefox</a>). </p>
<p>So, to ensure the AT can access the <code><title></code> and <code></code>:</p>
<ul>
<li>Add the appropriate ID’s to the <code><title></code> and <code></code>:
<ul>
<li><code><title id="uniqueTitleID">The title of the SVG
A longer, more complete description for complex graphics.
On the tag, add:
aria-labelledby="uniqueTitleID uniqueDescID" (use the title and desc ID’s) – both title and description are included in aria-labelledby because it has better screen-reader support than aria-describedby (see tip #4)
One more thing:
On the tag, add:
role="img" (so that the SVG is not traversed by browsers that map the SVG to the group role)
Want to add a simple animation, such as eyes blinking?
setInterval(function blinkeyes() {
var tl = new TimelineLite();
tl.to(".eye", .4, {scaleY:.01, repeat:3, repeatDelay:.4, yoyo:true, transformOrigin: "50% 70%", ease:Power2.easeInOut});
return tl;
}, 5000);
var master = new TimelineLite();
master.add(blinkeyes());
Update the title/description so that it accurately explains the image.
<desc id="catDesc">An illustrated gray cat with bright green blinking eyes.</desc>
For now, I’d steer clear of trying to use