It’s that time of the year when tech evangelists all around the web write their predictions for what is to come in the next year. While most write of the latest APIs and upcoming knock your socks off features, I wanted to add my own “down in the trenches” view on what trends will affect PlaceLocal’s front end development practices in the year to come.

As the popularity of more sophisticated web applications continues to increase, it becomes paramount to embrace tools that manage complexity. Two of the most popular tools for dealing with CSS are Sass and Less. While these tools are very similar — both of them pre-process CSS into manageable and maintainable chunks — Sass’s popularity will grow at an increasing rate due to its limitations in client side compiling.  Some view Less’s handling of client side CSS parsing as a feature, but it’s a hack which allows web best practices to be circumvented and ultimately harms development more than helps it. Also, while you don’t have to use client side rendering (there are even PHP rendering tools to parse Less server-side), a cleaner solution — Sass coupled with Compass — will reign supreme in the coming year.

As mentioned web applications are here to stay and the minute I say “web applications” your mind instantly wanders to some of the most popular frameworks that help develop client side applications such as Backbone, Ember, Spine, Knockout, and Angular.  While these will continue to gain popularity, none will increase as much as Backbone and Angular.  Backbone’s approach, with its un-opinionated view on how it is implemented, allows for a variety of flexible solutions that many frameworks simply do not offer.  Where the legwork in setting up a Backbone application may seem cumbersome, Angular takes over with its high level of abstraction and ease of rapid development.  These frameworks accounting for 97.35% of the use cases will therefore attract more use preventing the niche alternatives from gaining as much popularity..

Underscore… nothx

It is no secret that we at PaperG love Backbone.  We love it because of .sync() and its lightweight footprint, but we are also fond of its only hard dependency, underscore.  Underscore, which gives some useful everyday development solutions for arrays, objects, and collections, just wasn’t good enough for superhero tech dev extraordinaire John-David Dalton. Enter Lo-Dash as a drop in replacement to underscore that offers significant improvements over underscore with no trade offs in functionality or support.  Why anyone would argue against a performance gain with a simple file switch I can’t understand and therefore, this will be the year of the Lo-Dash.

Skeuomorphism is no more.

Skeuomorphism is a design trend in which UI controls/designs resemble everyday objects, and it has recently become a hot topic among Apple designers upset about other designers’ use of skeuomorphs.  The need for the skeuomorph to describe functionality based on the copied objects’ inherent properties is dwindling due to users becoming more familiar with common UX problems and the designers of applications no longer needing to anchor reality within their design. This increase in user maturity will strengthen the drive towards minimal approach and leave Skeuomorphs to outdated designers. No more Apple notepad lines, bookshelves, or calendars, please.

As with all tech predictions, these may or may not come true.  However, with 100% certainty, 2013 will be a year filled with progress made towards making PlaceLocal faster, more maintainable, and easier to use for all of our customers.

This past week the folks of the engineering team broke in our new digs with a movie night and gave us a little glimpse into the new space along with the great team culture we’re building there.

PaperG is in the position to  leverage our ability to generate ads for local businesses.‭ ‬When consumers use their mobile devices to search for activities and goods,‭ ‬mobile local advertising‭ ‬‭becomes paramount to the‭ ‬success of local businesses.‭

‬With our current infrastructure to create,‭ ‬distribute,‭ ‬and display local‭ ‬ads, we are able to push the market of mobile web advertising further.‭ ‬At PaperG we have redesigned the way we show and create our mobile ads with the‭ “‬mobile first‭”‬ paradigm in mind.‭  ‬

When we began developing our mobile ads we wanted a system that would have the broadest reach among the fragmented market of mobile devices.‭ We immediately discounted technologies such as Flash and canvas,‭ ‬due to penetration,‭ ‬and adopted a strategy using HTML,‭ ‬CSS3‭ ‬and JavaScript.‭  ‬This allowed us to‭ ‬give the consumer seamless mobile performance‭ ‬within the browser without sacrificing battery life.‭ ‬‬Through‭ the ‬development‭ process, three ‬challenges surfaced:‭ ‬mobile performance,‭ ‬graceful degradation,‭ ‬and responsive development.‭

Mobile performance

A good mobile ad is able to catch‭ ‬the eye,‭ ‬yet‭ ‬doesn’t interrupt the user’s experience.‭ ‬The worst thing an ad can do is slow a page down and cause the user to get angry at the featured business. We accommodate this by developing our ads with a solid design foundation‭ (‬no bouncing crosshairs‭) ‬and focus on performance.‭ This performance-first strategy is‭ ‬harnessed by using the power of CSS3‭ ‬transitions on supportive devices.‭ Our technology allows the device to optimize repaints within the browser,‭ ‬ultimately creating a smooth transition and a good user experience.

Graceful Degradation

Since we use ‬HTML‭ ‬we can develop a rich mobile ad,‭ ‬enhanced‭ ‬with smooth‭ ‬animations, that afford an acceptable experience for‭ ‬non-supportive devices.‭ We use more basic work-arounds for features that some mobile devices don’t support. ‬For example,‭ ‬when‭ ‬we can’t use CSS3‭ ‬transitions, we fall back to standard JavaScript animations.‭ With this approach, limited feature support is no longer a challenge.

Responsive Development

Supporting varied resolutions across devices is necessary. Each resolution has a different standard ad size that must be accounted for. PaperG’s PlaceLocal platform supports the following form factors:

It was important to develop one codebase to serve our ads on all supported sizes.   ‬In fact,‭ ‬other than the requested dimensions,‭ ‬there is no difference in the file‭ ‬structure served to the distributor.‭ ‬While developing within this framework,‭ ‬‬we encountered several challenges.

Text Sizing

We have a limited space to show reviews ‬within our mobile ads. To accommodate this, we developed a system that auto sizes the text based on the height and width of the container without having to hardcode individual values into our‭ ‬CSS. ‬This gives us much more flexibility to design attractive ads without worrying about the text layout.

Image and review transitions

Traditionally, animations had to be coded for each specific ad format. We created a system that lets us code animations once and transition our content across multiple layouts. In our animation system, code specifies when images and reviews transition in and out of ads; where they go depends on the layout. As an animation goes from 0% to 100% completion, our framework dynamically computes positions based on the dimensions of the ad, seamlessly adjusting to every format.

File Size

So,‭ ‬you want support on a huge array of devices with a small file size and fast load time? ‬No problem! To tackle this difficult, we‭ ‬set up our‭ ‬CSS to serve only the required markup and specially optimized images.‭ For you that means we don’t waste any bytes and for us we save time by using the same code across devices.

‎As the mobile web continues to evolve,‭ ‬we at PaperG pride ourselves in our ability to bring advanced technology to local businesses and ‬right now is an exciting time to help‭ ‬push mobile web advertising forward. ‭

PaperG
Local Mobile.‭  ‬Done Right.

That problem is old news to us. Thousands of people use PaperG’s products for their jobs, and all of them are trained to use our online ad software. When we redesign, we can cost these people valuable time re-learning our “improved” interface, and their time is their company’s money – our customers’ money. If we’re not careful, we lose customers out of frustration and irritation. So we take a step back, and we design the redesign.

Whenever you redesign your product, your users go through “retraining.” They have to figure out the new ways to do things and forget the old ones. They’ll figure out tiny changes quickly, but they need extra help with more substantial changes. For those changes, we design ways to guide users through new interfaces and minimize the pain of retraining – transition strategies.

Transition strategies pose a unique bandwidth problem because they’re temporary features. They’ll be gone in a month, so you don’t want to spend developer time on them. That would waste valuable talent, and we already have a persistent shortage of engineering bandwidth (did I mention that we’re hiring?). Rather than starve important projects, we adapt our strategies to use as little developer time as possible.

Our secret is deceptively simple: we offset most of the work implementing transition and retraining strategies to our support team. In practice, this requires significant planning by the product and support teams. However, after over thirty iterations over several years, we’ve gathered a few favorite strategies that are easy to implement.

Callouts

We often use callouts for small changes, but they only work if used sparingly. We deploy callouts to point out buttons that moved, or new features. Users only see the message once, and they have a choice to view the quick briefing or to just dive in. We’ve been using a service called WalkMe, which lets our support team design the briefings with no help from the developers. We rarely use callouts to explain features because users don’t like to read. Instead, we use them to direct the user’s eyes to changes, and to remove the sense of surprise. This is important enough to repeat: use callouts to point, not to explain.

Tutorial Videos

Unlike callouts, tutorial videos aren’t so great at pointing out changes, but they’re great for explaining new concepts and features. We show the tutorial video the first time a user encounters the updated feature, and the user can always dismiss the popup. Each video takes several hours of our support team’s time, but it takes little of our developers’ time to actually embed the video. As an added benefit, these tutorial videos make excellent training materials for new customers.

Support Articles

People do still read support articles, so we write them. However, we’re careful to avoid writing a manual, because our stats consistently tell us that nobody wants to read more than they have to. We make sure to hit two important requirements:

1. Navigation to the right article needs to be easy and fast. For that, we use contextual support buttons and carefully curate their links to make sure users trust them for the right snippet of useful information.
2. Our articles are short, light on text, and heavy on images. Our users don’t have the time to sift through a manual, so we don’t bother to write one. Instead, our support team writes articles to address the common issues users bring to them.

Once again, our support team does the heavy lifting.

Live Support

Finally, we have live support by phone, email, and chat. This is a safety net that catches every user who wasn’t helped by our other release strategies. Google Apps offers an easy phone and email functionality through Google Voice and Gmail. For live chat, we use a wonderful service called Olark, which only requires our developers to embed a JavaScript tag. The rest is done, once again, by our support team.

I suppose this post turned out to be more about support than engineering, but that’s partly why our release strategies work. As part of support’s job, helping frustrated users, they implement actual site features and free our developers to work on other things. And our support team interacts with users more than the rest of PaperG, so they’re actually the best people to retrain users with each new release.

A wise person I knew always asked: “well, have you watched someone use your product in the field?” For far too many startups, the answer is a guilty “no.” We all know we should run usability tests, but we don’t. Some people might add “but we do gather metrics” as a mitigating factor. No, that solves a different problem.

Metrics are great for answering questions you already have, but they’re not good at pinpointing usability problems. For that, you need user testing. We were in that situation: our metrics indicated problems, but we didn’t know what the actual issues were. So we started to run usability tests.

Our methods were inspired by an excellent book on the subject: Rocket Surgery Made Easy by Steve Krug. In it, he recommends periodically bringing in a few users for short, supervised sessions. This provides valuable feedback at a low commitment to your team – a few hours a month is more than enough.

Finding ad salespeople who could drop into our actual office for an hour at a time was more daunting than we expected, so we tried an online service instead: UserTesting.com. You submit a website URL, a list of tasks you want testers to try, and the demographics you want for your testers. UserTesting.com then chooses human testers for you and records their screen and voice during the session. Usability tests are amazing tools for highlighting both anticipated and unanticipated problems, and UserTesting.com makes running them quick and easy.

When we discovered how much useful data we could get from even one test, we made usability testing part of our iteration cycle. Once our release goes out, we run a round of tests to inform planning for the next iteration. This ensures that we address the right issues.

For us, reviewing the tests is a whole-company activity. Our accounts people get a better idea of what their users are thinking when they ask for help. Our designers get feedback for future UI changes, and our developers see the concrete evidence behind design choices that may sometimes feel arbitrary. Usability testing focuses our team’s efforts on the user, which is where we should be focusing anyway.

And finally, for your viewing pleasure, here are a few new UI features inspired by feedback from our tests. In each case, we fixed them and then double-checked our ideas in the next round of tests.