Tag Archives: navigation

Content Complexity vs Navigational Complexity

The dream job of any designer is one that gives the flexibility to design a product exactly the way the designer wants it. The best-case scenario is where the designer’s vision matches what the users want. Users may not want pretty user interfaces and this is where designers need to learn to tame the designer ego.

Designers, on the whole, deal with a whole lot of constraints other than just ego. Even beautiful products such as the Macbook is constrained by cost and availability of materials.

In MOE, the main constraint to designing great online communication lies in the heart of defining what good communication is. For the most part, users I’ve had the privilege of polling would like information presented clearly and plainly. We have tried our best to do that whenever possible. They want unambiguous instructions to facilitate their decision making process.

From MOE’s point of view, clear communications means a slightly different thing. Information and instructions should address the myriad of possible user scenarios down to the smallest minority cases. A lot of the time, this is the reason behind extremely long and convoluted instructions which end up doing a poor job of communicating to anyone with less patience than Mother Teresa herself.

Our mistake here is in believing that the addressing of all scenarios ought to be contained within the copy. The correct application should be to put the burden of sorting out user scenarios on navigation. So rather than reading 30 paragraphs of instructions trying to find out which paragraphs apply to you, the website ought to allow you to navigate to a webpage containing information pertaining to your specific needs; and on that page instructions should be written in simple, easy-to-understand language.

The balance of navigational and content complexity is something we’ll always have to grapple with.


Non-javascript Navigation

We finally solved the navigation problem. Though the number of users who have CSS-enabled but javascript disabled is small, untangling this dead-end was a priority for us because it is one of the basic guidelines for good accessibility.

The Solution

The current navigation needed javascript to function, so we wrapped a <script> tag around it and had it generated via a document.write. We added a <noscript> underneath it that called a server-side include for a non-javascript version of the navigation. Clicking on the roles without javascript enabled now brings you to separate websites housing the links you’d get from the slidedown menu.

It took a while to shift pieces of code for reusability’s sake, but I’m glad we got this out of the way.

Around the block

It’s been a little less than 3 weeks since we launched, and feedback regarding the new site design has slowly died down as people settled in.

We’ve had some very committed web developers out there who gave great pointers on what they liked and what they thought could be improved:

We had a few of their suggestions implemented almost immediately.

  1. Choonkeat’s suggestion to use an icon of a lock, rather than the words (login required) beside intranet links in the dropdown menu under “Teachers”.
  2. Choonkeat’s request for rss/atom (implemented in Media Centre).
  3. Vinay’s suggestion for custom 404 error pages.
  4. Vinay’s suggestion to make the masthead narrower (we made the skip navigation link a little less visually obtrusive)
  5. Vinay’s observation that feedback forms administered via iframe could lose the submit buttons on larger text sizes (we went back and set the height of the iframe in ems so it would scale)

No Javascript, no navigation

The most glaring bug at this point is the sliding navigation we used which doesn’t degrade gracefully when javascript is turned off. If you have any ideas, please do leave a comment. We could definitely use some good ones.

The sliding navigation

The implementation of the navigation has a whole didn’t sit too well with the tech-savvy. Yuhui is absolutely correct when he points to the fact that the links being flushed left after dropdown meant users needed to move their mouse quite a distance. Quite a number of people commented that a fast trigger-happy index finger could drive the script crazy and break the navigation. Sliding down takes time, which sacrifices efficiency for flashiness.

All of these are great comments, and we’re definitely looking into ways we could improve the interactivity. We originally had the menu appear instantaneously when users click on the “Students” or “Teachers” link, and the feedback we had from some users back in beta was that they were disoriented. So we thought a little animation would guide them from pre-click state to post-click state.

Jekyll and Hyde Information Structure

Yuhui and Divya both commented that there was some disconnect in the breadcrumbs and the top navigation. When you clicked on something like “Student Admissions“, the breadcrumb would say “Home > Education System > Student Admissions” when in fact you came from clicking the “Parents” navigation.

When we first constructed the information structure, we created intuitive silos to store information. Silos like “Education System” and “Careers” were set up to store information which existed in any one silo at a time. However we also understood that our users were segregated into a few main roles, which you see on the top navigation. These different roles often need the same information. For example, both Parents and Students were probably interested in “Student Admissions”.

So rather than have crumbtrails denoting the users point of entry, we set the crumbtrails to introduce the formal information structure in a macro to micro sort of filter.


The greatest reward we received from revamping the entire site in-house was the freedom and degree of control we now have over the site. We can now react to feedback given by our users almost instantaneously. The previous iteration of the site was locked down in a gargantuan content-management system in a format readable only by the vendor. This made changes extremely hard to implement and we often had to shrug our shoulders when we couldn’t find workarounds.

So if you have any feedback regarding what could be improved, or even if you’d like to tell us that you really liked what we did, do feel free to drop a comment here.