Aller directement à la fin des métadonnées
Aller au début des métadonnées

This page takes a step back from CSS and HTML to look at interface design from a more general level.
I think this video is really useful here:
I wouldn't have thought this is something that could be part of a 2.3 release, at least not fully, but instead see it as the beginning of a framework / shared understanding that helps us maintain coherernce and usability in an interface that does lots of different things.
Would be great to hear your feedback.

The idea of this document is to gather together guidelines for CiviCRM interface design that increase CiviCRM usability by making it more intuitive.

Standard screen layouts and repeated clues help people recognize the available options and possibilities for each screen and let them know where they need to go to peform a particular task.

Using the same principles on each screen means users have to do less learning when they meet that screen.

Design elements

The following are distinct design elements that are useful ways of thinking about constructing screen.  The idea is that for each design element we will construct a set of visual clues that we can employ when creating them.

Depending on the situation and space available, clues can take the forms of icons or CSS styles or both.  Using icons and CSS styles ensures  we can easily globally modifiy each element going foward.

As a rule, the more we can simply these indicators, the more of them we can use, and the more we can convey through our interface.  e.g. if we have a rule that says bold is only used to distinguish field labels, then we know that whenever we see bold it must be a label.  If we use different colors to distinguish different types of CRUD, then we shouldn't also use a differen color for field labels.

These rules already exist to a large extent within CiviCRM.  The idea of this document is to codify them and enable us to best design and improve them.

I've breifly outlined them here.  There might be more to say on each element, and CSS to define discuss.  In which case you could add a child page to discuss that element.

Screen layout

Horizontal screen space is more 'expensive' than vertical screen space - horizontal scrolling is painful for users.  Limiting the number of columns in layouts to either one or two prevents screens from becoming two wide and helps people read the interface - they know everything is in either one or two columns.

Global actions - i.e. actions that should always be visible are also included in this layout as part of a menu and or toolbar

Individual records

Also includes screens that display individual records with their associated records (e.g. an event record and all event attendees, or organization, and related contacts).

Screens for viewing records (like orgs, events, memberships) should closely related to those used in edit records.  Layouts should map as closely as possible.  Should also contain visual clue as to if the user is in view or edit mode.


A broad definition of an action is something you use to help carry out a task (like mailing people, adding people to events, search results, etc.).  Actions appear in lots of places.  You could think of them as 'context sensitive menus'.  It is useful to highlight areas of the screen that lead to particular actions taking place.

A popular subset of actions are CRUD, or at least the CUD of CRUD.  Because they are popular, they should have their own visual design, be related to each other and also distinct from each other.

From the user perspective, there isn't much difference between a link and a form button, an ajax field, etc.  Even though they might be programmed differently, it would be helpful for a user if they were seen to be part of a common actions framework.

Xavier: I'd like to set up a list of icons for the common actions (CRUD), to give visual clue (more precisely, I'd like to have a proper naming scheme, eg class="edit" and let the css add the icons)

Some actions are used much more often that others.  As a general rule "a high percentage of effects in a system are caused by a low percentage of variables" (the 80/20 rule).  To help users we should make the 20% as visible as possible, and keep the 80% hidden.  A common way of doing this is a toolbar (20%) and menu (80%).  Working out what the 20% is is difficult, and changes from client to client.



Used to show more than one record of the same type.

Lists are use to show records meeting a certain criteria, like search results, upcoming events, recent contributions.

Lists can also appear to  show records related to a another record type (like event attendences of a person)

Sometimes it is possible to perform a set of actions on more than one item in a list the same time (either the entire list, or just a few of the items in the list. all items or a sub section).  It would be useful to provide a visual clue for when this is possible.

Summary tables

Summary tables show agregate data, like summaries of recent contributions.  Data in cells does not map to a a specific record, but clicking on a cell is normally possible because a cell represents a certain search criteria.


Used to bring the users attention to major/irreversible changes - often the UD of CRUD.

Xavier: disagree, better to have a undo.


Used to display help, context, references to further reading, and other useful information.

  • Aucun

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.