Jeroen Coumans's blog

Drupal user account pages

Jeroen Coumans — Thu, 09 Oct 2008 06:10:09 +0000

It’s the little things that count…

On a default Drupal installation, the user account could really use some love and attention. There are a number of predefined pages to allow users to register themselves on the website, but the usability of these pages is pretty bad. This post is about one little example: they all share the same title. I’m going to show you how you can fix that.

Have a look at the drupal.org register, log in and request new password pages. You’ll note that each one has a head title of “User account | drupal.org”, and a page title of “User account”. While each page certainly has a different function, why would they all have the same titles? That’s just weird and plain bad usability – a page title should be descriptive of the main function of a page.

Anyway, there are ways to override that. Drupal uses a placeholder variable to dynamically determine the page and head title based on the internal path. In your theme, you’ll find something like the following:

<title><?php print $head_title ?></title>

And:

<h1><?php print $title ?></h1>

Since Drupal determines its context based on the path that is requested, simply checking for the arguments which are passed to the page is enough.


<h1><?php 
if (arg(0)  'user' && arg(1)  'register') :
  print t('Create new account');
elseif (arg(0)  'user' && arg(1)  'password') :
  print t('Request new password');
elseif (arg(0)  'user' && arg(1)  'login') :
  print t('Log in');
elseif (arg(0)  'user' && arg(1)  '') :
  print t('Log in');
else:
  print $title;
endif; 
?></h1>

It’s really simple PHP, checking for the first and second arguments (arg(0) and arg(1)). Note that instead of printing out the text, it’s wrapped in the t function, which will make it translatable. That way, you don’t have to edit the theme in order to translate your texts afterwards.
As you can see, there are two checks for the login page. That’s because both the user and the user/login pages present a login page, and the Drupal menu that is presented on the account pages defaults to the user page. So we have to check if the second argument is empty, and if it’s not, print the title of the login page. If we didn’t add that extra check, we’d have overridden the default user account pages, which all follow the form user/uid, where uid is the numerical id of the user.

Just adding the same checks to the <head> title will suffice to change it there as well. Full credit goes to the Drupal community, as this snippet is based on drupal.org. You can see it in action on the new CJP website: login, register and forgot password.

Thesis abstract

Jeroen Coumans — Fri, 21 Mar 2008 19:25:30 +0000

An average human being is capable of keeping approximately 6 items in his short-term memory. Then why do we still think it’s natural that websites present us dozens, or even hundreds, of links to navigate through them?

According to Jakob Nielsen, navigation on the web is often overdone: there are too many links on a page. His research shows that users ignore navigation area’s and dive straight into the content area. Despite the growing importance of disciplines such as information architecture and usability research, or the use of design patterns and content management systems in the website development process, navigation is still fundamentally based on clicking links in lists. Let’s not forget that the Web as medium is still very young: “I think the Internet is still on Day One… You can’t predict some of the really big changes. Who would have said that the development of the automobile would have led to suburbia?” (Jeff Bezos, Amazon CEO). So there is still plenty of opportunity for experiments with new interfaces to make information accessible. That is also the purpose of this thesis. Through a design research, this thesis will focus on exploring different concepts of website navigation.

To escape the confines of current ideas of ‘navigation’, this research will try to come up with different metaphors for navigation by doing user research in the form of a narrative enquiry. An example of an often used metaphor is the word ‘menu’, which relates the choice of a webpage with the choice of a dish in a restaurant. What other metaphors are conceivable, and what interaction concepts can be designed around them? This will be the central theme of the first part of the research.

Then the state of the art of user interfaces and interaction design will be examined to determine what concepts may be usable to create alternative forms of website navigation. For example, the concept of the Zoomable User Interface (ZUI) is based on distance: the further away an item is, the smaller it appears. Full details are visible when something is ‘zoomed in’. This is very effectively used on Google Maps. Another example is the Textual User Interface (TUI), which is language-based and works by giving commands to the computer. Thanks to its speed and extensibility, this is a very powerful interaction mechanism. Although it may seem like nothing new, as command prompts are as old as the ’70’s, these principles are rarely used on websites, with search interfaces as the proverbial exception to the rule.

The result of these and other experiments will be a series of paper prototypes, wireframes, design mockups and proof of concepts. These will be analysed from a qualitative point of view with user research, and documented through thick descriptions. Of course, I will publish my results here in my journal as much as possible.

A write-up of the creation of the thesis image can be found in my portfolio.

Identity management

Jeroen Coumans — Mon, 03 Mar 2008 16:56:47 +0000

As the World Wide Web continues to evolve, people use it for increasingly personal and social purposes. The current social networking sites are quickly gaining critical mass, moving the adoption curve forward from an early majority to the late majority. In the Netherlands, Internet usage in is still rising, and the skills of surfers continue to improve. According to the Dutch bureau of statistics CBS, more than 2 million people have designed a webpage.
As we put more of ourselves online, our identity expressions become more and more shattered throughout the web. Facebook, Flickr, Last.fm and Hyves all represent a small piece of me and my online identity. Bringing these all together will take a couple of years, although with developments like OpenSocial, OpenAuth and OpenID the first building blocks are in the pipelines.

Anyway, the whole reason of this introduction is that I’ve made a small step in consolidating my Web presence – I have now merged my portfolio into my blog. I really liked the design of my portfolio so I tried to keep as many aspects of it as possible, and only made small tweaks as necessary (although there are many of them…). There are some big improvements to the design though, mostly fixing mistakes from my last redesign.

First of all is a return of a navigation block at the top of the page. Since the previous incarnation only had two really big sections (the blog and the links), I didn’t see a need for a permanent navigation block. But it’s back with a vengeance, sporting a shiny jQuery-powered rollover effect.

The journal itself now boasts 10 entries again. This means more scrolling, but less paging, which is a Good Thing. This is more conform the Mullet-style layout I originally intended for the journal.

My elsewhere section, where I aggregate all my favorite website links, has dramatically improved thanks to the use of a four-column grid design. It’s one of those improvements that seem so obvious in rertospect that I wonder why I didn’t come up with it sooner. I’ve also increased the item count to 100, which is quite hefty, but very manageable. I found myself getting caught up browsing through my old links again, re-discovering old gems!

Thanks to the power of Drupal, I’m able to organize my portfolio in some pretty cool ways. Using the taxonomy module, every portfolio item is tagged with the medium or technology in which it is created. With the books module I created 5 distinct sections through which you can browse: my current freelance work, C-MD work, Solide work, print, and my early art work. For the landingspage I decided to use large thumbnails, giving an immediate (and for some, sufficient) idea of my work. Clicking on the images shows a larger version in a lightbox, while clicking the title or the casestudy link will take you to the permanent link of a portfolio page.

Getting this all to work in Drupal the way I wanted to involved some heavy themeing work, which I’d be happy to write up if anyone’s interested. Unfortunately, there were quite some places where I couldn’t override a theme function or manipulate Drupal’s HTML output (I’m looking at you, Views module), and it was time-consuming to find the proper way to handle these cases. I resorted to manipulating the DOM with jQuery to fix some annoying bugs.

I made no effort whatsoever to get this working in Internet Explorer 6. I don’t intend to either, unless anyone has compelling arguments otherwise. Less than 4% of my visitors uses Internet Explorer 6, which is such an insignificant amount that it doesn’t warrant the extra development time and headaches.

We feel fine

Jeroen Coumans — Tue, 08 Jan 2008 10:23:13 +0000

Did you know that people are happiest in Hawaii and saddest in Singapore? And that people feel most sexy in Las Vegas? We Feel Fine is an art experiment that has collected allmost 10 million feelings from 2 million people around the world and has built a unique interface to dive into this data. The project of internet artist Jonathon Harris and Googler Sepandar Kamvar has been harvesting the expressions of human feelings from a large number of weblogs. The system searches occurences of the phrases “I feel” and “I am feeling”, and stores these in a database. It also extracts additional metadata, such as age, gender, geographical location and even weather conditions.

The interface is a thing of beauty in itself.

The interface to this data is a self-organizing particle system, where each particle represents a single feeling posted by a single individual. The particles’ properties – color, size, shape, opacity – indicate the nature of the feeling inside, and any particle can be clicked to reveal the full sentence or photograph it contains. The particles careen wildly around the screen until asked to self-organize along any number of axes, expressing various pictures of human emotion. We Feel Fine paints these pictures in six formal movements titled: Madness, Murmurs, Montage, Mobs, Metrics, and Mounds. (http://wefeelfine.org/mission.html)

Panel

At the top of the screen, there are the various attributes that function as advanced search parameters. These allow you to answer questions such as “How are women in the ages of 20-29 feeling on a rainy day in New York”? The top bar always shows the currently selected parameters, and hovering over it will open up the selection panel.

The navigation metaphor is based on movements that can be selected by scroll ingover the heart at the bottom left corner of the applet and clicking on the desired movement. In essence, each movement is a separate visualisation on a selection of the data.

Madness

The default movement, Madness, displays all particles shooting around the screen wildly until one is clicked, after which it reveals its content.

Murmurs

The Murmurs movement displays a scrolling list of the selected feelings.

Montage

The Montage view loads all images in a mosaic. Effectively, it shows you how a feeling “looks” like. Photographs can be clicked to zoom, revealing the associated sentence and author information.

Mobs

The Mobs view reveals the statistical patterns in the chosed queries. It shows the most common metrics from each of the feeling, gender, age, weather and location attributes.

Metrics

The Metrics views shows statistical anomalies of the various attributes, the traits that best distinguish the chosen query from the global average. Like the Mobs view, Metrics is divided in five axes.

Mounds

The last view, Mounds, shows every feeling in the database, scaled and sorted in order of frequency. A small horizontal scrollbar can be used to traverse the complete database.

In all of the movements views, the particles content is revealed by it’s size, shape and color. The top 200 feelings are manually assigned colors that roughly correspond to the feeling (e.g. happy is bright, sad is dark).

The end result is a fascinating look into the anonymized public feelings of people all over the world. People’s most private feelings are public at the same time, particular while global, acquiring new meanings by being remixed into a large lump of similar data, becoming small and large pieces of customizable, collective art works.

It’s interaction design is also very refreshing. Instead of opting for your standard search queries, Jonathan has created a beautiful, animated, organic interface which reacts to your every movement, making it feel very lively and yet unobtrusive. Every time I open the applet, I feel myself drawn to all the floating particles, endlessly combining options and diving deeper. This is without a doubt a very addictive, playful interface which is at the same time very efficient at unlocking the power of the underlying database. It’s not very intuitive and definitely requires some instructions or learning before opening it, but it’s a small learning curve and is well worth the trouble.

The interface is built as a Java applet, and all visualisations are done via the Open Source Processing scripting language. While the applet is obviously the most important aspect, the creators also added some social features. There’s a gallery which allows you to save interesting images and send them by mail. It also shows the most sent, most saved and featured “montages” as they’re called, and thus provides a sort of best-of.

Last but not least, We Feel Fine also provides an API, which allows you to build query its database and build mash-ups. Strangely enough, the first mashup has yet to appear, as a quick search yielded no results.

Other sources

There’s an interesting interview with Jonathan Harris on the efforts and thougths that went into We Feel Fine, and the rationale between the particle system, which is the metaphor behind most of the movements. Also, don’t miss the excellent presentation Jonathan did at TED: Jonathan Harris: The Web’s secret storie, which gives a very nice overview of the complete application and the philosophy behind it.

Do you use personas?

Jeroen Coumans — Wed, 07 Nov 2007 17:35:19 +0000

37signals state that they don’t use personas because:

“We use ourselves. I believe personas lead to a false sense of understanding at the deepest, most critical levels.”

Personas are poor substitutes for real people, they argue, and you should always base your decisions on the problems and behaviour of real people instead of passive abstractions of people. This reasoning fits perfectly with their “getting real” process, which argues for a very agile development process.

It’s an interesting point, but this doesn’t mean that personas are therefore useless. Of course, personas should never be used as stand-ins for actual users, and thus can never provide the feedback that real people provide – it’s impossible to do usability testing with them!. Rather, they’re a heuristic tool to contextualise your design problems. Personas allow you to frame your design in a way that puts the goals of real people at the epicenter of your interface. By making personas an integral part of the story that your design tells, they become a common ground for all involved parties, stakeholders, developers, designers, managers.

Personas should be based on proper, qualitative user research. The data can come from various sources, eg. interviews, discourse analysis, observations, surveys etc. The analysis is actually the hardest part, since it’s very difficult to step outside your own frame of mind when trying to really understand people’s behaviours. The ethnographic techniques can be learned quite easily, but the proper understanding of the methodology and the required reflective use of it makes it a very difficult task without academic education.

Clay Spinuzzi’s observation that designers often frame themselves as ‘heroes’ to rescue the poor ‘users’ is a perfect example of designers executing a naive, superficial user research. But the solution is not to use yourself as the intended user of your application, unless you’re building a product which is only meant to be used by yourself. Doing the proper research and crafting personas and scenarios are a good first step in designing not just for yourself. However, even 37signals can’t be as arrogant as to presume they’re representative for all the possible people that their products intend to reach. As with any tool or methodology, using it without proper understanding ultimately leads to failure, but that shouldn’t be a reason to dismiss the tool completely.

Edit 18/11/07: Other people weigh in as well.

Jared Spool makes a similair point on the difference between crappy personas vs. robust personas
Boxes and Arrows publishes a timely article on building a data-backed persona

Andy Budd chips in with a post on rethoric sensationalism

WYSIWYG editor usability tip

Jeroen Coumans — Wed, 19 Sep 2007 13:29:58 +0000

Open Source WYSIWYG editing in CMS still sucks, but with developments like the WYMeditor (“What You Mean” editor, built on jQuery) the situations is improving steadily. This editor lets content writers focus on the structure of their document instead of visual layout. As you can see, this editor provides subtle clues about the type of content you’re currently editing with a clever stylesheet. Unfortunately, the WYMeditor is still in early beta, and Drupal’s module lags a couple of versions behind.

Until it’s finished though, it’s very use to use the WYMEditor stylesheet in your current editor (I mostly recommend FCKEditor in a stripped configuration, but TinyMCE works just as well). The stylesheet used by WYMEditor makes it very clear wether you’re editing a block level element or an inline element. It adds little icons to signify the semantics of the elements. This makes it very easy to determine if there are any stray headers or paragraphs in your content, a problem that often occurs after copious editing but that is nearly impossible to fix without editing the source code.

Using this stylesheet in your own editor is very easy. Just download a copy of WYMeditor, extract it and copy the entire contents of the iframe/default/ directory to a speficic location on your webserver. In FCKEditor, you can edit the file fckeditor/fckconfig.js and edit line 32, which states:

FCKConfig.EditorAreaCSS = FCKConfig.BasePath + 'css/fck_editorarea.css' ;

The last part (css/fck_editorarea.css) points to the location of the CSS used by FCKEditor’s textarea. Adjust it to reflect the location of WYMeditor’s CSS file, which is called wymiframe.css.

Note that it’s not necessary to manually adjust this file if you use the Drupal module for FCKEditor. Just go to admin/settings/fckeditor and put the location of wymiframe.css in the Custom stylesheet field, like this:

That’s it! Happy editing!

LUX Arthouse

Jeroen Coumans — Wed, 19 Sep 2007 12:15:54 +0000

Lux is one of the biggest Art houses in the Netherlands. It’s a home for international cinema, theater, music, debate, multimedia and visual culture. Their old website was based on ancient code (frames!) and design and was manageable by just one person. For their new website, Lux decided to go with Drupal instead and brought in the help of Webschuur, Guruburu and myself. Under visual direction of design and communication agency Wunderbar, I translated their Photoshop mockups to the Drupal theme you currently see.

There were several challenges with this theme. I tried to set up all styles as generic as possible, selectively overriding Drupal’s core stylesheets. This is always a challenge, since there is just too much CSS delivered out of the box with Drupal. My first instinct is to turn this all off to have a minimal, stable base to work on. Along the way, I enabled them so the admin pages would still be accessible and manageable under the new theme.

Lux has 4 main sections that each have a distinct visual theme. This was accomplished by configuring each section with its own body class, and using this class in the stylesheet to override colors and backgrounds. I used as much CSS sprites as possible to keep HTTP downloads to a minimum, which allows for a speedy website, especially with Drupal’s caching.

A lot of effort went into making sure the website was coded with semantics and accessibility in mind. We had the explicit task to make the Lux website as searchengine-friendly as possible and to adhere to the Dutch Web Richtlijnen, which are set of guidelines based on the W3C standards and international best practices. So the HTML structure and the ordering of information is intended to be as useful as possible; with the main content at the top (just below the branding), and navigation all at the bottom. All content chuncks were semantically marked up according to Andy Clarke’s proposed identifiers which he presented in transcending CSS, and using the names of new elements that are proposed in HTML5 as identifiers.

The final challenge was to come up with a decent system for managing a right sidebar which could be populated with either node-related content (such as on the film pages) or generic content. In Drupal, these two pieces of information are controlled in wildly different parts of the theme, and I had to resort to using variables in order to exclude them from conflicting with each other. Still, this allowed a lot of flexibility in the design of the pages and the views, making variations possible such as two colums, three columns with content-releated sidebar, and three columns with generic content.

Some additional background information from Jaap Stronks, one of the programme developers, on his blog (in Dutch).

Drupal image attach block module

Jeroen Coumans — Fri, 14 Sep 2007 16:28:00 +0000

I recently created several PHP blocks for a Drupal website that made heavy use of the image module and the image_attach module. While the block creation wasn’t very difficult, it was still a process that took me a long night of researching api.drupal.org and fiddling with SQL queries. (It was a great exercise though, since I hadn’t practiced my PHP/MySQL skills since I followed a basic course at C-MD last spring. It’s amazing how much you forget if you don’t keep practicing… )

Anyway, the website I created these blocks for has an extensive product database set-up as custom nodes in Drupal. Besides presenting plain text information on their products, they also wanted to easily maintain their product photo’s, and present them in galleries. To make this possible, I set up the image module. All photographs were imported at once via FTP, and attached to individual product nodes through the image_attach module. This proved to be very useful, since they could attach the same image to various products, e.g. for variants of the same product, and also multiple images to one product.

The challenge was for product pages to display the images in the sidebar. In Drupal, there is a clear seperation between node content and all other content, and they don’t mix very well. So it’s very difficult to display a piece of content in another place on your website without resorting to hacks or writing checks in your theme display logic. After Googling for a while, I took it upon myself to write two PHP blocks: one that displayed the attached images to the currently viewed node, and one block that displayed the nodes attached to the currently viewed image. This established the relationship between image and product, and allows users to click through the photo album to products, and vice versa.

Setting up these blocks wasn’t particularly hard with the great example of the hook_block function provided with the Drupal API documentation. With this template, it was mostly a matter of copying the provided code, and filling in the blanks for displaying my own queries. I spent a lot of time investigating Drupal’s query functions, and searching for ways to access node information in a block context. For that, the following snippet proved very handy:


<?php 
if (arg(0) == 'node' && is_numeric(arg(1))) {
  $node = node_load(arg(1));
  // Rest of the code here...
}; ?>

This loads the node object, the concept in Drupal for a content page (as opposed to dynamically generated pages, such as listings of pages). Knowing what piece of content a user is currently viewing is essential for determining if the block needs to do something with it.

While the PHP blocks work great, I decided to go the extra mile and create modules of them. This has numerous advantages. By creating a module, the functionality can be easily deployed on other Drupal installations. For this customer, several localized product databases will be set-up. In a multi-site setup, this will mean that the codebase can be maintained and updated from one codebase. Also, the block can then have it’s own theming, instead of the generic block theming. And it’s possible to define addtional defaults or configuration settings.

I’m sure there are lots of improvements that could be made to this module (and I’d love to hear about them!), but it’s quite usable based on my own tests. I’m not sure if it should have a long live, since it would be perfectly acceptable for the Image module maintainers to integrate this in their own module. Nevertheless, I’ve attached the current code for you to download. Please leave a message if you find it useful, or if you have any suggestions for improvements!

Update: the code is now included in the Image module, thus obseleting this module!

YUI grids extension

Jeroen Coumans — Tue, 11 Sep 2007 16:45:22 +0000

Despite the extra required <div> tags, I regularly use the Yahoo! UI grids framework. This provides several advantages when buidling multi-column layouts with CSS. Besides speedy development and source-order independence, it gives you a lot of flexibility when creating your site. More practically, it's extensively tested in A-grade browsers which includes the ancient, but still widely used Internet Explorer 6). Lastly, they're almost completely driven by classes, which means you can add your own, semantically chosen, id's.

The default widths provided can be used for pixel-precise layouts while maintaining font-size based scaling, but there's one curious thing about the default grids that has always bothered me. For the left sidebar, they provide widths of 160px, 180px and 300px, while for the right sidebar, they provide 180px, 240px and 300px. This asymmetry has bothered me long enough, so I whipped up some code for two additional sidebar configurations: the left 240px sidebar, and the right 160px sidebar.

You should be able to add the following code to any release of the grids.css:


/* yui-t8: 240 on left */
.yui-t8 #yui-main {
  float: right;
  margin-left: -25em;
}

.yui-t8 .yui-b {
  float: left;
  width:18.4608em;
  *width:18.016em;
}

.yui-t8 #yui-main .yui-b {
  margin-left:19.4608em; 
  *margin-left:19.016em;
}

/* yui-t9: 160 on right */

.yui-t9 #yui-main {
  float: left;
  margin-right: -25em; 
}

.yui-t9 .yui-b {
  float:right;
  width:12.3207em;
  *width:12.0106em;
}

.yui-t9 #yui-main .yui-b {
  margin-right: 13.3207em;
   *margin-right:13.0106em;
}

I tested them in the major browsers and it seems to work really well (it would really surprise me if they didn't, since I used the exact same measurements as in .yui-t1 and .yui-t5).

Edupaper

Jeroen Coumans — Thu, 23 Aug 2007 10:24:47 +0000

Edupaper is an innovative company with a green goal: it intends to reduce paper use in education by implementing mobile applications. Using electronic paper will reduce the number of books students need to carry, and in effect reduce the number of trees which have to be cut for books that students. Furthermore, by equipping and connecting them with Open Source Software such as Dokeos, it will enable students to learn more efficiently. Of course, when Frits Hoff, CEO of Edupaper, approached me for designing his website, I gladly accepted.

After a few iterations we finally settled on this design, which I am quite fond of. Since modern electronic paper has such a high resolution and strong backlight, it’s allmost as sharp as regular paper and can still be used outside. To support this communication goal, I focused on the typography, using large corpses for legibility and employing a vertical rhyme. Another goal was to make it as clean and fresh as possible, which I think is achieved very nicely by the use of just a few supportive colours.

The design was built as a Drupal theme. There were some small challenges, mostly in getting the vertical rhyme just right so it would line out with the background stripes. There was a very annoying issue with images seemingly getting a 7px padding in Firefox, which was clearly seen in Firebug, despite that all paddings and margins were explicitly set to 0. To solve this, I resorted to floating all content images, which isn’t very nice but at least they line up properly.

For the logo, I used an alpha-transparent PNG image, since I wanted the background lines to shine through. This meant that a little bit of Javascript had to be used for Internet Explorer 6, which doesn’t support this natively. It was very easy with a jQuery plugin, but unfortunately it required upgrading of Drupal’s jQuery version, which is stuck at 1.0. The Drupal developers decided to stick with the same major version of jQuery so module developers have a stable target to work with, but it makes it so much harder for us theme developers since most plugins available nowadays require version 1.1. Fortunately, the jQuery upgrade module takes care of upgrading Drupal’s Javascript so it works with jQuery 1.1, but it requires you to replace the system jquery.js. This isn’t always feasible, especially in a multi-site installation. But I digress…

All in all, I think the website turned out great, and I’m certain it brings a new level of professionalism and clear communication which will take Edupaper to the next level.