By: David Lewis

May 19th, 2006

Reader Rating: 7.5

The redevelopment of Vogue.com.au [1], the Australian Vogue site, began on 22nd November 2005, following several months of discussions about where the web site should head in the coming years.

The goals of the project were to:

• Simplify day-to-day maintenance of the site. This was achieved by introducing a Content Management System (CMS).
• Improve the user experience. The information architecture and visual design were both improved.
• Create a foundation on which to grow Vogue.com.au. This was provided by the CMS and architected by deploying the site across several domains.

Beyond these main goals, we also had to ensure that any old content that could not be brought over to the new CMS could still be delivered via Vogue.com.au.

Information Architecture

Site Structure

The first step in redesigning Vogue.com.au was to look at the existing site structure. In this analysis, we assessed where new content would be coming from (e.g. which existing sections were growing, and which new sections were coming online), and updated the structure accordingly.

In the past, the process of sourcing content for Vogue.com.au had faced several challenges, including:

• a lack of dedicated editorial staff
• copyright issues with existing content
• concerns about damaging the magazine by reproducing too much content for free

Without a recognised and regular content source, it's difficult to produce a site structure that is complete and doesn't make the site look empty. We also had to be mindful of how much space we had available on the navigation bar, so a finite number of sections had to be agreed upon.

The old site consisted of the following sections:

• Beauty
• Show Coverage
• Events
• Competitions
• Shopping
• Subscribe
• Forums
• Club Vogue
• Street Chic
• Titles

On the old site, the most actively updated sections were Show Coverage, Beauty, Competitions, Titles and Events.

Although Street Chic proved popular, it had been difficult to establish a regular flow of content to that section, given the work involved in finding quality participants.

Shopping was seen as an under-performing area, mainly due to our lack of resources to expand the section. We decided to address this later in the year.

The remaining sections, Forums, Club Vogue, and Subscribe, were seen as being key to the long-term growth of the site. Subscribe is the original revenue source for Vogue.com.au, Forums provided the backbone of the site's traffic, and Club Vogue provides the means to gather information and ensure constant communication with the site's audience.

The new site has all these sections, plus a new section called Fashion Central. To make way for Fashion Central the Street Chic section was merged with People + Parties. Combining it with content from Events will allow us to ensure that the Street Chic section won't appear stale.

As well as this consolidation, the Fashion section was expanded. Show Coverage became a sub-section of Fashion (although it still makes up the majority of the content), which gave us the opportunity to place more types of content into this section. For example, under the old structure, there was no natural place to put the recent "Gemma Ward's Backstage Diaries" content, and as a result it had been stored in the Titles section along with the issue in which the article appeared. Within the new site structure, the content can sit in a sub-section of Fashion and remain there indefinitely.

With these changes, the new site structure looks like this:

• Fashion (incorporating Show Coverage)
• Beauty
• People + Parties (incorporating Events and Street Chic)
• Fashion Central
• Competitions
• Shopping
• Forums
• Club Vogue
• In Vogue (incorporating Titles)
• Subscribe

This site structure was replicated on the CMS as a series of folders, and each folder was then assigned a template to determine the section's layout.

Archives

Under the old site, each section was fronted by a section index that featured the latest content, and had an archive that contained all content for that section.

With the expected increase in content on Vogue.com.au, the site's sections were expanded. The section index has the same purpose, but the new approach we took to structuring the archive has meant that the content is organized into a greater number of sub-sections. For example, the Articles sub-section of Beauty includes the categories of Makeup, Fragrance, Body and so on.

Specific templates are assigned to section indexes. Within sub-sections (e.g. beauty > articles), a "generic folder view" is used to display the contents of the folder. The generic folder view displays basic navigation, search, and a content listing. This allows users of the CMS to create new site sub-sections with just a few mouse clicks.

Content Structure

Under the old Vogue.com.au web site, all the content items were built as independent web pages, each of which had its own style information and markup. Very little data was shared between similar pages.

For the new Vogue.com.au site, the majority of content on the CMS was broken into "classes" from which "objects" can be built (these "objects" can be considered as the page you see online). Each class is associated with its own template -- or templates -- depending on which section is being viewed.

For example, there are many articles on Vogue.com.au (in Beauty, Fashion etc.). Each article is built as an "object" from an "article class". But if you view an article in the Beauty section, you'll notice that it has different formatting and design than an article categorised under Fashion. All that the people managing the site with the CMS have to worry about is a single generic article, as the web site knows how to display the information it is provided. Other classes include Event, Magazine Title and Slide Show.

Accounting for Legacy and Other Content?

In planning the site rebuild, we decided that it wasn't possible to have all content delivered via the CMS. Content that isn't controlled by the CMS includes Show Coverage, Competitions and Shopping. These areas of the site are controlled by independently managed systems, and the task of re-engineering that functionality would have taken us well beyond the project deadline.

The CMS we chose for the site was eZ publish, a PHP-based product that introduced an important restriction: the domain (Vogue.com.au) could not share CMS-managed and non-CMS-managed content. Therefore, content that is not uploaded into eZ publish will not appear on Vogue.com.au, and we weren't able to store traditional web pages in a sub-directory on the Vogue.com.au web server.

While it would have been possible to work around this restriction by installing eZ publish into a folder on the domain and including traditional web pages on that same domain, the Vogue.com.au redevelopment project was part of a larger project that aimed to control multiple web sites from a single installation of eZ Publish, so this potential workaround was ruled out.

The solution was to host non-CMS content on a sub-domain (e.g. http://showcoverage.vogue.com.au) and to create a "redirect" object that would point to non-CMS content. The redirect object contains many of the attributes for other classes on Vogue.com.au (e.g. Title, Description, Thumbnail), but the link to content is replaced with the location of the sub-domain.

New Section: Fashion Central

Fashion Central aims to become the leading resource for people who are looking for information on Australian fashion and beauty. The project was developed to address the company's lack of resources for producing content, and also to provide a service that would support the magazine by offering something that only new media can deliver.

Above: the evolution of Fashion Central from its initial proposal

Essentially, Fashion Central is a greatly enhanced version of the original site's "recommended web sites" page. It has been developed to hold two types of information:

1. profiles about people


2. information about companies

Sometimes, these items are linked together when there is a close relationship (e.g. linking a fashion designer to a fashion label), which effectively provides the user with a short-cut to related information.

This section of the web site will grow to become the foundation for every other section on Vogue.com.au. In six months' time, users will be able to view the latest Australian fashion shows, and if they like the designer's work, they'll be able to read about that person's history (in the associated Fashion Central profile) and find out where the label's stockists are located (via their Fashion Central fashion label information page).

New Section: Cover Archive - coming later in 2006

The Cover Archive is going to be a section of Vogue.com.au that allows users to view every cover (where possible) of the magazines Vogue Australia, Vogue Living, Vogue Entertaining + Travel, GQ Australia and Vogue Girl. The covers will be presented at a resolution that's high enough to allow users to read all the cover lines. For each magazine featured in the Cover Archive, a brief overview of the contents of that magazine will also be provided.

This was designed to be a section that we can add to on a regular basis, and requires minimal extra work once the full archive is established. When a new magazine is released, the information for the previous magazine is moved to the Cover Archive. The CMS automatically reformats that page so that it can be delivered via the Cover Archive -- there's no need for staff to add extra information or edit any of the document's details other than its location.

This was a similar project to Fashion Central in that it has been developed to overcome content production problems, and provides extra support for the rest of the web site. When an article is sourced from a previous issue of Vogue Australia, a link will be provided to the overview of that issue in the Cover Archive. The long-term plan is to link all references to past issues to that magazine's back issues section.

The Redesign

The most obvious change that has occurred with the redevelopment of Vogue.com.au is its look: sections have been redesigned (e.g. Beauty), navigation has been modified (e.g. tabs), the site is less reliant on pop-ups (e.g. slide shows), and it features increased interactivity (e.g. drop-down search options).

Initially, the scope for this project was to reproduce the web site on a CMS to simplify its day-to-day maintenance.

However, over the course of the project, it became apparent that this plan was flawed. There were too many new pages to allow us to use such a simplistic approach.

At first, we started to design new pages on a needs basis. For example, there was a need to have a "section index" for Titles (now called In Vogue), so a design was produced. However, this approach was also ultimately flawed, as the number of new pages required and the isolated nature of the design process was set to result in a site that would have had major inconsistencies between different sections, and created a less rewarding user experience overall.

The above designs show the inconsistencies of the initial design process

Therefore, we needed to rethink the design of all the major sections of Vogue.com.au with an attempt to make the site appear more consistent and in keeping with the magazine. While we needed to maintain a consistent look across all the sections, we also wanted each section to have its own layout, to avoid giving the sections of Vogue.com.au a generic feel.

The new redesign, which provides a consistent look and feel between different sections

Tabbed Navigation

While the section redesigns were quite major, we also made some subtle changes to the overall navigation on Vogue.com.au. Each section now contains sub-sections, which are represented on the template as tabs. This provides users a quick visual reference that indicates where they're located within Vogue.com.au, and will be especially useful if a user arrives from an external source (for instance, via a link on Google) to a page that's buried deep within the web site.

An example of a tab used in Fashion Central's People sub-section

Re-Code

As you can see, the site redesign process required a lot of work to improve the user experience and adapt the changes we wanted to make to the structure. However, the overall look can be considered an evolution of the previous site, rather than a radical rethink. The same cannot be said for the XHTML code that's used to display the new site.

All the XHTML in the CMS was rewritten from the ground up, and bares no resemblance to the previous site. We're aiming to achieve a high level of standards compliance (eventually XHTML 1.0 Strict) and generate semantic markup to the best of our ability. All layouts are controlled via a collection of Cascading Style Sheets (CSS) that are shared across the entire Vogue.com.au site.

This approach was chosen as it could provide:

• reduced bandwidth usage
• improved search engine exposure
• easier implementation of changes in the future (design and code)
• decreased development time
• more efficient workflow between designers and developers/#eli#

Reduced Bandwidth

This modern approach to markup means that the site's XHTML code is no longer littered with extra tags that are unrelated to the page's structure. In the past, the site used tables for layout. In one example, the following code was used to make the word Vogue appear halfway across the screen.

<table width="100%">  
  <tr>  
     <td width="50%"> </td>  
    <td><p>Vogue</p></td>  
  </tr>  
</table>

That markup would now be replaced with something like this:

<h1>Vogue</h1>

This code would be coupled with style information contained in a separate file. This very simplistic example shows how the markup has been greatly reduced by an approach that stores presentation information in a separate file. This approach, when applied to a typical page on Vogue.com.au, saved around 10 KB. If that page was viewed 1,000,000 times in a month, the reduction in file size would account for a saving of almost 10,000MB of data.

Improved Search Engine Exposure

The markup that's used on all new pages of Vogue.com.au has been rewritten to give the content greater exposure to search engines.

1. Title tags begin with the name of the page that's being viewed, and end with the name of the web site, as search engines give more emphasis to the text at the start of the title.


2. URLs contain keywords related to the content. For example, we have an article about Napoleon Perdis in our Beauty section. The URL for that article is http://www.vogue.com.au/beauty/articles/makeup/napoleon_perdis
   Without viewing the page, you can deduce that it relates to Beauty, Makeup and Napoleon Perdis.


3. Semantic markup is used to help describe and give weight to certain words on the page. For example, an H1 (header1 = high priority) tag appears at the start of each document, featuring the name of the page. We have also made extensive use of lists and document definitions to more accurately describe the content of each page.


4. Image replacement techniques have been used where traditionally we'd have used images and image tags to represent non-standard fonts. This approach is intended to give greater meaning to page content when it's indexed by a search engine.

Easier Implementation of Changes in the Future

By separating content (XHTML) from design (CSS), we're now able to effect changes to basic visual elements on Vogue.com.au, site-wide, within seconds. More fundamental changes can also be made quickly using this approach.

For example, later this year, we plan to expand the width of all pages on the site so that they no longer provide default support for 800x600 browsers. This project will not require us to change any of the XHTML templates used on Vogue.com.au; instead, all changes will be made at the CSS and CMS levels. The reduction of the number of affected areas will greatly reduce the risk of errors occurring as we make this change.

Decreased Development Time

To decrease development time, we created an agreed XHTML specification for the designer and developer to work to. The designer had to implement his design to that XHTML specification, and the developer had to ensure that the back-end delivered a XHTML document to that same specification. This approach completely removed a step in the development process, in which the designer and developer would have spent time combining their work into a single document.

For example, when producing the section index for Beauty, the designer created the layout by working on a CSS file that was linked to a static XHTML document. The developer had the designer's CSS file linked to the template he was building to the same XHTML specification.

When the designer had completed the CSS and the developer finished coding the dynamic XHTML template, the work was 100% complete. As the developer and designer worked simultaneously on the same page, the developer could see his work evolving into the finished page.

Work Flow

One of the original goals for this project was to make it easier for staff members who had basic web skills to be able to quickly upload content onto Vogue.com.au.

In the past, this role had to be filled either by a web designer or developer. The old approach meant we had an over-reliance on key staff members, and created a huge bottleneck in workflow.

With the use of eZ Publish, and the additional purchase of the online editor from the developers of eZ Publish, we now have a means for staff to upload articles, slideshows and other content, without requiring individuals to have any XHTML skills, and only basic Photoshop skills.

As an example, a basic Beauty article can now be produced and published in less than ten minutes from the moment the original Adobe InDesign file is opened. Under the old system, this would have taken at least 40 minutes, sometimes longer.

With this infrastructure in place, we were able to define several user accounts on the CMS to allow various members of the Vogue.com.au team to begin uploading content into each of the sections that were to go live on February 1.

The approach we took meant that we were in a position to do this after only two weeks of development. However, we decided to wait until two weeks prior to the live date so that team members uploading content could get a better view of the content they had uploaded. At two weeks we had the specifications for all content but we only had 20% of the templates viewable.

In the final two weeks of development we had two staff members uploading content, and two members completing back-end/front-end tasks. These roles were all so well defined that there was no need to manually synchronise the work each person was doing. All work came together on the new site as soon as each task was complete.

During the development process, several roles were defined, with some members of the team taking more than one role:

1. Designer


2. HTML Coder


3. CSS Coder


4. Back-end Developer


5. Content Manager


6. Image Editor

Defining the roles in this way, and taking the coding approach we used, helped to prevent team members from becoming overwhelmed by the task at hand, especially given the small team.

Members didn't have to think about the "big picture" on a constant basis and could just concentrate on the task at hand. For example, rather than thinking about producing the entire Beauty section, one member just had to think about producing the XHTML for Beauty irrespective of how the design would look, how the CSS would be written or how the back end would plug into it.

Content Management System

eZ Publish [2] was chosen as our Content Management System because of its great flexibility, excellent support, extensive documentation, and active online community.

WYSIWYG Editing

The eZ publish installation was extended with the addition of the online editor, which provided a WYSIWYG display to users of the CMS. The way the editor is now being used on Vogue.com.au means that page layouts are extremely flexible (e.g. we can use an unlimited number of images that can be positioned anywhere on the page).

Remote Working

As the admin area for the site is now hosted on a web server, we no longer require third-party software to maintain the day-to-day running of the site. In practice, this means that when reporters or other content producers are working out of the office, they are less reliant on Vogue's IT department. Vogue.com.au team members can work on the site using any computer with a modern browser.

Multiple Web Sites on one Installation

eZ publish offers many installation options. Our site's base code is installed on a generic domain, and this installation has been configured to allow other domains to point to it. eZ publish is then made aware of the domain from which the user is accessing the site, and displays the corresponding web site (e.g. Vogue.com.au).

In the long term, this same base installation will be used to run other sites. The benefit of this approach is that only one installation of eZ publish is maintained regardless of how many sites it powers. This is crucial for:

• security updates
• software upgrades
• reduced reliance on IT resources
• reduced installation time for new sites

Installing Functionality Across Multiple Sites

One of the most exciting features of eZ publish is that it gives you the ability to develop functionality on a web site, and export this functionality as a "package" to be installed onto another site running eZ publish.

In practice (and depending on testing) this should allow for the development of an interactive feature on a site -- e.g. voting on Vogue.com.au -- to then be installed on another site -- e.g. VogueGirl.com.au. This should reduce the development time of shared features.

Performance

Performance was our biggest concern with using eZ publish. Upon researching the CMS we came across reports from people who found response times sluggish or, worse still, discovered that their entire site would not function once it was swapped to eZ publish.

Further research indicated that these reports were the results of poor software implementation, or poor server configuration. We also looked into benchmarking test that showed that eZ publish could handle over 2.5 million page requestion a month on a very low specification server setup.

Vogue's IT department provided a dedicated front-end server to complement the database server that was already used by http://forums.vogue.com.au. The web server was configured to use Zend optimizer, which is reported to give up to 80% faster delivery of PHP code. The projected performance improvements will be more than enough for the next 12 months, and future hardware improvements will mean that moderate performance upgrades will be straightforward. We are also looking at putting eZ publish into a clustered environment should traffic increase by an unexpected rate over the next few years.

The Old vs The New

The following offers an overview of some of the major differences between the way the site is managed and our previous approach.

Less Human Error

With the implementation of eZ publish onto the Vogue.com.au site, many of the tasks required to run the site were automated. This reduced the amount of errors that could creep onto the public web site.

For example, in the past, if we wanted to promote an article across different sections of the site, the Site Administrator would have to manually re-enter the name, description and thumbnail for that article into each page on which they wanted it to appear. With the new Vogue.com.au, Administrators select a section in which they want an article to appear, and "points" part of that section to the article. The CMS handles the title, description and thumbnail on behalf of the Administrator.

Faster Uploading of Content

Under the old Vogue.com.au each web page had to be created by hand, images loaded into a specific directory, and all relevant pieces of content linked together manually before they were transferred to the production web server where they would appear online immediately.

Under the new system, content is taken straight from the file server (e.g. in Word format), pasted into the CMS, and images are loaded straight into the page, ready for layout. Once the layout is complete, the content is published to the site through the CMS.

Previewing Content Before Publication, and Hiding Content

To preview content on the old site, users had to create a page, upload it to the live web server, and check it before linking it to the rest of the site. Anyone who had access to the URL was able to view the page. To hide a page, staff members had to rename it to a name that the public would not guess, then manually unlink all the references to that page elsewhere on the site.

With the new Vogue.com.au, staff member can go through all the steps of creating content, and then view a preview of it. At no time through this process is this content available for the public to view. They can hide content that's live by selecting "hide" from that object's properties in the CMS. Once the content's hidden, all references to that content object are also hidden, meaning that no manual unlinking is required, and no broken links occur.

Content Versioning

The old Vogue.com.au site gave us no way to keep track of the changes made to a document. If staff members uploaded an article, then amended it, and later found out that the amendment was incorrect and the document should not have been edited, their only option was to source the original material and recreate the content from that.

On the new site, all document changes are recorded as "versions". When staff members edit a page (object), a new "version" is created, containing all the changes they made. Now, if we need to rollback content, we simply call upon a previous version of the document and republish it.

Multiple Image Upload and Dynamic Resizing

On the old site, resizing images and transferring them to the web server (as a zip file) was a manual process. On the new site, this is performed within the CMS, which also provides team members complete freedom to resize the images to the required size.

The new site also allows the order of images' appearance on the page, and their captions, to be sourced from the images' file names. So, "01 Vogue Photo.jpg" would, by convention, appear first, and be given the name "Vogue Photo".

Launching the Site

4pm on February 1st 2006 was the final deadline for the launch of phase one of the new Vogue.com.au site. The time came, and the team had completed all the tasks necessary to make the switch.

Even though we were keen to keep downtime to a minimum, we had allowed two hours to make all necessary changes. The biggest difference between this project and building a new site is that, in this case, there were many separate systems that could have been affected by the changeover.

We had to make modifications to our Show Coverage, mailing lists, Forums, and Competitions. We needed approximately 30 minutes to switch over, test and make live all these independent systems.

The final switchover for the main site was handled via a change in DNS entry from the old server to the new. This ensured that no unexpected environmental changes occurred.

Overall, the launch process was smooth aside from a small hiccup in the implementation of shared images and style sheets, which caused an unexpected drain in resources on the main web server. Once this problem was isolated and fixed, the new site was fully functional by 5:30pm.

Conclusions

Having more people trained to use the CMS has already made a huge difference to content on the site. We can now update content daily with little effort, and over 50 new beauty companies have been uploaded information into Fashion Central.

Having the site built on XHTML + CSS has allowed us to make widespread changes in a matter of seconds. For example, after we launched the site, we needed to give the text on all the tabs a slightly higher level of contrast. One line of code was adjusted and every tab on Vogue.com.au received the increased contrast. This is just one example of many of the major benefits that are anticipated from this thorough rebuild.

[1] http://www.vogue.com.au
[2] http://www.ez.no