Rebuilding Vogue.com.au

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 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.