I got in to town on Thursday, just before dinnertime. I drove with my friend Matt Forcum, and a new friend, Mark DuBois. Mark is a very knowledgeable web designer and instructor. He is heavily involved with the local community of web designers, and also the community at large. It was great to finally meet him in person.

The first day of the event was kicked off by Adobe’s Paul Trani, Steve Withington from Mura and Mark Drew from Railo. All are good speakers and had good content, but I have to admit I was expecting something less about tools and products and more about state of the industry or a broader topic. Not a slam on any of them per se at all, just a minor programming nit, IMHO. I spoke immediately following the keynote and presented my topic, “Is Mobile for Me, What Skills Do I Need?”, I’m sharing the presentation here, along with some more information on it. I think the reception overall was pretty good and got quite a few questions at the end, so that was great!

Next up was “Developers – The Most Critical Designers on Your Project” by David Ortinau. David’s presentation was well organized and loaded with useful anecdotes anchored around some very well researched quotes and stats. Great content overall and full of useful tips for developers as to why design truly matters and how to begin integrating design practices into your development workflow. I had a chance to talk quite a bit with David at the conference. I’m looking forward to seeing more of his work in the future.

We then broke for lunch, with the groups, Mobile, Designers and Developers hitting the road to do a Birds of a Feather talk off site. First event I’ve been to that did that, but I have to admit, I kind of liked it. It was cool to get out of the space for a bit and even though it was hot, stretch our legs. Good conversation, and food, too. Tough to beat.

I had a phone call to make, so, I missed a bit of JP Revel’s talk on JQuery, but when I walked in, it was clear he had hit a nerve…He was getting a lot of questions and there was a conversation going on about what he had presented. Engagement is a good thing in presenting, and it looked like he had it.

Paul Trani, Ben Stucki and Jesse Freeman were some highlights from the rest of the day… All in all a solid way to start off the conference! Since we were in Kansas City, I went to visit one of my favorite breweries, Boulevard Brewing Co. The tour was fantastic, and the tasting room was really nice! They had a test beer there that I hope they add to the Smokestack series, a nice caramel-y Belgian Dubbel called Nommo. After sharing dinner with some of the best and brightest in the Flash and Flex world at Jack Stack, I called it a day. We had a lot to cover the next day after all.

The second day, I started out in Jim Babbage‘s session on Prototyping using Fireworks. Fireworks is one of those tools that I know I should use, but I just can’t seem to get into it. Jim obviously knows it pretty well, so it was cool to see a bit more about what you can do with it. That said, I was looking for a bit more on actual prototyping tips, rather than a how to use Fireworks session. Overall though, good content!

After Jim’s session, it was off tot he 28th floor to see Chris Griffith talk on “Developing Compelling User Interfaces”. He provided a wealth of tips, tricks and user interface conventions you should consider in your next mobile app. Nice rounding out of the concept overall, and the crowd seemed to agree by an large as well.  Chris has been building quite a little app catalog for himself, creating a lot of conference apps for multiple platforms. Very cool work, by the way.

Then, it was back to the LL, developer track to see Aaron Pederson and James Polanco present “Jumping Alligators: The Pitfalls of Project Planning”. This was a great presentation, focusing on the nuts and bolts on how to put together the early planning stages of a medium to large scale development effort. Their deck was awesome by the way, with images taken straight from the Activision classic dash and grab, Pitfall. These two are amongst my favorite presenters to see, I just love their chemistry. Funny, smart guys who really know their stuff. Great topic, shown by people who know what they are talking about. I didn’t get a chance to talk to them about their presentation that much afterward, so I didn’t get to ask them about if they’ve had success in setting up a “discovery phase” project to iron out technical or prototyping issues and get paid for it, rather than cramming it into the estimating portion of selling the work. We got a chance to talk a bit of Drupal, though, so that was cool.

Lunch followed at the Raglan Road Irish pub, with some great conversation about enterprise level Flash and Flex development. It’s conversations like that that make conferences so worthwhile to me. Talking shop in an informal setting, just being open and having a real connection with the others you are with.

Post lunch, I re-caffeinated and headed back to see Seb Lee-Delisle present al-fresco, basically with no deck. He interacted with the crowd, taking a lot of questions and using his twitter stream as a conversation starter. Seb is known by most as a top-notch Flash designer, building games, visualizations and wicked cool particle effects. Seb was mostly talking about his recent forays into HTML5 and JS, so this is a new forum for him and a new creative coding outlet. His work in that space is impressive, and he’s been touring to teach others how to use particles and WebGL in their web design work. Things got a little hot in the room due to the passion about the HTML vs. Flash debate, but overall things stayed very civil and full of insight.

After the Seb show, it it was time to go see Dave Hogue offer his “It’s OK to Throw It Away: Prototypes as a Collaboration Tool” presentation up. Dave is a super sharp user experience designer and project lead, and his expertise is so clear in the way he speaks. He offered up real world examples on how to successfully prototype, not just some canned prefab examples. This was a nice change from a lot of the other presenters showing non-descript tutorial like samples. Good show Dave!

I have to admit it was getting to be a long day, so but I managed to troop on… Headed back up the elevator to go see Rob Rusher present on “Simple and Usable”. He provided some no-nonsense tips on how to remove the non-essentials from your mobile design. No major revelations here, just solid advice from a veteran. Good stuff overall and well worth the time.

That was the final concurrent session, with the finale of the conference taking place downstairs. Tom Green and Jim Babbage hammed it up with plenty of jokes and loud shirts, showing how to take a design from one end of the Creative Suite to the other. Good demo from some peeps that definitely know how to use the products.

The conference closed with some great giveaways and Leif Wells and Mike Labriola just cracking everyone up. All in all another fantastic community created event, all made possible be Dee. Thanks Dee for a great event, you really are a vital part of this community. Thanks for letting me be a part of it!

In producing a website design, there are replicable steps you should take in order to ensure success, this is a “Process”, if you will. This process should be sharable, transferrable to others on your team and easy to implement. Eventually, the steps should become like second nature to you and your team members. Hopefully, at some point, anyone on your team will be able to step in and take over at virtually any step in the process. It’s crucial for any company that produces creative and technical solutions to adhere to a process in order to build a business and elevate beyond the status of simply being a “job shop” or “making ends meet”. At the Iona Group, we use such a process called “The 4D Process”. You can learn more about it here.

I teach an abbreviated form of the process we use at The Iona Group to my students in my course at Bradley. This simplified process is easy to grasp after a couple quick projects and works great for students, as it allows for a lot of input over the course of the effort. This works for academic settings where the instructor or peers need to offer critique at key project milestones, but it also transfers well to the professional world where you may distributing the workload and looking for stakeholder approvals. In client work, I strongly believe it is best to engage the clients early and often in decisions that affect the project. Each successive step in the process should be a minor reveal, not a massive “AHA!”, IMHO.

Some example design phase deliverables in a web design project would be as follows (I’m skipping past the strategy and definition dleiverables in this post, maybe we’ll cover those some other time):

• Sketch
• Wireframe
• Moodboard
• Mockup

Those would be documents you could share with your client and get feedback, critique, suggestions, and other stakeholder input. There is one deliverable missing from that list that I have coined “The Redline“. The Redline is not a document shared with the client, but rather a document used internally to ensure the designer, developers, copywriters and SEO experts are all on the same page when it comes to hierarchy, standards implementation and the details of templating the website. This document also serves a valuable purpose to junior level team members in how to structure their efforts. It’s basically a webpage equivalent to an engineer’s CAD drawing of an engine or other mechanical part. In our class we create the Redline document after the mockup phase, but it’s easy to see that there could be a lot of value in creating a Redline as part of the wireframing process. This document works well in a web design class setting to help teach students about page structure, semantics and design hierarchy.

This document also reinforces an oft quoted Zeldman-ism:

Content precedes design. Design in the absence of content is not design, it’s decoration.

I have produced these documents in the past using a printout and a fine-point red Sharpie marker, but the example here was made using Omnigraffle Pro. So, let’s see an example of “The Redline” (click the image for a larger view):

Essentially every element on the page is bounded by a red box, and in each box, the HTML tag that will be used in the creation of the page’s structure is clearly listed. Yes, I realize this should be elementary for an advanced web designer; and yes, once you become adequately skilled you may not need this document. However, for a junior level developer, or for a distributed team that relies heavily on standards based SEO and proper marked up pages, this document has a high amount of value. What benefits does it bring to such a team? Consider these:

• Prevents HTML “Writer’s Block” – There is no question that junior web designers struggle at where to start once they open a text editor. How will the nav bar be structured? How about that sidebar? What constitutes an H2, an H3, etc?
• Puts Proper Emphasis On Page Structure – One of the very best ways to SEO optimize is to start out with good bones. By looking at how your content is placed in the page you can make sure that tag weight won’t interfere with proper indexing or page accessibility. Sure, it’s great to have a website with a pretty face, but without good bones, you’re never going to have a design that truly performs. The Redline forces you to think critically about how your page content and structure live together.
• Separates Design Strategy from Design Production – Let’s face it. Thinking is expensive. You may only have a couple of high end designers capable of producing scalable, SEO friendly standards based designs. You probably have a much larger base of coders capable of writing HTML with some guidance. This allows the team to divide and conquer, with individuals adding value where they can really shine.
• Eliminates Divitis Before It Begins – Unfocused HTML writing results in poorly formed markup. No question about it. Writing without a plan is a recipe for disaster. This document is that plan.
• Documents the Design for Historical Purposes/Recordkeeping – As a website ages, the pages get edited, content maintenance systems get patched, templates are tweaked, etc. a website can get rickety. The redline document allows a team member to perform a development/design soft reset down the road. If you want to rollback the site later to the SEO optimized version that everyone agreed on, unless you have pristine document history or version control systems in place you may have difficulty reinstating the original template. The redline will at least allow you to recreate it with minimal fuss.
• Reduces Coding Time – No question about it, it’s easier to “restructure your page” semantically via diagrams than it is to rewrite HTML time and time again. Just like wireframes help short-circuit the “Photoshop Mockup Death Spiral”, this document helps accelerate the development phase.
• Establishes and Document Naming Convention for Classes and Elements Ahead of Time – When adding the ids and classes to the document, you are in essence documenting the framework for the CSS and the JavaScript to be integrated with the designs. This really will make sure a distributed team is all on the same page (pun intended).
• Empowers the Design Team To Help Developers Adhere to Standards – I’m not naming names, but I have come into a number of situations where backend developers have been entrusted to write the markup for the web designs they have been provided. These developers mean well, and can write great SQL and business logic, but page templating isn’t there thing. As anyone knows, a poorly structured DOM is going to produce invalid HTML pages. Invalid HTML documents are NOT going to be cross browser compatible.

So, there you go. I hope this info helps you either learn web design for the first time, or maybe even enhance the process you are using at work to help maximize productivity and increase your overall web design quality. Are you using a similar document in your process? I’d like to hear about how you are implementing planning documents like this to jumpstart your designs.