Get in Touch
How can we help?

Whether you have a new web design project or just want to talk about updating your brand, we are here to help!

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

Pencils Down: Knowing When You’re Done and How To Get There Faster

Posted by Paul Kelley on January 8, 2014. Tagged: design

As designers, sometimes our biggest hurdle can be ourselves. I’m a bit of a perfectionist myself and occasionally I find it difficult to export a comp, close Photoshop and say, “I’m done.” What I’ve learned as I become a more seasoned designer is recognizing the difference between when I’m just pushing around pixels (Push Mode) and when I’m actually being productive (Design Mode). Unfortunately, knowing the difference doesn’t always keep me out of Push Mode so I’ve tried to modify my process a bit to keep it from happening.

Schedule breaks into your design time

Sometimes the best thing you can do is put some space between you and your design. If I’m struggling with a design I’ll make sure I put it down for a while and work on something else, or if time permits I’ll spend a few hours on it at the end of the day and then go home. When I pick it back up in the morning new solutions come to mind. It’s incredible what can happen after a quick walk to grab lunch or a good night sleep.

It doesn’t have to be perfect to share it with others

If you’re lucky to be part of a design team like I am, you can lean on those designers when you find yourself in Push Mode. Sometimes you don’t realize how deep you are in the forest because all you see is the tree in front of you. What you might not like because you’re burnt out and being overcritical of your own work might actually be a decent solution. There have been times I’ve haven’t been satisfied with this or that but my fellow designers have liked what I’ve done. A fresh set of eyes can make all the difference.

If you aren’t part of a design team you can try dribbble, after all that’s what it was created for. If you don’t have a dribbble account send an email to paul@imarc.net with a link to some of your work and maybe I’ll draft you.

Start Lo-Fi and push it from there

If you notice that you spend half a day on a design and all you have is a perfected navigation bar then maybe that isn’t the best use of your time. An approach that I’ve adopted is starting with a low fidelity comp that is basically a slightly polished wireframe. This keeps me from getting stuck in the weeds of selecting the perfect image or spending way too much time making sure the navigation looks amazing. When I have everything laid out the way I want and I know everything has the proper weight, then and only then do I start to add the high buff shine. This method gives you a strong foundation to build on top of and it keeps you from over designing something that might not need that much pizzaz.

Go forth and design efficiently my friends.

Looking Ahead to 2014

Posted by Katie Desmond on January 6, 2014. Tagged: culture

It's hard to believe how quickly time has passed and that suddenly 2013 is just a memory as we look ahead to 2014. As is customary at this time of year, I have paused to reflect and think about what I am grateful for and what I truly appreciate. On a professional level I am really grateful for my role here at iMarc.

We work at one of the best digital agencies in Boston and in Santa Cruz; and we deliver exceptional results. We love what we do and we are really passionate about it. I realize this all sounds a bit cliche, but it is the foundation of who we are and why we are so driven by our clients success. However even more than that, through all of our collaboration and healthy debate we truly like and respect each other. 

Over the holidays we gathered together as a team to celebrate with a Secret Santa gift swap. Of course because we are iMarc, Matt wrote a script to randomly assign names for each of us to purchase a gift for one another. Once we did that we held a party, Skyped with the Santa Cruz office, and one by one opened our gifts. The gifts ranged from t-shirts, to old school records, to an autographed Bergeron hockey puck, and books. Patrick even received a Photoshop poster of him and Peyton Manning based upon his recent domination in the iMarc fantasy football league. 

Patrick marries Peyton Manning

The fact remains that every single person put a lot of thought and effort into each of those gifts to get something that the recipient would really enjoy; which is much like our approach to every client project. 

As we look ahead to 2014 and all the possibilities ahead of us I am grateful for working with such an incredible team. I look forward to working with our great clients, our new clients on the horizon, more healthy debate, collaboration, and success in 2014!

 

More than #noise

Posted by Robert Mohns on December 23, 2013. Tagged: social media, strategy

Hashtags. Those things starting with a pound symbol and followed by a word, or several words. They started out being used to denote channels in Internet relay chat, and were adopted by the users of Twitter in 2007. Hashtags became a handy shortcut to tag and find content.

#RSAC
Hashtags used to aggregate relevant content at RSA Conference.
Photo ©RSA Conference (Flickr)

Their utility continued for years, although they became less critical to finding content. Twitter created “lists” to group users, and more effective search tools. Third-party Twitter clients developed their own search-and-filtering capabilities. Tools such as Storify enabled users to gather and share related tweets on custom timelines.

None the less, hashtags went mainstream—no longer a tool for nerds but for everyone. And they're no longer Twitter-only; they're also supported on Instagram and Tumblr. And they are everywhere.

#coldplay wristband
©Jason Rosenberg (Flickr)

#team #kids fruit

©Michael Coté (Flickr)

By 2012, hashtags had entered the spoken vernacular. “Share hashtag boston party zone!” And, perhaps driven by hashtag speech, we've finally seen hashtags being almost comically misused:

This all drove me to wonder if we've reached peak hashtag. Do they still have any relevance? Or are they just noise? If they're noise, are they degrading the signal?

What's the official word?

How does Twitter itself view hashtags? There's no official stance, but the Twitter traditional REST API's search function does not distinguish between hashtags and ordinary words. It does its best to provide relevant results based on meaning and trends. That's good—but doesn't signal that hashtags themselves are considered meaningful by Twitter's engineers.

Twitter's Streaming API, though, does provide hashtag information as part of the feed. Since the streams are real-time, Twitter doesn't attempt relevancy filters, leaving this instead to the outside developers who use the streams. Because of this, systems such as LiveFyre StreamHub can quickly and efficiently find hashtags and apply their own relevance criteria.

Let's also not forget the potential for metrics, the Holy Grail of effective marketing. If you can convince your customers to use specific hashtags, you can figure out what content is working. And you can do it fast—no need to wait for quarterly sales reports.

Lastly, let's not forget that other Twitter services, such as Web Intents, also provide explicit hashtag support.

Where does that leave us?

Let's recap:

  1. Hashtags are used extensively in marketing to encourage social engagement with brands.
  2. Twitter users hashtag inconsistently, making them less useful for finding or curating content.
  3. Twitter's search API doesn't treat hashtags as meaningful content signals.
  4. External Twitter developers can treat hashtags as content, if they wish.
  5. Twitter encourages marketers and external developers to use hashtags.

Finally, we have our answer. Brand engagement—no more, but no less! Marketers can encourage customers to both search for hashtags, and to tweet using specific hashtags.

For personal communication, then, hashtags are irrelevant. But they have tremendous value in free viral advertising, crowdsourcing content to create a buzz, and generating metrics. As Matthew Hunt noted, hashtags encourage people to talk, not just passively watch. Not just about anything, but in a directed fashion. Again, marketing.

The cynic in me has begun to see hashtags as #irrelevant #noise in my personal stream, but the idealist sees incredible potential for bringing people together. Marketing, after all, isn't a dirty word—in a broader sense, it means building awareness. And therein, perhaps, we find true meaning.

#hurricanesandy

#TyphoonHaiyan

#olympics #equality

#randomactsofkindness

Merry Christmas and Happy Holidays
May your life be filled with love and peace.

Disclaimer: LiveFyre is an iMarc business partner, and RSA Conference is a client.

unserialize() notice when uploading files to MediaWiki

Posted by Robert Mohns on December 19, 2013. Tagged: engineering, open source

We use MediaWiki – better known as the Wikipedia engine – as our internal knowledge base. Recently, I encountered a bug. It took us a while to track down and fix, so in the interest of saving other people time, I'd like to share it.

The Bug

I uploaded a file to the wiki, and while the upload was a success, a PHP error appeared at the top of the page:

Notice: unserialize(): Error at offset 51 of 56 bytes in /var/<path-to-docroot>/includes/LocalisationCache.php on line 1007
Notice: unserialize(): Error at offset 21 of 26 bytes in /var/<path-to-docroot>/includes/LocalisationCache.php on line 1007
Notice: unserialize(): Error at offset 13 of 18 bytes in /var/<path-to-docroot>/includes/LocalisationCache.php on line 1007

It's worth noting that this a notice, one of PHP's least urgent errors. Somewhat like a compiler warning, it doesn't stop the code from running, it just warns you that there may be bugs in your code. Most people run with notices disabled. We don't like flawed code to slip through so we report all errors.

Attempts to Reproduce

First thing we did was check the development sandbox section of the deployment system. Oddly, the dev code did not have the problem.

Next, we tried updating the staging virtual host with the latest code and a copy of the production database. Again, the bug could not be reproduced. It happened only in the production environment. Odd.

Solution

Next Dave looked into it. Here's the transcript from the bug ticket:

I did some debugging as well:
* redeployed the SVN code to production (still causes an error in the production environment)
* dumped and recreated the production database (still errors in prod)

Eventually, I ran across this documentation about the table that controls the "LocalisationCache"

http://www.mediawiki.org/wiki/Manual:L10n_cache_table

> The l10n_cache table. Its content can be deleted and excluded from
> backups as it will be regenerated when needed.

....so I just did a `DELETE FROM l10n_cache`, deleting everything from the table.

That seems to have fixed it.

If this ever comes up again and someone finds this ticket – an easier way of troubleshooting, instead of uploading images, is to just visit the Version page – http://wiki.imarc.net/Special:Version – when the localisation cache is messed up, just visiting that page caused the serialize offset error.

So there you go. 

Lights. Camera. iMarc.

Posted by Jared Laham on December 13, 2013. Tagged: creative, culture

Ever wonder what iMarc is all about? Well you are in luck, because our new culture video has been added to our site for your viewing pleasure. We had a lot of fun making this video with our good friends at Off The Front Productions. In fact, we looked so legit and Hollywood like, that while shooting a couple scenes on Inn street a few onlookers thought we were a part of a Mark Wahlberg movie cast. 

So sit back, grab some popcorn and meet our team of talented designers, engineers, strategists, and business experts.

Selections from this video also appears on our homepage – adding a nice dynamic & human element to our hero banner. Wondering how we did it? Check out an insightful blog post from Jeff, our Director of Engineering discussing how to optimize video content for the web.

If you are interested in some behind the scenes shots of our video shoot, click here. 

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.