Setting the Mood with Mood Boards

Posted by Jared Laham on March 19, 2014. Tagged: creative, design

moodboards

Setting the Mood
When starting a design project, it's important to establish a clear definition of branded visuals and tone before moving forward with design deliverables. In most cases, clients have a well defined brand style guide at the ready, which helps clarify and reinforce visuals to come. However, what if a client doesn't have a (good) style guide and they aren't sure what exact aesthetics they are looking for? Mood boards to the rescue!

What's a Mood board?
For that very reason, iMarc's creative team uses a process called "Mood Boarding" to get farther faster. Mood boarding is a design exploration that leverages color palettes, stylized photography, typography, iconography, patterns, and layouts to develop a look and feel within a unified concept. In other words, an educated rough design that attempts to visualize what a client is asking for. 

Unfortunately, mood boards have been given a bad reputation as random boards of inspiration or abstract gatherings of "liked content". Truth be told, any step forward in a design process that adds clarity and identifies a creative direction is a valuable one. Designing a homepage is a calculated and time consuming process.  By exploring moodboards before a homepage design, you can quickly prototype multiple look and feels much faster than you would iterating on multiple home pages.

Create your own Mood board
At iMarc we take mood boards further than simply bundling elements onto a page, by establishing a strong concept that helps tie all elements on the mood board together. We have found the following process works well to strengthen your concept while getting better buy in from clients.

  • Collect inspiration from everywhere and anywhere;
  • Distill into no more than 3 concepts - Too many options, too many "frankensteins";
  • Show a variety of color palettes - Color is strongly tied to mood, so don't be shy in showing some serious contrast between palettes;
  • When in doubt, Latin to the rescue - Words are powerful on their own, and if a piece of marketing copy isn't exactly right, this can hinder further consideration of the board. If you don't quiet have the messaging nailed down, just use Lorem Ipsum. It still shows typography, hierarchy, and content density;
  • Talk about the board before showing it. Think of this as your drum roll before unveiling each board. Rather than rattle through the boards and ask "what do you think?". Create breakdowns for each board, clearly calling out the concept, elements and brand attributes associated with it.

Keep your mood happy
These boards should be light work and fun to create. Don't spend more than a few hours on each board and feel free to break out of your normal style of design while creating them. I like to look at moodboards as an opportunity to try a new technique or explore a new typeface without feeling too committed or fearful of usability. Mood boards aren't for everyone but if you ever find yourself not sure what visual direction will really resonate with a client, try showing them a few moodboards and see what happens. But beware designer friends, the biggest pain point with moodboards is the fact that when writing the word moodboard, every text editor and email client will auto correct it to "moldboard" and let's face it, no client wants those — yuck. So beware! Good luck and happy mood boarding.

To help you get started with your visual discovery, we have created a simple template to aid you in your next mood board. 

download_template

Download iMarc Mood Board PSD Template (.ZIP)

RequireJS Per-Page Modules

Posted by Jeff Turcotte on March 12, 2014.

We're trying out RequireJS  on a new project. It lets our Javascript be nice and modular with a single entry point and script tag.

One of the initial issues that I ran into with the implementation was doing per page modules. We like to organize our scripts by the page (or CMS tool) that is using them. If you are writing a one-page application fully controlled by Javascript, than you don't have this issue, the single entry point will work just fine. If you need to load a module per page, there's not really a great standard technique for doing so. The best example of how to do per page modules is described here: https://github.com/requirejs/example-multipage, but I found this way to have a pretty big downside: Useless "shim" files. Each page is required to have it's own javascript file (or inline javascript) to load your app-wide configuration javascript and then the page-specific module.

For our project, we decided to do it a different way, RequireJS already uses the data-main attribute on its script tag to load up your main entry file, so I decided to use another data attribute to specify the per page module.

We are using Twig templates for this application, so the implementation looks like this:

 

With this implementation, we just need to set the script variable on the template and the RequireJS bootstrap file will use it to load up the proper module. So far, this has been working out great and is a much more elegant solution than anything else I've come across.

How much is too much? A new rule of thumb for managing cognitive load in user choice

Posted by Robert Mohns on March 4, 2014. Tagged: best practices, user experience

If I showed you a page with 37 navigation links, 16 content links, 7 pictures, two ads and a search tool, would you tell me it’s too much?


Our clients often tell us, when we start working on a site redesign, that their old home page is “cluttered”, “too busy”, “too much content”, “overwhelming”, “confusing”. They don’t want their new site to fall into the same trap as the old.

There are a lot of decisions to make about what content makes it onto the home page. For now, let’s focus on one: Cognitive load.

It’s a pretty simple idea, despite the number of syllables: the more choices we face, the more work we must do to choose among them. Ever stand in a supermarket, looking at a wall of nearly-identical jars of pasta sauce[1]? That’s what I’m talking about.

How much is too much? Should we apply the old “7 items”[2] rule of thumb?

Review of Prior Art

Let’s look at the interface of the most wildly successful consumer product since industrial bread slicers appeared in the 1920s[3]. The iPhone.

What’s the first thing you see after you turn on your phone? The home screen. A modest grid of icons, each representing some activity you might wish to do. Here’s mine:

My iPhone's home screen

That’s an iPhone 5, which added an extra row of icons to the original 2007 design. There’s a lot going on there. Let’s break it down:

iPhone Breakdown

To simplify things, I’m ignoring the status bar and I’ve treated the four icons in the Dock as one object. Still, I count 21 choices.

How about the larger-screen iPad? Same number of items, just less densely clustered:

iPad Breakdown

This analogy isn’t perfect, of course. The phone is personal and familiar. You use it every day, and the locations of the icons become second nature. But I think it’s a good-enough analogy. The iPhone is designed to be unintimidating and easy to pick up; I’m confident that Apple’s designers spent a lot of time before settling on the original iPhone’s four-by-five grid, and it speaks to a fundamental conservatism that both the big-screen iPad and the the widescreen iPhone 5 only added a single row of icons.

If you look around, you’ll see plenty of other examples of limiting choice to improve user experience. Google could deliver hundreds of search results on the first page, but instead, offers just ten. Amazon suggests related products in batches of six to twelve. Apple has just two sizes of iPad and three iPhone models. The McDonald’s “value menu” has roughly a dozen options, no matter where in the world you go.

A McDonald's in Tokyo
(Image adapted from photo by Ian Muttoo)

All these companies are fully capable of providing more choices, and if you dig deep, you’ll discover they do. Apple’s iPhone, for example, actually comes in 116 different possible combinations[4] of model, color, network operators and storage size in the US alone.

So if a dozen or two items are managable, how about three dozen? I don’t think so – the Mac’s “LaunchPad” crosses the line into overwhelming with 36 items:

The Mac's Launchpad

Kibitzing about Subitizing

Most people can manage up to 7 items in working memory at a time. Does this mean you can only have 7 items on a page? No, it does not. It places a cap on how many new things you can expect someone to work with, but not on how many things you ask them to recognize[5].

The limit on how many items in a list of choices seems to be time-based. Working memory persists for around 20 seconds. If the time between starting and finishing a task exceeds 20 seconds, it’s a high-load operation for the brain, which must start committing pieces of the work to long-term memory for storage.

Studies[6] show the brain can count up to four objects at a glance (±2). Beyond that, our gestalt is “many” and we must subitz, chunk, or count.

Wait, what was that word? Subitz is a word psychologists use to describe when we count a group of things – too many to recognize at a glance – by breaking it down into countable groups. (It seems to be built on chunking items down into the limits of four.)

Whatever it comes from, it’s useful. It could explain why we like our phone screens have three or four columns of icons (a precedent that was set years before the iPhone) and not many more rows. Our brains can subitz a couple dozen items into less overwhelming, more managable groups, if we give it a pattern to break down.

A New Rule of Thumb

Quick recap:

  • More choices = more work
  • Working memory handles 4 to 7 choices
  • The brain will try to break down a dozen or two items into managable chunks
  • We see evidence of using this sub-chunk pattering everywhere from iPhone to car dashboards to fine art.

Put it together, and we can mint a new rule of thumb for how much is too much:

You can easily provide 20+ distinct content objects on a screen without overloading your user, if you break it out into a few clearly structured and differentiated groups.

Earlier, I asked what you’d tell me of a page with 37 navigation links, 16 content links, 7 pictures, two ads and a search tool. Too much?

Yahoo Breakdown

Nope. Not at all.

Postscript—

Two days after publishing this blog, Howard Moskowitz sent me an email:

The rest of the story.... Howard Moskowitz's career was jump started by George Miller (The magic number seven, plus or minus two). George was Chairman, Dept. of Psychology, Harvard in 1966. He accepted Howard for the Ph.D. in 1965, and after Howard passed the preliminary exams, George put Howard into SS (Smitty) Stevens' laboratory, with the prophetic statement -- Howie, you are resilient.

I couldn't be more tickled. Mr. Moskowitz, thanks for all you've done. Web usability professionals stand on your shoulders, sir. (Also, thanks as well for Cherry Vanilla Dr Pepper.)


Footnotes:

  1. Blame it on Howard Moskowitz.  ↩

  2. The Magical Number Seven, Plus or Minus Two, Miller, 1956  ↩

  3. Seriously. Sliced bread transformed the US bread market. At the time, about one-third of the average American’s daily caloric intake was bread, so it was a big deal.  ↩

  4. iPhone 4S: 2 colors, 4 carriers. iPhone 5: 3 colors, 3 capacities, 4 carriers. iPhone 4C: 6 colors, 3 capacities, 4 carriers.  ↩

  5. Jakob Nielsen has done much to popularize the application of working memory theory to web usability. He mentions the magic 7, but also warns that being too aggressive in minimizing options creates a new set of problems.  ↩

  6. Such as this one. ↩

Roses are #A60000, Violets are #0096D2

Posted by Jared Laham on February 14, 2014. Tagged: creative, culture, design

It’s Valentine’s Day, and what better time to show our love to clients, partners, supporters and everyone else we have worked with over the past year by sending a digital Valentine's Day card.

imarc_sweeties

How the Chocolate's Made

This year we thought we would change it up a bit and send out a Valentine's Day card instead of our infamous December holiday card. After we nailed down our concept, we sketched out a rough layout for each iMarc sweetie in the box. We knew that the only way this was going to feel authentic was to go big and for a companywide photo shoot. The Creative team setup a full day photo shoot and kept all our models in the dark about the concept until they arrived on location so we could ensure we'd get their natural reactions. 

valentine_collageThe Creative team selected our kitchen as the best location for this photo shoot as we had access to a loft to shoot from above and nail the perspective. Everyone was asked to bring their best "blue steel" looks to the photo shoot, but they really took it to the next level and dropped some serious Magnum for the camera. We coached them with things like "give us some come hither eyes like a cartoon character with hearts floating above their head" and "React to someone just bit off your leg, how does that feel?".

After color correcting the photos and loosely placing them in their respective spots within the photoshop document's layout, we began adding some Choco-Rific effects to each person – Taking bites out of some employees appendages and melting others to add more of that classic chocolate look.

And finally, what box of digital sweeties would be complete without a stylish chocolate legend showing each iMarc employee's hilarious chocolate flavor?

vday_candy_legend

 So from everyone here at iMarc, we wish you a happy V-Day and just want to know... will you be our Valentine?

 

PS - For anyone scratching their head about the title of this post, those crazy numbers are hexadecimal color values for red and blue.

Your PC is not a typewriter

Posted by Robert Mohns on January 27, 2014. Tagged: design, rants, user experience

Quick—What is the most mis-used key on a computer keyboard?

A keyboard

Now Entering the Wayback Machine

For centuries, typographers have improved clarity and legibility by using several kinds of dashes: Hyphen, figure dash, en-dash, em-dash, and the minus sign.

  • (-) The hyphen is used in two-part adjectives (see what I did there?), in phrases used as adjectives, and of course for hyphenating long words at the end of a line.
  • (–) The figure dash is the same width as a number in any type face, and is used only between numbers. Many fonts are missing it, as is the HTML specification; an en-dash may be used in its stead.
  • (–) The en-dash is used, without spaces, to connect things related by distance or range (ex: 6–10, May–Sept). They're also used, on occasion, to connect a prefix to a proper open compound (ex: pre–World War I).
  • (—) The em-dash is used to denote an abrupt change in thought or direction, or—very rarely—in groups of three to substitute for redacted names.
  • (−) The minus sign is used only in math (ex: 8 − 5 = 3). It's Unicode 2212 and, like the figure dash, is often omitted from fonts.

(Often, the en-dash is combined with a space on either side instead of an em-dash. Proponents argue this is the modern and simpler equivalent of an em-dash; traditionalists insist that the dashes have distinct benefits and are not interchangeable.

(Ultimately, it's a matter of taste. The Chicago Manual of Style prescribes the unspaced em-dash, as do most American publishers and the Oxford Guide to Style. Canadian typographer Robert Bringhurst, in his classic The Elements of Typographic Style, codifies the practices of several major English publishers (including the prestigious Cambridge University Press) in prescribing a spaced en-dash. The AP Style Guide ignores the matter entirely and shows its telegraph roots in prescribing a double hyphen instead.

(iMarc's Frontend Handbook follows Bringhurst's in prescribing using a spaced en-dash; in fact, we use only the hypen and en-dash, retiring the other three dashes completely. I think that's a travesty, but I lost the vote.)

But to our muttons—

By now, you will have inferred the answer: the hyphen is the most mis-used key.

Like the 19th century typewriter, our keyboards provide only a hyphen. When the only tool you have is a hammer, everything must be nailed.

But the personal computer is not a typewriter. Our PCs' keys are far more flexible than a mechanical typewriter ever was.

And, at least if you are using a Mac, it's really easy to use the correct dashes in your writing. The option key provides access to alternate glyphs. Press Option-Hyphen to produce an en-dash:

Keyboard with option & hyphen keys highlighted

And to create an em-dash, add the Shift key:

Keyboard with option, shift & hyphen keys highlighted

Voila! Whether you prefer the spaced en-dash or the more traditional em-dash, you are now self-sufficient! (For fun, experiment with the other keys. You'll find dozens of useful glyphs, ranging from ™ and ® to ∆ and ∞.)

If you use a Windows or Linux PC, try holding the alt key and enter 0150 on the numeric keypad. If all goes well, you'll have an en-dash. Use code 0151 for an em-dash. (You're on your own for the rest.)

Happy typing!

§

* Blog title: Hat tip to Robin William's The Mac is Not A Typewriter. No, not that one. This one.

Why I Want to Build You a Custom CMS

Posted by Matthew Sahagian on January 9, 2014. Tagged: engineering

Often times clients are interested in turnkey CMS systems. The general theory goes something like this.

  1. Install CMS
  2. Customize With Plugins
  3. Vendor Independence
  4. Profit

While turnkey solutions are great for some people, there are limitations to systems which are designed to fit the needs of as many people as possible. People look to systems like these for a number of reasons, most importantly is what is often perceived as end user control without the need for a vendor intervention.

While it may be true that one can gain a certain amount of vendor independence, I'd like to address the primary reason that I think a custom CMS trumps generic CMS systems.

Your Data is Important to Me

One of the primary and obvious benefits of a custom CMS is that the tools you use to manage your content can be modified to reflect both your data and your domain models explicitly. While a number of CMS solutions offer mechanisms for defining taxonomies and schemas; these are often very shallow representations which cannot provide the deep relationships and business logic between conceptual objects which can be achieved with custom schemas and models.

The vast majority of projects here at iMarc begin and end with a business's domain model. That is, much of the early strategy phase is exploring what client's want to present to the world, what terminology they use to represent it, and how it relates to other conceptual objects; with good reason...

Your Data is Important to the Web

HTML5 popularized the idea of the "semantic web." Although this is something developers have been talking about and focusing on for years, part of what HTML5 began to offer the world was new ways to identify content. Since this is part of the very language that rules the web, it can be standardized to such a degree that companies like Google can aggregate much richer information about your business, organization, or project.

This results in better search results, higher potential for syndication and networking, and, of course, a more fulfilling experience for administrators, web users and, ultimately, customers.

Well structured and organized data has the ability to produce well structured and organized markup. Using Google's Structured Data Markup Helper, I used a recent blog post on iMarc's homepage to see some changes we could make to our markup.

I began by selecting text and choosing what it represents after having first selected the type of data we want to identify, in this case a blog post:

A screenshot of the initial steps of Google's Markup Helper

Once I tagged the content, I can create a modified HTML version which generates changes that allow Google to index that information in a semantic (i.e. meaningful) sense:

Google's markup helper suggests modified HTML to identify elements.

Now, while it is completely possible to use a non-custom CMS and manually insert this markup or install plugins to try and gain similar results; I can see pretty quickly how tedious this might be to manually identify otherwise non-distinguishable data and fields.

Alternatively, as I look at the data in our own CMS, it is immediately clear to me that this information could be added in very much the same way the blog content itself is. One of the key benefits of custom solution is that any adjustments I'd make to how one blog article gets rendered would persist across all future and past blog articles without any additional work.

Data, Forget Presentation, Meet Entropy

Often, what clients are actually interested in is "free-for-all" type content editing. This demand is not merely for the sake of being able to say whatever they want wherever they want, but also for the sake of being able to present it how they want.

Inevitably, what users and customers want is information. RSS, for example, was perhaps the first commonly known foray of the web into rich semantics. The result of this data format was a host of readers both native and web-based which put information at people's fingertips. And wouldn't you know it, there were probably nearly as many RSS readers as there were people reading RSS. I believe that this is because as most of us fetishize about presentation, a single firm, designer, or stakeholder is rarely (if ever) uniquely capable of deciding the best way to go about presenting their information (in this case articles).

Overall, the great fear that a custom CMS means lack of control and, thus, lack of function, is a myth. While it may be true that users working with a custom CMS cannot arbitrarily do whatever they want, that is precisely the function it offers.

The explicit tools designed with your data in mind are what affords your website a lack of entropy over the long haul. It is what makes it live longer than any one design trend. It is what makes content end up where users expect it, rather than where the new content manager you hired decides to put it. It is what gives consistent, reliable, and accessible user experience that has the capacity to deliver great content regardless of a user's desired presentation model.

It is the reason the HTML and "the web" exist.

The Middle Ground (Conclusion)

Custom CMS systems afford a high degree of specialization and a consistent experience for both content editors and content users. A well designed custom CMS system should be easy for both the original vendor or a third-party developer to modify and customize. Using good object oriented design, a high level of abstraction, and a future-focused approach on the first build will conserve all of the benefits and limit the amount of time and money required for future modification.

While this does not equate to being able to download and install a plugin from who knows where to add new feature X, it does mean that features Y and Z will not have you trying to shoehorn your business's data into something so broadly designed that it works just as well for a kid in his parent's basement writing a blog. If you remain concerned about the control you'll have to modify and develop your new website or application long term, make that concern known, and address it with whomever you decide to work with, I think you'd be surprised at the solutions the right partner can offer.

In short, the idea that vendor independence and long term customizability, is a "free" feature of an off-the-shelf CMS is a misnomer.  Any truly well-developed solution will still require someone familiar with modifying and customizing that CMS, and the hidden cost of something designed without your data model in mind may be more than you realize.

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.