Get in Touch

How can we help?

Whether you are looking to redesign your site or simply refresh your brand, we are here to help!

Prefer to send us an email? hello@imarc.net

Sweet, sweet collaboration, from the bottom up

Posted by Robert Mohns on December 9, 2013. Tagged: culture

Developer Room One of the great advantages of our open-plan workspaces is they encourage informal collaboration. It's easy to listen, to learn and to contribute. But sometimes there are topics that benefit from a little more focused attention.

Some years back, our Creative team started an informal “Photoshop Club” to teach Photoshop techniques to non-designers. It met monthly after the end of the work day, and quickly morphed into New Skills Club. Anyone could come in to teach a skill, and topics ranged from fixing photo defects, to multi-track audio recording, to how to scratch and backspin like Grandmaster Flash.

Not terribly long afterwards, our Engineers created the (unpronounceable) WSFPAD, a weekly meeting to discuss new code and frameworks, recent projects, and ideas for future exploration. Thanks to WSFPAD, iMarc explored and adopted new technologies and processes, including code scaffolders, version control systems, disciplined deployment processes, automated server setup and cloud-based infrastructure. More importantly, it spread knowledge of these throughout the entire engineering team.

Over time, iMarc added dedicated user experience engineers to our teams — specialists in usability and front-end web development. Eventually, we started the easier-to-pronounce UXJam, a weekly meeting to share techniques, examples, best practices, worst practices, experiments and yes, the ever-popular browser compatibility issues. Open to anyone, UXJam provides a regular place for UX and back-end engineers, creative designers, bizdev and producers all to learn and share knowledge. To date, UXJam has met for 109 weeks.

Earlier this year, Jeff, our Director of Engineering, decided that after 355 weeks of nobody knowing how to pronounce it, WSFPAD should be renamed and refocused. Thus was born CodeJam.

Jam Calendar Like WSFPAD, CodeJam is a weekly meeting to share and learn. But CodeJam also uses targeted projects and even competitions to spur innovation. Engineers get time out of their client development activity to work on CodeJam special projects. Whether it's installing and testing out every major open source CMS we can get our hands on, or competing to see which team can achieve the fastest load time for the iMarc home page, CodeJam has radically accelerated the rate of technology exploration and adoption in our client work.

There's one more Jam to note: JamJam. Started by Kevin, every Thursday morning, everyone is invited to the kitchen to share and try strange and new jams, jellies, and preserves with toast, coffee, and music. It's not exactly professional development, but it has turned out to be a good place to find out what our colleagues are up to and how projects are going. It's at least as informative as our weekly production planning meetings.

Wiki SearchTo make sure we don't lose the knowledge we gain and share, UXJam and CodeJam have pages on our company Wiki. If you remember something interesting or relevant from a Jam, you can just hit the search box and find it.

So, there you have it: grassroots knowledge sharing and education, given structure by motivated employees and supported by iMarc's management with our most valuable asset, time. Jams are a result of an open and empowering culture, where management not just allows but expects employees find the best way to do anything.

Creating Toggle Filters in PHP

Posted by Kerri Gertz on December 4, 2013. Tagged: engineering

During the buildout of a new site, I came across an issue when trying to create filters for several pages. The filters were designed to be additive and look and act like toggles by being able to select and unselect each filter. Without wanting to bring Javascript into the mix, I asked Jeff for help on how to achieve this functionality using only PHP. After thinking through the different possibilities on how to do this, we came up with a solution of using a form and HTML buttons.

For each filter I created both a hidden input and a button: 

$key = "filters[" . $filter->getId() . "]";
<input 
     type="hidden"
     name="<?= $key ?>"
     value="<?= fRequest::get($key, "string", 0) ?>"
/>

The hidden input's name uses an array of all the filters using a key with the ID of the current filter. The value I pass over is the value in the request for that filter, which is whatever the last value was. If there is no value in the request it defaults to 0 (off/inactive). The hidden input is used to pass each filter into the request even if the filter is inactive.

Sidenote: It's a good idea to keep the array name ($key) short. If you have a lot of filters, the URL can get very lengthy and ugly. I used a one letter variable to keep the URL shorter but changed the name above for example purposes. The benefit of having each filter in the URL is that it allows the filter states to be fully preserved when the page is shared through sending the link. 

<button
     name="<?= $key ?>"
     value="<?= (fRequest::get($key) == 1) ? 0 : 1 ?>"
     class="<?= (fRequest::get($key) == 1) ? 'active' : '' ?>">
     <?= $filter->prepareName() ?>
</button> 

The button for each filter is similar to the hidden input as the name uses the same array and key so it can overwrite the hidden input if the filter is selected. The value of the button however is different as it sends over the opposite of what the current state is. This allows the button to act as a toggle. If the button is active (value equals 1) and then clicked again, I pass the value as 0 to set it to inactive. The value state then gets used for the class to style the button. If the button state is 1, I set a class of ‘active’ and style the button to look as if it is selected.

In order to filter the actual results with these filters there were a couple more things I had to do on the backend. In the controller, I needed to create a new array consisting of the ID’s of the selected filters. To do this, I started with getting the filter array from the request and store it in a variable ($filter_themes). Next, I used array_filter to create a new array of only the selected filters (return ($value == 1)). Then to get the ID’s of the selected filters, I used array_keys since I created the array with the ID's set as the keys.

$filter_themes = array_keys(
array_filter($filter_themes, function($value) {
     return ($value == 1);
})); 

Once I had the selected filters in an array, I was able to pass it into the method to return the filtered results and have the selected filters show and function correctly as toggles. 

Show your visitors what they're looking for

Posted by Paul Kelley on November 26, 2013. Tagged: best practices, content, design, mobile, user experience

We talk a lot about scrolling, clicking, and the fold and I think we’re making great headway in the battle against an old, antiquated term. There is one important thing to keep in mind though — just because users scroll doesn’t mean we should make them do it more than they need to. This is more important than ever when we talk about our responsive sites at a small screen size.

Stacking content, and when not to do it

When you compare the desktop version of a responsive site to its small screen counterpart one of the major differences you’ll notice is that content is now stacked rather than displayed side by side. We do this because stacking content allows us to make it a comfortable and legible size on a mobile device. This makes the page longer but that’s ok because we know users scroll and scrolling is easy on one of them fancy smartphones.

We really need to be conscious of what we’re stacking though. The main goal, regardless of screen size, is to get the visitors to their content as quickly as possible. That means the first screen of any mobile website (what the visitor sees before they scroll anywhere) should be mostly the content they’re looking for. Below you’ll see two websites. On the left is the iMarc website and on the right is a low fidelity version of a real website I stumbled across the other day. Unfortunately it’s a layout I see far too often.

mobile header examples

Both of these examples are of a blog detail page. On the iMarc site you can easily see that you’re in the blog section of the site, you can see the title and meta data of the blog article, and you can read almost the entire first paragraph of the blog. Taking a look at the example on the right all you get is a logo and two levels of navigation. Visitors aren’t here to admire your logo and navigation, they’re here for your content. If you’re not giving them even a whiff of your content on the first screen then you’re doing something wrong.

Give the people what they want

When it’s time to determine what you’re responsive site is going to look like on a small screen try to keep a few things in mind.

  • I’m sure your logo is wonderful but your visitors aren’t here to stare at it. Make it as small as you can get away with.
  • Collapse your navigation into a UI element that will display it when the user needs it.
  • Make sure your visitors can see some of your content on the first screen. Let them know there’s more to you than logos and links.

Remember these simple guidelines and you'll create an enjoyable mobile experience for your website.

Control + N

Posted by Christian Keyes on November 19, 2013. Tagged: creative, design, rants

I'd like to talk for a moment about losing. Specifically about losing work, and ultimately, time. Back in the early days of my employment at iMarc, we didn't have the same luxuries we so heavily rely on today. Before we adopted subversion, it wasn't uncommon to lose copious amounts of work due to simple miscommunication. Groans and swearing would echo through these walls as we carelessly saved over each other's hard work. Before cloud computing and automatic backups, everyone would inevitably lose data and designs due to occasional mechanical or human error. Even as recently as last week, I almost lost an hour of work when Photoshop decided to lock up unexpectedly as I was saving a fresh new design. The near loss of my work reminded me of something I used to do frequently that I still do from time to time.

I destroy my own work.

Often times as designers, we'll spend hours and days creating a design comp that we think our clients will love and embrace. We'll show it off internally to the entire creative team, strategy department, as well as our project managers and anyone else who happens to walk through the room. Some may love it as is, while others will offer several opinions on how it could be improved. How much feedback do I welcome before going back to work implementing said changes? I'd wager that most designers are content keeping what they currently have, iterating as needed to incorporate all of the feedback they've gathered, despite how tedious. More often than not in these scenarios, I take a different approach.

I create a new document.

A blank canvas can cause anxiety, especially with a deadline looming. The silver lining to this is that things always go faster the second time around. I know what works and what doesn't. I know the tricks to replicating the good styles I had established the first time around. If I had painted myself into a corner in the first version, I'm now free to explore new options. If my design was too complicated before, a second attempt is almost always cleaner and therefore easier for our front end team to implement. 

I'm of the belief that nothing is ever truly "done". There will always be something to improve or remove. The most important things I can do as a designer are knowing when to stop fussing with a design, knowing when and what feedback to ignore, and realizing when it's time to start anew. There are plenty of fields and careers where the luxury of starting fresh with your work isn't a possibility. We forget sometimes that just because we may never have to "lose" our work again doesn't mean we shouldn't axe it ourselves from time to time.

file not found

Resumes: Why I Didn’t Ignore Word (But Probably Should Have)

Posted by Patrick McPhail on November 13, 2013. Tagged: hiring, rants

iMarc will go through the hiring process once or twice in a typical year, and after almost two decades in business we've really been able to experiment and figure out what works great for us. Over this time, we've established things like:

hiring.imarc.net

  • our hiring site, where everybody at iMarc can check in on the process, see who the candidates are and what we like about them individually*
  • our roles doc & employee manual, which serve as the blueprints for our job listings
  • what we're looking for in a candidate, and in what order
  • when to interview in person vs. phone vs. email and what to ask whom, when
  • ... and a bunch of other things that seem obvious but if you don't write them down you will invariably forget about (e.g. Making sure the applicant can actually get to the office.)

iMarc doesn't have a “formal” Human Resources person, so the manager of the relevant department (Engineering, Operations, BizDev, etc.) leads up the process. When it comes to hiring in Production this almost always falls on Dave, because he's just so darn good at it, and puts up the least amount of fight when we're arguing over who gets to vet two hundred applications from Craigslist.

When it came time to hire a Jr. UX Engineer, we gave Dave a break and I took the reins. Prior to diving in I sat with The Master and learned some tricks of the trade, so-to-speak. One thing that I had actually remembered was this blog that Dave had written back in 2009: "Why We Ignore Word". I'd recommend taking a moment to read that, but I'll provide a quick summary just in case: We instruct applicants to submit resumes in plain text or PDF - resumes sent in MS Word are ignored. This generates some controversy and speculation that we are inflexible tyrants and/or morons.

I knew the "ignore word" rule-of-thumb, but in my process I just couldn't bring myself to do it. What if that perfect candidate just overlooked that one, tiny thing, but otherwise they were God’s gift to User Experience?! So I vetted nearly every application regardless of resume format, 50% of which had a Word resume attached and little to no cover letter provided.

We're a few weeks into the process, and I've talked to a dozen or so talented engineers across the country, four of which we loved and invited to the office for in-person interviews. On a lark, I took a look at the initial emails I received from the candidates we seriously considered, and without an exception, they all provided PDF or online Resumes, as well as a personalized cover letter.

I just put down the phone with our newest hire: our friend Maribeth has accepted the position for the UX Engineer role. Looking back over the entire process, I probably could have cut my overall time in half, and saved a number of applicants a whole bunch of back and forth, if I had simply ignored Word.

 *Did you know that Jeff and I were hired together in 2006, and I outscored him 9-8 (out of ten) in our hiring class? NBD.

Encoding HTML5 Video with FFmpeg

Posted by Jeff Turcotte on November 6, 2013. Tagged: engineering, technology

We just implemented a new video background on our homepage. Typically, our go-to tool for converting video into the necessary HTML5 formats has been Miro Video Converter. It's been relatively successful at compressing most videos we've thrown at it in the past, not to mention it's dead simple. For better or worse, our latest video was getting a little hefty in size and Miro didn't give us the options we needed to be able to tweak bitrates and so forth. Enter FFmpeg.

FFmpeg is pretty much the standard open source video/audio encoding tool. (The FFmpeg Wiki is full of great encoding tips and examples) You can install FFmpeg on OSX using homebew. 

brew install ffmpeg --with-libvpx

Using --with-libvpx ensures that we will compile FFmpeg with the VP8 encoder which we will need for our WebM video file. Using ffmpeg can be a bit daunting at first as there are so many options, but for the straightfoward encoding we will be doing, we can follow the command template below:

ffmpeg -i INPUTFILE -c:v ENCODER -preset slow -s SIZE -an -b:v BITRATE OUTPUTFILE

For our use case of using HTML5 video as a background element, we do not require any audio. We are disabling audio in the output with the -an flag above. Now we can go ahead and start encoding our HTML5 video formats! Here are the commands that we used:

WebM:

ffmpeg -i original.mp4 -c:v libvpx -preset slow -s 1024x576 -qmin 0 -qmax 50 -an -b:v 400K -pass 1 homepage.webm

MP4

ffmpeg -i original.mp4 -c:v libx264 -preset slow -s 1024x576 -an -b:v 370K homepage.mp4

The key to getting a successful result is definitely a lot of trial and error. Play with the bitrates/size until you get an acceptable quality to filesize ratio in each format. One of our goals was to keep the video very close to 1MB and we were able to achieve that using FFmpeg.

iMarc projects win 4 Silvers in 2013 Davey Awards

Posted by Robert Mohns on November 4, 2013. Tagged: awards, clients

2013 Davey Awards - Silver Award WinnerWe're very excited to announce that four of our client projects have been honored with the 2013 Davey Silver Awards.

In alphabetical order, the winners are:

  • Anna Jaques Hospital Website in the Health category. This pairs with the Anna Jaques Women's Health Care website we did in 2012. The Anna Jaques Hospital also took a Silver in the Communicator Awards last year.
  • Off The Front Productions Website in the Self Promotion category. Off The Front is a full service video production company that focuses on telling its clients' stories. The site is dynamic, responsive for great mobile, tablet and desktop experiences, and of course features seamless integrated video. Off The Front also won a W3 Silver award earlier this month.
  • RSA Conference Website in the Events category. This site uses outstanding blog, social, video and event content to create a year-round experience for attendees, and uses fully responsive design and programming to work perfectly on all desktop and mobile browsers. RSA Conference also won a W3 Gold award earlier this month.
  • Wilson Elser Website in the Law & Legal Services category. Wilson Elser is one of the nation's largest law firms, and the complex content management system we built for them lets them manage attorney biographies, offices, practices and industries, news and events, and microsites without ever touching a line of code. And, of course, it looks great and is easy to use. Wilson Elser also won a 2013 Communicator Award of Distinction this past spring.

We're very proud of the work we do for our clients. Without such great clients, we wouldn't have won so many awards over the years. Thank you!

10 Questions to Ask Yourself Before Renaming Your Brand

Posted by Jared Laham on October 29, 2013. Tagged: creative, strategy

10_questions_to_ask

Renaming your brand can truly be a daunting and challenging exercise that forces you to look over your core values and leverage them as a new entity. There is always some hesitation to "start fresh". The best brands out there are memorable, relevant, and resonant.

Memorable - The top goal of every brand. It helps form lasting connections with your audiences and influences how they think about your brand. 

Relevant - The ability to identify and relate to your audiences needs, wants, and desires. Your brand can speak their language and appears current in that space.

Resonant - The emotional connection. Ultimately responsible for the long-term brand loyalty. Use emotionally driven communications to elevate your brand from your compeition.

To calm the fear associated with potentially mis-aligning your new brand or losing key characteristics, make sure to ask yourself the following questions:

  1. What are your brand's core values? How does your current name fail to correctly represent those?

  2. Who is the primary audience of your organization? Will the new name make sense to that audience?

  3. What weaknesses or obscurities do you hope a new name will clear up for your audience?

  4. Can all of your stakeholders agree on the value being gained from changing the name? What is the value?

  5. Does the name hold up to your brand vision moving forward?

  6. Is the new name available as a domain name for purchase (.com, .net, .org)?

  7. Say the name outloud. Does the name sound harsh or is it difficult to say?

  8. Will this new name have a tagline? Can the new name stand on its own without it?

  9. Do any visuals come to mind when thinking about this new name?

  10. Does this new name have any harmful connotations (inside or outside your industry)?

By knowing the answers to all of the questions above, you will have the solid foundation needed to then create a new name for your brand...and avoid reinacting this scene: 

 

Getting everyone on the same board

Posted by Robert Mohns on October 18, 2013. Tagged: culture, strategy

The biggest, but least visible, challenge in any collaboration is ensuring that every contributor shares the same vision for the end product. The obvious methods are traditional project documents, such as site maps, wireframes, specifications documents, and design compositions.

They are necessary, but not sufficient.1

Each team member will have a slightly different interpretation of the design documents. This is good: diversity limits blindspots and tunnel vision. Yet, it also is bad: too much divergence can result in the end product lacking conceptual integrity. Symptoms include confusing navigation, unfocused content, irregular styling, inconsistent UX ... overall, an uneven user experience. The website or app may not be bad, but it won't be as good as it should be.

How do you ensure that every team member has the same conception of the product?

Involving the entire project team as early as possible goes a long way. This gives the benefit of diversity, while ensuring that every member has participated in conceptualization. We exercise this in obvious ways such as our full-team project kickoffs, but also in less obvious ways.

Enter the Whiteboard

At iMarc you are likely to see someone stand up and start writing on a whiteboard at the slightest provocation. And over the years, more and more dry erase surfaces have appeared throughout our Newburyport offices. Why?

They are impermanent, which encourages experimentation.
Anyone can use one, which encourages participation.
They are big, which encourages exploration.
Everyone can see them, which makes them social and shareable.
They are informal, which democratizes the process and encourages joining a discussion.

Experimentation. Participation. Exploration. Sharing. Discussion. All attributes of effective collaboration. Whiteboards make it easy for groups to explore ideas early in the process, which in turn makes them co-authors of the project. This increases the consistency of the project vision across all the participants, improving the quality of the end product.

And as an unexpected bonus, we've found it usually results in faster execution.

Whiteboard Table

A Flock of Whiteboards

When I started at iMarc over eight years ago, we had one whiteboard. It was one of those giant seven-by-four foot, heavy wood-framed monstrosities. We carried to from room to room, hanging it on eye bolts we had screwed into the walls. It required effort and planning to use. As a result, it wasn't used by many people.

Over the past few years, though, we've added more and more whiteboards to our office. But instead of hanging more big, heavy boards, we've been converting entire walls at a time.

The first was our lunchroom wall. We experimented with rolls of stick-on dry erase surface, for an inexpensive proof-of-concept. That wasn't very durable, so we took it down and put up inexpensive panel board from Home Depot. The big expanse, combined with the nearby table and seating, makes for a great workspace.

Rockin' Sockin' Sketchin' Jeff

UX of Processes

The downside of panel board is the seams. They catch markers on the way by, discouraging full use of the space. They also don't erase as cleanly as "real" dry erase boards. For that reason, I recently removed the panel board that had been installed in our UX/Strategy room. I replaced it with a painted-on dry-erase surface sold by Rustoleum.

Rustoleum Dry Erase Paint Cans

UX-Strategy Whiteboard

Upsides: Erases extremely well, enhances marker colors, frameless. Downsides: Requires three to four coats, and if you put it on too thickly, it runs. Since it's glossy, it shows every flaw in the wall underneath. It's a net win.

Kevin

The next dry erase surfaces to appear were downstairs in the BizDev office. Nick and I tried out the more expensive IdeaPaint brand. Like the Rustoleum, it's a two-part epoxy, but it's much thicker and requires only one coat. We painted the wall and the top of our rolling 4' cube with IdeaPaint, and the sides of the cube with Rustoleum. The cube makes a great collaboration surface, mixing physical and drawn items.

Cube Collaborators: Paul and Katie M

As for that huge whiteboard that started all this? Still in use. It now lives in our designers' room:

Christian Keyes, not the blues musician

Next? Perhaps the Engineering Room... for the moment, though, our Engineers seem happy to gather in the lunchroom when brainstorming. And it saves disturbing anyone in the coding zone.

I won't go so far as to say that whiteboards are the reason our work has gotten so much better over the years. But they sure haven't hurt.

Bonus: Drive-by Sketchings

Nyan WRT54

BizDev Graffiti

iMarc web and mobile work recognized with 4 W³ awards!

Posted by Nils Menten on October 7, 2013. Tagged: awards, clients, mobile

We are very excited to share that 4 recent projects were just honored with W³ awards!

The W³ Awards honors creative excellence on the web, and recognizes the creative and marketing professionals behind award winning sites, videos and marketing programs. The W³ is sanctioned and judged by the International Academy of the Visual Arts, an invitation-only body consisting of top-tier professionals from a "Who's Who" of acclaimed media, interactive, advertising and marketing firms.

The work honored included:

The RSA Conference website, in the Events category (Gold). This site uses fully responsive design and programming to work perfectly on all desktop and mobile browsers. 

The Rapid7 website, in the IT/Software category (Silver). In addition to the new website design and strategy, iMarc also reimagined their brand and designed an all-new identity.

The Anna Jaques Women's Health Care website, in the Health Care category (Silver). This site pairs with the award-winning project we did for Anna Jaques Hospital in 2012.

The Off The Front Productions website, in the Marketing category (Silver). This site also uses fully responsive design and programming. 

We're thrilled about having our work so well received, but also for our project partners on the client side. Every great project springs from a great collaboration, and in each of these projects we had great partners on the client teams. Thanks and appreciation from all of us to our terrific clients for their contributions to the great outcome.