• A while ago I was kindly invited to Ljubljana to speak to the local web designers & developers about web typography – how could I resist? My talk last night formed episode 85 of Spletne Urice (Web Hour), a series of weekly talks held in CyberPipe, a café/bar/computer museum/free wifi hotspot in central Ljubljana. It was a thoroughly enjoyable evening, with a good crowd contributing to a excellent Q&A session, which apparently was quite unusual for Slovenes, who claim to be a very reserved nation of people. The slides are available online.

  Reserved Slovenes may be, but they are certainly hospitable too. So many thanks must go to Marko, Marko, Jure, Andraž and the guys at Zemanta for keeping me entertained and connected. Thanks also go to Parsek Interactive for getting me there and putting me up.

  Speaking of Zemanta, do check it out – it’s a clever way of enhancing the content of your blog posts. By way of Firefox extension, Zemanta analyses your blog post text and suggests photos, links and tags which you can add or remove by a simple click.

  The photos are gleaned from sources of CC-licensed images such as Wikimedia Commons and Flickr; the links from various news sources, Wikipedia and Zemanta-enabled blogs; and the tags by text analysis. Zemanta currently works with Wordpress, Blogger, Typepad, LiveJournal, and there’s an API in private testing as we speak.

  I should also add the Ljubljana is a lovely city, with the relaxed cafe culture we Brits seem to lust after. The weather was gorgeous for this – my second visit – and I think I’ve been luck enough to see the city in its two best guises: blanketed with snow and bathed in sunshine. The city also has a vibrant web community, with events on almost every night, all run by volunteers. I may well be back again.

Read or add comments

Thanks to a concerted education effort by key Web designers, as well as a few prominent accessibility and usability experts, the Web development industry has begun to form its own best practices. These are built on top of of Web standards, are informed by human-centered design, and honed through nearly a decade of trial and error. While the routines of those best practices vary depending on the site and team focus, but at their core they all share the same philosophy.

Some may call it usability, others visitor loyalty, others rich content, but the goal of the vast majority of Web sites is to become a routine for its visitors, and to do that, the users needs are primal; no matter what the papers say, you don’t own your site, your users do.

This is an overview of these notable best practices — future installments will delve deeper into specific topics an areas of interest.

Be helpful

 

People want your advice, show them what you can offer

Know both your users and the purpose of the site, and provide two or three clear paths that enable visitors to easily achieve their goals (which, in turn, should map to the purpose of the site itself). Imagine a concierge.

 

Inspire curiosity to encourage exploration and discovery

With rare exceptions (i.e., a task requiring the completion of a fixed goal) each path should provide branches for visitors to take, thereby exposing them to parts of the site they are interested in, but didn’t necessarily come for. Think “serendipity”

 

Without wayfinding, you’re telling visitors to get lost

On every single page of the site, the visitor should be able to see where they are, where that item is within the site, and where they can go to. This can be explicit, like breadcrumbs; implicit like friendly Web addresses and design hints; or both. This is the “Wikipedia Effect”

Be flexible

 

Technology shouldn’t be a limiting experience

There should be no such thing as an “unsupported browser” in the sense that any visitor should be able to access the content you offer, even if its not optimally presented. The site should embrace the three pillars of open Web standards, accessibility, and device-independence.

 

Welcome the outside in and let the inside out

The Internet is built on the exchange of information, and sites are rewarded the more they reach out beyond their domain. Encouraging visitor participation builds both loyalty; enabling others to easily access the site’s contents helps market its services; and pointing to other sites, even competitors, enhance the site’s own authority. This is the “Yahoo Effect”

 

Being nimble means being adaptable

In everything from business strategy to technology choices, being able to quickly bring to market a new feature allows the site to adjust to changing conditions, saving money while maintaining the current audience. If the feature doesn’t work after a reasonable period, quickly admit to it, remove it, and continue forward. Think “fail faster”

Beware

 

Even in anarchy, there are rules

After nearly a decade-and-a-half of Web-based development, combined with its profound integration with mainstream society, there are unspoken conventions that nearly every user understands. Ignoring them creates a sense of discomfort amongst visitors; relying on them creates a solid foundation to explore from. Think: “green means go”

 

The tea leaves reveal what you want them to

The online world offers a universe of metrics to quickly draw upon: visitor surveys, site analytics, revenue patterns, and market analysis. But their easy availability obscures their unreliable nature; use them a background source to inform, not to define, plans and goals. Think “Deepthroat”

 

Technology will fail you in proportion to the faith you put into it

As a means to an end, choosing the right technology for the purpose at hand requires careful forethought, but there is no perfect solution. Understand the limitations, but know that the what is developed is only as good as the process and people that developed it. This is the “Messenger Effect”

Over two years ago now I wrote a post entitled Potential Client Red Flags, wherein I listed 6 situations that, if they come up while talking with a potential new client, might possibly lead to me passing on the work.

I re-read that post this morning and have a few red flags to add.

7. Previous Web Developer Baggage
Once in a while I’ll be approached by someone with a project that has already been taken on by another developer and the project has failed.  In these situations the potential client always blames the previous developer for the failure, saying they had misrepresented themselves, or were over committed, or were just flat-out not able to do the work.  The potential client will then appeal to my ego with statements like “After reviewing your portfolio it’s obvious you would be a much better fit than the previous developer was.”

But - like stories of dating relationships and marriages gone awry -I’m only hearing one side of the story.  Might the issue really have been a client with unrealistic expectations, or who were unable to pay their bills on time?

I always feel like the only real way to seriously think about taking on a project with baggage would be to interview both sides of the failed project and see if I could determine what really happened.  But the time investment for doing that is such that it never makes sense because neither side is going to want to reimburse me for that time.

Additionally, if the site is sitting there half-baked and “just needs to be finished” then I’m faced with the prospect of it being started poorly and either having to rebuild it from the ground up or being responsible for issues with the site due to poor decisions being made at the foundational level by someone with less experience than I have.

8. Emergency 911
It’s amazing the number of contacts I get for projects where the timeline is “ASAP”.  Here’s an actual request: “We need a complete EE build with content and user migration from a Drupal install, the design is in Photoshop and needs to be converted to HTML, and looks like we either need some custom EE code or use of a 3rd party module.  Oh and the deadline is in 11 days”. 

Not 11 business days, just 11 days.

So after I’m done with the gut-reaction snide response that I won’t post here, the first question I have to ask is “How did the project get to be in this state?” And if the answer is “poor project management” then the follow-up question is “What other aspects of the project are suffering due to being managed poorly?” Is the design going to be right?  Has the proper functionality been identified?

I’m reluctant to take on projects that come with a red flashing light to wear on my head - I didn’t create the crisis situation so feel no urge to shoulder the responsibility of resolving it.  Although - I have toyed with the idea of proposing to take it on, but at 2 or 2.5 times my normal rate.  So far the stress potential hasn’t been worth the possible financial gain.

9. The Client Who Knew Too Much
Maybe the better title is “The Wanna-be Developer as Client”.  When I get communications from clients that include nonsensical statements like “we like the idea of separating content from presentation for SEO reasons”, or they want to talk about URL structure before the site design or IA is done the hair on the back of my neck goes up just a bit.  It’s not that I don’t appreciate technically-savvy clients, but when they have things just a bit “off” it makes me wonder how they got there, will they be open to and capable of being re-educated, or will it be a constant struggle to get them to understand how things actually work?

10. Hi, My Name Is Tom Sawyer
Once in a while I will be contacted to put a proposal together for an ExpressionEngine site, but the real reason for the proposal request is to determine if EE is actually well-suited for the project.  The challenge with these types of requests is that in order to do a quality needs assessment and (if EE is the right fit) a proposal it requires a lot of time - which is likely why the client hasn’t done it.

ExpressionEngine provides a pre-sales forum for answering questions like this - and I’ll often even pitch in on those threads.  But if the project needs an in-depth requirements analysis then that’s really outside of what I should have to provide at no charge in the form of a quote - that’s work that should be defined as it’s own project and I should get paid for as an internet consultant with specialized CMS knowledge and experience.

11. You Don’t Know Me
Boyink Interactive was a charter member of the ExpressionEngine Professional Network, and it’s been a valuable source of leads on new projects.

The downside is I’ll often be BCC’d in on emails along with multiple other members of the Pro Network.  I’ll have to be honest—if I’m elbows-deep in projects when these emails come in they do have less weight than email addressed to me specifically, or email that has come through Boyink.com instead.  I wonder if they’ve even reviewed my work at all, or are just blasting everyone on the Pro Network to see who responds.  I don’t immediately discount these emails, but if they have any other red flags (and they often do) then it’s not likely I’ll respond to them.

12. Can You Hear Me Now?
I’ve had a few interchanges with potential clients where they just couldn’t answer simple direct questions put to them via email.  And asked two or three times in different ways.  In one case after email exchanges hadn’t worked well I scheduled a phone call with the potential client instead.  When I called at the appointed time they answered with “Uh, hello?”.  This didn’t exactly instill confidence that they could communicate well enough to work with and that they were a marketing & communication firm was the deciding factor in passing on the work.

So there you have it - now the “dirty dozen” of client red flags. Will there be more?  Only time will tell…