Eureka!

Think of layout as the blueprint of a manufacturing building, where the production lines of each department provide individual products of value. Taking all these products and combining them into a new product produces even greater value than the sum of all the parts (Gestalt theory). Now, if you optimize the layout of the production lines in such a way, that a minimum of effort is needed to derive the end-product from the assembly of the parts, then you have heightened efficiency, decreased time to delivery, and upped your return on investment.

This analogy holds just as true for web sites. Careful and proper placement of page sections (like navigation bar, footer, side-bar, header, etc.) will ensure that the user has a very low click-to-experience ratio, as well as providing high scores in readability, ease-of-use, and conveying the content.

Design Requirements

It is in the designer’s nature to control every aspect of the design. This is to ensure that the feel and flow of the layout is experienced as the designer intended. Often designers will want strict sizing and positioning of page sections and elements. You will see that this is often in direct conflict with the development and even best practice requirements for web sites.

Also, the designer will often want the page to look exactly the same, regardless of browser or operating system it is viewed on. Unfortunately, if this is the case, the designer will most likely not allow for graceful design degradation for non-compliant browsers.

Development Requirements

Ease of maintenance is a top priority for the developer. To this effect they will want to place the layout specification in a separate CSS file. This will ensure that any layout tweaks or complete reorganizations can be done simply by creating a new layout CSS file. Additionally, standards-compliant code is extremely important for maintenance purposes (non-standard-compliant code will not be valid in the future and may break functionality as new browsers emerge) and user experience.

Another important aspect is that the layout specifications should be such that they are applicable to all technologies trying to read it. This means that the layout should apply, or degrade gracefully, in all viewers (like browsers, Palm devices, PDAs, Blackberries, iPhones, etc.) in such a way that will not trigger any errors or impact functionality. If the layout does degrade due to the limitations of the viewer, then it should render page sections in an order that makes sense to the user, and not scramble the copy, or reorganizes it in such a way that makes reading the copy difficult.

Best Practice Solution

Define your target browsers

Before you even start coding, define a set of browsers you want to target. Your goal is to provide a complete experience within these browsers without degradation of layout, design, or functionality. Develop your layout CSS with these browsers in mind, constantly testing in each one to make sure the experience remains constant. Also, don’t be afraid to let the user know which browsers you have optimized for, and what versions thereof you support without degradation.

Be Accessible

Make your layout accessible to impairment-assisting technologies. For the most part this means arranging your layout in such a way that rendering without CSS applied still appears logical and can be understood by someone using a screen-reader or braille-screen.

Purpose-Driven Layout

Create page sections that make sense for the contain they hold. Do not create new page sections for the same type of content that is held elsewhere. In short, this means: do not create two footer sections, for example; consolidate and optimize. Your users will expect each section to have a specific purpose and multiple sections with the same purpose only aid in confusion.

However, if you place individual content items in their own boxes, or areas, that can appear to be separate page sections, style them similarly to each other, and different from other sections. That way your users will immediately identify them with their proper purpose.

Consider Alternative Technologies

Should your design team insist on fixed layout that doesn’t accommodate all technologies that might view it (blackberries, iPhones, zooming, etc.), urge them to consider different technologies that are geared more towards that type of medium. Flash or Silverlight applications for example.

Closing Thoughts

None at this time.

Bibliography

Cederholm, Dan. Bulletproof Web Design: Improving Flexibility And Protecting Against Worst-Case Scenarios With XHTML And CSS. Berkeley: New Riders, 2006.

Usborne, Nick. "Design Choices Can Cripple A Web Site". A List Apart. 8 November 2005. A List Apart Magazine and the authors. 20 February 2008 <http://www.alistapart.com/articles/designcancripple/>.

Koch, Peter-Paul. "Fluid Thinking". Digital Web Magazine. 2 October 2002. Digital Web Magazine and its authors. 20 February 2008 <http://www.digital-web.com/articles/fluid_thinking/>.

Unknown. "Variability In Web Page Displays". Web Developers Notes. Unknown. Web Developers Notes and its authors. 20 February 2008 <http://www.webdevelopersnotes.com/design/variability_in_web_page_displays.php3>.

Unknown. "A Theme For Your Site". Web Developers Notes. Unknown. Web Developers Notes and its authors. 20 February 2008 <http://www.webdevelopersnotes.com/tips/webdesign/a_theme_for_your_site.php3>.

Other References

None at this time.

Document History

[v0.0.1.20FEB2008] - Document created.

[v0.0.1.25FEB2008] - Initial draft and publication.

What’s a site without a page, right? Or, if you are a fan of Gestalt theory, you will know that the whole is greater than the sum of its parts. The same goes for web sites: your site will only be as good as the underlying pages. However, the impact that a single page has on a user is exaggerated by the experience of the site as a whole. Should a mistake on a single page cause the user experience to be affected then this experience is extrapolated to the entire site.

In the overall view of all things web, the page is second important only to the site as a whole. Because of this, pages need to be developed with consistency across the entire site. Common elements (like navigation tools, headers, footers, and side-bars) need to be in the same location and maintain the same appearance and functionality, providing the user with a tangible and familiar interface.

Problem

As web page visitors we all have encountered web pages that did not perform under various circumstances and technologies as intended. These are most often caused by web applications not being developed with W3C standards in mind, however, even if W3C standards are enforced, some browsers just won’t behave and break then as well. Here some tuning is necessary to support these browsers to make the site at least functional.

We often can also see problematic implementation of various features, like frames, pop-up windows, breakage of basic navigation functionality (back- and forward-buttons), loss of session information, and much more.

Other problems also arise when inappropriate delivery methods are used for various media, like embedded media that rely on specific technology or software on the client computer, interactive functionality, poor implementation of design elements, improper form validation, dead links, and JavaScript errors (resulting from JavaScript coded to specific browsers).

Design Requirements

For the designer the web page presents itself as a canvas. It is the area available to them with which they can present content in a manner they deem best for the given circumstances. However, that is much more an issue of Layout & Design, rather than the web page itself.

The designer does not have any inherent requirements of the web page as it is merely a medium. Their sole involvement is creating the overall design for the specific web page.

Development Requirements

On the contrary, the developer will have many requirements in intents with the web page itself, as it is the developer’s role to manage and build the architecture and code behind a web page. For the developer the web page is the user interface for a predetermined purpose.

Developers are responsible for implementing the proposed design in such a manner that it will be accessible, maintainable, extendible, and feasible.

Accessibility

DocType

The DOCTYPE will ensure that browsers interpret a web page in (nearly) the same manner. This provides consistency, and ultimately greater accessibility, to your web site. “But I have a DOCTYPE in all my pages, yet it doesn’t seem to make a difference!” you protest. The absence of a well-formed (that’s the key here: well-formed) DOCTYPE tag will throw browser compatibility out the window without even having parsed the first line of code. If the browser does not encounter the DOCTYPE tag before the HTML tag, it will revert to its bad old quirky self and render content on its proprietary DOM and CSS interpretations. This is especially prevalent with Internet Explorer and Netscape. There are three DOCTYPE declarations that work, at the moment (there may be more in the works, but these are the established ones):

HTML 4.01 Strict, Transitional, Frameset

   1: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>

   2: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>

   3: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Frameset//EN” “http://www.w3.org/TR/html4/frameset.dtd”>

XHTML 1.0 Strict, Transitional, Frameset

   1: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

   2: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

   3: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>

XHTML 1.1 DTD

   1: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>

Adhering to these DOCTYPEs will ensure that your page behaves properly, and most of all, as expected. “Using an incomplete or outdated DOCTYPE—or no DOCTYPE at all—throws these same browsers into “Quirks” mode, where the browser assumes you’ve written old-fashioned, invalid markup and code per the depressing industry norms of the late 1990s.” (Zeldman).

Maintainability

For a web site, or web application even, to be successful, it needs to be easily maintainable. The developer needs to be able to address the issues at hand without having to jump through hoops, and roll them out quickly and easily. At the base of maintainability is clean code. It doesn’t have to be quick, minimalistic power-code that will run a space station; the code can be as efficient or as inefficient as the abilities of the developer(s) permit. The main thing is that it is clean and consistent.

Feasibility

Technical

The most obvious issue here is the lack of technical knowledge by the employed staff. In these cases management will most likely realize the department is lacking in skill-sets and take appropriate measures, such as out-sourcing or hiring contractors to supplement the existing staff.

The second issue is the lack of technical equipment to make the project a success. For instance, if you don’t have web servers to host the web pages on, the feasibility depends on the restrictions of your hosting provider, or on the (non-) ability to hire an appropriate hosting provider.

Resource Availability

Probably the most determining factor as to how well-designed your web application will be are the availability of resources. This means specifically: time and money (anything else is a derivative of the two).

Given that a lack of resources will require constraints on development and implementation, they will most likely be sacrificed in the planning stages. This means that documentation will be greatly reduced, if not eliminated entirely, and development will be off the seat of the pants. This opens huge risks for the following:

• Scope creep, which can turn the project into a never-ending disaster.
• Bad coding, which can manifest itself as spaghetti-code, inefficient functionality, duplicate code, and improper implementation of functionality.
• Unorganized project files, caused by various developer creating and organizing their portions of the project to their own standards.
• Drop in communication levels, causing the various elements of the teams to splinter apart, and start “fighting” for their own needs, instead of working from a common agreement (the documentation).

Any of these items (and there are more, as well) may bring the project’s feasibility into question. However, because shortcuts are being taken, it is highly likely that a feasibility inquiry isn’t even considered.

Extensibility

When developing the web app, careful consideration must be given to extensibility. Despite what is given by the requesting entities as requirements, even if they say it is a one-time effort, it still needs to be managed, updated, and often upgraded with new functionality.

Keeping that in mind and developing for extensibility will also ensure that any updates and tweaks can be performed quickly and efficiently, even if a different team (who have little prior knowledge of the product) is performing these tasks.

Best Practice Solution

Code

Handicap Accessibility

Many viewers user screen readers that product audio (blind) or tactile (deaf and blind) output. These technologies should be supported under all circumstances, and take very little extra effort to implement. The main thing is being aware of the required tags, attributes, and usage conventions that they take advantage of and adhere to.

DocType

Of the various DOCTYPE examples shown earlier, the one that is most robust and should be used is the XHTML 1.1 DTD. This DOCTYPE will require that your code is completely XHTML compliant (yes, this also means that you can / should not use depreciated tags if you want your page to validate). This alone will force cleaner coding, as well as more attention to detail when planning the site.

Conventions

The developer(s) should adhere to a pre-establish set of rules and guidelines that govern the coding conventions. This includes variable naming, upper- or lower-casing, indentation, use of braces, brackets, and parenthesis, and so on. It really isn’t a question of adopting an industry standard (however, it is preferable, as it is more likely to be recognized by new developers coming into the team), the important part is that the entire team adheres to it. This alone will make code easier to read and understand, because consistent conventions are being used.

Layout & Design Implementation

Layout

The layout specifications of a page should be consistent throughout the entire web application. This demands that a common layout specification be made accessible throughout the application. This ensures two things: consistency and one central maintenance point. Layout and design are also to be separated from content and function, again optimizing maintainability. As of the time of this writing CSS is employed both for layout as well as design purposes. However, the layout specifications should be kept in its own CSS file, as this provides versatility by allowing the entire site’s layout to be reconfigured by simply swapping out one file. (Keeping it mingled with the design CSS would obviously complicate things, as you would then also have to redo the site’s design, or theme.

Design

Just like with the layout CSS file, the design CSS file is meant to provide a consistent look and feel to the web site. However, you may very well have different design CSS files for your application, allowing for varying themes (possibly by section of the site, or by user preference). Each unique theme should have its own design CSS file to allow for easy design management. This will also let you test multiple themes side-by-side when developing the site without have to redo the design CSS file every time you make a change.

Content

The page’s content is just that: meaning conveyed through text and imagery. Content is what is left when you strip away all the design, layout, and functionality.

One option to take under consideration is also the implementation of alternative delivery technologies, depending on the requirements for the site. For example, if there are strong design-requirements where the site must look a certain way for all users, regardless of browser and platform, some thought and consideration should be given to using Flash or Silverlight (just two of many emerging alternatives) to serve up the application.

This is because HTML was originally developed to deliver text-based documents over the Internet. This means that it was never designed as a delivery method for graphically intensive sites. This also means that there will be rendering issues with different browsers, as currently each browser adheres with varying success to W3C standards. Often the purpose of the site, as well as the target audience will help in determining the delivery method to be used.

Head

The <head> section of the code contains meta-data about the content and delivery of the page, as well as title and keywords used to identify it and promote it using SEO (Search Engine Optimization) methodologies.

The <head> should also contain any JavaScript includes that are used site-wide (page-specific includes should only be included on the pages in question as this conserves bandwidth). You also need to specify the various style sheets to be used. Typically all style sheets that are used throughout the application should be included (they do not take up much bandwidth).

Body

The <body> tag / section contains the elements that will be rendered to the browser. This means it contains the raw data (formatting occurs via the style sheets) for the content to be displayed on the given page.

Business Rules (Functionality)

Client-Side Processing

Any client-side code should be implemented to fulfill the following criteria:

• Editing form fields (while saving the new values will inevitably be server-side).
• Form validation (as well as server-side).
• Dynamic hiding and showing of page elements.
• Any other dynamic page changes where no database requests are necessary.

Any client-side processing should be implemented to support speed and efficiency, which has a great impact on user experience.

Server-Side Processing

Server-side processing mainly fulfills data interaction functionality, as well as new page requests. You’ll want to place the following functionality in server-side code:

• Form validation (in addition to client-side to prevent hacks).
• Saving form data.
• Processing external information.
• Reading from database and populating page elements.
• AJAX and JSON functionality.

Closing Thoughts

None at this time.

Bibliography

Zeldman, Jeffrey. “Fix Your Site With The Right DOCTYPE!”. A List Apart. 12 April 2002. A List Apart Magazine and the authors. 30 January 2008 <http://www.alistapart.com/articles/doctype/>.

Other References

None at this time.

Document History

[v0.0.1.15FEB2008] - Initial draft and publication.

Over the past several years I have been involved in all aspects of web publishing, both from the design end, as well as the development and database sides. Over time I have recognized methodologies and standards (best practices) that will provide a higher level of functionality, easier maintenance, and cleaner design.

However, there is often a tug-of-war that I have always experienced, where ever I have worked, between design and functionality. Often times the designers are married to their ideas and layout, not realizing that they are compromising functionality, versatility, and extendibility.

My goal with this series of articles on web best practices is to codify a set of best practices that will allow for both maximum functionality, as well as a maximum level of design control. Over the next few weeks I will be writing articles on the various elements of a web page and how best practices can be applied to them. These include (but not limited to) the following:

• The Web Page
• Layout
• Design
• Functionality
• Server- & Client-Side
• Content
• Navigation
• Menus & Trees
• Headers
• Text
• Links
• Tables
• Charts
• Pagination
• Tabs
• Web Forms
• Validation
• Radio Buttons
• Check Boxes
• Text Boxes (and Areas)
• List Boxes
• Select Lists
• Buttons (Text, Image, Submit, Reset)
• Labels
• Dates & Times

Once all these best practices (more will be added should the need arise) are spelled out, one should have a clear set of standards that both design and development teams can adhere to. It should provide an agreeable set of rules, a common link that ensures that both design is not limited by technical constraints, as well as functionality not diminished through design constraints.

Why perilous? Because of the “war” between design and development. If designers had their way, they would control every detail without regard to functionality. Every designer I have met has always wanted to revert back to styling principles used in print. My goal is to show why this is not feasible, nor desirable with web sites, and why a more principled and best practice approach will provide a more appealing design.

While there are countless of extremely well-written and applicable best practice documents available, these all apply in their own right. However, my goal is to develop a comprehensive set of guidelines that will be universally applicable for all aspects of web development: a codified set of principles that will ensure that my web application is the best it can be at all times.

Each Best Practice article will contain the following sections of discussion:

1. Overview
2. Design Requirements
3. Development Requirements
4. Resulting Best Practice
5. Benefits
6. Drawbacks
7. Thoughts
8. Bibliography
9. Other Resources

As each article is published it will also be added to a master document that will be available for download from this article. Additionally, I will update the listing of best practice discussions above to link to the respective articles as they are completed. As I post each article, I will gather and evaluate comments and feedback, as well as my personal thoughts, in the second-to-last section (7) of each article to provide a reference point with common concerns.

JavaScript,Extending,Objects

How often have you run into the situation where it would be great if you could chain getElement(s)By method calls? Unfortunately JavaScript does not support this out of the box since the getElement(s)By functions return various collection objects.

Thankfully there is a way you can extend JavaScript functions and objects using prototyping. The stub would look somewhat like this, and you would have to include this in whatever pages use the chained calls:

Object.prototype.getElementByID = function(s_id)
{
alert(s_name);

return null;
}

This is just one example. Using this process you can then run effective chaining that could look like this:

document.getElementsByTagName("rule").getElementsByAttribute("format", document.getElementsByAttribute("data_format");

As soon as I have the extended methods completed, I will make them available here for download. Feel free to contribute, if you have any particular ideas on this!

contribute,adobe,cs3,contribute publishing server

Well, here is the promised follow-up on my evaluation of Contribute and its buddy CPS.

I had some initial trouble getting it configured so that it would tie in to our ActiveDirectory server (that way we don’t need to manage users aside from in ActiveDirectory). The problem was that I couldn’t establish a connection between CPS and AD.

My assumption at this point was that CPS as actually seeing AD, but I was providing incorrect credentials. Well, the CPS documentation states that you need to enter your user DN as follows: uid=username, ou=group, dn=server, dn=com. This never worked for connection to AD using Windows Authentication Method, eventhough I customized it to use our schema (meaning instead of uid I used samAuthentication).

Making a call to Adobe Support also proved fruitless, as they will not support unregistered (speak trial) versions of their software. When I mentioned that I was evaluating the software for a company with the possibility of a future purpose, it didn’t even phase them; *Indian accent* “I’m sorry sir, we can only support registered versions of your software.”

Back to the drawing board. Luckily (after hours of searching) I stumbled accross a post that mentioned that the user was connecting using the folliwng user DN: user@server.com. This worked like a charm!

Now that I was up and running, I ran contribute and began administering the users (I could now search active directory) and was able to establish a writer > publisher > admin workflow process. Exactly what we are looking for.

Contribute really is the optimal solution if you want to give your content writers as little or as much leeway as they need, while not sacrificing versatility (which is often lacking in CRMs with admin modules). Our users can now create whatever content they wish withing the parameters we allow them, without fear of them breaking site funcitonality; all the appropriate checks and balances are in place.

The downside is, that is is divorced from your Microsoft development path that comes with using Visual Studio. In our case that is not a real big deal, as we will simply use Adobe line of software for our public company site, and continue using Microsoft line of software for our intranet. This is a clean division of applications that corresponds to the division of responsibility (meaning that the users creating content for the public site aren’t the users managing the intranet).

What CPS provides is a tie-in to AD (user management), change control (versioning up to 99 changes per page), and mist importantly process workflow.

Where do I start? Well… I guess I could post about the reason behind this post. I am currently evaluating Contribute CS3 as a potential tool for our non-technical staff to assist in maintaining our company we site.

So far I am amazed at the ease of use in Contribute CS3! I played around with it back when Contribute 2 was published (not CS2), and dismissed it as a nifty tool that didn’t have any real value to me at the time. However, it has significantly matured since, and am delighted to find that it recognized my custom install of this WordPress blog on my site with no manual configuratino necessary! (It also recognizes many other blog standards, like Blogger, etc.)

Further testing will determine how viable it is for a medium-sized business that wants to allow content publishing to its web site without necessarily involving the IT department all the time. This means establishing of roles, publishing rights, and chain of events in the publication process. Contribute Publishing Server should allow for all this (and more!).

I’ll break into that next.

[Update: 9/25/2007] At the moment I am still awaiting purchase of Adobe CS3 at my workplace to post more detailed testing results. This post was basically a use-case for connecting to my WordPress blog. Future write-ups will be more detailed.

I’m sure many of you are aware of the JavaScript scripts floating around the internet allowing for fading colors on web pages. The ones that I have seen tend to not use a class-based approach. Tonight I embarked on creating a color-fading class using only JavaScript. It was important for me to write this as a class for two reasons: I’m a great fan of object-oriented development, as it allows you to really ‘hook’ into the application (for testing, API documentation, and more).

What turned out to be the biggest problem was the timing between color changes. Traditionally JavaScript (JS) uses it’s infamous window.setTimeout() command to allow you to call functions after a certain amount of time has passed. The drawback with that command is that you cannot use objects with it, for the following reasons:

• If you pass in an object that depends on reference (i.e. you want to execute a class method for a certain instance of that class), it looses the reference, and most likely won’t find the method called.
• If you run multiple iterations and pass in variables to the method or object you are executing within setTimeout, and the code has completed running prior to executing the call in setTimeout, the each iteration will use the last available values of your iteration; it does not remember the individual values of the parameters of each iteration.

So, very bad situation. And searching the web only complicated things more for me. There had to be a simple way to get around this. This got me to thinking about how I could retain instance- and iteration-specific values, and still be able to use setTimeout. I had used function wrappers before in non-JS projects, so I thought it just might work here as well.

What I did was write a wrapper class for the setTimeout function. Each call to the setTimeout function would create a new instance of my wrapper class, thus retaining all the relevant information that I passed in at the time it was being passed in! And what do you know, it worked!

I have attached the code here, for your criticisms, as well as suggestions. Feel free to make use of it, should you like. Please do drop me a line if you do decide to use it. Also, if you make any updates or changes, please email me your changed code, as per the licensing agreement.

To use it, simply add a tag to any object that can have a background-color, like so:

<p fade="#ff0000|20|1500">Self-fading example (on page load).</p>
<p fade="||">Self-fading defaults example (on page load).</p>
<p onclick="FOBC.fade_element(this, 30, 3000, '#ffff66');">Event-driven fade (i.e. on click).</p>
<p onclick="FOBC.fade_element(this);">Event-driven fade with defaults (i.e. on click).</p>

Click me for demo.

Download: fade.js
Include the file in your page header, like so: <script type=”text/javascript” src=”fade.js”></script>

Syntax is: fade=”[hex color]|[frames per second]|[duration in miliseconds]”.
To use the pre-set defaults, simply use the following: fade=”||”, however, fade=”" will not work.
The defaults are: fade=”#ffff66|30|3000″.
Using the previous syntax will fade all items on page-load.

To fade items on demand, use the following JS:
Syntax is: FOBC.fade_element([DOM object], [frames per second], [duration in miliseconds], [starting hex color], [target hex color]);.
To use the pre-set defaults, simply use the following: FOBC.fade_element(document.getElementById(”test”), null, null, null, null);.
Defaults are same as above.

[Updated August 16, 2007: Included click demo, and added code examples.]

[Updated August 24, 2007: improved click demo.]

[Update August 24, 2007:] I have discovered a bug that will break the rendering of the fading effect, and will have a fix for this in shortly: when clicking and dragging (speak: highlighting) text that has a fade event, the fade will stutter and then cease to fade entirely. This also occurs when high-lighting text with a fade event through double-clicking.

Over the past few months I have been working on creating an optimum development environment for creating web applications in .NET. The current development environment is for creating web applications in PHP.

While the tools differ (.NET vs. PHP), the goal is still the same: creating web applications. Thus, you should be able to use the same development environment. Now, this will not hold water if you have a PHP environment that is highly specialized toward PHP development; the same goes for strongly .NET dependent environment set-ups.

My contention here is that your development environment should be set up according to the goal, and not the specific flavor of technology being implemented. This will allow for migration between different technologies without creating a huge upset in the way things are done. “What are you specifically getting at here?”, you ask me. Well, lets examine what a development environment entails.

Research
Ideas don’t just make themselves. A lot of thought, trial and error, and playing around goes into perfecting an idea and developing a use case and proof of concept. This includes database designs, code, integration of 3rd-party-tools, plug-ins, and so forth.

Documentation
Once your idea matures and you are able to show proof of concept and derive a use case from your research, it needs to be documented. Often documentation is a burden placed on developers or technical writers to satisfy process, and not necessity. I’m not talking about writing a doctorate on the work that needs to be implemented (code changes, functionality updates, new project design, application design, etc.). What I’m talking about here is the short and sweet documentation that is concise, demonstrative, and clear on how to implement the proposed items outlined in the document. You should be able to hand one portion of the documentation to any developer who should be able to create the desired end product without having to consult with the client. It needs to be that good! And at the same time you should be able to hand the other part of the documentation to the client, so as to give them a clear picture of exactly what the end product will do, what its specific parts are, how they interact, and how the client’s users will interact with them. Yes, it has to be that good. Only then will you achieve a useful product that your clients will be happy with.

Architecture
You will architect your products and applications based on the documentation, as well as your findings from your research. Architecting and documenting a web application design often go hand-in-hand and will require extensive revisioning of the documentation. Your application architecture needs to implement best practice designs wherever possible. If there aren’t any for your given situation, don’t hesitate to create best practices and publish them! Public scrutiny is your best advocate in creating high quality designs.

Development
The development stage of the product should not entail any unforeseen activities. Yes, you have developers, but they should not be trying to figure out problems as they are developing your applications. All problems, hurdles, and glitches should have been thought through in the documentation and architecture phases. At this point the development should follow the guidelines of the documentation, just as a cook follows a recipe.

Testing
While your situation may not allow for test-driven development, it is the best way to achieve your development goals with a minimum of bugs, and it also encourages use of best practices. Test-driven development means that you first develop a test class with various test methods that test each functionality of your application. Since you have thoroughly documented all functionality, you already know what you want to achieve; you write your test methods to test for the desired result by running the methods, classes, or functions of code in your application that correspond to that functionality. If the function fulfills those requirements without failing, you have achieved your goal, and your test is successful; if not, your test fails.
Like I said, not all environments will allow for this, and in the event you can’t or decide not to implement this, you always need to test your code during its development to ensure that you are meeting your goals. This testing should optimally include peers, so as to expose your code to their scrutiny. They will have feedback, certainly if there are errors, and more often than not even if your code runs fine. There is always room for improvement, and it is a great way to advance your programming skills.

Trial Phases
Once portions of the application are preview-ready they should be tried by the client. Never abandon your client during development. Keep them up-to-date at least on a semi-weekly basis, if not daily. Your client will never ever get the design specs exactly how they need to be in practice, so the trial of functionality will reveal any problems that actual implementation may hold. Keep your client in lock-step with your development, show them what’s going on, and even what is not working. Give them the opportunity to adjust the project. This is not necessarily scope creep, but more often corrective measures. We like to label this scope creep so that we can blame the client for missed deadlines. However, not all changes need too be implemented right away. Document any planned changes and add them as enhancements after the project is rolled out, or in another phase of development. Try to avoid adjusting your current documentation to much, as it will cause disruption in the development process, if many developers are working on many different parts, and have to rework a lot of their code. On the other hand, if extensive re-work is required it may be best to halt all development and iron out the details with the client, re-document, and then go from there.

Deployment
Once all trials have been performed satisfactory, the product needs to be deployed into the production environment. The deployment mechanism should have no impact on the development environment, and should not be part of, or depend on, your development environment. If at all possible, deployment should be automated, so as to avoid human error.

Maintenance
We all know that there will be updates and bug-fixes down the road, no matter how good we code an application. Maintaining bugs, and tracking errors should be done in a standardized way, regardless of technology. This means that your applications should inform you that the client is having problems. You should be aware, and maybe already have a patch available when the client comes to you with their issues.

Everything I outlined here is technology independent. It is a collection of procedures that can be adhered to regardless of the technologies being used. This means that you should be able to switch from PHP to .NET development in the same environment with no impact on your procedures, making the life of your management so much easier. Heck, it will make your life so much easier, too.

Now, this isn’t as easy as it sounds. We often have special tools to aid us with each of the above processes, like bug-tracking, project management, deployment, code versioning, and so on. Often these tools integrate with our development environments to make our lives (at the moment) easier.

This is the actual crux of my post: what tools can aid you with your processes, while remaining technology independent. I will post more on this as I work through it myself.

Yahoo! has started a project on web design around the idea that ease of use is a must. While Yahoo! isn’t the first to use these technologies, they bring the concepts together in a targetted manner, almost like a workshop, complete with code examples.
I believe the project is ongoing, but it already has some substantial technologies in its repository that deal with navigation issues, drag-and-drop functionalities, menu systems, and so much more.

While all these technologies are ‘neat’, ‘fun’, and ‘cool’ to develop, and even use, I would argue that improper implimentation will actually be detrimental to the user experience. These technologies are not the one solution that will fix everything, however, with the right planning, the proper foresight, and the correct implimentation, they will take web users into the next generation of non-flash web sites.

Of course these technologies tend to behave a bit different in the different browsers, so when designing the implimentation methods and functional requirements for your site, you need to be keenly aware the specific (dis)abilities that each browser presents, so that you won’t alienate potential customers or visitors.

[Click the title to visit Yahoo!’s site.] Over the next few weeks I will begin to impliment the various technologies and will detail my experiences here.

Cheers!
Mike

Many sites have alot of different select fields in their forms. In order to streamline my coding efforts I have consolidated and am using a function to satisfy all my drop-down needs:

    function MakeSelectList($strSQL, $strParameters, $blnShowBlank)    {        $arrData = GetArrayQuery($strSQL);?>                    <select <?= $strParameters ?>>                        <option value=""></option>                        <option value="<?= $arrData[$i][0] ?>"><?= $arrData[$i][1] ?></option>                    </select>The GetArrayQuerry() function is another streamlined function I use to return data as a data array from the database. This way I only deal with arrays and am removing my code from having to deal directly with the database:
    function GetArrayQuery($strSQL)    {        $i = 0;        $objRS = $db->query($strSQL);        CheckError($objRS);        while ($objRS->fetchInto($arrRow)) {$arrData[$i++] = $arrRow;}

        return $arrData;    }
Let me know if you have more elegant ways of doing this! I’m always open to new ideas.