Forum OpenACS Q&A: Icons: let's do it

Posted by Michael Cordova on
I wrote a few months ago about icons in Suggestion: Improve the UI with more images, icons, thumbnails... post. And now, I've got energy enough to retake this issue. I'm not a graphic designer although I've already used very sophisticated image manipulation programs to retouch icons :-P
I'm really interested in improving the UI through icons.

I think we all agree we need to review the current set of icons, and maybe to get a new one. It will be hard to agree what kind of icons, or even harder what style they should be. But my idea is not exactly that, but even more ambitious:

  • where they should be located (package(s))
  • naming convention (files and folders)
  • default dimensions, format (gif/png/svg)
  • how to implement (hard-coded, catalog keys, css)
  • when are they supposed to be used?

I'd like to improve OpenACS in general, and then, dotLRN.

We should also remove old versions and old paths to non-existing files. I don't like icons with text like old "admin", "join", "drop" ones in .LRN. I like those that can synthesize a concept. For instance, simple actions as "new", "add", "remove", "admin", "edit"...

I've been looking in OpenACS forums about icons and that's what I've found (and I'd like to know which is the status of):

I have created a folder "icon sets for OpenACS" inside a multipurpose one called "Multimedia" in file storage. I've also added a few links to some icon sets referenced in other posts. Please, feel free to add more links, or screenshots or whatever image format.

I wouldn't like it falls in deaf ears.

2: Re: Icons: let's do it (response to 1)
Posted by Robert Taylor on

Very exciting. I will updating our mockup design for the new oacs website layout when 5.5 is released so this work is also really great news.

Here are some thoughts:

1. There is nothing wrong with creating all new iconography from scratch. That indeed is probably a wortwhile effort. My personal thinking is that we should simply re-use whatever is already available in the open source world and maybe just modify the colour palettes to match the new zen theme.

The most important feature of re-using existing work is not really the labour saving, but spreading out the labour for creating new iconography as the toolkit capabilites expand. If we choose to re-use iconography from an existing project then we will benefit by having a unified set of design guidelines to follow, not just by us, but by developers to oacs that come after us.

A unique icon set requires design guidelines to also be developed which is an added amount of work, re-using work from an established project allows us to re-use their guidelines and by extension re-use their labour for current and ongoing work.

Of course, they benefit as well from our particapation.

2. Probably the #1 icon project that we should be looking at is the Tango Icon library project at

The goal of this project is to try an offer a unified design guidelines and a icon library that all projects can use. It is primarily aimed at the desktop environment so not all iconography may be applicable but some overlap may exist.

3. The second icon project that we might want to look at is the Oxygen Icon project for kde4 at It is a more up to date look than the Tango project as Tango seems to be very gnome centric and very "blah".

Personally, I think any approach you take will be fine. Tango makes more sense because it's not toolkit/desktop centric while Oxygen is designed for KDE4, but either picking another iconset project or starting from scratch is fine.

Thanks for jumping in on this!


3: Re: Icons: let's do it (response to 1)
Posted by Emmanuelle Raffenne on

It would be worth to join effort and work on a theme manager as the first step towards a real theming feature for openacs.

I've started to investigate theming implementations with that in mind a few weeks ago and wrote those ideas up at the wiki (

Comments are welcome.

4: Re: Icons: let's do it (response to 1)
Posted by Michael Cordova on
I've been working during last months on making custom themes, based on theme-zen, mostly adding client logos on header and footer and institutional colors by css.

I think the most interesting feature of my work is a "transparent color CSS version". Let me explain that: about 5 different png's fading from white to transparent that allows any color as background (set in css). The same image files could be used to get any new color theme (skin), just by setting a new background color.

I want to work with icons to improve usability. For instance, I'd like to use a "grayed" or disabled version of some common icons. Sometimes is better to show the same layout, but not allowing clics, than only showing one enabled icon. And I'd like to use the rollover event. (Emma, don't worry, I have always accessibility issues in my mind).

I wonder how could be the right way to have theme-able icons (or better said, skin-able icons) i.ex. same icons (not necessarily same files) with different backgrounds, depending on the css being used (for instance, to match colors in .LRN communities and so on).

I'd like to have big web2.0 icons, for some cases. But that's another story...

AFAIK about Tango and Oxygen, they are desktop icons, nice for a desktop, but incomplete for web applications. Maybe it's ok for a lot of places in OpenACS, but I still miss a few basic icons.

We could also use the YUI icons (ajax-helper) in order to have a more consistent look&feel just in case some ajax is added (through this framework, of course).

I agree with Robert about whatever is already available in the open source world, I think it's important to establish a design guidelines (reusing a existing one is ok for me).

About the theme-manager is something I was waiting for a long time :) since I started using .LRN. I'm glad to hear about that. If I'm not wrong, it should replace all theme-* packages into a theme-manager one (or acs-themes or maybe acs-theme-manager). What about acs-templating, new-portal, acs-subsite? Those packages have "shared" icons, and a mixture of different functionalities to create the result web page.

Chatting with Dave on IRC about icons, we agreed:

what we REALLY need is a style guide
like Apple or Gnome
we need to have some rules
when are where to use them
along with the theme rules on where the files go, naming conventions for files etc.
so two things 1) UI rules 2) Code rules

And he put a link: but it doesn't work.

5: Re: Icons: let's do it (response to 1)
Posted by Dave Bauer on
Here are the old aD user interface documents
6: Re: Icons: let's do it (response to 1)
Posted by Torben Brosten on
Regarding generating icons, this community has some useful work already available (if only for inspiration):
7: Re: Icons: let's do it (response to 5)
Posted by Michael Cordova on
Really interesting! We should put it in OpenACS wiki.
8: Re: Icons: let's do it (response to 4)
Posted by Emmanuelle Raffenne on
The theme manager won't replace all theme-* packages, at least it's not the initial idea. It will provide a central mechanism to register themes and to choose and apply a theme at subsite and user level (and class/club level in .lrn).

As of packages that have "shared" icons, the idea is that common icons should be defined in a theme and not per package. That doesn't mean that package can't have their specific ones.

Theme manager project has just started so specifics are not defined yet and many questions have no answer yet.

9: Re: Icons: let's do it (response to 8)
Posted by Michael Cordova on
Really nice idea the theme manager. I guess it will take us long to get it finished although it will be time worth.

Meanwhile, I'd like to talk about icons in order to:

  • improve the user experience asap with some icons. What we learn now will be worth when theme-manager was working, I mean, real icons and also techniques to implement them, for instance, css sprites.
  • talk about icons and write a guideline
  • clean current packages from unused icons (files) and/or old paths (in code)
  • define a desired design style