Entries Tagged 'grokable' ↓

If you’ve always worked at an ad agency, you probably know the technical Thunderdome it can be. If you’ve never worked at one or are just jumping on board, I’m here to tell you the nitroglycerin-addled heart of it is equal parts ‘The Matrix‘, ‘12 Angry Men‘, and ‘Dude Where’s My Car‘. While in the trenches of development, you can lose focus on the the right technologies, trends and competencies to chase. What are you bringing to the fight? You need to be bad-assed rockstars with a focused set of skills. You know, like nunchuku skills, bow hunting skills, computer hacking skills; but honed for hot Agency work. Here is what I see the baseline tech skill set needs are of a fun agency development team for 2010, a sort of “Things in which an Agency dev team ought excel list”, only without that horrible name.

Check out my hot front-end

In the agency world, the charge of development is to take the design, branding, and influence generated from your Creative dept and translate it for the web. The traditional media versions of these concepts all have analogs in the web space, it’s up to your team to be able to run with the ball, carry the torch, or whatever other sporting metaphor fits your demographics.

The basics:

1) As a team, you need to be have serious depth with Flash, Jquery, CSS, sifr, @font-face, and coming fast, HTML5. These are not optional. If you are going to forward the vision of an agency which often thinks in terms of TV, stickiness, romancing the brand, creating identities, and other similar bullshit marketing phrases, you need this toolset down cold. You need to be able to push back to design and get comps for institutionally-overlooked pages such as forms, search results, sitemaps, 404 pages, and favicons. These have styling and implementation techniques all their own and their lack of being given creative love can quickly bring down the hotness of an otherwise sexy site.

2) You need a go-to CMS that you can theme, configure, break, and work-around. I don’t need to tell you (but I will), maintaining content on brochure sites is not the space you want to be in. Like it or not, a lot of agency type sites are perfect/imperfect candidates for CMS implementations and as soul-crushing as they can sometimes be, are ultimately your ticket to client happiness in the end. Like a roll call of high school girlfriends, some are great looking and slim-line, others are unwieldy propositions you’d rather no one else find out you are associated with. Bottom line though, you need a go-to system you can bend to your will, extend, modify, and end-around as need be.

Next Steps:
Get an understanding of video streaming server solutions, content delivery networks. Be ready for the hella-traffic you’ve always wanted when it finally comes knocking on your door.

Integrate the heck out of something

The Basics:
True story. I received a pottery barn catalog yesterday that had social media icons on the *back cover*. "Follow us on Twitter, Become a fan on FaceBook, etc."  Ridiculous? Perhaps, but clearly social media is no longer an up-sell or nice-to-have. You *need* to understand each social media’s ecosystem, create presences for your client if they don’t have them, and integrate their existing ones if they do. You should be able to pull in a feed, stream, or embed from anywhere as a matter of course. Whatever dev language(s) you are using, know all the modules, classes, gems, whatever that will make these tasks a non-issue. Oh, and importantly, Pottery Barn has some pretty cool looking lamps.

Next Steps:
Get crazy, get your developer API keys, accounts, environments and start making out with the APIs and fog up the windows. Custom Facebook Apps, Twitter integration, Youtube, and Amazon queries are really becoming standard offerings across the board. The grim reality for full agencies with fledgling dev departments is if you don’t have a path to skilling into these techs, you will be losing business to interactive pure-plays in 2010. Don’t mean to be a downer, but it’s true.

Hello, McFly, Mobile sites!

The Basics:
Mobile presence is a huge selling point and while the tech is very accessible, but also frequently poorly implemented. Heads up friends; mobile web development is not just sticking a 400px-wide stylesheet on your current site. (Gasp!) To make it work for you and your client, you need to grok:

• mobile conversions, probably creating a custom site map
• a raft of meta tags standard web devs have never seen before
• old-school attention to file sizes and speed on the wire
• targeting resolutions and capabilities depending on demographics and analytics

Next Steps:
Mobile Apps for major platforms (iphone, android, blackberry, windows 7 mobile) These can be tough nuts to crack, and some lines need to be drawn in the sand depending on the size of your shop. That said, this offering is of course the new hotness, and what your agency will eventually pitch clients, ready or not. There’s no doubt it’s a brave new world fraught with bureaucracy, api keys and certificates, registering devices, emulators and app stores (and you without your soma!), but this market is huge and only embiggening.

SEO

The Basics:
All of the on-page SEO 101 things that fall more into the category of not-shooting yourself in the foot.

Next Steps:

Get deep, work with your SEO / PPC / Media people and master the tagging, tracking pixels, click-tags, and custom variables in Google Analytics and understand how these bubble up into the reporting.

Converting!!

The Basics:
Ultimately agency sites always have a conversion vector to them, be they of the infomercialesque BUY NOW ilk or the kinder, gentler, delivery of information / sign up for the newsletter variety.  There is a dance of compromises that plays out between design aesthetics, calls to action, user experience, and information architecture that will culminate in the eventual comps, sitemap, and wireframes passed down to the developers. (If not, you are in trouble.)

At the next more technical level, your team working with SEO dept should be conversant in:
A/B or multivariate testing apps like Google Optimizer
Technically identifying visitors by personas, based on referrer, user-agents

Final thoughts

This post is meant to just be a quick checklist to help keep focus on the core skills of an agency web dev team. Agency work and technology can at times seem to be a battle of flavor-of-the-month memes, languages, and protocols as we package old media influence and persuasion inside ever-hipper trappings. Keeping up to date is mandatory for relevance, and in the Lord of the Flies marketplace of agencies, if you can’t figure out who’s Piggy, it’s probably you.

Here’s a quickie for you.  One of those typical gotchas you never see coming until you need to do something seemingly obvious, only to spend a bunch of time banging your head against the wall in frustration, festooning the atomosphere above your desk with rebarbative expletives, and shaking your fist impotently at the heavens.  AKA a typical Tuesday.

The quick bottom line ….

When a browser requests a url with a named anchor at the end, the named anchor is NOT part of the request!

Evidently browsers, in their little browser brains, universally realize that anchoring to a specific location on the page is a purely client-side behavior that they will take care of themselves.  When making these types of requests, the server only receives a request for the page with any attendant query string parameters:  the browser keeps the named anchor information to itself to use however it sees fit.  It makes no difference what type of web server / server-language you use, I’m here to tell you you aren’t going to get the named anchor in your hand.  The only way to act upon this programmatically is through a JavaScript shim.

BTW, according to the W3C a named anchor is a properly referred to as a "fragment identifier", but I’ll dispense with calling it that as I’ve never heard any real person ever refer to one as such.

Where this bit me in the ass:

In general practice you probably don’t need to care much about this behavior, I certainly didn’t and only marginally do now and I’m writing this friggin’ post.  Chances are all you want to do is anchor down somewhere in the page, and if this is the case, your request will be fulfilled as you’d imagine it would be.  Where you run into problems is when you think you are being clever (as I often find myself) and co-opting the anchor for some ulterior purpose.  In my case, I was working with our Flash guy on an almost entirely Flash driven site.  As with any Flash site, when you click the navigation, you can get to any numbers of new screens of information, but html-request-wise, all the client has really ever done is load the initial default page. 

This situation was has two drawbacks. 

1) Visitors can’t bookmark a specific ‘page’ on your site as the URL never changes. 

2) You can’t send any linked traffic to a specific page of the site.  You might want to promote the information found on ‘page 3’ of your Flash site, but don’t have a way to link there aside from funneling people who have already expressed a very specific interest in ‘page 3′ to your main page and forcing them to navigate their way in from there. 

The standard Flash workaround is as follows.  By adding #SomeFakePageName to the url through JavaScript called from Flash, you solve your display and bookmark-setting issues.  Going in the other direction, on page load, if a named anchor exists in the URL, simply push that variable to Flash and have it load up the corresponding ‘page’.  Excellent.  (BTW, I have since been made aware of  swfaddress, a JavaScript library made just for this purpose).

Needless to say (or I wouldn’t bother with this post), my first stab at this was to grab the #SomeFakePageName using server-side C# / ASP.NET and use that to feed my JavaScript whose job it was to tell the Flash which page to go to.  I’m no noob to this kind of thing and have dealt with pretty much every way you can get a handle on a path, rawurl, querstring, you name it from C#, but try as I might I came to realize there is NO WAY to access this one part of the url. .. I will not disclose how much time I spent trying to figure out how to get what was so clearly meant to be gotten, but my lack of wanting to disclose it should speak volumes.

Eventually research and examining HTTP headers lead to my ‘ahh, it’s client-side’ eureka moment. I retooled my C# into JavaScript and and was in business. While this all makes good horse sense, I had never really considered this before and the people I mention this to seem equally shocked to hear about it, and so .. a blog post is born.

Go ahead, check it out for yourself!

I encourage you to view this for yourself.  Using the Live HTTP Headers Firefox extension or a broswer-agnostic tool like Fiddler , go to a url with a named anchor like this W3C page on fragment identifiers  (http://www.w3.org/TR/html401/intro/intro.html#fragment-uri) and watch the request.  You will see that the GET sent to the server does NOT include the #fragment-uri you’ll see in your browsers location bar …

Final thoughts of thinly-veiled bitterness:

While all of this makes sense in that the named anchor part triggers client-side-only behavior, I think most people probably assume that it’s part of the request anyway.  I’d never really thought about my browser slicing and dicing the URL from the location and taking it upon itself to override my simple puny human’s direct instructions and to instead only send the actionable bits as part of the GET, as wonderfully efficient as that might be.  So good for you, you smarmy browsers, you’re soooo friggin’ smart.