Archive for July, 2008

A List Apart Survey 2008!

Tuesday, July 29th, 2008

Yippy skippy hoorah!

I took the 2008 Web Development Survey and so should you!

For whatever reason (I blame the relative youth of the tubes) there is little data out there on the people who are actually designing, coding, implementing, consulting, and basically sacrificing to make the Web a nice place. Thank goodness A List Apart, one of the finest online resources for people like me, decided back in 2007 to start a survey (the results of which can be seen here – 2007 survey results from a list apart) to document all this undocumented stuff.

I participated back in 2007 and I’m really glad I did. It really showed me how in and out of tune I was with the rest of my peers. I know I’m certainly WAY under-paid, I’m doing the job of roughly three people (thank the Web gods it’s not a design position on top of that), and it’s perfectly fine that I don’t have a degree in what I do because neither do about 46% of the industry!

I encourage all my peers out there to participate and help us figure out how to make this brilliant career work for all of us! If you’re a designer, a code monkey, a back-end sysadmin, or just a student making sites in your spare time, fill out the 45 question form (took me about 5 minutes) and we can see some cool results in the coming months! I love the fact that there are so many job titles from goofy pc-correct/ new-agey/ Web 2.0 “Information Implementation Engineers” to old school “Web-masters” to the bizarre “Lead Programmer” (that’s my title and it really makes no sense and insults those who actually do the hardcore coding tasks), there’s little standardization in the industry. I prefer “Web Developer” because I think it’s short and to the point.

A goal without a plan is just a wish

Tuesday, July 22nd, 2008

So at my day-job, we’re working to turn our static (but accessible) XHTML + CSS site into a clean, usable Flash-based site and run it in conjunction with our redesigned static one. As Sun Tzu once said, ” One who knows the enemy and knows himself will not be in danger in a hundred battles,” and so it is with development. We don’t look at the design, the copy, or the code until we tackle the information architecture for the site as a whole. The planning is key – knowing yourself (that is, how to structure your copy and path) is just as important as knowing your enemy (that is, your visitor, your end user, and how they will perceive the site).

When we jump into this kind of work we generally start from a flowchart. This chart outlines how the site gets structured and where the copy should go. We’re moving from a roughly sixty page (fifty of those are dynamic and populated by portfolio samples) to a 10 page site. This gets a little harrowing

On top of all this, we are restructuring to allow for a Flash-based version of the site which will showcase Flash and dynamic content skills. We want to move away from the tired old portal with “here’s the bitching new Flash site with the latest and greatest and here’s the tired old piece of shit XHTML site that we update when we feel like it – you pick” and move towards “here’s our Flash site, where stuff moves and is fun and here’s our XHTML site loaded with SEO, great code, and really beautiful look which completes the package – explore both!”

Information Architecture is one of the most important steps in development. I don’t care how beautiful, how complex your site is, if it’s hard for users to navigate and find what they need quickly and easily, they will leave and not come back. This is a time-honored, more-labor-intensive-than-you-think, activity which happens between clients, developers and creatives that requires in-depth thought and knowledge before a design ever gets considered.

Creating IA for a Web site is like a well-planned waltz – every step needs to be in the right place, in time with the music or it doesn’t work. It’s the Information Architects who really make the base of the site, that give it the structure around which the copy flows and the design is stretched. If you’re not working with solid IA, you’re not working.

Why the “party-line” is important in development

Tuesday, July 22nd, 2008

So there’s always been an issue between account services and developers/ designers/ creatives/ a.k.a. the people who do the work. Account service people have the best interests of the client in mind, but they also want to make the client very happy. This has (and always will) the potential for abuse.

If the client wants something, let’s call it “stupid thing X”, the account service wants to make the client happy, so says, “of course we can do that”. Now “stupid thing X”, or STX, is only stupid because it’s stupid – not the client. The client is smart, I mean, they came to you to do their Web didn’t they? The problem is that they asked for STX without knowing that it was either not in their budget, not the right tech to get them to their goal, or something that is completely superfluous to the action of the site. We’ve all run into STX and we’ve all told the client why we though about it and think that there’s another way to get them where they need to go.

Because Account Service has already promised the client that development was going to get them their new, shiny, “stupid thing X”, we as developers look the bad guy when the Account Service rep complains that we have to go tell the client “stupid thing X” won’t work for her/him. This can be solved through consistent, clear inter-office communique.

The party line, so says the entity known as Wikipedia: “The Marxist-Leninist concept of democratic centralism involves strict adherence to, and defense of, a communist party’s positions in public, while in inner-party debate sessions, the line can be questioned, criticized, and changed if necessary.” This is what we mean by party-line. We can talk it all over inside the agency, but the client sees one face, one unified front set on helping them achieve their goals because we are a well-oiled, sleek uber-machine of creative awesomeness.

Account Service must be trained well, they need to understand how time and organizational structure in done internally. They should always be open to ask questions of creatives, and be trained in the subtle art of weaning a client to a line of “Well, that’s interesting! Let me run it by the creatives and see if there might be a more economical, or direct method to help you achieve our goals. It might be that that’ll work just fine!” This is helpful because it makes the client feel like a rather smart chap, shows her that her money is being well spent and the entire team is thinking of her and her goals for the site, and that the Account Service is taking care of everything (‘our’ goals makes the client part of the team, you see).

Account Service, go talk to your creatives – see what they have to say. Read their blogs, find out what they think. They like to rant a lot, so you’re bound to pick something up. Get out there and keep the client happy, but toe the party line on what you agree to!