We want to say congratulations to our longtime client Consero Global Solutions LLC, named as one of Inc. magazine’s 500 fastest growing companies in America.  Quite an accomplishment, really.

Based here in Austin, Consero delivers best practice F&A services for small and growing businesses through a combination of experienced on-site and/or off-site staff, software-as-a-service (SAAS) technology, and process optimization.  ENTERMEDIA redesigned their website in 2007 and have continued to support their web design and web development needs as they have grown rapidly.

Consero ranked #321 on the list, on the basis of 922 percent growth last year.  Wow!

Something we have started doing very deliberately, something that really works to help us accurately scope and manage a project, is writing user stories for understanding project requirements. It’s not a new idea by any means, and we’ve always thought this way, but we’re seeing now it as a “must-do” step in our process. When we’re trying to get our arms around a project, it’s a formula to get moving with.

What’s in a user story? It’s simple (at least the way we write them). It’s just one thing a user can do and why. That’s all. So it describes an action the user takes…and thus implies a function we need to enable, and a user experience we need to streamline. You put all your single user stories together and voila:  that’s the entire website project in action form. It’s also a great way to start documenting your work (more on this another day).

A user story has a beginning, middle, and end. First is the Who.  In the middle is the What.  Last is the Why.

It looks like this:

As a <type of user>, I can <do something> so that <some reason>.

or

As a <who>, I can <what>, so that <why>.

The Who is important because it differentiates between types of users, whether they are:

• “anonymous” (non-logged in users, more than likely existing/potential customers who only are allowed to view specified pages on your site).
• “authenticated” (logged in users with more permissions than anonymous types…in addition to being able to view content perhaps they can also upload attachments, write comments, or otherwise interact in some way).
• “administrator” (can do just about anything from creating/editing content to SEO customization to menu manipulation, and lots more).
• there are other flavors of user types and some hybrids, but these three are pretty much the arch-types.

Here are some examples around posting comments on a blog:

As an anonymous user, I can read all recent blog articles in ascending chronological order, so that I can learn about what X company has been up to most recently.

As an authenticated user, I can submit a comment to a blog article, so that I can provide feedback to X company.

As an admin, I can moderate and approve/disapprove of comments submitted to my blog, so that I can ensure that my blog comments are not inappropriate or offensive.

Three different angles for three different types of users, all concerning the same aspect of the site (blog comments), but now we have defined the workflow and we can start discussing it in more granular detail. For the authenticated user, we can extrapolate to think “hey, we will need a little message that says ‘thank you for submitting, awaiting moderation now’”.  For the admin, we need to start knowing how he will be notified that there are comments awaiting approval, or is he allowed to edit or just approve/deny.  It appears to build on itself…but really these project requirements were lurking underneath the surface since the beginning.  We’re simply seeing the whole iceberg better.

As you can surmise, one of the big benefits of writing these silly user stories is that they often foment discussion and further investigation. That’s a wonderful thing…the devil is in the details.  When we get to a point where we have written every last possible user story we can possibly know about…that’s when we can put an hours estimate on implementing each story to completion and feel confident that we’re not missing something. Our clients and ourselves can talk about the project in a very informed fashion. The formulaic writing process forces both parties to suss out the hidden complexities of a project, and evaluate these for priority, i.e.maybe there’s a more efficient way to approach the What, so you can still provide the Why that matters to the Who.

Beyonce is a superstar.   Everyone knows and wants Beyonce.   She’s the kind of entertainer that only needs one name…Elvis, Prince, Cher, Madonna, Liberace…the short list.

Beyonce can name her price these days. Got $2 million dollars for a one off show? You can probably book Beyonce for your next big party.

That’s why she’s Beyonce.  It’s what makes her a superstar.  She’s a scarce resource that is beautiful, dynamic, beloved, and hard-working.  She brings it.  When she was younger she toiled in obscurity and sacrificed as necessary to become the world-class performer she is today.  Now she reaps the profit of all that practice, and there’s really no stopping her.

She’s on automatic awesome, and she’s appropriately expensive.  All she has to do is show up for the gig, prepared and on time, and just be Beyonce.  It’s all her fans care about…that 5 minute or 2 hour segment where she does what she does best and earns a small fortune.

Ever wonder what her job is like between performances?  Probably not very exciting right?   More practicing, taking meetings, signing deals, getting rest, working out, vocal exercises, recording, writing, choreographing, collaborating with other artists, charity work, managing her business.  Yawn.  It’s Beyonce up on stage (or screen) that makes the people happy.

When you think of Beyonce performing live at the Grammys, you think of her singing and dancing and the crowd going wild.  You don’t think of all the work that goes into making that happen.  You’re just consuming it.  But somebody must be producing it…and at a high level.

What about the team behind Beyonce? You don’t stop to think of all the handlers Beyonce surely has that allow her to sustain her career and schedule.

There’s the agent, the business manager, the bodyguard, the choreographer, the stylist, the personal assistant, the assistant to the personal assistant, the driver, the shopper, the spiritual advisor, the personal trainer, the nutritionist…  These people are not stars and no promoter ever hires them to entertain a room of thousands.  They might even be ugly and poor dancers.  Whatever.  They come with Beyonce, help her be ready to rock, set her up for success…great.   Take them for granted because they are behind the scenes if you wish.  So what if they are good at their jobs and Beyonce likes working with them between, during, and after the gig…there’s only one Beyonce. She’s the star!

But she’s not the show.

Beyonce could not be Beyonce without a lot of help.  She wouldn’t be able to be nearly as effective nor as focused without the worker bees she employs to make her job easy.

And she needs to pay these people.  That big fee she charges for 2 hours of work?  Does that mean her rate is $500,000 an hour?  No.  She’s got to share that with those that enable her, the ones who have spent hundreds of hours doing trivial and non-trivial tasks that are just as necessary, really, as her singing the right words to her song up in the spotlight.  All the way down to the bodyguard making “only” five figures. He’s not sexy and he’s not expensive, but he’s playing an important role in the show, too.

In our business, Beyonce is the lead web developer. The lead web developer is what the people crave. He’s the star performer.  He’s the scarce resource that folks don’t mind paying for.  He can charge a high hourly rate and our clients don’t argue.

Unfortunately, some clients only budget for the development work and forget to save a little outlay for the other hours that they will need to get the development work ready to work with.

Just like Beyonce’s support team, the lead developer is dependent on the efforts of others to really succeed.  Without a well planned project with fully vetted user stories and functionality requirements, a prioritized task list, and a client who has been well-educated as to the nature of web development projects (to name only a few necessary support jobs) he is adrift and likely to fail.  His talent and time will be wasted, at least by some percentage.  And since his talents are hired out at such a high rate, a lot of money is wasted when his time is wasted, too.

Don’t waste your lead web developer…it’s like wasting your Beyonce!  You wouldn’t waste your Beyonce, would you?  Of course you wouldn’t.

Think about it.  Do you really want Beyonce answering phone calls from the worried venue manager when he thinks an email has not been responded to sufficiently?  No, you want someone else to smooth out that situation.

Do you need Beyonce to personally inspect the legal documents pertaining to insuring the show or fulfilling the show contract?  Of course, she should be briefed but she should not have to read every line of small print either.  She’s got better things to do more germane to her skill set.

And it’s the same way with the web developer.  He doesn’t need to manage client expectations or make sure the checks are in the mail. But somebody has to.

He doesn’t need to make sure the designer has time tomorrow to go over client feedback, and he doesn’t need to populate the content in the FAQs section.  He shouldn’t worry about uploading the right SEO modules.  Other, less scarce resources that can’t handle writing a custom hook that integrates with Sales Force and accomplishes X, Y, Z unique use cases can handle the more mundane stuff.  But just because it’s mundane doesn’t mean it’s not important…it’s only less scarce.  So you have to put the right person on the right job.

It’s essentially a matter of a team dividing and conquering the myriad of details that go into making a complex system look simple and work elegantly…each and every time it’s on display.  That takes teamwork and team commitment.

If Beyonce was your lead web developer, you’d be happy to pay her for her time and you’d be right to expect a knockout performance.  But you’d still be really dependent on her support team setting her up to succeed in her moment.  Otherwise, it’d be kind of a waste.

So all this is to say to clients: appreciate and enable the efforts of the team, not just the web developer.   Pay a little for the personal assistant, the agent, the stylist, the legal counsel…pay the star her higher rate so she can happily do her thing…and you’ll get your money’s worth when it counts.

DreamHost reviews

It ain’t easy being a web developer. Heavily depended upon, frequently maligned, seldom seen yet largely taken for granted, these folks turn ideas into code. They make a thought consumable, a desired action attainable…stuff that works.

They are mysterious and essential. Great ones are in high demand, especially Drupal chefs. But they’re not machines. They are actually quite human although they do talk kinda funny. They get mixed up and back on track. Tired and revived. Inspired and bored. Cranky and less cranky. Good luck guessing which side they’re on at any given moment, though. That’s fun for the project managers.

Here’s a thought:  a good web developer is neither a slave nor a prophet. Think somewhere in between Chuck Heston as Ben-Hur and Moses and you’re getting close.

When they are working all nighters trying to post an update for a sprint deadline…that’s sweaty rowing, grunting, shirtless kind of work. Down in the dank galley, below sea-level, making the ship move “that way”.

Why “that way”? Just keep rowing, Ben, and don’t go dying on me before I can send this link to the client.

“Galley-slaves lived in unsavoury conditions, so even though some sentences prescribed a restricted number of years, most rowers would eventually die, even if they survived the conditions, shipwreck and slaughter or torture at the hands of enemies or of pirates.”
from wikipedia

Yet, when you’re frantically looking for a custom web dev solution and there’s only one person in the conference room who could even posit a plausible scenario, that’s when you say to yourself “If only I could go up on that mountain and come down with a useful answer (or ten) like he can! What a commanding presence (no pun intended). Take me to the promised land!”

That’s when you start to think of that developer as if he could part the Red Sea…on the low end of your budget range. Well, that hasn’t happened in thousands of years. But there is always hope!

Now we can finally bring this blog post to something resembling a point.

If you think of your developer as the galley slave, you don’t trust him enough. You’re excluding him from the crucial conversations up on deck and you’re ignoring that he’s likely exhausted and apathetic. That’s going to be bad for your project and no one will be happy.

If you treat him like a prophet, maybe you trust him too much. You’re offloading responsibility that is more yours than his. Why?  He’s got enough else to worry about. Or, as brilliant as he is at what he does (code), you are more right about what you do (ideas). It’s impossible to predict which times, so don’t just check out and think the prophet-developer will know “the way”. Explain it well and discuss it thoroughly so you avoid miscommunications. Like what happened to Lot’s wife…

Remember:  the developer should always be thought of as part of your team…challenged, trusted, enabled, and given credit when credit’s due. Just like you, he needs support and guidance to do his best work.

Happy Friday.  Hug a developer this weekend!

Thou Shalt Not Make Me Browser Test for IE6.

blog ping

ENTERMEDIA has built a lot of websites since 2004 for clients of all types. Over the years we’ve gravitated to build practically every site with Drupal. Why is that?

Drupal is flexible.

From it’s inception Drupal was built with open source in mind. The founder of Drupal was smart enough to realize that predicting where the web will go in the future is a fool’s game, so let’s build it to be as flexible and modular as possible so it can adapt to each clients needs as well as any future developments. Remove as many constraints as possible at the outset. What this means is that you need to understand best practices for development to contribute modules that the rest of the community will endorse and adopt, but isn’t that how it should be? For instance, old site planning methodologies such as the waterfall project management approach, were concerned with concepts like knowing exactly where the main navigation menu was going to be before you would write a single line of code. With Drupal, if you decide that the main nav needs to move to the right side or left side instead of across the top you can make that change in a matter of minutes, so long as you haven’t styled the whole site prematurely.

Drupal is modular.

The devil is in the details when you are developing a website. Unfortunately, the majority of projects do not achieve the initial goal of building the entire scope on-time and on-budget. That’s because unless the developer has previously coded something exactly like what you need now, he’s having to estimate how he can get the job done on assumptions alone.  Building every simple thing from scratch is hard.

But with Drupal, ‘there’s a module for that.

Like the Apple store’s claim ‘there’s an app for that’, there’s most likely a feature rich Drupal module that does what you need and can be configured for your exact requirements. If not, there will be soon. There are over 3500 modules that can be used in Drupal to accomplish just about any requirement you can imagine.  Many times multiple modules are introduced that do the same thing, but over time the best solution emerges and the community gets behind it.  Once a module is adopted and accepted by the Drupal community it will be continuously tested and refined to fix any issues or add any ‘got-to-have’ features due to it’s vast number of implementations and specific feedback.  Developers help developers figure out these problems, and then the rest of us get to share in their solutions.

Drupal is scalable.

Drupal works with practically any type of database, so it doesn’t matter if you’re using an enterprise level Oracle databases or a free MySQL database. Without getting too technical, what you need to know is that Drupal can scale to meet your needs, but you’ll need an experienced Systems/Server Admin toproperly guide you to the right hosting a server setup. The greater point is that Drupal can scale as well as any other technology. The best proof is the number of large web properties who are successfully using Drupal, such as the economist. You can find more example drupal sites on the founder of Drupal’s blog.

Drupal is SEO friendly.

SEO is largely misunderstood from our experience. Drupal makes it easy for you to make your site follow best SEO practices.  It also allows you to write, publish, and correct problems with your site content that the search engines might not like with a little training and without needing a web developer to be involved.  Drupal does a lot of things automatically, such as provide strong internal link structure to make sure each link to pages within the site are tagged in the same way.  Drupal does not do SEO for you, however.  For more information on what you should be doing to practice good SEO, start here for a simple overview, but go here if you’re looking for professional help.

Drupal is free.

Drupal is open source and is therefore free of charge.  You will need to pay for hosting if you don’t have your own web server, and if you’re not a web developer you will probably need to hire a good team if you’re hoping for something professional.  However, you won’t have to pay Microsoft liscensing fees, the hosting for open source costs less, and the majority of the web is open source, so there are plenty of capable people in this world who can support a Drupal based website.

Drupal has momentum.

Like most movements, what’s critical to the success of Drupal is the huge adoption rate of the development community and the business community in general.  It is one of the greatest crowd-sourcing success stories around.  It is this community that will decide if Drupal deserves it’s success, if it should continue on, and for how long.  The Drupal 7 User Experience Project is a good reason to believe that Drupal will continue to be the best available option for years to come.  Already, some very big and important websites are built with Drupal, like:

• The British Government
  
• The Whitehouse
• Duke University
• Lucas Arts
• Reuters
• CNN

Drupal is simply an efficient tool.

Drupal is a content management system that allows non-technical site owners to manage their own content. It’s open source, which means it’s free as well. It still requires a high level of experience and expertise in web development practices and principles to build a professional website, which is not free unless you are one of those people. Drupal is simply the tool that allows you to do great things like build an online storefront, event listings, a social community, blog, photo slideshow, multimedia video player, forums, discussion groups, etc.

We’re proud to be co-sponsoring DrupalCamp Austin 2009!

This will surely be a cool event this upcoming Saturday and Sunday, dedicated to timely topics of development, design, and business by and for the local Drupal community.  (Note the ENTERMEDIA room where all the Design and Business track sessions will be held.)

Our own Nick Lewis will be presenting on the topic of Building Amazing Interfaces with Drupal & jQuery UI.  Oh yes.

We hope we’ll see you there. Register here!

The facts:

Who?

• Drupal Gurus and Newbies!
  
• Drupal users, developers, designers and decision makers. It’s where community ties are strengthened and Drupal’s future is decided.

What?

• DrupalCamp!
  
• Where some of the best developers and leading business owners cross paths, exchange ideas, find partners and conceive projects.

Where?

• Norris Conference Center!
  
• Three large meeting rooms for speaker sessions, keynotes, and BoFs. Located at Northcross Center (Anderson Ln. and Burnet Rd.).

Why?

• 20 sessions (10 each day)
• Two keynotes (one each day)
• Session tracks include: development, design, and business
• Dedicated Birds of a Feather (BoF) space
• Breakfast and lunch are included each day

AustinontheRocks.com is live!  This brand new website is all about serving up search results for local happy hour and food/drink specials based on user submitted criteria.

Say you want to find a bar in North Austin that has a nice patio, beer and wine specials this Thursday night, a big TV to watch the big game, is “date worthy’, and allows a dog.  Austin on the Rocks will deliver the skinny.  (It won’t buy you a pitcher, root for your team, find you a date, or walk your dog.)  This unique site actually caters to Austin bar-goers and Austin bar/restaurant-proprietors alike, because it matches up the perfect customer with the perfect local food and drink establishment.  Bars can control and update their own entries on the site, too.  Design cues are simple, clean, and easy to navigate, so the user experience is smooth.

From concept to creation, ENTERMEDIA made it happen for this start up custom application-based web business built in Cake, including:

• brand and online strategy consulting
• creating the cool logo
• designing all interface and admin layers
• sussing out important content strategy and user-experience decisions
• setting up a database design that will allow Austin on the Rocks to scale gracefully

Our fantastic client Cathi Rustmann and her daughter Taylore Cunningham are the one-two punch signing up the hippest bars all over Austin to be a part of this.  Cathi and Taylore have big plans in store for Austin on the Rocks and really perform a great FREE service to local folks who want to find the best food and drink specials in town. Be sure to follow AusontheRocks on Twitter and become their facebook fan:  you’ll hear about unadvertised food/drink specials and “get ‘em while they last” promotions you won’t want to miss.  Cheers!

One of our all time favorite clients is Ausley Algert Robertson & Flores, LLP, the best family law practice in Austin.  We redesigned and launched their website in Drupal this summer and really enjoyed the collaboration.  Then they they were kind enough to mention us in their first blog post:

” … The folks at Entermedia are professional, patient, creative, and helpful beyond anything we could have expected.  If you need website help, we highly recommend Entermedia…”

Wow!  Probably the best testimonial we could ask for, but we swear we didn’t ask.  We are very grateful.

We’ve known for some time now that the aggrieved local taxpayer and Austin web professional community’s outcry over reported plans to outsource the City of Austin website redesign to a Californian firm did not fall on deaf ears. Kudos to Austin officials for listening to concerned locals and resetting the project.

Austin Chronicle reporter Wells Dunbar delivers a thorough rundown of the project’s history, priorities, and current trajectory in this week’s issue.  It’s a good read, and the stuff about “crowdsourcing” is just plain cool.  Who knows?  Maybe there’s a scenario where we’d do work on the project, if stars align.

Whatever final form the website redesign takes, it will certainly be an improvement not only over the existing portal but also over what the city was mulling just a few months ago. The balance the city faces is in designing a site that can satisfy not only the tech-savvy crowds of OpenAustin, who have vastly invigorated public discussion of the site, but also the average visitor looking to contact her council member. (As Web tools like social networking, blogging, and the like become more ubiquitous, this gap is already shrinking.) Another component that shouldn’t be overlooked is the original impetus behind the redesign, the push for greater transparency and accountability; the city could get the slickest website in Cyberspace, resplendent with Web 2.0 doodads, but if it isn’t fed more information on permitting, development, and budgeting, it would still be an epic failure.

Read the full article here!

A great collection of interviews from the illuminating Jeffery Zeldman starting with the past, present, and future of web standards (and then on to the history of blogging, open source collaboration, and more).