WO2008067621A2

WO2008067621A2 - Method and apparatus for representing the layout of a website

Info

Publication number: WO2008067621A2
Application number: PCT/BE2007/000126
Authority: WO
Inventors: Michel Tassent
Original assignee: Tassent E. Corporation Belgium Bvba
Priority date: 2006-12-04
Filing date: 2007-12-04
Publication date: 2008-06-12
Also published as: WO2008067621A3

Abstract

Method for representing the layout of a website, comprising: subdividing the layout of the website in a hierarchical structure of building blocks, comprising at least two hierarchical levels, wherein the highest hierarchical level subdivides the layout in at least one building block, wherein a building block comprises at least an object, and wherein at least one of the objects in the hierarchical structure comprises an indication for defining a location wherein the website displayable contents is insertable.

Description

Method and apparatus for representing the layout of a website

1. Method for devising templates

At present, the process of developing websites follows several steps .

1. A web designer makes a graphical design of a website.

2. The design is translated into (X) HTML-code and a stylesheet (CSS) 3. A programmer develops a database

4. And links the database to the (X) HTML-code using a

(scripting) language (e.g. PHP, Java, .NET)

5. The website is filled with content

Most websites (80%) consist largely of similar elements. It may seem logical that these elements should be reusable or recyclable for the creation of new websites. However, some market-specific problems cause the reuse of objects to be all but evident :

- As the W3C, the World Wide Web Consortium, has made no arrangements, agreements or rules on how to structure a stylesheet (CSS-document) , a template (HTML-document) or website, a proliferation of unstructured tags has risen in these documents .

- But it doesn't stop there. A website consists of HTML- code, javascript, CSS-stylesheets, images (images other that those used to illustrate the texts, but those that form the lay-out of the website like rounded corners, shadows, arrows, borders etc.) and scripting code (the code making a website an advanced website, allowing a website to communicate with a database) . These five elements must be able to cooperate optimally to create a working website. If one of the elements changes, the others should be adjusted accordingly. This complicates reuse of parts in another website a complex matter.

Our new method wants to change that .

1.1. Component Decoding Language (CDL)

By splitting up a website in objects, and by splitting these objects again in components or attributes of components, and by naming all these objects and their elements, we create a possibility to describe a part of a website as a series of names of sub-parts. And by doing so, we create a means to describe a whole website as a hierarchically structured series of (sub) part names.

Thus we create a language, that can be used to describe the graphical design of a website on one hand, and to describe already created (programmed) parts of a website on the other hand. This largely contributes to the reuse of website objects, boosting productivity and optimization, and offers possibilities for the automation of indexing parts of websites (objects) , opening venues of reuse, considering even huge numbers of objects.

We named this language Component Decoding Language . It is a de-coding language, which means that it decodes code into a

(humanly) understandable series of names, this by showing the names of blocks of code instead of the code itself. As those names were derived from CoDA-components (Component-oriented

Design Architecture) , the name CDL came to life.

1.1.1. Theory behind the method

An (X) HTML-document is composed of a collection of elements.

On the lowest level, those elements are tags (e.g.

<span>abc</span>) . Those tags can be nested, creating large collections of elements: <divχspan>abc</spanχ/div>, that on their turn can be nested again. Each website thus consists of larger collections of elements, all nested between the main <html> and </html> tags.

<html>

<blocklχ/blockl> <block2>

Each collection of elements has a specific function in a website: navigation menu, headline, product overview, footer, search, and so on.

Similar collections of elements with specific functions are being used in several websites, but we can even state that almost all websites utilize certain element collections. By detaching those element collections, you create a building system that consists of building blocks. By inserting those building blocks (objects) in a clever way one into the other, you get a valid and working (X) HTML-document .

The new model simplifies an (X) HTML-document to the following diagram:

<html>

<attributeχ/attribute> </buildingblock> <buildingblock>

<attributeχ/attribute> </buildingblock>

</html>

Standardization

This intelligently using building blocks to construct websites, however, has to take some problems into account:

1.As mentioned above, websites consist of the five said elements ((X)HTML, javascript, stylesheets, images and scriptingcode) . This also applies to separate building blocks in websites. If a website is comprised of a large number of components (and that is extremely likely) , the number of (small) HTML-documents, stylesheets, images and javascripts per website will rise accordingly. That could create problems: some web browsers (Internet Explorer) only allow 30 stylesheets being used in one website, and websites get slower if a large number of (even small) external files have to be read.

2. Not only the number of files per website, but the total number of files (HTML, CSS, javascripts, images) will rise in time. The threat of creating chaos is not unthinkable. It is a challenge to save this huge amount of files in libraries that are both surveyable and performing .

3. It should be possible to create most websites with the available components. Making this possible asks for a framework that is both flexible and solid (figure 20) ; 4. Building blocks should be independent. This means a change in building block A must have no influence on building block B. At the same time, building block B should sometimes know what building block A does. In other words: building blocks should be completely independent but should still cooperate.

We found solutions for all these problems.

1&2. 'Standardization¹. Meaning all websites created with CDL and CoDA have to use the same keywords. That simplifies the reuse of code enormously.

A computer is very strict when it comes to names. The javascript function ^ΛCheckEmail' is a completely different function for a computer than 'checkEmail' . Strict naming rules are of the utmost importance if you want to define computer recognizable components.

3. We have found a flexible and stable framework, see 1.2 Frameworks (CoDA) .

4. Again standardization plays a major role: a component headnavigation can easily assume that a component subnavigation will always carry the same names for its variables. On top of that, the current programming standards related to OOP (object oriented programming) have already solved the depending independence issue. OOP implies that communication between blocks of code is kept to a strict necessary minimum, freeing the remaining code of dependence. If blocks communicate whatsoever, they do so following strict rules and regulations. Logical groups

Building blocks are divided into logical groups. This logic is represented in the naming process of building blocks. Every filename incorporates a series of numbers each starting with a separation mark, than a letter, followed by a number of digits (e.g. _A01) . Every series in the filename of an object reflects a certain characteristic of that object. Those characteristics are filed in a database, with an indication of the series they relate to. That way characteristics of an object can easily be found in that database, and objects can easily be traced. The lowest figures in the digits part of the series are reserved for the most commonly used objects of their kind. Those are selected through syndication of thousands of websites: the forms in which a certain object appears in most of those websites will get _A01, _A02 as their series number for a certain characteristic.

Each logical group gets a color in our system. Within every main group, we can define subgroups that will be presented in a different hue of the color of its main group, to maintain the possibility to oversee an exponentially growing number of components . The table below represents a hierarchic view of the various building block groups.

Main Tags (MT) :

Objects that form the basic structure, that contain all other objects, but have no visible characteristics (represented in tones of gray) .

As explained above, every component in CDL is named with a series of numbers that can describe characteristics of the component. The characteristics of a component can be understood as an overview of the components and attributes it is built with.

Example of a MainTag:

BodyMiddle AO1 : LeftSet - MiddleSet - RightSet

If in this example the LeftSet component is withdrawn from the

BodyMiddle (e.g. to be used in another component like the BodyLeftSet) , a new BodyMiddle component will be created that will receive a new name:

BodyMiddle_A02 : MiddleSet - RightSet The same process takes place in all the other components, as the examples below will show.

Sub Tags (ST) : Objects that form the intrastructure (structure inside Main Tag basic structure) and have a basic lay-out (represented in light brown colors) .

Examples of Sub Tags RightSet_A01: RightSetTopBlock - RightNav -

RightSetBottomBlock RightSet_A02 : RightSetTopBlock - RightNav

SubTag Elements (ST) are objects that also help construct the infrastructure, they too receive a basic lay-out. They divide the SubTags in smaller parts which simplifies creating a layout. (SubTag Elements are represented in dark brown color) .

Examples of SubTag Elements RightNav_A01_A01_A01: Headlines

RightNav_A01_A01_A03 : Headlines - Topics - Links

Components (COMS) : Objects used to form the lay-out of the site (a ^λmulti-color' group) .

Basis Elements (BE) :

Basis Elements are part of the group Components (COMS) and are used inside SubTags. Together with the SubTags they shape a complete webpage . Basis Elements consist of SubEletnents (e.g. Detail: [...]) and Attributes. (Basis Elements are represented in blue color. ) Examples of Basis Elements:

UpNav_A01_A01_A01: HeadTitlelmg - HeadTitle - HeadTitlelmg - MainCat-Cat- SubCat-SubPlus{nr} -Detail : [Img/ Symbol - Title - Img - Separator/ ImgSeparator ] *

Syntax in CDL

To guarantee the surveyability of CDL, a lot of attention is given to the syntax. Following the syntax rules is strictly imperative. Some syntax examples applied to Basis Elements:

CDL names are written in camelcase, capitalizing every meaningful part of the name;

The hyphen ("and") is used to list attributes and/or components. If the items listed are mentioned with complete names, a blank space is added in front and behind the hyphen, (e.g. HeadTitlelmg - HeadTitle -

HeadTitlelmg) . If no blank space is used, the starting or ending part of the name is the basis for all items in the list (e.g. ImgCat-Sub-Detail) ; - A slash (/) means "or" . In the example of the UpNav above, it means that Detail will have an image (Img, e.g. an arrow) or a symbol (Symbol, e.g. a plus sign) . (e.g.

Img/Symbol) ;

- An image (Img) is always a separate file, that is inserted into a website using CSS. A symbol (Symbol) is inserted with HTML;

A field that needs filling out is placed between brackets

(e.g. SubPlus {nr});

Items that belong together are placed between square brackets. If, like in the example above, such a group is repeated, a star is written after the closing bracket.

(e.g. Detail: [Img/ Symbol - Title - Img - Separator/

ImgSeparator ]*. This example reflects that the category

"Detail" in the UpNav can consist of an Img or a Symbol, it has a Title, an Img again, followed by a Separator or an ImgSeparator . This whole construction is repeated for every appearance of the Detail part in the UpNav) .

Functions (F) & Element Functions (EF) : Functions are objects that change the appearance (or 'function') of another object (for instance, and mainly, the Globalpage and Content objects) . Element Functions are objects that are part of Functions. (Functions are represented in pink color, Element Functions in green color) .

Two functions are worth mentioning in our new method: the BF_Form function and the Mapping function.

BF Form

A noticeable fact is that a form can be completely configured by the user of our system. BF_Form is subdivided in several logical blocks for the user to include or extract from a form. The user can include existing elements (like the Element Functions BEF Form Info or BEF Form Configuration) or by configuring an element himself (with e.g. the attributes Checkbox, Text, Captcha...) .

BF_Form_A01_A01_A01: (to build a form)

LeftSet - [ BEF Form Info - BEF Form Configuration - ReceiveNewsletter : [Checkbox - Text - [ NoticeLink/ Message ] ] - Accept : [Checkbox- * - NoticeName - [ NoticeLink/ Message ] -

Captcha - [ TextSubmit -/ ImgSubmit ] - [ TextReset -/ ImgReset ] - FormSave] - RightSet BEF_Form_Info_A01_A01_A01: (form used to ask data about visitors of a website) :

[HeadTitle - [ ClientNr-/ login - Password ]-* - [ Name-* - Field ] - [ ContactName-* - Field ] - [ Address-* -

Field ] - [ ZipCode-*{Nr} - Field ] - [ Location-* - Field ] - [ Country-* - Field/ ListMenu ] - [ [ TeI-* - Field ]*{Nr} ] - [ Fax-* - Field ] - [ EMail-* - Field ] ] - [ Note - Field{Nr} ] - [

TextSubmit -/ ImgSubmit - TextRequiredFields ] ]

BEF_Form_Configuration_A01_A01_A01: (component to build items)

HeadTitle - CopylnfoForm - BEF Form Info - [ Title-* - InfoType-*: [TextField/

TextArea{Nr}/ Checkbox*/ RadioButton*/

ListMenu*/ Date-*/ DateValidation-* : [Day-Month-Date-

Year / Day-Date-Month-Year] - [Note -

Field{Nr}/ Text ] - FileLoader ]* - [HeadNote - Field{Nr} - ]

Mapping

We define mapping as the redirection to another part of the website or an external website, from within a Function, using a URL. Compilation indicates the compilation (e.g. TopBar: [{Compilation}] , in this case a compilation of Topbar will be shown) .

An example can be found in the Function BF_SiteMap, that gives an overview of a website by combining elements from various building blocks: BF_SiteMap_A01_A01_A01 : Lef tSet -

Mapping>Topbar: [{Compilation}] - Mapping>Categories : [{Compilation: [ [ MainCat ] -/ [ Cat ] -/ [ SubCat ] -/ [ BF DetailPage ] ] }] -

Mapping>BEF Products InThePicture : [{Compil ation}] -

Mapping>Headlines : [{Compilation}] - Mapping>Bottomb_ar : [{Compilation}] - RightSet

SubElements (SE) :

Some building blocks are so small, they are nested in other building blocks. We call those building elements SubElements. Splitting a building block in yet smaller components that way, prevents the number of types of a certain building block to grow out of proportion. (SubElements are represented in light blue color)

Attributes:

An attribute is the smallest, indivisible part of a building block, similar to an atom in a molecule. It does not imply that an attribute only holds one HTML-tag. It means that the tags it comprises are so related, they cannot be separated without losing their strength. There is no advantage in dividing an attribute in even smaller parts. If building blocks and building elements are completely disassembled, attributes would be the only components left . (Attributes are represented in dark blue color.)

Stylesheets, Design Elements and SuperDiv By dividing all objects in parts, and by making building blocks or (sub) elements of all those parts, we create the possibility of styling every element separately through its own stylesheet. This minimizes the total number of necessary- files by creating more combination possibilities.

We can show an example of this using the component LineNav, a horizontal navigation component. After analysis and syndication of thousands of websites, we came to the conclusion that there are four SubElements (MainCat, Catl, Cat2, FlyOutMenu) that, in different combinations can form five basis types of LineNav when it comes to structure. Those types, on their turn, by adding style using CSS, can be used to form any thinkable horizontal navigation bar. In CDL LineNav is written as follows: (figures 1-2-3)

1) LineNav_A01_A01_A01: MainCat : [Img/ Symbol - Title - Img/

Separator ] * -

FlyOutMenu: [Cat-SubCat-SubPlus{nr} - Detail: [Img/ Symbol - Title - Img ]]*

2) LineNav_A01_A02_A02: MainCat : [Img/ Symbol - Title - Img/

Separator ] *

3) LineNav_A01_A03_A02: MainCat-Catl : [Img/ Symbol - Title -

Img/ Separator ] *

4) LineNav_A01_A03_A03: MainCat-Cat2 : [ Empty ]

5) LineNav_A01_A04_A01: MainCat-Catl : [Img/ Symbol - Title -

Img/ Separator ]*- FlyOutMenu: [SubCat-SubPlusjnrj -Detail : [Img/

Symbol - Title - Img ] ] *

As the example above shows, in most cases it is important to keep the CSS-code that takes care of positioning, or even of the action or process incorporated in the component, close to the component block itself in order to guarantee the reuse possibilities of the block. The CSS-code is not written into the building block itself, but in a separate CSS-file, that gets a pointer to the building block it is associated with in its filename (e.g. MainCat_idlO6) . A certain object can have multiple CSS-files associated with it, that can be used upon it to give it style. That greatly enlarges the number of combinations possible: because all parts of an object are given standardized names, a lot of the previously devised CSS- files can be used with the same goal with all the objects. By building for example 10 navigation bars, resulting in 10 components with 10 CSS-files, one hundred bars can be put together (10 times 10) resulting in 90 extra combinations.

In order to give style to an element, we have a process of looking for unique (X) HTML-structures that form a certain "entity" that can be styled. In the LineNav case above, those entities are the four SubElements . To add style to elements, they need to have certain "anchor points" in the HTML that can be used to attach style. If we want to provide a lay-out for the LineNav with, say, rounded corners, we need some anchor points in the HTML structure to attach the rounded corners to. Lay-outs that are built using this unique (X)HTML structure, are called Design Elements. Considering the LineNav example, we distinguish four SubElements (MainCat, with the head categories of the navigation, Catl, with the subcategories of the navigation, Cat2, holding a mere background image and FlyOutMenu that contains deeper subcategories and that will only be rendered (visible) after some action with the pointing device (e.g. mouse hover or click) . With this example in mind we clearly point out the difference between SubElements as structural elements and Design Elements as graphical Elements . A structural element in CDL marks places in a website that will be taken (e.g. 'In this website a FlyOutMenu will be used' ) , Design Elements show how everything will look eventually (see figure 11-17) . These Design Elements all get their own ID. The 100 first id-numbers will be reserved for standard use .

To prevent that a lot of style issues will be the cause of a proliferation of building blocks, we created SuperDiv. The SuperDiv feature allows us to build the basis HTML-structure so that every possible style characteristic can be added with CSS, by adding extra DIV-tags around an element. E.g., to build a complete border with rounded corners around a DIV-tag, the SuperDiv feature allows us to create 8 DIV-tags around the original DIV-tag allowing for space for borders and corner images.

Object Exchangeability- All objects are built to be independent, and can be exchanged easily. That fact allows us to create the possibility to simply configure (point at, in an administration console) instead of program (generate or adapt code) part of a website (an object, element, component) by replacing an object with another object, mostly but not imperatively, of the same kind.

The use of CoDA-frameworks (see point 1.2.) makes it possible to retrieve objects from a specific part of a frame and 'plug them in' someplace else, as all surfaces in a website or web user interface carry standardized names and form a stable structure. This allows for pointing out where to place an object, and for not endangering the structure while removing or adding objects somewhere.

The possibility to represent millions of websites for what their usefull objects are concerned in 4 pages each. This shorthand-like notation, what CDL is, in fact, makes it possible to define the lay-out and structure of a complicated website in maximum 4 pages. That short-hand notation will allow for the construction of said website by just choosing all enumerated objects with their names and frameworks, (apart from content and personalized or personal parts like pictures, logo, texts, ...) , as far as all those objects are already made and put in the library of course.

1.2. Frameworks (CoDA)

CoDA-frameworks (Component-oriented Design Architecture) can be defined as predefined choices of objects that are solely used to represent the structure of a website. By choosing a file for a certain object that calls three other objects, for instance, and by choosing files for those three objects that each call three new objects, a hierarchical structure is created in which the main object consists of 3 objects that each contain 3 objects. So you have 9 smaller, 3 medium and one large surfaces. If we change our choice for the first object and choose an object that only contains 2 of the 3 previously called objects, we get a site that is made up out of 1 large, 2 medium sized and 6 smaller surfaces, etc. As such an object cannot merely call other objects but also contains HTML-code, and can be associated with a CSS-file, apart from splitting surfaces it can add visual structure to the hierarchical one. The choice of all components that are structural (MainTags, SubTags) together is a CoDA-framework.

In our new method of building a website, we start with choosing a framework. Such a framework consists of dozens of surfaces that can be filled or left empty. If they are not filled from the start, they are left in the structure to be filled later. To develop these frameworks we analyzed and syndicated thousands of websites. One of the frameworks that we worked out in CoDA (figure 19) can be used as a starting point for most of these thousands of websites. That way you can start off from a structural solution that can be labeled "best practice" because the adaptations you have to make are minimal to build an own, unique website.

We also use colors in the framework to add visual surveyability . The hierarchical place of elements in the structure, represented by the groups they are part of, is shown in colors. We include a possibility to visualize that colored structure in a browser window so that it is visually clear for a designer or user where certain objects can be found in the administration console. That way changes are made more swiftly.

If a website designer wants total freedom however, our framework method is not imperative; as easy as you can choose a framework with dozens of small surfaces and add or delete some, a designer is free to start off with a completely blank framework and add his own structure to it by choosing our predefined structure elements (object from MT or ST groups) or build his own.

The framework is devised with loose HTML-objects and loose CSS-files, so that every object of the framework is independent, and the framework won't fall apart if an element is taken out of it.

The framework can be adapted by adding or deleting objects. Those actions are made by configuring, not by programming. You configure by checking checkmarks next to object names and choosing HTML-files and CSS-files for each chosen object. By saving the CSS-files of each object separately, we create the possibility for users that only want (or only know how to configure their site to choose a 'template' for each object. Evidently, they can also pick a style for the complete site as a whole, like template systems offer nowadays already, but our method creates the additional possibility to configure the style of a certain object within the "complete site template" by choosing an "object template" . With a small number of templates per object the number of combinations quickly reaches indefinite boundaries, as websites consist of large numbers of objects.

Summarizing - Decoding Language (CDL) : o A language that describes the various parts of a website. It structures the graphical design and the programming code on one hand, and it improves reuse capability of the various parts of the website on the other hand.

Theory behind the method: o The same collections of elements are frequently used in multiple websites. By describing these elements in CDL and plugging them together in an intelligent way, the same elements can be used in different combinations to create new and unique websites over and over again; o Logical groups: the elements are divided into logical groups that each get a unique name so that they can easily be traced and found in a database.

On top of that we add color representations to those groups to make searching objects simpler, and to easily obtain a hierarchical overview; o Stylesheets, Design Elements and SuperDiv: by contemplating the way style will be added to objects during the creation process, reuse possibilities of separate building blocks are enlarged vastly, and it will keep the amount of various building blocks surveyable ; o Object exchangeability: all objects are built so that they are independent and can be exchanged easily. This means an object can easily be moved from one place in the wensite to another, and one object can be replaced easily with another; o The possibility to represent millions of websites for what their usefull objects are concerned in 4 pages each: the short-hand CDL notation makes it possible to define a complicated website in its structure and lay-out in maximum 4 pages. Frameworks (CoDA) : o CoDA-frameworks (Component-oriented Design Architecture) can be defined as predefined collections of choices of objects that only serve to add structure to a website; o During the development of website with CoDA we start by choosing a framework; o Frameworks are always 'best practice' ; o Frameworks are also visualized with colors; o There is no obligation to stick to a certain framework, a designer can compose his or her own framework; o A framework is built so that every object is independent ; o Changing a framework is done by configuring, not by programming; o A user is not restricted to adding style to the complete site, but can style each object separately. 2. Process to design templates

Using the new method, the CDL and CoDA principles are maintained throughout the various steps of the working process, allowing communication between the various actors in the process to ease, and time is won thanks to the reuse of various elements, that are saved in libraries open for designers as well as developers.

The different steps in the workflow of our new method:

- The designer is briefed by the account or project manager and starts working in graphical software (e.g. Photoshop, Fireworks, Flash, CorelDRAW, ...) . As the framework and a lot of building blocks are already present in the libraries, he will probably only use 20 % of new, original elements which he has to draw himself. These newly made elements will be described with the standard CDL-names, exactly like the existing elements, using these names for maps, layers, images etc. Because a lot of elements are already present, and can be used as they are or after minor changes or adaptations, the designer can work a lot faster than usual. The end result will be a new collection of existing and non-existing elements, within an existing or new framework, all using set standard names;

In the next step, using the WPS development environment (WPS {Web Portal Syndication) see point 3.), a framework is being chosen or made if necessary, using the standard names described in CDL. The framework actually is the frame to which all individual elements will be attached; If the designer used elements that have not yet been developed, they will first be made describing them using CDL. As for doing that, no specific programming knowledge is required, this part of the work can be done by the designer. Building blocks that do not as yet exist receive a number that corresponds to the number given to them by the designer in the graphical software using the syntax of CDL and CoDA;

The developer gets an overview of the missing building blocks he has to code and sees how they are supposed to be structured. For that purpose he gets an image of the building block from the graphical design software, and CDL further describes how the building block should be structured. By means of these and optionally remark on the effects that need to be created in Javascript, he builds a building block and the additional CSS;

- WPS, the development environment, has two separate sub- environments: WUILive wherein the site is initially built, and WUILabo wherein at any time changes to the website can be made without having an effect on the publicly accessible website. In WUILabo, a project manager or even the final customer can, at any moment, from the time the designer starts to build, monitor the result in real time and adjust the process if necessary. If the designer and developer are ready and all parties are happy with the result, the website can be put online in WUILive. Existing websites can also be modified in the WUILabo environment before the adjustments go online. Building blocks that are being used in the process are write-protected for others;

- WUILive is an environment with direct interaction with the online website. A quick modification of the above parts can take place here, but of course, testing modifications in the WUILabo environment first is to be recommended. Summarizing

In the new method, the CDL and CoDA principles are maintained throughout the various steps of the workflow or working process. This simplifies communication between the different actors in the process, and reduces production time through the reuse of multiple elements, kept in libraries to which both designers and developers have access.

3. System to compose and adjust templates

Using CDL and CoDA, websites are built using components. To make this process of building websites smooth an intelligent system is needed. This system is called WPS (Web Portal Syndication) . One of the major improvements is that it is capable of proposing a framework and a set of components when fed CDL terms through input by a developer.

The WPS can have following characteristics : - WPS knows CDL and CoDA philosophy and can apply it. The actual identity of a component (what is it) , and what kinds thereof exist in the library (the various types, styles etc) have to be programmed into it, but the WPS is able to find and apply the building blocks to compose the components;

- The WPS can build (compose) a complete website with selected components. This is the operational part of the WPS: this part turns selected components into a grammatically correct and valid website; - Functionalities can be implemented. With functionalities we mean functions like a login system, search engine, newsletter, sitemap, font size enlarger, etc., functions that most websites (can) use. With implemented we mean they can be programmed according to the CDL and CoDA specifications or syntax ;

The WPS can search for components using a search algorithm that evaluates CDL terms,- - The WPS administers the various necessary libraries (HTML, CSS, Javascript, images) ,-

- The WPS is attached to a CMS (Content Management System) in order to manage content;

- Multiple websites can share the same WPS and database (the system and database are multi-tenant) . This implies that components, (or any other part of the libraries) developed or designed for one website, can be used for other websites. This in order to add to the reuse effect.

Summarizing

4. Platform used for sharing parts of templates

4.1. In general

Web Portal Syndication (WPS) is a syndication (union) of necessities (or: needs arising in the market) that are provided through the internet for a large quantity of customers, to compose advanced websites or portals.

It is an addition to, or an extension of a CMS (Content Management System) because it enables the user to not only control and alter the content, but also the outlook, structure, lay-out, actions and processes of a complete website .

Furthermore, a WPS is designed to setup (i.e. build) websites (or WUI' s, web user interfaces) in a SaaS environment (Software as a Service) . (A lot of users can develop as well as administer, alter, change and control their own website online using one and the same WPS installation. It is not necessary for them to install their own version of the software . )

4.2. How

Users subscribe to the WPS and receive database space. In this database, all templates and building blocks have also been described. Using the WPS administration console they can select as well as edit templates, building blocks and stylesheets .

The user gets their own workspace. He can copy templates and stylesheets to his own workspace, where he can experiment with the code of the templates, building blocks, building elements and stylesheets .

Website development in WPS in steps:

1. A user subscribes to the WPS; 2. He gets a username and password to login to the administration panel;

3. He gets a workspace on the WPS server;

4. He copies templates from the library to his personal workspace (figure 16) or he builds his own template using the Freestyle option (figure 18) .

5. He selects a template from his own personal library (figure 17) , he copies stylesheets from the library to his own workspace (overview) or he builds his own new stylesheet using the Freestyle option (figure 21) . 6. He selects a stylesheet from his own personal library by checking the checkmark next to it .

7. He fills his website with texts and images and decides upon page structure using the CMS in the WPS administration panel.

These steps provide a working website. In order to further personalize his website the user can:

1. Edit, change or replace the stylesheet and save it (figure 21) .

2. Edit, change or replace the template and save it (figure 18) .

3. Copy different types of building blocks for the ones used in his template to his own workspace (figure 24)

4. Check (choose) a different type of building block in his personal workspace. This new type will be used in his website (figure 23)

5. Copy building elements to his workspace (figure 29) 6. Check (choose) other building element types in the personal workspace. This type will be used in the website (figure 28) . 7. Copy stylesheets built for objects to his personal workspace and alter them to his own wishes or taste.

Utilize graphical software and HTML-editor

WPS represents all (self) made templates, building blocks and building elements visually in an extensive image file using layers (e.g. Photoshop PSD-file) . Using that file, users can easily get a visual presentation of how the use of a certain template, building block type or building element will work in his or her design.

Every group of templates (e.g. all _A01 templates) have a visual image file. This image file incorporates all building blocks and building elements that can possibly be used in this template in various structured folders. All visual representations are set up in tones of gray. By using the technical capabilities of graphical software (like Photoshop, Flash, CorelDRAW, Fireworks) the user can experiment with color, fonts, font size, images, positioning, etc. In the image file, once the design and lay-out have been made definitive, it is possible to determine what templates, building blocks and building elements the user has to select in the administration console in order to obtain the website as designed. With these settings, the WPS composes an HTML- page and a set of stylesheets .

Photoshop-document : Figure 7 - Images (the right way and the wrong way) .

By opening this HTML document with the stylesheets using an HTML editor (Dreamweaver, Frontpage, etc) the user can alter the stylesheets in a graphical manner to his own wishes.

Dreamweaver document: figure 11

Create personalized templates, building blocks, building elements and stylesheets Users can create their own templates, building blocks, building elements and stylesheets. They can edit existing files, alter and save them. Or they can use Freestyle templates and Freestyle stylesheets to devise completely new templates and stylesheets.

Templates, building blocks or building elements created by users can be recognized by their own unique name. A new or altered template gets the username and a sequential number. The same principle applies to freestyled stylesheets, building blocks and building elements.

New modules We will constantly develop new functions and modules for the WPS according to CDL and CoDA rules and syntax. Possibilities include advanced search applications, login applications, forms, polls, web-feeds, catalogues, newsletters, e-shops, weblogs, etc. Users can subscribe freely or at a set cost (depending on the function) to these applications. They can easily and swiftly couple these modules to their own website.

4.3. WikiWPS and ApplicWPS

We define WikiWPS as the swift sharing of information. One can offer his knowledge as a service to a community and in exchange for that can use the knowledge of other community members . WikiWPS opens the Web2 world for WPS : the internet for everyone, by everyone. All new user made designs are open for use to all WikiWPS community members, free of charge or at a very low fee. That applies to templates, building blocks, building elements and all adhering stylesheets, graphics and scripts. Through this system of user-generated designs, WPS constantly renews and extends itself within the community.

ApplicWPS is a platform for webdevelopers who want to compose advanced websites or portals in a fast, efficient and structured manner. All objects or scripts created within ApplicWPS remain the sole property of the creator or user.

Summarizing

Web Portal Syndication (WPS) is a syndication (union) of necessities (or: needs arising in the market) that are provided through the internet for a large quantity of customers, to compose advanced, database-driven websites or portals. To make a clear distinction with traditional CMS's, a user is given the capabilities to alter the lay-out, outlook, structure, actions and processes of the complete site or part of it.

- How o A user subscribes to the system and gets database space and an own workspace where he can experiment with the code of templates, building blocks, building elements and stylesheets; o Utilize graphical software and HTML editor: every group of templates in the WPS has its own image file that is structured according to CDL rules and syntax. Once a website is designed and an HTML-page is produced, this document can be supplied in an

HTML editor with a stylesheet; o Create personal templates, building blocks, building elements and stylesheets; users can use existing templates, building blocks, building elements and stylesheets or can create their own. All these self made or adjusted templates, building blocks, building elements and stylesheets get their own, unique name ; o New modules: we will constantly develop new applications for WPS users to subscribe to, either free or at a charge;

- WikiWPS and ApplicWPS: o WikiWPS : A 'user generated' model or web2 application based on CDL and CoDA principles allowing users, free of charge or at a minimal cost, to online use a platform to build a website, and to share their creations with the community. Items created within WikiWPS will always be used to contribute to the community in favor of the other community members; o ApplicWPS: A platform for webdevelopers who want to compose advanced websites or portals in a fast, efficient and structured manner. All objects or scripts created within ApplicWPS remain the sole property of the creator or user.

Below a number of exemplary structures and exemplary building blocks are given.

LineNav (5 CDL types) :

De 5 standrd types of LineNav as described in CDL are shown in figure 1-5.

CDL uses colors to represent building blocks. Basis Elements such as LineNav are represented in blue, SubElements such as MainCat in light blue and Attributes such as Img or Separator in dark blue.

Figure 1 :

1) LineNav_A01_A03_A02 MainCat-Cat1 : [Img/ Symbol - Title -

Img/ Separator/ ImgSeparator ] *

Figure 2 :

2) LineNav_A01_A02_A02 MainCat : [Img/ Symbol - Title - Img/

Separator/ ImgSeparator ] * - FlyOutMenu: [Cat-SubCat-SubPlus {nr} - Detail: [Img/ Symbol - Title - Img ] ] *

Figure 3 :

3) LineNav_A01_A03_A02 MainCat - Catl: [Img/ Symbol - Title -

Img/ Separator/ ImgSeparator ] * Figure 4 ;

4) LineNav_A01_A03_A03 MainCat - Cat2 : [ Empty ]

Figure 5 :

5) LineNav_A01_A04_A01 MainCat - Catl: [Img/ Symbol - Title -

Img/ Separator/ ImgSeparator ] *- FlyOutMenu: [SubCat-SubPlus {nr} - Detail: [Img/ Symbol - Title - Img ]]*

De 5 basic combinations of the four SubElements of LineNav that, by applying CSS, can assume every possible appearance of a horizontal navigation bar, are shown in figure 6-10.

LineNav (4 CSS DesignElement types) : 4 DesignElement types :

1) MainCat_ids

2) Catl_ids

3) Cat2_ids 4 ) FlyOutMenu_ids

Figure 6 :

1) LineNav_A01_A01_A01_idl

Figure 7 :

2) LineNav_A01_A02_A02_idl

Figure 8 :

3) LineNav_A01_A03_A02_idl

Figure 9 :

4) LineNav AOl AO3 AO3 idl Figure 10 :

5) LineNav_A01_A04_A01_idl

The four SubElements of LineNav that can be the five basic combinations of LineNav are shown in figures 11-17. _idl is a minimalistic representation with all possible Attributes such an element can comprise. _ids from 100 are assigneed to complete designs.

Figure 11: 1) MainCat_ids

Examples :

Figure 12 : MainCat_idlO4c Figure 13: MainCat_idll7

2) Catl_ids

Figure 14 : Catl_idl

Examples :

Figure 15: Catl_idlθl

Figure 11: Catl_idlO2

Figure 12: Catl_idlll

3) Cat2_ids

Figure 13 : Cat2_idl

Examples :

Figure 14: Cat2_idlO2

Figure 15: Cat2_idlO5

Figure 16: Cat2_idlO6 4 ) FlyOutMenu_ids

Figure 17: Respectively: FlyOutMenu_idsl and the examples: FlyOutMenu_idsl01, FlyOutMenu_idsl03 , and FlyOutMenu_idsl05

Figure 18 : Two examples of the structure of a website

Figure 19: Framework_A01_partl-MainTags . Most websites can be created with this framework as starting point. The structure of this framework is as follows:

Framework AOl

Framework AOl AOl AOl AOl AOl AOl (6 levels)

<BasisDiv_A01 >

<BodyTopDiv_A01 > Empty <BodyMiddleDiv_A01 >

<BodyLeftSet_A01 > Empty <BodyMiddleSet_A01 > <BodyTop_A01 >

<SiteTop_A01 > SiteTopLeftBlock - Topbar -

SiteTopRightBlock

<Menu AOl > MenuLeftBlock - MenuTop - MenuMiddle MenuBottom - MenuRightBlock

<BodyMiddle_A01 >

<LeftSet AOl > LeftSetTopBlock - LeftNav -

LeftSetBottomBlock

<MiddleSet AOl > Content <RightSet_A01 > RightSetTopBlock -

RightNav - RightSetBottomBlock <BodyBottom_A01 > <SiteFooter_A01 > SiteFooterLeftBlock -

Bottombar - Copylnfo - SiteFooterRightBlock

<BodyRightSet_A01_idl> Empty <BodyBottomDiv AOl idl> Empty

Figure 20: Framework_A0l_idl ; the choice of all objects that only have a structural interest together (Main Tags, Sub Tags) form a Framework. Framework_A01 is the framework most often used; this means that almost all websites be created with this framework as starting point.

To guarantee the visual surveyability, a framework can be visualized with colors, in order to allow one to directly see to what color group an object belongs.

To facilitate visual pointers VDL utilizes colors. Main Tags are represented in different tones of grey, Sub Tags in light brown colors, and SubTag Elements in dark brown colors.

Figure 21: Framework_A01_id 24; In the new method one first chooses a framework when starting to build a new website.

Figure 22: Framework_idl04 ; The framework can be modified by adding or removing objects.

Figure 23: Framework_idl07 ; The framework can be modified by adding or removing objects.

Figure 24 : An overview of available templates in the WPS library. A user may copy these templates to his or her personal library. Figure 25: An overview of templates in the personal library. The user indicates what template he wants to use for his or her website.

Figure 26: Modifying a template. Building blocks may be moved. Building blocks comprise notes such as: <div id="buildingblock_name" > { include file=" $buildingblock_name" } </div>

Figure 27: Same principle as figure 10, but applied to stylesheets

Figure 28: Same principle as figure 11, but applied to stylesheets

Figure 29: Same principle as figure 12, but applied to stylesheets

Figure 30: Overview of components that are used in the chosen template, with their file names and stylesheet file names.

Figure 31: Every building block has its own set of templates from which the user can choose one .

Figure 32: Every building block has its own set of templates from which the user can choose one.

Figure 33: Example of the code of a. Tags between double braces {...} show the links with the database. The tag {{include file=...} } includes a building block or building element. All existing types of building blocks, building elements and stylesheets may be edited with WPS. Figure 34: Code of building blocks, building elements and stylesheets may also be edited in a seperate editor.

Figure 35: Structure plan. Once building block numbers are assigned, an (X)HTML editor (for example Dreamweaver) may be used to create stylesheets. Once the template and the building blocks have been chosen in the administration console of the WPS, and stylesheets have been either chosen or created with the Freestyle option, the website is ready to be filled with content from the CMS.

Figure 36: This layer structure in Photoshop shows a good example of how confusing tradition web design and web development may be. Searching for the correct layer to make a modification may be both frustrating and time consuming.

The present invention is not limited to the above described exemplary embodiments . The claimed rights are determined by the following claims within the scope of which many modifications are possible.

Claims

1. Method for representing the layout of a website, comprising: subdividing the layout of the website in a hierarchical structure of building blocks, comprising at least two hierarchical levels, wherein the highest hierarchical level subdivides the layout in at least one building block, wherein a building block comprises at least an object, and wherein at least one of the objects in the hierarchical structure comprises an indication for defining a location where in the website displayable contents is insertable .

2. Method according to claim 1, wherein the content to be displayed is supplied by a content management system.

3. Method according to claim 1 or 2 , wherein an object comprises at least one of: a main tag for representing the logical structure in the layout of the website, a subtag for defining the structure in a parent obj ect , and a component for representing the visual layout of a component of a parent object.

4. Method according to claim 3, wherein the position of the main tag in the hierarchical structure is limited to: the highest level in the hierarchical structure, or as a child object of a parent object that itself is a main tag .

5. Method according to claim 3 or 5, wherein the position of a sub tag of the hierarchical structure is limited to: as a child object of a parent object that is a main tag, as a child object of a parent object that is itself a subtag, or the highest level in the hierarchical structure .

6. Method according to claim 3 , 4 or 5 , wherein the position of a component in the hierarchical structure is limited to: as a child object of a parent object that is a main tag, as a child object of a parent object that is a sub tag, as a child object of a parent object that is itself a component, or the highest level in the hierarchical structure .

7. Method according to any of claims 3-6, wherein a component comprises a function, wherein a function modifies the visual representation of a sibling or child.

8. Method according to claim 7 , wherein the parent building component of a function is an object.

9. Method according to claim 6 or 7 , wherein the function comprises at least one of: a "base function" , a "various function" , and a "special function" .

10. Method according to any of claims 3-6, wherein a component comprises a base element.

11. Method according to any of claims 1-10 wherein building component comprises an attribute, wherein an attribute is an atomic component, and wherein an atomic component comprises at least one of : an image, and a textblock.

12. Method according to claim 11, wherein an attribute in the hierachical structure has no child building components .

13. Method according to any of claims 1-12, wherein with an object is associated at least one of:

"markup tags" for defining the layout of an object, "scripting code" for adding executable code to an object, which code is executable in an user interface that displays the website, and style information for defining the visual representation of the object.

14. Method according to any of claims 1-13, wherein each parent object comprises a specification of the number, the type, and the order of each of its child building components .

15. Method according to claim 14, wherein a parent object has a name associated therewith, and wherein the specification comprised by the parent object, is one of the constituting parts of the name that is associated with the parent object.

16. Apparatus for storing the structure of a website, comprising storage means, arranged to store the hierarchical structure that has been acquired by means of the method according to any of claims 1-15.

17. Apparatus for designing a website, arranged to execute a method for any of claims 1-15.

18. Apparatus according to claims 16 or 17, wherein as far as being present, main-tags, subtags, components, sub- elements and attributes are respectively identifiable by a distinguishing colour.

19. System for supplying web content to a web browser, comprising an apparatus according to claim 16 and a content management system comprising web content, wherein the system has been arranged to, in response to a request from a web browser, layout web content from the content management system by placing web content in a location indicated by the location indication from claim 1 in the layout code.