As we're getting pretty close to launching the WAL beta, I can't really provide you with the same coverage that Carson's blog has, but I'll start covering the process from today on.

In last few days we had a little shake-up in the company, because we realized the potential of a completely different product that could be of tremendous value to website developers. I don't want to reveal to much about either product, but I'll say this: WAL is meant to streamline the website development process, whereas our next product will most likely help website designers to better manage their fast-growing customer base.

It's great to embrace new ideas, but we decided that it would be foolish to delay the launch of WebAssemblyLine™ in order to initiate the work on the new product.

More on how we develop WAL coming soon, as we count down the number of days to the beta launch.

Actually, the Internet would never work without the standardization of protocols like the TCP and IP. Furthermore, the W3C spearheads the Web Standards effort with the HTML, XHTML and CSS specification to make the user experience standardized across the multitude of Web browsers... which in turn (you guessed it) are getting standardized.

So, what about the development of Websites? How is the concept of building a Website different from the concept of building a house or assembling a car?

We believe that all good Websites have certain features in common and these features can be nicely standardized. The page layout for majority of sites can be nicely broken down into the following blocks:

• Header
• Main Navigation
• Sub Navigation
• Breadcrumbs (raise your hand if you don't know what this means...)
• Side content area (or Sidebar)
• Title
• Content area
• Footer

You can build just about any page using these standardized components. You can make them look anyway you want, position them in different places on the page but you will most likely use them.

Anyhow, this is just a small example of what standardization of Website development (and actually the Website development process) can bring. I will perpetually post additional examples and more "rationale" for standardization in this industry.

One of the things we are trying to accomplish with WebAssemblyLine™ is the actual standardization of Website development that will allow for unprecedented cooperation within development teams (and even among multiple development teams), freelancers, marketing and advertising companies (which now hurt because they generally do not have the right skills and experience to develop good, extensible, and affordable Websites). Furthermore, WAL™ will help to streamline tremendously the actual process of conceptualizing, designing and building of Websites. Then it will allow to extend and add new sections, dynamic features and even E-commerce seamlessly to the already existing site.

Sounds too good to be true? Stay tuned... or go ahead and sign up to be notified when we are ready to show you more.

Why do they not work?

Most of them do not work properly with different browsers, some of them work ONLY with certain browsers and if you want to make them work with multiple browsers, generally you need to trim down the functionality so much that it does not make sense to have a WYSISYG anymore.

Another bone to pick with the WYSIWYGs is that majority generates garbage code and has poor support for CSS. Honestly, I feel of Web based WYSIWYGs as a gimmick so that the company offering them (or company that incorporates them into their CMS or Website builder) can claim that "If you can use MS Word, you can use our application."

From my experience, none of the WYSIWYGs functionality is even close to MS Word. In general, it has been a struggle for years to come up with a "graphical" way to effectively develop and/or maintain Web based content. I feel that we are not getting any closer. The WYSIWYGs simply lack the control you may need to work with the Web document and are simply not a help at all to someone who does not understand that Web is not Print and that the Web page will not (and actually SHOULD NOT) look like a printed piece of content.

Furthermore, when you use a WYSIWYG within a Web based application, you almost never get what you see. The content you are editing is only a part of the Web page and some of the CSS styles do not work properly. What you're left with is a cumbersome text area that shows you some text bold, some italicized and some underlined (for links).

Why are they evil?

Ok. Here is why they are evil...

For unexperienced user, WYSIWYG becomes a tool to "decorate" the content. As a result, the content is a bunch of fonts, colors, sizes, etc. The problem is that the user does not concentrate on the content itself and whether the formatting makes semantical sense and provides a consistent experience for the intended audience.

For experienced user, WYSIWYG becomes an obstacle. Experienced users do not need to highlight something and click the "B" icon to make it bold. The experienced users gladly trade the WYSIWYG for something much cleaner and more efficient (like the Textile markup we use for WebAssemblyLine™).

As you can see, the WYSIWYG is evil because it actually keeps the users from achieving their objective, which is a contextually formatted written content. The "decorating" should be left for the designers and developers that prepare the CSS styles that are much better supported through a markup approach.

Perhaps the most important point I would like to make is that the use of WYSIWYGs actually promotes "inexperience" while using a contextual markup formatting very quickly transforms an inexperienced user to an experienced content contributor by forcing the user to spend the 15-20 minutes to learn the basics of providing the content.

Regardless of the name, this approach is absolutely essential for a streamlined Website development process. In many cases such environment is setup as a sub-directory ( e.g. /new-site ) within the live Website. This is not a very good idea and it is extremely limiting for many reasons like problems with paths to site assets and CSS files for example.

Perhaps the best way to setup a development environment is to create a parallel website with a unique URL and treat it as a completely separate site. Then, it is possible for the entire development team to access the site via browser, connect to it and manage the files. Even better idea is to have the development environment setup on a completely different server alltogether. This protects the actual real LIVE server from going down when the development team is experimenting with functionality on the development site.

At newline Creations we felt that this is one of the most important parts of streamlined website development process so we seamlessly integrated the entire concept into the WebAssemblyLine™ Managed Website Infrastructure.

It turned out that nobody besides me and Oto knew how to use the app or knew about it's functionality and data that it contains. So I figured instead of trying to post a manual in our JotSpot Wiki I'll try to incorporate instructions and explanations directly into the user interface (screenshot below).

There is a few benefits for having instructions directly in the interface:

1. You won't forget to update them when functionality changes, because they're constantly in front of you
2. You eliminate the natural resistance to looking into a manual (who likes to read manuals?)

I am looking forward to hearing more "AHA's" in the office and less basic functionality-related questions.

Here is a little elaboration on this concept.

Objectively good Website is one that excels in categories that can be objectively measured and objectively compared to any other Website on the Internet within particular categories. Here are some Website characteristics that can be objectively assessed:

• Compliance with Web standards
• Web accessibility
• Quality of printed version
• Page load time
• Ease of navigation
• Search Engine friendly page composition and code

Subjectively good Website is one that happens to have a design that appeals to you. Perhaps you like the colors used, the pictures or some other design elements. For example, you may think a Website is good because it has a very unique and ingenious navigation system but 80% of the visitors are confused and leave the site without finding the information they are looking for.

We built the WebAssemblyLine™ to provide all the characteristics of objectively good Website. When you use the WebAssemblyLine™ you can concentrate on the subjectively good Website aspects. The system will do the rest of the work for you.

One way of thinking about the WAL service is that it's a website framework with an open API. It's a website framework, because it gives you tools (CMS) and conventions (code snippets) on how to build your website. It has an open API (application programming interface), because it allows you to plug-in virtually any type of functionality into your website via widgets. And I think a plug-in type of architecture can be treated as type of API.

Another way of looking at WAL is as unified process. In essence WAL gives you:

• a process for managing and building a website - the WebAssemblyLine™
• tools to accomplish it (the content management system)
• a notation and language to describe and prototype a website (grey-screen prototyping and some phrases)

Sounds awfully similar to the Rational Unified Process in software development.

The anxiety related to the ownership of websites is mainly caused by the fear of being locked in to a given provider's service. That can be easily solved by providing a mechanism for exporting the website content and the XHTML/CSS template. For instance, if you run an e-commerce site with Provider A and decide to move to Provider B, then A should give you the tools necessary to quickly export all your website content from the CMS and all product catalog/orders data from your e-commerce system. Knowing that you can leave at any time makes you more comfortable in staying.

The problem is that a move between providers is not going to be easy, because there are no standards for storing and exchanging website data of various kinds. What I mean by that is that your new provider will have to spend time and your money on importing the content and e-commerce data that you've provided to him (it will not be as easy as a click of a button).

Why is it not possible for the client to own the final working product?

The answer is both legal and financial. Firstly, many of the tools used to host a website are open source and are licensed in a way that does not allow for commercial sale (i.e. GPL).

Secondly, if each tool required to host a website (e-commerce platform, blog system etc.) was proprietary and developed specifically for the client, than the cost of developing and hosting the website would exceed most client's budget. It is necessary to use existing software components in developing and hosting websites, in order to minimize the cost to the end customer. However, those components in many cases cannot be re-sold to the customer, because of licensing issues.

newline is planning to add content and theme export capabilities to the WebAssemblyLine service.

What do you think about all this?

Going around the Internet and reading blogs, forums, articles, etc. one cannot help but to notice that most of the material is about the same stuff over and over. Website design should be separated from presentation. Websites should be designed with accessibility in mind. The content matters and not the design. It is important to have a logical and standardized navigation. The Website structure or architecture matters very much and has a direct impact on the quality of the Website.

Yet, I have not seem anyone to formalize any of this. How does it all fit together? What is the succession of steps? I feel that the true quality of a Website development company is within their development process. Most of the Website development shops do not really have a clear idea on how to approach the actual development. Most of them start with creating a stunning design. Then collecting some content. Then creating a bunch of "new media" components for the site to clutter the pages and "razzle and dazzle" the visitors with motion and graphical appeal. I feel that this is not the right way to go.

Anyhow, this is just the beginning of my ranting. Come back for some more shortly.

• project is completed on schedule
• any changes in the schedule are mutually agreed on with the client
• project is completed within budget
• if the scope of the project changes during the cycle, change orders are initiated and separately billed for

There is several things that can go wrong on both the clients and developers side that will hinder the above and cause the project to be less successful. Let's review them...

There is many breeds of clients. Some like to micromanage the development project, while others simply want to stay out of it and let you handle everything. None of the extremes is very helpful. There is several methods you can use to mobilize your client to communicate with the project manager on a regular basis. Firstly, you should start using a web-based client extranet/project management application, such as BaseCamp. In this way the client will have a convenient channel for communicating with the PM or the rest of the project team and reviewing project progress. For clients that are not computer-saavy, the best solution is regular meetings. For those meetings you need to come prepared with a set of specific questions that you need answered or problems that need to be resolved.

The project manager carries the most responsibility within the team. He is responsible for setting up a realistic schedule, which should be closely followed to assure that a project can be completed on time. A schedule is essentially a collection of major milestones with their deadlines. Milestones are usually associated with deliverables. The completion of certain milestones, like content delivery is the responsibility of the client. Therefore the client needs be hold accountable for any milestones that are not completed by them on time.

Why is the delay of the project schedule a major problem? If your a web development company, you most likely work on several projects at a time. Therefore the time of the various team members needs to be scheduled for particular tasks at a particular time, so that all the deadlines can be met. By delaying a milestone within a project with a delinquent client, you completely disorganize the schedule of the team member who is responsible for the consecutive milestones.

The so called scope creep is the most financially unpleasant problem to experience for a web development company. Scope creep occurs when the project requested functionality exceeds the initial requirements, for which you have quoted in the proposal or project plan. Changes within the project requirements are often justified during the development process. It is essential however to initiate a change order for any major extension of the requirements. A change order is an amendment of the original development contract with the client, that introduces new costs for all the added requirements implementation.

• writing a project plan based on a thorough survey of the clients needs before initiating the development process
• building and collaborating with the client on a website blueprint that addresses site structure, content structure and navigational paths of the website

If you have an experienced project team and there are no problems with the completion of milestones by a client, but you're still failing to meet project milestones, you must have a scheduling problem. The project manager must consult the project team's calendar before setting up a schedule for a project. It is essential to determine when a given team member has time to work on a given task and setup the milestone deadlines for the new projects according to that.

A well thought out schedule will be respected and used by the team as their main guideline for what to do on a given day. Web based project management apps like BaseCamp give you the capability to setup milestones and assign them to team members, as well as keep track of their completion date/time.

A new article series about project management will be initiated on WAL very soon. It will focus on the details of managing a web development project from start to finish.