Productivity In The Office

If you’re like me, you have a lot to do in a day. You’ve got meetings to attend, emails to answer, phone calls to make, and various other tasks to complete–and those are just the things you’re expecting.

Over the last five years of working at Algonquin Studios, my responsibilities have increased and my days at the office have become more and more hectic. For me, that can be a big deal. I like to be organized. I get satisfaction from completing tasks. I like to give my client first-rate service. I like to be productive.

Regardless, the craziness of a day at the office often threatens to blow all of that to pieces. Sometimes, you receive more emails that you can realistically answer in one day. Sometimes, your day is filled with unexpected interruptions. Sometimes, you may have so much to do that it’s simply overwhelming.

Over the years, I’ve learned to combat the urge to plunge into the mayhem head first. I’ve learned how to stay organized and calm through the storm of insanity that gathers in my inbox. Most importantly, I’ve learned how to be productive when distractions mount.

Here are some of the things I do to keep perspective and be productive:

Make To-Do Lists

I like making lists. I use them to keep track of the various tasks that I need to complete in a day or in the next week. Every morning, I make a new list with the tasks that I need to do that day. Sometimes, a few of those tasks are carried over from the day before and that’s okay. I don’t always get through my list, but just making it gives me a plan for the day.

Block Out Your Calendar

One of the easiest ways to get behind on work is to allow yourself to get overbooked. Each week, I look at the tasks that I need to complete and block out time on my calendar to work on those tasks. Each morning, I review my calendar and update it as needed to correspond with my to-do list.

Does it really matter if I send this email or make that follow-up call right at 1:00? Most of the time it doesn’t, but blocking out my calendar keeps me (and my co-workers) from scheduling more appointments than I actually have time for.

Complete One Task at a Time

Multitasking often seems like the perfect solution for achieving the mounting responsibilities of your day, but research shows that it doesn’t really work for most people. The article, “Think You’re Multitasking? Think Again” puts it well:

“People can’t multitask very well, and when people say they can, they’re deluding themselves,” said neuroscientist Earl Miller. And, he said, “The brain is very good at deluding itself.”

Focus on one task and work it to completion before you start the next one. You’ll be more productive because you’ll be able to give your full attention to one thing and you’ll get the satisfaction of completing that task. It may mean ignoring your email or your phone for periods of time, but, in many cases, it’s worth it.

Take Occasional Breaks

I find that if I plow through the day without taking the occasional break, I’m burned out by mid-afternoon. Take a few minutes to recharge and between tasks. Get up and stretch or get a drink.

Along the same lines, use your lunch break to re-energize. Move away from your desk and allow your mind to focus on something else for a little while. Personally, I like to read during my lunch break.


These are some of the things that help me make the most out of my day and hopefully these tips can help you stay focused and increase your productivity, as well. If not, then hopefully they’ll get you thinking about what things work best for you. Let me know if you have tips or tricks that you use to get the most out of your day.

The Often-Overlooked Value Of A Quality Support Team

My team and I are software support representatives – when end users struggle with issues they can’t resolve themselves or encounter bugs or glitches, they call us.  We’re the first line of defense – being there for our customers and putting their minds at ease.  Over the past year, I’ve learned a lot about why the position I hold is necessary (and I’m pretty sure the developers we help would agree).

Frustrated customers don’t remain customers for long:

This one should be fairly obvious.  If a product or service you’re using causes you more grief than benefit, you’ll probably stop using it.  When a support call comes in, it’s the support representative’s job to provide the feeling that someone associated with the product cares about the customer’s issue.  If the end user is forced to leave a voicemail and wait for several hours before hearing a response, they might begin feeling like their problem will never get fixed.  No one ever wants to feel as if they are being ignored when they have a problem; letting customers fend for themselves is bound to have them looking for alternatives.

Support representatives are the face of the company:

Support reps are frequently the first people to have contact with a customer, and first impressions can be everything. A positive experience can make the customer feel confident that their issue will be addressed quickly.  A negative experience, however, can deter the customer from calling again.  Although support representatives often make up a very small part of a company, they’re usually closely associated with a customer’s opinion of the entire organization.  When a customer hears my voice, they have something tangible to associate with their product and my demeanor can set the tone for their continued relationship with the company.  Ideally, you want the person on the phone with your customer to be caring, kind, and patient, so the relationship will be as well.

Developers often don’t mix with customers:

While it’s not true in every circumstance, there are a lot of developers who don’t necessarily want direct contact with the customer. Certainly, it’s tough to concentrate on coding if your phone is ringing several times an hour, but developers can also suffer from being too “sophisticated” for their own good (and the clients’) – since they’re surrounded by colleagues who understand complex processes, it can be difficult for them to put a description into layman’s terms for an end user. Software support provides a bridge between end user and developer; the reps have enough technical know-how to work with the developers on more complex issues, but can easily relate to struggling (and, sometimes, impatient) customers.  Plus, I know some developers who just “don’t like talking on the phone” and that’s not the kind of person who should be communicating with customers on a daily basis.

Support representatives take pressure off developers:

This is obviously related to my previous point, but important nonetheless. When a customer loses patience (and nearly everyone does, at some point), they can lash out.  Support representatives are trained to handle this pressure and work to prevent it from reaching the developers. The goal of the development team needs to be producing quality software; the goal of the support reps needs to be managing the expectations of customers and helping them resolve problems quickly and with minimal pain.

It’s no coincidence that the most profitable companies have excellent support teams to back up their excellent products.  Now more than ever, these companies have come to realize that without a strong, committed support team, there would be no customers to support.  Don’t underestimate the value of a great relationship with your customer!

Building A Brand: Some Thoughts From LMA12

At last week’s Legal Marketing Association annual conference, I was lucky enough to get away from our exhibitor booth to attend a breakout session entitled The Evolution of the Law Firm Brand: How to Promote Individual Attorneys within the Parameters of the Firm’s Brand.*

Obviously, I don’t work at a law firm (though I did spend some time in my mid-20s at an old-school firm where the senior partners still smoked cigarettes in their offices and called members of their all-female support staff “baby.” Yes, I’m serious). But, I am responsible for helping to craft the Algonquin Studios brand and for translating it into “outbound communications that strengthen the firm’s marketing message” (stolen directly from my job description), so I figured I’d be able to find some interesting overlap in the marketing messages from this session, as they apply to a law firm or a professional services firm – and I was right!

Some great insights from the session:

For Law Firms

  • There are too many law firms, with too many lawyers, in the mix these days. Legal marketers need to focus on differentiating their firms and attorneys from the competition.

How We Can Apply it at Algonquin Studios

  • Similarly, there are many web and technology companies to choose from these days and our work is frequently commoditized. Clients are often looking for the best price rather than the most helpful service or reliable vendor. It’s important that we strive to constantly distinguish ourselves from the competition and show prospective clients how we’ll bring real expertise and value to our relationships.

For Law Firms

  • Focusing on individual attorneys’ personal brands, rather than pushing the firm’s brand, becomes incredibly important when you consider that 56-75% of legal site traffic happens on attorney bio pages.

How We Can Apply it at Algonquin Studios

  • A quick look at our analytics information shows that, while they don’t pull in the same super high percentage of traffic as bio pages on law firm sites apparently do, our principals’ bio pages and the AS “about” page both consistently rank in the top five for page views on our corporate site. Creating quality content for these pages – content that demonstrates our knowledge but, more importantly, helps site visitors feel connected to us – is not only smart, it’s vital to the success of our company.

For Law Firms

  • In order to make bio pages successful and accomplish the differentiation needed, the attorney and their personal story need to come through in the biographical content.

How We Can Apply it at Algonquin Studios

  • We need to humanize our professionals; allowing prospects to feel like they really know us, understanding what we can do for them and what a relationship with us will be like before they ever call our office or come in for a meeting. Site visitors should be able to tell what we do and, perhaps even more importantly, what we love about what we do.

For Law Firms

  • Legal marketers need to remember that it’s their job to facilitate, assist, and coordinate the creation of thought leadership content at their firms. And, they need to resist the urge to author content on the behalf of their attorneys.

How We Can Apply it at Algonquin Studios

  • In an ideal world, there would be a ton of people here at Algonquin able to pitch in on our content creation efforts. But we’re all incredibly busy and finding time to compose a blog post or co-author a report is tough. This is where our own marketing team comes in – encouraging folks to contribute, managing our editorial calendar, reminding authors of upcoming posts, offering to do preliminary research, and more. Sure, it might be easier (and possibly less time-consuming) to author it all ourselves and slap someone else’s name on it but the content we create needs to have a personality. And that personality needs to be genuine, which can be hard to pull off if you’re pretending to be someone else!

My takeaway from this session was that, while we’re on the right path, we’ve got some real work to do on the Algonquin Studios corporate site and in the creation of our thought leadership materials. I’m pretty excited about working on our brand and our corporate personality… and helping the talented individuals who make up the great team here at Algonquin work on theirs, too!

*Moderator: Adrian Dayton, CEO; Adrian Dayton & Associates
Presenters: Aden Dauchess, Dir. of Digital Media; Womble Carlyle Sandridge & Rice LLP
Robert Algeri, Partner, Great Jakes Marketing
Peter J. Winzig, Dir. of Mktg. & Corp. Development; Weltman, Weinberg & Reis Co., LPA
Joe Calve, Chief Marketing Officer; Morrison & Foerster LLP

HTML5 and Enterprise on Mobile

This post originally appeared on my blog on Saturday, March 10, 2012.

An Argument

HTML5, CSS3Early last week .net Magazine posted an article Why HTML5 is not the choice for enterprise mobility by David Akka. The article starts off with the statement HTML5 is being hailed as the programming language… That’s as far as I got before I realized this article had a fundamental misunderstanding of HTML5.

If you’ve read my blog enough, you know that I have been constantly struggling with how developers have shot themselves in the foot by allowing HTML5 to mean far more than just the HTML5 specification. Reading the comments to the article you can see that some people think the author is talking about just the mark-up language, and others seem clueless that there is a markup language.

I soldiered on and read the rest of the article. I realized that the main thrust of the article is less a technical assessment of HTML5, but is instead a discussion of how this collection of specifications is seen by so very many as a panacea for web application development. The author makes some valid points about security (specifically user-based, such as phishing scams thanks to bad browsing habits), lack of robust synchronization, and the ongoing changes to the W3C standards that can wipe away development efforts when the browser makers decide to change direction to match.

The author’s inability to clearly and correctly identify the appropriate specifications and speak to examples left the door wide open for anyone who rails against words such as “enterprise” to attack the article on its lack of technical merits.

A Response

In a response post, Why HTML5 is a choice for enterprise mobility by Kevin Sweeney, the three core arguments from Akka are challenged. The security issue is brushed aside as a function of poor development. The asynchronous nature of the web is addressed out of hand as a function of images and CSS, not so much about client-server communication and how best to lock and release records (for example). The argument about HTML5 as an unfinished specification isn’t addressed any more than to suggest that using it will make it wrap up sooner, but still with a fundamental misunderstanding of just which of the W3C specifications are really the ones in question.

A Response to the Response

Akka responded with another post, Why HTML5 is not the right choice for enterprises right now – or the defence of David Akka, which gets into some more detail on the technical side, but still gets some terminology wrong. As the one comment on the post demonstrates, people will skip the arguments within just to go after the technical detail, making the response effectively moot.

My Thoughts

When I get past all the misunderstandings of the specifications in the posts, including HTML5, I tend to agree with the overall message of the original post that rapid adoption, possibly for the sake of being cutting edge, is a real issue. This also assumes, of course, that the writer of (and responders to) the original article actually understand what “enterprise” means.


So much of modern web security is about defending against user-initiated attacks — phishing scams, malware, adware, viruses-as-email-attachments, and so on — that I think the real issue with security is really a combination of keeping users from doing daft things and protecting your environment when they do.

Add to this developers who haven’t been inculcated in an enterprise environment and maybe don’t think about the sensitivity of data passed over the wire, or enterprise developers re-positioned to use these new web technologies, and you have some further risk.

Factor in web beacons that seem to come with the territory of developing all the “new shiny” and there is also an end-user security factor to consider. While a developer may not embed a Facebook button or an ad banner on an enterprise web app, that doesn’t mean they aren’t in the code borrowed from somewhere else, especially if the developer is new to the game.


I’d like to think every developer has already built a system to lock records — ideally one that doesn’t halt all other operations on the system. This should always happen at the server level. The challenge here is how to handle dropped connections, users who don’t “log out,” and the other trappings of a stateless protocol propped up by a scripting language that has to manage calls to an API on the server that actually does the real work.

This can be addressed and has been successfully on the desktop. On mobile it’s a bit trickier with more likelihood of flaky connections and long wait times. It doesn’t need to be, but too many scripting solutions that ping the server (maybe for XML, maybe to order a pizza) don’t have clean methods of handling dropped connections and can end up leaving users stranded.

While that’s not the technology’s fault it is something that, lacking a clear standard, requires each company to re-invent for itself.

Unfinished Standards

Many sites are leaning on the W3C Web Storage specification (which is not HTML5, but is lumped in with it). If you’ve been paying attention over the last week you have seen a battle over this specification, with some developers calling for its termination in favor of a solution like Mozilla’s IndexedDB or the now defunct WebSQL W3C specification.

Those developers who might have wanted to use WebSQL only to see it get pulled may now fear the same thing happening to the localStorage API (Web Storage). Web applications they built to support it may need to be revisited. Clients, projects, etc. may need to be updated. Dollars will need to spent. This is enough to make a company hesitate.

If you aren’t in the loop, check out some of the ongoing discussions and remind yourself that anyone in enterprise development through web apps (mobile or otherwise) needs to stay on top of these battles to make ongoing informed decisions.


Look to the business case. Don’t fall for the arguments against enterprise mobile web applications just because someone is afraid of a new paradigm, but instead make sure the resistance is based on sound business and technical considerations. Don’t fall for the arguments in favor just because of a knee-jerk reaction against “stodgy” enterprise models or a gee-whiz fanboy/girl mentality to all things mis-labeled as HTML5.

Ongoing Misunderstanding of Flash and HTML5

This post originally appeared on my blog on Saturday, March 3, 2012.

The latest article that uses absolutes and broad generalizations to imply an otherwise non-existent struggle between Flash and HTML5 is from UX Booth, “What the Demise of Flash Means for the User Experience.” To be fair to this article, I see regular missives on Flash vs. HTML5 and this particular UX Booth article is just an example of many of them in one easy to cite place.

The opening gives away the false premises for the rest of the piece:

Adobe’s decision to cease development of the mobile Flash platform and increase their investment in HTML5-related efforts created perhaps the final piece of conclusive evidence that HTML5 is the current go-to technology for creating ubiquitous user experiences regardless of device.

First I have to accept that the author is talking about more than the HTML5 specification and is also referring to CSS3, JavaScript, and the W3C specifications that are related to HTML5. This lack of clear delineation chips away at the argument.

Adobe has held that the fragmentation of mobile devices is too hard to keep up with on its own. Flash will still exist for mobile wrapped in AIR applications instead, and Flash is not going away from the desktop. Adobe’s decision to increase investment in HTML5 (via Edge and to a lesser extent Muse) is mostly unrelated since there is a market for an HTML5 authoring tool independent of Flash.

Not only is this neither conclusive nor the final piece of evidence that HTML5 is the current go-to technology, this is anecdotal evidence at best. In addition, HTML5 itself is nowhere near complete and the element often regarded as the Flash-killer, canvas, isn’t anywhere near as robust as Flash and still lacks strong scripting or styling support in the specs.

I think it’s fair to challenge the claim that HTML5 creates “ubiquitous user experiences regardless of device” when you consider all the polyfills and shims that need to be implemented to create similar experiences on a few devices. It’s also fair to say that my netbook does not handle some of the related HTML5 specifications the same as my tablet or mobile phone, partly due to various levels of hardware and browser support. Let’s not even get into video and audio codecs or the touch events specification (neither of which are part of the core HTML5 specification).

HTML5 excels at giving users a delightfully inconsistent experience on any device through the concepts of “graceful degradation” and “progressive enhancement.”

Those terms pre-date HTML5 and I can do both with HTML4 and CSS2. The author continues on and cites responsive design as a feature of HTML5, even though my own site is an example of an HTML4 site using responsive design to adapt to assorted displays.

Additionally, more than 90 percent of all smartphones and tablets are HTML5-enabled, which means that all the benefits of HTML5 can be utilized today to provide impressive mobile websites.

The author’s math doesn’t bear out the assertion — by the author’s numbers, 10% are not HTML5-enabled and so cannot benefit from HTML5. For the other 90% that are, even they cannot enjoy all (author’s word) the benefits of HTML5 today.

Making or upgrading to an HTML5 site can be as minimal as simply using HTML5’s doctype […]

The implication here is that simply changing a doctype gets you all the benefits of HTML5, when in reality you still have the same HTML, CSS and script.

The post never does answer its own question — what does the demise of Flash mean for the user experience? From the article, more HTML5 use. In itself that doesn’t tell me how the user experience is affected, just how developers are affected. If the developer does a good job, the user experience doesn’t need to change. The user shouldn’t need to worry about the underlying technology.

Too many HTML5 articles and posts today, like this one, work to promote the markup language (and usually CSS3 and JavaScript, even if they don’t know it) by contrasting it against another technology that is falling away or is just a popular target of derision. The pro-HTML5 cheering is easy when another technology has already been recognized as out-of-date, but this doesn’t do anything to advance HTML5 and its related specifications.

I’d love to see more practical discussions of what HTML5 (and related specs) can do today along with all the nifty experiments that are moving the collection of specifications along.