jQuery does produce a buzz. Some people love it, some people… not so much Many more just don’t get it. We at lifeBLUE love it to death, and with good reason. We spend more time creating great interactive applications and less time trying to make those applications work across all browsers. It’s a win-win for our customers and our developers.

However, there are the detractors. While some of them dislike jQuery from a purely philosophical standpoint, most just don’t truly understand it. These misconceptions fall into three categories. Let’s take a look.

“jQuery isn’t JavaScript”
Yep, your right! It’s not JavaScript. That may just be because NOTHING is JavaScript JavaScript does not truly exist. JavaScript is a technology recommendation that nobody really follows. EVERY browser vendor changes how they implement JavaScript every major version change (be it ever so small). In fact, it’s EXACTLY like the “Code” in the “Pirates of the Caribbean” movies; it’s more of a suggestion and can change whenever the browser vendor decides it’s going to change.

So… jQuery is no more or no less JavaScript than anything else written by any other developer anywhere. In fact, one of its stated purposes is to bridge the gap between the various browser’s implementations of JavaScript. jQuery does not require any special technology a browser doesn’t already implement. It does not require any special configuration changes to a server. It’s as “plug and play” as JavaScript gets.

“jQuery is cheating”
Whenthe “rules” of JavaScript really don’t exist you can’t cheat, can you? In fact, to use jQuery, you have to follow standards. jQuery has been around long enough to have a mature feature set and API. It stands worlds above any JavaScript standard in terms of consistency and predictability. If anything, jQuery levels the playing field so that you don’t have to cheat. You can use the same code for every browser, no hacks required.

“jQuery has to much overhead”
Of all the arguments against jQuery, this one has the most validity. jQuery does use memory, bandwidth, and processor power. This point is conceded. However, so does any other piece of JavaScript ever written. The total download size of the jQuery library (in the minimized version) is about the size of a small logo (around 55k), so it does not take much bandwidth. As far as processor power, it does not take very much more or less than any other JavaScript doing the same operation. So while jQuery does take up some resources, it will only really be an issue on really old computers with really slow connections.

In short, jQuery is a great option for most everyday JavaScript tasks. You can produce clean, lightweight, effective code simply. What’s not to like?

For the first time here at the LB, I’ve decided to write a blog directly reflecting my role. Sure we all write about industry related topics, as a team, we all basically perform any and all duties we can to build a website. Whether it’s designing, coding, coming up with a domain name, or talking search engine strategies, we’re all in this together.

Allow me to introduce myself (better late then never, right)… I’m Shauna, our Front End Developer. For the non-nerdy type, that basically means I turn an image into a website, for the somewhat-nerdy, I take the completed design and build the “front end” of what soon becomes a functional website, and for the super-nerdy, I’m responsible for the HTML/CSS side of things.

As with most things, we all have our “style”, “habits” or “the way we think it should be done”. In coding, here at lifeBLUE, you can look at code and immediately know who did it. One of the things that I prefer to do, that can be done probably 20 different ways, is do all navigation in a “list” format. Again, super nerds let me speak your language, <li>’s. It doesn’t matter how simple or complicated a navigation is, whether its live text or images, horizontal or vertical, jpg’s or png’s, whatever the situation may be, I promise you, you can build it in a list. (subliminal message: feel free to prove me wrong, in which I will then show you how it can actually be done).

Why? Several reasons. The OCD in me says do it this way because aesthetically it’s cleaner code (oh, how pretty it looks), but the technical side screams for the search engine aspect as well. Search engines prioritize lists and recognize lists as being a navigational element. So we should take advantage of this and use it properly. It also allows us to associate text with what could essentially be image-based only nav, where you would then lose out on this important feature. It’s also easy for editing, all controlled by the CSS, allowing for simple additions, deletions, and complete makeovers.

So here we go, my time to prove I may know what I’m talking about…

CSS:

.nav {width:500px; height:50px; background:#e00260; font-family:Verdana, Arial, Helvetica, sans-serif;}
.nav ul {margin:0 0 0 18px; padding:0;}
.nav li {margin:0; padding:0; list-style:none; float:left; font-size:18px; line-height:50px; text-transform:uppercase; color:#CCC;}
.nav a {color:#FFF; font-weight:bold; text-decoration:none; padding:0 12px;}
.nav a:hover {background:#c80055; color:#FFF; font-weight:bold; text-decoration:none; padding:14px 12px;}

HTML:

<div class=”nav”>
<ul>
<li><a href=”#”>Home</a>|</li>
<li><a href=”#”>About</a>|</li>
<li><a href=”#”>Portfolio</a>|</li>
<li><a href=”#”>Contact</a></li>
</ul>
</div>

CSS:

.nav2 {width:500px; height:50px; background:#9101b0; font-family:Verdana, Arial, Helvetica, sans-serif;}
.nav2 ul {margin:0; padding:0;}
.nav2 li {margin:0; padding:0; list-style:none; float:left; font-size:15px; line-height:50px; text-transform:uppercase; letter-spacing:-.5px;}
.nav2 a {color:#FFF; font-weight:bold; text-decoration:none; width:125px; height:50px; background:url(nav2_bg.jpg); display:block; text-align:center;}
.nav2 a:hover {color:#FFF; font-weight:bold; text-decoration:none; background:url(nav2_bg_over.jpg);}

HTML:

<div class=”nav2″>
<ul>
<li><a href=”#”>Home</a></li>
<li><a href=”#”>About</a></li>
<li><a href=”#”>Portfolio</a></li>
<li><a href=”#”>Contact</a></li>
</ul>
</div>

CSS:

.nav3 {width:500px; height:50px;}
.nav3 ul {margin:0; padding:0;}
.nav3 li {margin:0; padding:0; list-style:none; float:left;}
.nav3 a {width:125px; height:50px; display:block;}
.nav3 span {display:none;}.nav3 li.home a {background:url(nav3_home.jpg);}
.nav3 li.home a:hover {background:url(nav3_home_over.jpg);}
.nav3 li.about a {background:url(nav3_about.jpg);}
.nav3 li.about a:hover {background:url(nav3_about_over.jpg);}
.nav3 li.portfolio a {background:url(nav3_portfolio.jpg);}
.nav3 li.portfolio a:hover {background:url(nav3_portfolio_over.jpg);}
.nav3 li.contact a {background:url(nav3_contact.jpg);}
.nav3 li.contact a:hover {background:url(nav3_contact_over.jpg);}

HTML:

<div class=”nav3″>
<ul>
<li class=”home”><a href=”#”><span>Home</span></a></li>
<li class=”about”><a href=”#”><span>About</span></a></li>
<li class=”portfolio”><a href=”#”><span>Portfolio</span></a></li>
<li class=”contact”><a href=”#”><span>Contact</span></a></li>
</ul>
</div>

Let’s face it. Form validation is about as much fun as playing tic-tac-toe against yourself. It is a dull task that has to be done but really isn’t that much fun. Mostly it’s just a thousand “if” statements. Of course, the bigger the form the bigger the pain.

jQuery to the rescue.

While there are lots of great jQuery plugins for form validation, you can do it simply without any of them. If form validation is complex, a plugin might be useful, but for things like “contact us” forms or forms with lots of text inputs but no complexity then this method works great.

First let’s do some HTML.

<form action="/the/target/file.php" method="post" id="form1" onsubmit="return checkForm();">
    <label for="field1" class="reqtext">Form Label 1</label>
    <input type="text" name="field1" class="req" />
    <label for="field2" class="reqtext">Form Label 2</label>
    <input type="text" name="field2" class="req" />
</form>

Notice the two CSS classes placed within the tags. These two classes, “reqtext” and “req” are the jQuery identifiers we will use to discover and then check each input field. Also notice that we put in an “onsubmit” element in the form tag. I like to use these instead of the jQuery.submit(). You can work either way. I’m just more comfortable with this format. Here’s the jQuery statements.

function checkForm() {
    // Initialize our error flag
    var error = false;
    // Cycle through the tags with the CSS class "req" in them.
    $('.req').each(function() {
        if($(this).val==()) {
            error = true;
        }
    });
    // If the error flag is set, set the titles for all required fields to a
    // nice shade of red to let them know which fields are required.
    if(error) {
        $('.reqtext').css("color","#922");
        return false; // don't submit the form
    } else {
        return true;
    }
}

Let’s work through the “checkForm()” function. First we set a flag to record if we have errors. Second we iterate through all the form fields with the CSS class “req”. If they don’t have any text in them, it sets the “error” flag. Lastly, after we finish checking things we provide the user with whatever visual feedback we think is required. In this case we set the text color for all the elements with the CSS class “reqtext” to red. You can take the last step as far as you want.

So there you go. A quick and simple validation that can be used for small forms and large forms alike. It allows you to validate what you want and leave the rest alone. Happy validating.

How to identify programmers and cope with their different coding styles.

Everybody has their only personal touch when it comes to pumping out code. Oftentimes the difference is negligible since similar work items are usually delegated to one programmer or department, minimizing the chance that you will ever have to sort through their source since it ‘appears to work’. Having to decipher another person’s code can be time consuming and runs the risk of erroneous implementation of code. Being able to recognize a particular programmer’s style is the first step to successfully utilizing their work for your benefit. Listed below are a number of different programming styles that you are likely to come across in your workplace along with their distinguishing traits.

The Clutter Bug:

More often than not this type of programmer can be identified by looking at their workspace alone. These ‘cluster-coders’ lack organization and are more concerned with results than upholding standards. Clutter Bugs are the product of loosely defined business requirements, poor fundamental programming education (or a personal indifference towards accepted programming methodology), and not enough team experience. The Clutter Bug gets a bad rap, because they often are the most intelligent programmers. Most Clutter Bugs know their code like the back of their hands and given a conflict can resolve it promptly. Other symptoms include inconsistent lunch schedules, late hours, and unkempt hair.

The Dungeon Master:

These programmers assume that others will adopt and follow their programming styles down to which data structures they use. The Dungeon Master is resilient to change and is always ready to defend their work with a lengthy list of reasons why their style is superior to yours. They are quickly irritable when dealing with other persons’ code, and will become quickly lost if too much or too little whitespace is present. Individually they might stand out from the crowd, but when working within a team environment they oftentimes become the nitpicker and inhibit work from getting completed by requiring that all deliverables meet their standards first and not the clients’. Some Dungeon Masters are the product of the Dinosaur mental block (can’t teach an old dog new tricks), but more often than not they are just prideful and have an insurmountable prejudice.

The Spatially Aware:

If there was a beauty pageant for code-writing the Spatially Aware would win every time, however they might fumble when asked how they would use their code to better the project. The primary flaw of the Spatially Aware is that they probably have spent more time organizing their code than writing it. Some of them are tightly bound by the instructions of their first programming teacher while others simply have some form of textual spacing Obsessive Compulsive Disorder. This type of programmer may make it extremely easy for you to find what you need from their code, but they will struggle immensely with your code if you have not mashed your “tab” button to death. They also tend to waste valuable time making code look presentable even though the client will never touch the source.

The Shape Shifter:

Always looking for a new and improved way to perform the same old trick, the Shape Shifter will solve the same problem three different ways in three different places. Their included files list usually has to be placed within a collapsible tag to keep it from taking up half the page. The hardest part about dealing with a Shape Shifter’s code is learning how their code works or learning the foreign resource they decided to pull in. Other programmers struggle with Shape Shifter code, because it requires them to learn alternative ways of implementing a solution that they are already capable of doing with tried and tested logic. Shape Shifters are usually technical bookworms, random bloggers, and tend to jump into a problem headfirst without analyzing the needs of the project first.

The T-1000:

In the brain/processor of the T-1000, coding standards are expendable. Opening up a T-1000’s code is like opening a Windows Media Video file with notepad. Class and variable names look more like serial codes than descriptive titles, lines of code run together, and commenting is, in the programmer’s opinion, unnecessary. These programmers are living machines and should be watched carefully when working on a team project, especially if you have employees with the last name of “Connor”. If you’re delegating an entire project to a T-1000 rest assured that it will function correctly, but do not expect great documentation. T-1000’s can understand anybody else’s code, but others will struggle to understand the simplest statement of a T-1000 program.

While it is impossible to unite all coders under one programming standard, it is very easy to alleviate several issues that may occur between clashing programmer mentalities by implementing and enforcing rudimentary practices. This can be as simple as defining naming standards, having a logic flow associated with work items (aka use cases), or enforcing good commenting. Below are a number of steps that can assist in tightening the nuts and bolts on your development team:

1. Create a predevelopment process where overall project analysis and design is performed. This includes designing database schema, use cases, naming conventions, and business rules.
2. If your team is large, or your projects expansive enough, you may consider developing a business-specific software development cycle where project workflow can be custom-tailored to your business’s needs and methodology.
3. Getting your developers to discuss their ideas openly in Developer Meetings can help establish what kind of standards are necessary for your workforce, and will also promote constructive technical discussion between programmers.
4. Commenting is a simple and easy way to describe what your code does. This is the only reason commenting exists…so use it!
5. Documentation is painful to compile, but it will save your developers time, your end users even more time, and your customer support department 50% on their phone bill.

In order to get the most out of your developers it is important to recognize the differences and utilize the strengths of your team members. Being able to identify what type of programmers you are working with will save you time, money, and minimize the need for oversight. Taking some of these proposed precautionary steps can drastically increase the efficiency of your development team and also increase the conviviality of your workplace.

Building Simple Javascript Classes

Three cheers for jQuery, Prototype, YUI, and other javascript libraries that have made the web developer’s life simpler. These libraries make doing what needs done straight forward and clean cut.

However, these little gems do not solve some of the basic “no-no’s” of javascript development.

1. They simplify the namespaces issue, but they don’t make it go away.
2. They often don’t do much to promote good programming patterns.
3. They usually promote a procedural approach to solving problems, rather than a object oriented approach.

On that last note, the object oriented aspect of javascript is almost completely ignored by many developers. Most developers who user these libraries assume that the libraries have removed the need to learn this aspect of the language. Why learn it if you don’t have to?

Simply put, learning javascript as an object oriented language means the same thing as it does for every other language. Your code is generally cleaner, more reusable, and solves the horrors of namespaces (or lack thereof).

Since I’m nice, here’s a quick primer on how to create a javascript “class”.

First, create a variable that equals a function like this.

jsclass = function() {
    // Code goes here!
}

Next let’s create a few properties. Properties are variables that live inside the class and belong to it.

jsclass = function() {
    this.variable1 = "This is our first variable.";
    this.variable2 = "This is our second.";
}

Now we are going to add a few methods. Methods are functions that live inside the class and belong to it. We are going to allow the script that calls this little method to pass it an argument.

jsclass = function() {

    this.variable1 = "This is our first variable.";
    this.variable2 = "This is our second.";

    this.method1 = function(anArgument) {
        alert(anArgument);
    }

}

Wahoo! We now have a fully functional javascript class! It may not do much, but it works. Let’s test it. Create an HTML file and put this script in its head.

Next, throw this little bit of code into the same script block to create an object from our class.

newObject = new jsclass();

Next, in the body of your HTML document, create a button and add an onclick event as follows.

<input type="button" value="A Button" onclick="newObject.method1('Hello world.');" />

Now load your page and press the button. Prepare yourself as you are underwhelmed by a nice little alert box containing the industry standard and massively overused “Hello world”.

Now let’s do just one more thing to round out the basics of using javascript classes. Let’s use member functions and variables inside our class. We are going to change up our class just a bit so make sure to note the changes.

jsclass = function(ourMessage) {

    this.userMessage = ourMessage;
    this.errorMessage = "No message sent.";

    this.method1 = function(anArgument) {
        alert(anArgument);
    }

    this.method2 = function() {
        if(this.userMessage=="") {
            this.method1(this.errorMessage);
        } else {
            this.method2(this.userMessage);
        }
    }

}

newObject1 = new jsclass("Hello world.");
newObject2 = new jsclass("");

Now add a second button to your HTML document.

<input type="button" value="Message" onclick="newObject1.method2();" />
<input type="button" value="Nothing" onclick="newObject2.method2();" />

Clicking the buttons will give you either the message you sent, or the error message contained within the class.

Before you say it, I know that this function is basically useless and could be easily done in other ways. However, when it comes to things like roll-overs, javascript classes can be a life saver. You can have multiple roll-overs on a page that use the same code for their functionality. You can then take that same class and use it on the next project you do easier than with a procedural approach.

So take the OO dive into javascript. You may find that some of the problems (like roll-overs, menus, etc.) that took a lot of convoluted javascript functions to get working become clean and easy when created as a class. Happy experimenting!

There are tons of people, just like me and you, who have had problems installing Magento on any server, let alone a Go Daddy one. Among the horrible errors I received, these were the most common:

• The server encountered an internal error or misconfiguration and was unable to complete your request.
• Base table or view already exists
• Column already exists, or Column already exists: magento_eav_attribute

After hours of trial and error, I’ve finally figured out how to get it done right.  Unfortunately a lot of the blogs and forums I read along the way had it figured out at some point too–but between Go Daddy changes and updates from Magento every fix requires tweaking along the way. I think the key is to find a version that works for someone, and stick with that. Lucky for us Magento keeps archived copies of all their installs.

Here are 11 straight-forward steps to installing Magento 1.3.2.1.

• Sign up with a GoDaddy Linux account. I’ve read that any account will work, or that you have to at least have a Deluxe account. For this example I used the Deluxe account.
• Create a new MySQL database using the Go Daddy Hosting Control Center. Be sure to make a note of your server name, username (which is also your database name), and password.
• Download the latest release of Magento (1.3.2.3 worked great for me)
• Download the sample data that goes with that release (also on that same page)
• Add the custom php5.ini file (below) to your web root, or just create a new one and add these three lines:
  • register_globals = on
    allow_url_fopen = on
    cgi.fix_pathinfo =1
• Copy both Magento zip files (the main application release and the sample data) you downloaded to your server root. It’s quicker to copy them there, then unarchive them using the Go Daddy File Manager. Unarchive both sets using the default path of “/”.
• It may take a few minutes, but once everything is unarchived, you’ll want to copy any folders under “media” in the sample data to the main “/magento/media” folder.
• Take the SQL file in the sample data, and paste it (or import it) into the database you created in step 2. It’ll take a while, and it will create over 200 tables.
• In the “/magento” folder we’ll need to make a change to the .htaccess file (or you can download the custom one below)
  • Change “# Options -MultiViews” to “Options -MultiViews” (remove the “#”)
• Now we need to change the permissions on a few of the folders in the main /magento directory. I used an FTP manager to do this, leave a comment if you need help. Change “/var”, “/app/etc”, and “/media” to 777, and make it recursive so that it does all child folders as well.
• Browse to your site, http://www.yoursite.com/magento, and fill in the form. I chose my timezone and currency, and did not append the table names with anything. On the three checkboxes at the bottom, the only one I checked was the “rewrite” box. Click the button, and the installation will begin. It takes a few minutes, and you will probably get an error at some point in the install. Just ignore it by going back to your magento site (ie http://www.yoursite.com/magento). If you get to the point where you can create a Magento store username and password, you’re at the finish line.

Even after the install finished, the first time I went to the front side of my store, I received an error. I just refreshed the page and it went away. This happened to me on every install attempt. I think people get stuck because they immediately try to reinstall. Don’t. Just fight through it and refresh, or go back to the /magento directory and refresh your browser. I hope this tutorial saves you hours of headaches!

In part one of this blog we discussed predevelopment documents and the value such diligence adds to the overall product. Developing this documentation will improve every aspect of the project, including customer satisfaction, code stability, time management, and overall quality of work. With a clear project direction, developing a technical roadmap becomes a much more possible and manageable task.

The traditional processes and frameworks of building websites differs little from any software development. In both cases, the project needs to be divided first into layers and then into units. These are units of work which need to be built. Units have dependencies upon each other and varying levels of difficulty or complexity. Both of these factors are considered when writing an action plan. The standard of software logical layers is the classic model, view and controller. MVC refers to the data store, interface code and application code. Typically a team would begin at the database layer.

Armed with the pre-development documents discussed above, it is important get the database schema on paper. Getting your design onto paper opens up communication between developers, expresses problematic areas and at the very least adds to a team’s growing collection of site documentation. This is a great example of measure twice, cut once. The database schema is literally the brain of the website.

Application code is at the minimum the adaptor sitting on top of the database retrieving from and updating it. Application layer is where business logic gets enforced. Server resource consideration and effectiveness are factors at this layer. Designing this layer is defining the technical architecture of the project. The level of documentation sophistication varies greatly here. There is a coding syntax, called UML, which can be employed to define this layer. In practice, UML is little more than diagramming. Typical diagrams are simply boxes and arrows with brief description of what’s happening on those little arrows. An example might be: user clicks order button, check is user, check stock level, verify no holds, add order to queue, update stock, etc. No detail is too small to document. Next, the development team overlay these diagrams with the literal class names or functions required to accomplish the actions laid out.

As this process is continued, the mosaic of the software finally begins to emerge. In a sense, this step is taking the user case flows made earlier and upgrading them to a new level of complexity and relevance. Just as the user case flow allows a team to discover issues with features or usability, this analysis will expose issues in programming that are better dealt with here than later in the thick of coding with the danger of dark side of the moon syndrome. That is to say, once a programmer has gone so far in programming only to discover a problem. They might be tempted to add more code to mask the problem rather than delete existing code. If the same developer has gone into programming mode with a clear strategy, such issues would have all ready been circumvented typically resulting in more concise and effective code.

Even once programming has begun documentation should continue, now in the form of logging. Proper logging is basically making notes. Each time a unit is completed the developer would log a note stating so and any complications encountered. These logs will become invaluable in the final development stages. Project managers can review the logs and check items off their feature list. Reviewing the amount of time each unit required will aid immensely when assessing future project risk. Often, documentation produced at this stage is kept internal to be reused in future projects. However, if the client is large and technical enough, the application design too might be a welcome addition to the overall site documentation.

Interface development has changed incredibly in the last ten years. A decade ago, interface consisted of simply laying out tables and graphics while applying styles and page properties. We simply plugged in variables produced from the application code and called it done. Contemporary web technology has taken interface to a whole new level as the market demands a rich user experience. We can use our previously created wire frames as a jumping off point for developing the interface strategy. As before we list all external libraries and justify their inclusion. Some type of scripting language will likely be employed on the front-end. Whether Javascript, VBScript, or Actionscript, it is critical to get down on paper what functionality each is going to provide. What functionality is required while assessing each unit’s difficulty level? This is a technical list that should refer to specific function or class names. A complete list would be such that once completed so is the interface

In any successfully managed project should be an abundance of documentation. Some of these documents will be highly sophisticated polished products unto themselves while others might not be much more than rough notes. Regardless, they are evidence of professional diligence. At each iteration along the way we stated on paper what we intended to do, discussed the strategy with the contributors, and then did exactly what we stated. The secret to creating a quality strategy and unlocking its value is communication.

Developing a website and building a house aren’t really so different.

Both cases start with nothing, yet through the methodical, strategic placement of different materials, and labor, a new even cooler product is created. If a general contractor brought a team of experienced builders, roofers and electricians on site with ample materials and instructed them to just start building, they would likely think him crazy, jump back into their pickups and drive off as fast as possible.

Yet many pre-development teams fall into the temptation of doing just that, often armed with only the equivalent of exterior concept sketches. In small projects this is acceptable or even advisable. There would be no need to draw a blueprint or to map out the electrical for a backyard playhouse. However, buildings such as a new symphony auditorium may undergo years of planning before the first shovel ever hits the dirt.

In the web development world, the shovel breaking ground is the first lines of code being put to a text editor. Experienced IT managers understand that writing code is paramount to nailing in rafters or installing insulation, and in some instances just as immovable as the concrete foundation. “Measure twice, cut once” is a fundamental wisdom amongst builders and a philosophy also adopted by successful web developers. Going back and changing features or functionality within software is eerily similar to tearing back the plaster because someone forgot to add a pipe to the kitchen sink. You are going to have to replace the plaster, you just made a big mess on the carpet – and it’s unlikely that pipe will be installed in the ideal manner.

That’s probably enough convincing and metaphors.

Presuming a job is big enough to warrant diligent planning, where does one start?

There are numerous techniques that break the ice.

• User case flows
• Features matrix
• Wire framing
• Composite mockups
• Style guide

While a developer or project manager might loosely follow this order, he or she is really working on all of them at once. It is common to fall back and update one document as a later one illuminates some new thought, idea or most often a requirement. In fact, every recommendation in this article can be done in parallel to some degree.

Let’s explore these documents more closely.

Creating an initial user case flow can serve as a great brainstorming session. Start with a single square, usually labeled “Homepage” and from there begin asking, “Where can the user go from here?” Continue asking that question until satisfied that every page, no matter how inconsequential, has at least been noted on your case flow. A finished user case flow can become a very sophisticated document that identifies not only what pages exist but profiles the types of users and the various paths user types will use. From this user analysis the functionality required to satisfy such usage starts becoming apparent. What becomes crystal clear is the number of distinct pages a project will consist of – a handy thing to know.

This exercise sets us up for creating a soft list of site features, written out in outline format and organized by page. The more minute detail the better, as writing text into a word processor is much less expensive for the team than writing code into a code editor. This is the document both the client and the team should become extremely familiar with. Rather than revising functionality once the site is developed, it’s preferable to argue, discuss and modify within this outline. Eventually the goal of project manager and account executive is to freeze this list.

Only two documents in and we have all ready learned a great deal about the project. For an enterprise scaled project, mocking the site up would still be premature. Instead, start simply with wire frames. It is quite literally a basic mockup of every page that contains functionality. Graphic assets, such as a logo, would likely be represented by just a box with the word “LOGO” in it. However, it’s dimensions should be to scale with the rest of the page and all graphical elements noted in the same manner. Input fields, links or any page element offering interaction should be expressed. It is important to compare the feature set list with the wire frames and verify that everything from the list has been addressed by these basic illustrations.

Once wire framing is complete we not only see a roadmap beginning to develop, but can derive a list of graphic assets needed based on the previous analysis. A team that has come this far has reached a valuable milestone, creating a technical blueprint of the website. This blueprint can be communicated with the client and discussed in depth, focusing on the feature set. Do you have any additional suggestions for formulating a development strategy? Perhaps other useful types of documentation or any cool team exercises?