Getting Org Charts Right

If there’s one diagram that plagues almost every corporate website on earth, it’d have to be the organisational chart. It’s a graphical representation of the corporate hierachy very similar to hierachies present in HTML, yet web designers spend hours searching for the lost photoshop file whenever someone in the organization gets transferred, promoted, or leaves.

I’ve seen 2 common implementations of the org chart:

  1. The ginormous image. Attaching a single image is easy on the html. Most of the work is done in Photoshop where everything is drag and drop. Given that you can’t have all 9 pages of text describing the organizational structure fit into the “alt” attribute, most designers just name it “Organizational Chart”.
  2. The nested table. The web designer that came up with this is a little more prophetic: he knows that photoshop file will invariable get lost, so the org chart is coded in HTML instead. Every element in a cell, all laid with pixel-precision. This org chart is easy to update if someone leaves and is replaced, but is an utter pain to update should the organizational structure change.

There has got to be a better way. But we’ve got to throw some pre-conceived notions out the window first.

The world is flat

Unless you’re working in a traditional Chinese family-run business that saw a bumper crop of children, your organization’s structure is likely to be flat and wide rather than tall. Different levels of hierachy are denoted by their vertical position, befitting of the corporate ladder metaphor. The main problem with this is that the online medium doesn’t do well when forced to grow sideways. Layouts break, horizontal scrollbars appear, floated sidebars get bumped down.

We need to turn the visual model on its side. It’s radical, but radical isn’t necessarily a bad thing. Big boss is flush left, everyone else moves a little to the right. The lower down the position, the greater the distance from the left. The visual cue is kept intact.

Choosing your markup

HTML is full of hierachies. H1 level headers are more important than H2 headers. The obvious choice to markup an org chart would be as a list. But ordered lists, or unordered lists?

Ordered lists provide a fixed hierachy. The first list item in an ordered list is greater than the second. This proves a problem when we have 2 subordinates who are equal in status. An ordered list does not allow us that flexibility.

Unordered lists allow the grouping of elements as equals. But alone the unordered list doesn’t denote any differences in hierachy.

The nesting of unordered lists allow the creation of different levels, while allowing list-elements to exist as equals. In my opinion it is feasible to nest unordered lists inside of an ordered list, explicitly labelling the various levels, but I choose to nest unordered lists as I prefer the less overt structure of power. There is no loss in semantic meaning, the greater wraps around the lesser.

The Office

So this is the scenario we’ll work with:

Jessica is the director of the company. She has 3 assistant directors under her.

The HTML:

	<ul class="org-chart">
		<li>
			<p>Jessica Chan<br />
			Director<br />
			Corporate Communications Division</p>

			<ul>
				<li>
					<p>Hung Lee<br />
					Assistant Director<br />
					Public Communications</p>
				</li>

				<li>
					<p>Shin Ho<br />
					Assistant Director<br />
					Media Relations</p>
				</li>

				<li>
					<p>Sarah Tan<br />
					Assistant Director<br />
					Publicity</p>
				</li>
			</ul>

		</li>
	</ul>

You should have something that looks like:

  • Jessica Chan
    Director
    Corporate Communications Division

    • Hung Lee
      Assistant Director
      Public Communications
    • Shin Ho
      Assistant Director
      Media Relations
    • Sarah Tan
      Assistant Director
      Publicity

More meaning

We could improve on the markup by using the hCard microformat. Names, titles and units can be made distinct from each other rather than pouring everything inside a paragraph tag.

The HTML:

	<ul class="org-chart">
		<li>
			<div class="vcard">
				<div class="fn n">Jessica Chan</div>
				<div class="title">Director</div>
				<div class="organization-unit">Corporate Communications</div>
			</div>

			<ul>
				<li>
					<div class="vcard">
						<div class="fn n">Hung Lee</div>
						<div class="title">Assistant Director</div>
						<div class="organization-unit">Public Communications</div>
					</div>
				</li>

				<li>
					<div class="vcard">
						<div class="fn n">Shin Ho</div>
						<div class="title">Assistant Director</div>
						<div class="organization-unit">Media Relations</div>
					</div>
				</li>

				<li>
					<div class="vcard">
						<div class="fn n">Sarah Tan</div>
						<div class="title">Assistant Director</div>
						<div class="organization-unit">Publicity</div>
					</div>
				</li>
			</ul>

		</li>
	</ul>

Adding microformats won’t change how things look. It’s just about adding specified classes to the relevant bits of information.

Styling it up

So now we have a very simple nested list. If you’re removing all browser-set CSS styles (and you should), you’ll need to style the visual cues that’ll make this nested list look like a proper org chart.

The CSS:

	ul.org-chart li,
	ul.org-chart ul li {
		list-style:none;
	}

	ul.org-chart,
	ul.org-chart ul,
	ul.org-chart ul ul {
		margin:0;
		padding:0;
	}

	ul.org-chart ul li {
		padding:0 0 0 50px;
		margin:0 0 0 50px;
	}

	ul.org-chart li div.vcard {
		padding:15px;
		margin:0;
	}

Until CSS figures out a way to allow us to draw straight lines through our block level elements, the branches will have to be made of good old-fashioned graphics. There are 2 types of branches we’ll need: one for all employees placed under a boss, and a special branch for the last listed subordinate of every level of the hierachy. This is because bosses report to no-one (hence no need for a branch), and the last guy doesn’t need to extend the branch to anyone else.

We’ll also add a class="last" on the last list item element of every list to identify these people.

The CSS:

We’ll need some simple graphics for the branches of the organisational tree. So all list elements get a T-shaped (lying on its side) branch while the last element in the list gets an L-shaped branch to end things off.

	ul.org-chart ul li {
		background:url(org-tree-mid.gif) no-repeat left top;
	}

	ul.org-chart ul li.last {
		background:url(org-tree-last.gif) no-repeat left top;
	}

Throw in some basic type formatting and you’ll have something that looks like the org charts we have on the MOE website (scroll to the bottom of the page).

Tags: , , ,

Advertisements

Accesskeys

One suggestion that came up every now and then was that we could provide accesskeys to improve the accessibility of the MOE website.

After doing the necessary research, there seems to be quite a number of reasons why accesskeys don’t work. Most of these revolve around the fact that browsers have already taken up most “alt-x” combinations for their own shortcuts, and overriding these default behaviours with accesskeys was a step backwards. It is important to note that the inclusion of accesskeys is a convenience, rather than an essential part of making a site accessible. I wasn’t ready to disable browser default shortcuts (already etched into some users’ usage behaviour) to add a little convenience which would be specific only to the MOE website.

A compromise was to include a few accesskeys using alt-number which was for the most part unused by the major browsers. I included accesskey 1 for home, accesskey 2 for skipping navigation and accesskey 9 for feedback on the recommendation from my longtime web hero Mark Pilgrim.

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.

Conclusion

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.