Project Description

Redesign of www.loeuf.com

Role

Design & Front-End Development

Project Type

Website - architecture design portfolio

Team

Jessica Dan, Eliane Billon

Designing for L'OEUF

The previous website for L’OEUF reflected neither the energy nor the ethos of the firm, and they never updated it because of complications with the existing CMS interface. A complete redesign of the website was needed, one that would both immediately engage the visitor and showcase the wide variety of projects that L’OEUF worked on. The intention was to not only show that they design great architecture, but that they do research and consultation as well. Their architecture spans many different sectors: affordable housing, commercial, institutional - just to name a few. The current website endeavours to convey the richness and depth of their architecture, while creating a user experience that makes it easy to navigate between these categories of work.

L’OEUF stands for « L’Office d’Éclectisme et Urbanisme Fonctionnel » which is quite a mouthful, but does reflect the complexity and depth of their diverse portfolio. Their website needed to do this too.

Before

website before

After

website after

Choosing a CMS

Before getting into the design of the website, I did a study to determine if switching the CMS (Content Management System) was the right idea. Understandably, they wanted a website that they could update on their own as projects moved forward or when they had news to announce. The website at the time had been designed in Drupal and set up so that they could update it, but it seemed as if this was a frustrating process and did not happen very often. I had some experience with Wordpress, and knew that it had a very user-friendly interface. On the other hand, switching interfaces would require transferring all of the information currently in the database: a potentially time-consuming process. To make the final decision, I sat down and researched Drupal to understand the requirements for me as both a designer and front-end developer of the website.

The most important step of the process was speaking to the employee at the office who was currently responsible for maintaining the website.

I sat down with her to go over what the process of updating the website in Drupal was like, and then pulled up a sample website in Wordpress and ran through the dashboard with her. Ultimately, we agreed that it made sense to switch to Wordpress.

Project Mosaic: The Starting Point

The starting point for the design was the client’s desire for their architecture to be the first thing you see when you visit the website. The previous website did not immediately sell their work, it took a few clicks to get to a project and see photos or graphics - and architecture is ultimately a visual product. On the other hand, having a front splash page with a rotating featured image didn’t seem like the appropriate response in this case either - the categorization and the diversity of the projects was quite important. L’OEUF stood for eclecticism - so a mosaic of their work seemed the most appropriate.

I discovered David deSandro’s Isotope and was sold. Isotope has a masonry mode - easy to sell a group of architects on that terminology - and it perfectly reflected the mosaic idea. Not only that, but it allows the user to categorize the projects without ever leaving the front page. This was very important conceptually, the desire to keep the visitor engaged on the very first page and get them where they want to go. The other thing that excited us was, of course, the animations. It makes the website fun, engaging the visitor to play.

project mosaic

Website Layout: The Fundamentals

The next step was figuring out the skeleton of the website - locating the items that would persist throughout the website : the logo, navigation bar, language toggle, and search bar.

layout options

Front Page: Design Iterations

Eliane, a summer intern, and I worked in Photoshop to rapidly develop design iterations that evaluated the possibilities for the website layout. The easy decisions were locating the logo, the language toggle, and the search bar. We went with established convention and placed the logo in the upper-left hand corner of the screen and the search bar and language toggle in the upper-right hand corner. The challenge was the navigation bar - we were asking a lot of it, and there was a lot of inherent complexity with the desired categorization, and it had to work fluidly between different pages on the site. We played around with different variants: a cloud of text at the top, a left-hand sidebar that expanded into two columns, and even menus that could be dragged and dropped on the page. We ultimately decided on a single column left-hand sidebar - as it gave us the most flexibility throughout the site.

Front page iterations

Project Pages: Design Iterations

While we worked out these navigation bar variations on the main page, we also evaluated how it would flow on the content pages. The navigation bar is persistent on the site, showing the visitor where they are. For the layout of the project pages, we opted for a picture slideshow front and center. We thought it was important the visitor should be able to see the images as clearly as possible, so the image carousel can be clicked to open a larger pop-up slideshow. We also studied the location of the project data box and added in toggle options for large areas of text.

Project page iterations

Final project page layout

Challenges as a Developer

One of the most important aspects was that the navigation bar would work fluidly within the site - we wanted the navigation bar to show these breadcrumbs but also allow a quick way back to the main mosaic. This definitely made the most sense as an intuitive user interface, but ended up being quite a challenge to me as I developed the code. I consulted StackOverflow and Isotope’s GitHub and was able to develop a workaround to feed the information back into the Isotope on the main page.

// Set cookie based on filter selector

$(‘#cookieoptions a’).click(function(){
  var selector = $(this).attr(‘data-filter’);
  $.cookie(“listfilter”, selector, { path: ‘/’ });
});

if ( $.cookie(‘titles’)===’on’ ) {
  $(‘div.view-first’).addClass(‘hover’);
  $(‘a#turn-on’).addClass(‘active-page’);
}

else {
  $(‘div.view-first’).removeClass(‘hover’);
  $(‘a#turn-on’).removeClass(‘active-page’);
}

$(‘a#turn-on’).toggle(function(){
  $(‘div.view-first’).addClass(‘hover’);
  $(this).addClass(‘active-page’);
  $.cookie(“titles”, “on”);
},
function() {
  $(‘div.view-first’).removeClass(‘hover’);
  $(this).removeClass(‘active-page’);
  $.cookie(“titles”, “off”);
});
              

One of the other challenges was the functionality and graphical representation of the navigation bar categories as togglable links. Since we wanted the visitor to be able to select multiple categories at once. Functionally, the options could not be links or buttons - they had to be a checkboxes. However, we felt that the presentation of checkboxes could present a cognitive challenge to the visitor and wanted them to appear as links in a navigation bar. I implemented a workaround using the jQuery UI buttonset widget to get the checkboxes to appear as links.

The other challenge was that the inherent functionality of the checkboxes was to work as an “or” filter. This would mean that when you clicked the “residential” and “built” categories it would show you everything that was residential, and everything that was built. What we wanted was the Isotope to only show you projects that are both residential and built.

Collaborating on GitHub

Updating the Website

There was a good database of the projects that were already on the website, but there was still work to be done with adding new projects and adding more information to existing projects. Some of this information was stored as “institutional knowledge” so I created a spreadsheet so I could keep track of progress and know which of the firm’s partners could point me in the right direction and would ultimately approve the presentation of the project on the website. The Excel spreadsheet presented below shows this workflow.

Snippet of the project database in Excel

Helping Others Update the Website

One of the biggest hurdles with portfolio websites for offices is that they tend to not get updated very frequently because the person that designed and developed the website is usually not the one maintaining the website. One of the things I kept in mind as designing and developing the website was making sure that anything in the backend was easy to operate, bilingual, and intuitive. Wordpress is inherently like this, but I added in a good number of custom post types, custom fields, and shortcodes to customize the experience. I created a website user manual that explained all of the parts of the website and where to edit them.

Excerpts from the website manual