LARGE SITENo Problem

An overview of how a large website can be created and maintained by breaking it down in smaller, manageable chunks.

Creating large websites can present a number of challenges for todays web designers. Not only can you end up with a monster of a site that becomes unwieldy and difficult to manage, but you will, most probably, have to recreate it for several different device widths. In many web development applications, this can create the added problem of a site that becomes so large, it cant be effectively handled by the development environment without overloading your computer system. For those of us that are more used to products such as Dreamweaver, or those that create sites through hand coding, the issues are not so great. But, in this day and age of convenience tools for web development, it’s better to work on smaller files. This also allows for several people to work on the same site at the same time without having to have a copy of the whole site clogging up their system.

Site updates are also another area where consideration must be given to site size. It may be that you need to add only a single page to an existing site. This can be a major headache if you have to open a huge file in your development application. Furthermore, if you do have a number of different people working on the same site, the actual process of uploading the website has to be carefully monitored to ensure that one person’s changes don’t undo another persons work.

With the above in mind, this document sets out the easiest and most effective way of creating large websites that may have to be frequently updated. even if the site is being developed by a single person, this methodology will still save you hours of work and make future site updates simplicity itself.

It’s all about

Organisation

Home

Recipes Techniques Chefs

Recipe Pages Technique Pages

Chef Pages

When we look at traditional website structures, we tend to work in “pages”. Essentially, every element of the site is set out as an individual page that then gets linked to other pages to form a site hierarchy. The diagram on the right shows a typical structure for a cookery site.

Everything starts from a home page. Links are provided from the home page to a set of sub-pages covering topics such as Recipes, Techniques, and Chefs. Each of these pages will typically contain links to individual pages, such as pages for recipes, pages for cooking techniques, and pages that give profile information about contributing chefs.

This structure allows for some fancy cross linking also. For example, individual chefs pages can contain links to specific recipes that the chef has contributed. Likewise, each recipe can contain a link back to the appropriate Chef page so that visitors can easily find other recipes by the same chef.

Now there is nothing wrong with this structure. It works, it’s fairly clean and provides for a nice. easy to navigate site. The problem is, however, when the site grows to contain maybe 50 chefs or two thousand recipes, each with their own images. Suddenly, the site becomes a little too large for comfortable handling.

Add to this the fact that other pages will also be required, such as about us, privacy policy, terms of use, contact us etc. it will be seen that the site can grow quite rapidly. The site could become even more complex if another section about ingredients was to be included. You could require another five hundred odd pages on individual ingredients which you may wish to cross reference through links in recipes. You may even want the ingredients pages to link to all recipes that contain that specific ingredient. Clearly, such a site needs to be well thought-out and planned in advance to ensure that it can grow without crashing your development system in the future.

Folders are your

Best Friend To overcome the problems normally associated with large websites, it’s better to think of your site in terms of folders rather than pages. The reason being that folders allow you to creates a mini website in each folder which can be created and maintained independently. Such an arrangement will allow you to place specific people in charge of maintaining certain sections of the website. Their FTP access will be limited to their particular folder, thus ensuring that there is no accidental erasure of of other parts of the site during periodic updates. It also means that each individual mini-site is the subject of its own development environment, which keeps project files within acceptable norms.

The diagram on the right shows a typical folder structure for a cookery site. It’s taken from a real life site comprising of over 11,000 pages. Clearly, such a site would be impractical to create and manage without a simplified approach to site structuring.

Each folder within the site structure is an individual website with its own index.html file. Essentially, all the links on the site’s common main menu point to folders rather than pages. Another important feature of the site is that all the main images used to illustrate the site (about 22,000) are not even held in the main site. They are hosted on a separate domain that can only be accessed by this particular site. This not only helps reduce the size of the individual project files, it also stop the likes of Google images and others from hot-linking to the site’s image content. This feature isn’t essential but it can help in reducing bandwidth usage for image intensive sites.

There are, of course, additional main site pages that provide the normal static site-wide information, but for the purpose of illustration, we shall ignore those for the time being.

Defining your

Site Layout Obviously, with such a site, that may or may not be being created by several contributors, it’s essential to set site layout standards to ensure consistency in look and feel of each mini sub-site. The best way to do this is to create an initial master site layout comprising of a master page containing the main site navigation and header, as well as a consistent footer area where all the common site links can be placed.

Once created, this can be duplicated and used as the starting point for all the smaller sub-sites. It’s important to remember that all site navigation links within the master use absolute, rather than relative links. In most cases, the links will be to folders rather than pages. The best way to create a suitable menu for such a large site is to use a mega menu that opens up when the recipes link is clicked (see example below). These links will go to the relative “collections” folders. A similar menu can be constructed for named chefs, in which case the links will go to the relevant chef’s folder.

Likewise, a common footer should be included in the master layout. This would display certain site-wide links that may need to be accessed from any page within the site. An example is shown below.

You would now have a consistent page layout that includes all the basic essentials upon which every sub-site can be based. Where the common components require javascript or CSS style sheets (such as the mega menu component), these too can be included as part of the main site structure (where the home page resides). The only thing you will have to ensure is that links to the style sheets and the javascript use those all-important absolute links rather than relative links. In most web development applications this can be easily achieved by pasting the html code for things like mega menus into your master page via an “insert HTML” option, rather than creating it within the site page itself. You may not be able to review the options in a standard preview, but if you upload the common components to your domain before developing, you should be able to preview everything by previewing in a browser.

What you should end up with is a master page that looks something like the illustration on the right. This can now be used for every single page in your site, regardless of it’s content or the section that it’s going to reside in.

You will also notice that we’ve set up a 12 column grid (for the desktop version of the site). This grid should be standardised throughout the site in order to maintain consistency of look and feel of the individual pages.

The 12 column grid is a practical choice as it allows for a great deal of flexibility and variety in laying out pages which are likely to be image-intensive. The idea is to use the columns for laying out a variety of image grids within the page. This stops the pages from becoming boring as visitors scroll the page.

The illustration on the following page shows the grid in action. The first 3 columns are used as a sidebar. The remaining 9 columns are used for laying out image and text content that varies at different points in the page. By creating a mix of image grids spanning the 9 columns, you create variety and interest throughout the pages. In some cases, the image grid can be broken to create advertising space without upsetting the overall look of the page. Body text should ideally only span no more than 6 columns to keep it comfortable for reading.

The page illustrated would be one of the “Collections” pages, designed to provide links to “recipe” pages. The links would be created from the images and the image captions. Collections pages are created in the collections folders of the site, Each folder will be for a specific collection of recipes. The illustrated page would also be the index.html page so that links TO this page would only have to point to the folder. Additional pages can then be created as the number of recipes increased in this collection. The additional pages can be reached by providing a “read more” or “load more” link at the bottom of the page (just above the footer)

The page illustrated includes links to 12 recipe pages, but the number of links per page can be easily extended by adding more image grids. These should be varied to keep the page interesting.

Once this page is created as a sort of template, it’s very easy to bring in content from the various resource folders in your site.

For example, images can all be high resolution images stored in an images folder. Each image placeholder can then link to the relevant image and scale to fit the placeholder allocated to the image. This is usually done through style sheets, which many modern web development environments will create automatically. This means that you only need a single image that can be used site-wide.

In this example, our smallest images are those contained in the 5 image grid. These are all 120 px wide. This is important because this size allows adequate room for the image to be used as a “finger target” for those using mobile devices (touch screen). The largest image is, of course, the full bowser width image at the top of the page. This image has to be carefully chosen to ensure that its focus region (usually the centre) doesn’t disappear as the image is enlarged to fit the browser width.

It should also be noted that there are other browser-width elements, such as the header and the footer region. Although these are full browser width, the elements they contain are fixed positioned. The menu and logo in the header, and the links in the footer, would all be set up to fit within the design width of the site, so they will always be visible. The header should also be a “sticky” header so that the primary site navigation is always available to the visitor.

The links to specific recipes will be to HTML pages within the recipe folder of the site. Again, each recipe page can utilise the same images that have been used as the link within this page. However, instead of being a thumbnail image, the image will be rendered as a header image at a larger size in the relevant recipe page.

Another feature of the page will be the captions under each image. Not only will these provide an additional link to the recipe, they could also contain the name of the contributing chef. The name could then be used as a link to the relevant “Chef’s” page within the site, which in turn will contain additional links to that chef’s recipes in the recipes folder.

And here is the page loaded with images. Although there is quite a lot of information on the page, it still contains that all-important white-space that make web pages functional for the viewer. The addition of image captions will obviously complete the page and make the links to recipes more meaningful.

Essentially, what has been created here is a one page mini-site within our main site structure. If it requires more space to display more recipes, the pages are just extended or new pages added as normal but using a “read-more” or “load-more” link at the bottom of each page.

As long as the person responsible for maintaining this page was supplied with the URL’s of the relevant recipe pages and the associated images, this section of the site could be maintained independently of anything else that may be going on in the rest of the site. All they would have to do is create/edit the page and upload it as a site to it’s own folder within the site structure. The existence of the sticky mega-menu at the top of the page and the site-wide links in the footer, will ensure that site visitors can get to any place in the site from this page without reaching a dead-end.

In this example, the mini-site has been created as a collection of recipes relating to the ingredient “Duck”. It could equally be a page dedicated to a particular chef, the only difference being that it would contain a bio on the chef and links to the chef’s specific recipes. Such a page would be a mini-site created and accessed from the Chefs menu category.

The key is, that ALL recipes, regardless of their category or who may have created them, all reside in one folder named recipes. These can be added to over time without upsetting the structure of the whole site. As recipes are added, the person responsible for creating the mini-sites for collections and chefs would simply be advised of the recipe URL and the url of the appropriate images. They can then get on with updating their little section of the site with the minimum of disruption to the rest of the site.

For the actual recipe pages, we use exactly the same master site layout. The only difference is that instead of using a browser-width image, we use a page width image instead. The reason for this is that these are the pages of the site that may get printed by the site visitor, therefore, we wan’t everything to be contained within the width of the printable page.

In the example page at the right, we’ve maintained the 6 column width of the text box for the method, and utilised the right-most 3 columns of the grid to set out a shopping list of ingredients for the recipe. The side bar has also been retained that may contain other useful information such as a weights and measures conversion chart.

The header, with its sticky menu and the footer have also been retained. Additionally, we’ve added picture links at the foot of the page for other similar recipes that may be of interest.

Just like in the collections pages, the individual recipe pages are created within a dedicated folder as a complete site. This will allow for the creation, editing and uploading of pages without too much interference with the rest of the site structure. Once pages are added to the recipes folder, the URL is sent off to the person responsible for the recipe collection and chef pages of the site so they can make their changes in their own good time. Likewise, the recipe images are uploaded to the sites images folder so that the image may be included by all those making changes to the site’s pages.

Finishing

Touches To make the site really useful, we can add an ingredients section. This will be another mini-site of smaller pages, each of which will contain an illustration and description of a specific ingredient. These pages will be designed to open in a pop-over when an specific ingredient is clicked on a recipe page shopping list. The page will not need a header or footer, or links to any other pages. It will simply be a pop-over page that opens in a lightbox to show visitors what a particular ingredient looks like and maybe contain some other information such as nutritional data.

These pages can be constructed as a whole site within an ingredients folder. Whenever a new recipe is created, links to its primary ingredients would be created in the shopping list section. If the ingredient doesn’t exists in the site’s ingredients folder, it can be created and added whenever it’s convenient.

Again, the responsibility for maintaining the ingredients site can rest in the hands of a dedicated person. They can make changes to their section of the site all day long and will have very little impact on the functioning of the site as a whole when updates are needed.

Simple

Site Administration Although the purpose of designing a site around folders as opposed to pages is to make it easier to handle when updating, there is still a degree of administrative complexity in ensuring that the site is updated correctly, particularly if there is a team of different people involved with maintaining specific sections of the site. For this reason, you have to have a simplified admin system to ensure nothing gets overlooked.

In our example, the problems can be overcome simply because everything starts with a recipe. When a recipe is first added to the database a simple update docket should be created (illustrated right) that contains all the relevant information. This can be passed to those responsible for maintaining the collections, ingredients and chef folders. All the information they need is included in this small checklist.

This, of course, must be a two-way checklist. For example, if the chef, the collection or ingredient doesn’t exist when the recipe is added, those responsible for maintaining those sections of the site will have to send the checklist back to the recipes person once the relevant URL’s are available so that the recipe page itself can be updated with the relevant links.

Recipe Name Salt Baked Salmon

Recipe URL http://mysite/saltbakedsalmon.html

Contributing Chef Fred Bloggs

Collection Fish

Image URL htpp://mysite/images/saltbakedsalmon.jpg

Ingredient 1http://mysite/ingedients/

salmon.htmlsalmon

Ingredient 2 http://mysite/ingredients/seasalt.html

Ingredient 3

Ingredient 4

Ingredient 5