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.

So I’ve come up with this great business idea that will revolutionize the world, abolish hunger, and set in an era of universal peace never seen before. Well, ok, not quite… but almost, I swear!

Now, of course you need the catchy domain name to go with it. Think again, my web-clicking friend! Over 90% of all domain names have been snatched up by so-called domain brokers who make a living off of others wanting to buy a particular name.

Sure, I promote free markets as much (or maybe more) than the next guy, but I actually caught myself thinking “they should have laws against this sort of stuff”. Wow! I actually caught myself thinking in ways that totally contradict my political beliefs (liberty, freedom, and free markets). This caused me to question my presumption: what right do I have to a domain name that someone else purchased legally? Of course I have none! Is it underhanded and nefarious, or enterprising?

Sure, they aim to take advantage of you wanting your domain name, but don’t all businesses do that now-a-days? I mean, really, isn’t advertising doing the same thing: creating a perceived desire so that you go out and buy it from them? OK, so there’s a slight difference in how the company operates: domain brokers take advantage of the shortcomings of existing markets without having to do any campaigning or marketing for their “product”, but other companies do that as well.

On the other hand, it is near impossible for one business to register all business names in a given state and act as a business name broker. Why is that? This is because registering a business name is in most places a legal requirement that mandates paperwork. And quite often lots of it (articles of incorporation, registration application, etc.). Who wants to start up 100 businesses with all the involved paperwork just to get a monopoly on the names in the off-chance that someone will buy it from you? I highly doubt that the effort pays off.

Should similar registration requirements be placed on domain names? I believe they should. Whoa… wait, wait… let me explain! I believe they should … in certain situations and to a certain degree. All top-level domains should be assigned according to their purpose designation (currently it is more hap-hazard than a chicken coop), as described here. Additionally, I would also enforce the following restrictions:

• .com: require that it be registered by a business and that it cannot be resold (instead it must be relinquished to the domain registration authority if the business closes).
• .net: may only be registered by network companies (IT, communications, internet providers, etc.), otherwise same as .com.
• .org: may only be registered by non-profit organizations, otherwise same as .com.
• .edu: may only be registered by educational institutions, otherwise same as .com.

All names used for business purposes should require additional registration requirements (not government controlled!), e.g. the above-mentioned. These requirements should effect a verification procedure that makes sure the information provided is accurate. Now, this would admittedly upset many domain registrants, such as individuals and those that do not fit the mold as described above, but it would accomplish the goals of the top-level domains in the first place: to effectively categorize the internet. In addition it would free up domain names and put an ill-gotten industry out of business without harming the liberties of individuals. Well, that, and of course I would be able to get the domain name I’m looking for.

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.

Stefan Esser made a great suggestion: we should have a “Month of PHP Bugs”, highlighting a bug in PHP every day for a month.

I think this is a great idea. If for no other reason than to give novice programmers some good learning material. So far there hasn’t been much “active awareness” pushed by PHP (Zend, et al.) to communicate things that beginning programmers need to be aware of.

The drawback with this is that the programmers need to learn by trial and error (usually at the employer’s expense) and in the mean time make their applications vulnerable.

I would love it if there was a site dedicated to PHP security. Not just vulnerabilities as in bugs, but also in proper ways of coding secure applications, best practices, and such. I’ve always found php.net to be the best resource when looking up functionality and syntax. A lot of the issues and vulnerabilities that programmers need to know about are indeed “hidden” in the user contributions at the bottom of the pages, however, they are cumbersome to read through, and often include a slew of ideas, tips, tricks, warnings, and best practices thrown together.

Of course, the other side of the coin (playing devil’s advocate here) is that developers need to be on top of their game at all times. Meaning they need to educate themselves regularly about their chosen programming languages. This includes reading up on best practices, coding securely, and learning new tricks.

**SQUASH**

Here are some links on the topic to get you started:

• PHP Security Blog
• PHP Security Consortium
• Essential PHP Security
• PHP Advisory
• Hardened-PHP Project
• SecurityFocus

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

In a cross-plattform development environment, something that only works in windows is terribly restrictive. Its even worse, if there are no Linux clients available. In this case the dilema is Visual Source Safe. While a good package overall, I have identified the following shortcomings:
- No good rollout process.
- Server application is Windows only.
- Client application is Windows only. I haven’t been able to find a Linux client for this.
- In order to access the VSS database on a remote computer, you need to have VSS installed locally.

What I am looking for:
- A cross-plattform solution that provides clients for at least Windows and Linux.
- The server application itself can run on a windows box, but a solution that caters to at least Linux and Windows is preferrable.
- A system that supports incremental rollouts and patches, concurrent versioning, multi-checkout capable, …

So far I’ve come accross the following:
- JEDI CVS
- CVSGUI: graphical frontends for various CVS-based systems.
- TortoiseCVS: a windows client for CVS.
- GNU CVS: opensource CVS system.

Research to be continued on the various available packages…