Moved to official ideas list at http://drupal.org/node/237901
Hello everyone! I'm not meaning to spam the group, but I wanted to get out a brain-dump of actually how icons could be implemented in Drupal. yoroy has kick-started the group with a lot of great ideas about creating icons and defining a set of icons that should be included with Drupal. What I've attempted to do is start the complementary part of making icons a part of Drupal: how to actually put them on the page.
Being a Drupal product, we won't settle for having one set of icons. Default icons could actually be quite a hindrance if there were only one set and you had to actually remove/replace all those icons manually every time you created a theme. So instead, we'd like to have "icon packs", an entirely new thing to the Drupal community, on the same level as modules, themes, and theme engines.
Some challenges with icons and Drupal that are hopefully solved by the documents I've outlined:
- Icons are likely to appear both inline in the page markup and included as background images defined in CSS.
- The markup can vary between different themes, making icons placed in CSS difficult.
- New modules will likely introduce new icons.
Anyway, I just wanted to put this all out there. I'm hoping that we'll be able to refine the concept a little further, then hand it over to GHOP or Summer of Code.
Here are the documents outlining the creation of an "icon.module":
http://groups.drupal.org/node/9830 - Requirements (what it needs to accomplish)
http://groups.drupal.org/node/9833 - Specifications (how it should work)
http://groups.drupal.org/node/9835 - Design (how it should be implemented)
These pages are all wikis, but groups seems to not let me edit them at the moment. I'll go back through and update them to link to each other once the edit page works again.
Comments
Thank you for all the input.
Since there are essentially no icon packs at all at the moment, wouldn't it be a good idea to make it so that existing icon packs like the ones at http://kde-look.org/index.php?xcontentmode=27 can be imported?
I realize that 'style' will be an issue, and we should not be restricted to one default style. But it would also be a pity if we have a designteam of say, 10 people that are working on 10 different icon packs. Well, depends on how many icons are in a pack of course, but still.
Anyway, I made some icons for Filefield module here: http://drupal.org/node/115223 . Dopry suggested to follow the freedesktop.org naming spec and hinted at wanting it to work as decribed above, allowing people to drop in existing icons.
Also, do you think some of this could be a GSOC project? http://groups.drupal.org/node/9738
Thanks again, curious to hear your thoughts on this.
Reuse existing packs - Yes
Reusing existing desktop icons packs is an excellent idea. The problem with a lot of desktop icon packs however, is they don't exactly map well to websites. For example, you certainly don't need to use the "cdrom" image in a website, but you might want a "shoppingcart" icon.
So desktop icons will provide only a small amount of usefulness to Drupal websites. However, we certainly CAN reuse desktop icon sets for Drupal. The only thing that's necessary is including an info file that maps the "icon_name" to the icon path. Since KDE has a standard directory structure for info files, you just need to plop in a kde-compatible .info file that does the mapping.
Not *just* so easy
fd.o icon theme spec compatible desktops (both KDE and GNOME) specify their directories by means of desktop files (named "index.theme") as defined by the above mentioned icon theme spec and based on the fd.o desktop entry specification. So while 3rd party themes might use the same directory structure as KDE's default icon set (Oxygen), they don't necessarily do so.
On top of that, icon theme spec compatible desktops provide automatic fallbacks so if an icon doesn't exist in the current theme then the one from the "parent" theme (defined by the "Inherit" property in index.theme) is used. Also, the newer icon naming spec (also implemented in KDE 4 and recent GNOME versions) provide additional fallbacks inside icon themes, so that stuff like edit-delete-node falls back to edit-delete if the former doesn't exist. (And only if neither of those exist, it uses edit-delete-node from the parent theme.)
Not all but still many icons defined in the icon naming specification do apply very nicely to websites as well. I don't think we should strive for having a complete set of all the icons listed there (not even the desktops provide complete sets, yet) but I do think that we should standardize on those names where applicable, and include the fallback mechanism(s) as mentioned above (minus reading index.theme files, it's probably not worth the effort and might not be the right solution for Drupal anyways).
That's useful information
The fallback feature is a smart one, definitely worth including. The "inherit" property isn't really needed though, as users would be able to choose which icons to use from which icon packs using the user interface, as explained in quicksketch's outline. But the fallback mechanism would be very useful.
I also agree that we should have a standardized naming scheme, which should go into some Icon Guidelines, as I mentioned further down this thread.
file naming
Nate sweet with the outline -i was thinking of getting you to post the outline but seems you beat me to it ;)
The mapping idea would be übercool - then we dont have to force the designers to name their drupal website icons based on a desktop engine :) , and the possibility for quickly adding an existing set (and distribution of sets)
One thing though shouldn't we just keep it to the css implementation? so we dont end up with both adding a bunch of css & img tags all over the pages?
/morten.dk king of rock
morten.dk | noget med ILD
/morten.dk king of rock
morten.dk | geek Royale
CSS vs. Inline
CSS will definitely be required. Inline? Yeah it's optional for the most part. I think a lot of themers might appreciate being able to just place an icon with a handy variable though (e.g. $icon_shopping_cart). Otherwise I'm afraid we'll get an endless stream of "How do I replace text X with just an icon?". Not everyone knows the ol' -999 text-indent trick :)
I realized I forgot to include the inline implementation, design, and requirement. I've updated the docs to reflect those needs.
Cross-posted to SoC 2008 group
This fell off my radar because it wasn't there. I added it to our ideas list @ http://drupal.org/google-summer-of-code/2008/ideas-list. Here's hoping a student goes after this! :)
This is a cool idea!
This is a cool idea, icons is something a lot of people seem to want in Drupal. And as a student I'm definitely interested in doing this! I'm considering some other ideas at the same time though, so will have to think it through first before I decide on what should be my proposal. quicksketch's outline was detailed and very nice, so writing a proposal shouldn't be too difficult ;) Looks like this has been in the works for quite some time already (I know Morten has a module going already).
I have one concern though, and that's consistency. An icon pack will cover all core parts, but then you have contrib modules providing their own icons, making for some horrid clashes of style (somewhat like this). It might be just me, but I really dislike having different icon sets mashed together in one system. One solution is to provide a lot of generic icons in the icon packs and have modules choose from these generic icons instead of providing their own, but that would mean very large icon packs and reuse of icons.
Also, an idea: To provide a static URL for each icon (URL stays the same, icon changes depending on icon pack chosen etc.), one could provide URLs like
http://example.com/icons/admin-user-roles.png, being catched by a callback that returns the right icon.. if that's not bad for performance/caching. Just an idea :)It would be great if you'd
It would be great if you'd jump in on this one with your proposal! I agree that consistency is an issue, but I don't think it's something you can or should try to prevent from happening. Coding the solution is step one, helping users/builders/themers with not messing up their icon styles is another and probably out of scope for this? Having a basic set of generic and reusable icons that contrib can use as well is definately something to work on, but I don't think that should be part of the SOC project, do you?
You're right
You're right, the C in SoC does stand for Code. But I think having clear guidelines for icon builders will be important.
Anyway, I've decided that I'd like to do this project! I think it's an interesting idea, and although it's not the most challenging task, it's at least feasible and should end up as a fully working module after 3 months.
A bit about me: I'm a Norwegian IT student with 2 years of Drupal experience. I speak PHP as well as jQuery and CSS, and I know the (X)HTML DOM well. I know a bit about how Drupal works under the hood, I'm both a frontend and backend person, so I think this project suits me well. My main topic of interest in Drupal is usability, having participated in discussions in the Usability group and made the nodeform module. Other than that, I have the whole summer to kill and a desire to work on a Drupal project in this year's SoC program :)
I'll write a proposal within a couple of days and present it here.
Joakim //ximo
Great!
Ah, yes, nodeform module, great job on doing that. I'm excited, and whatever I can do to help out as a non-coder (design icons perhaps? :-) I will! Building a 'platform' for icon integration will be a big usability win for Drupal me thinks, within appropriate guidelines indeed.
Application posted
Just to let people know, I've posted my application on code.google.com/soc/2008/.
RFC on my application
We have a week left till the deadline, so here's my application for reviewing purposes. I'd be happy to receive comments and critique on this - it will make my application and the foundation for my project stronger. Thanks in advance!
Update: Removed the project schedule and bio parts, as that's more suitable for my application on http://code.google.com/soc/2008
ABSTRACT
The Icon module will add a central system for icons in Drupal, which will help improve the usability. In a way similar to themes or modules, it will allow users to install icon packs and choose which icons to use for their theme. By providing a simple API, developers may use icons in their modules in an easy and coherent way, without reinventing the wheel. I will focus on robustness, simplicity and consistency.
BENEFITS TO DRUPAL
Administration tasks in the Drupal CMS are currently performed by wading through a series of text-heavy and confusing pages. Most tasks lack any sort of graphical representation, causing users to spend an unnecessary amount of time searching for specific options, even if they've performed that particular task before.
Icons will make the administration pages easier to use, especially for users new to Drupal. As shown in the usability testing conducted at University of Minnesota, newbies are often overwhelmed by the amount of text presented to them. They spend a lot of time reading (often all of) the text. It is faster for the brain to process images than text, and icons are easily recognized at a glance, making for improved scannability - perhaps most so on the main administration page.
Icons may also be used to draw the user's attention and to better indicate the type of status messages displayed. Simply using colors (as is current practice) makes it hard for visually impaired users to get the nature of the status message.
The concept of icon packs will also make for better consistency with themes.
PROJECT DETAILS
The idea for this project was presented by Nathan Haug (quicksketch), who has written an excellent development plan outlining the creation of this module (http://groups.drupal.org/node/9830). I consider the development plan a big asset and will use it as a basis for this project.
The Icon module will be somewhat similar in function to the implementations of modules and themes in Drupal. Just as a theme or module is represented in the file system by a folder with an .info file, icon packs will follow this same structure.
There will be an administration page where the user can manage icon packs and choose which icons to use per theme. The development plan suggests using the settings page for each theme at admin/build/themes/settings/your-theme. Instead, I'd prefer to create a new admin page at admin/build/icons, similar to the Themes admin page, allowing the user to choose icons on a per theme basis there, instead of polluting the theme settings pages. Nathan has already agreed that this could be a more appropriate option.
To install an icon pack, the user would first download it from the web (ideally from drupal.org), then extract the compressed folder into the icons folder of the Drupal installation. On admin/build/icons, the user would see a list of all available icon packs and be able to activate the icon pack just downloaded, just like with themes and modules. The next step would be to go to the Configure tab and then the tab for the user's chosen theme. On this page, the user would be presented with a table of all available icons and choose which icons to use from which icon pack. This way, the user will always be able to choose an icon even if the favorite icon pack doesn't provide one.
Since icons are displayed on the theme level, themes will have to conform to the new icons framework. An icons-enabled theme would present in its .info file a list of icons that it supports. This will again determine the interface for the theme at admin/build/icons. The theme would then place the icons in its template files using the background-image property in its CSS file, alternatively using <img> tags and the $icon_ array that will hold the URLs of all selected icons.
Module developers may also provide icons for their own modules. If a module contains new icons, it must expose those to the Icon module through its .info file. Any icon may also be placed directly into HTML output using something like a theme('icon', $icon_name) call. This allows modules to take advantage of the available icon packs' existing icons, without having to provide their own. This is particularly useful on action links such as View, Edit and Delete, but the use cases are endless. Some modules that may benefit from this Icons API are Views, User Badges and External Links.
There will be many issues to tackle along the way, and things may not work out as expected. Whenever I get stuck, I will look at how more experienced developers have solved similar issues in the past and search Drupal's core for inspiration. I think the theme system in particular may provide some answers. Looking at the code of other developers is always a good practice.
DELIVERABLES
Some updates
Based on feedback, I've updated my application:
* Reformulated the Abstract
* The first paragraph in Benefits to Drupal is new
* Minor corrections here and there
Revised application
Below is the latest state of my application (except the project schedule and my bio) that has been submitted. The deadline is in ~1 day, so feel free to give me any feedback you may have before then. Text that is new or has been altered is emphazised.
ABSTRACT
The Icon module will add a central system for icons in Drupal, which will help improve the usability. In a way similar to themes or modules, it will allow users to install icon packs and choose which icons to use for their theme. By providing a simple API, developers may use icons in their modules in an easy and coherent way, without reinventing the wheel. I will focus on robustness, simplicity and consistency.
BENEFITS TO DRUPAL
Administration tasks in the Drupal CMS are currently performed by wading through a series of text-heavy and confusing pages. Most tasks lack any sort of graphical representation, causing users to spend an unnecessary amount of time searching for specific options, even if they've performed that particular task before. This was evident in the usability testing conducted at University of Minnesota.
Icons would make the administration pages easier to use, especially for users new to Drupal. It is faster for the brain to process images than text, and icons are easily recognized at a glance, making for improved scannability - perhaps most so on the main administration page.
Icons may also be used to draw the user's attention and to better indicate the types of status messages displayed. Simply using colors (as is current practice) makes it hard for visually impaired users to understand the nature of the status message.
The framework provided by this project will also benefit module developers and themers, allowing them to easily incorporate icons without having to reinvent the wheel. The concept of icon packs will make for better consistency with themes.
PROJECT DETAILS
The idea for this project was presented by Nathan Haug (quicksketch), who has written an excellent development plan outlining the creation of this module (http://groups.drupal.org/node/9830). I consider it a big asset and will use it as a basis for this project.
The Icon module will be somewhat similar in function to the implementations of modules and themes in Drupal. Just as a theme or module is represented in the file system by a folder with an .info file, icon packs will follow this same structure.
There will be an administration page where the user can manage icon packs and choose which icons to use per theme. The development plan suggests using the settings page for each theme at admin/build/themes/settings/your-theme. Instead, I'd prefer to create a new admin page at admin/build/icons, similar to the Themes admin page, allowing the user to choose icons on a per theme basis there, instead of polluting the theme settings pages. Nathan has already agreed that this could be a more appropriate option.
To install an icon pack, the user would first download it from the web (ideally from drupal.org), then extract the compressed folder into an icons folder in the Drupal installation. On admin/build/icons, the user would see a list of all available icon packs and be able to activate the icon pack just downloaded, just like with themes and modules. The next step would be to go to the Configure tab, then the tab for the user's chosen theme. On this page, the user would be presented with a table of all available icons and choose which icons to use from which icon pack. This way, users will always be able to choose an icon even if their favorite icon pack doesn't provide one. If the user does not select icons manually, a fallback mechanism based on a standardized naming scheme will be used to automatically select the most suitable icons from the available ones.
Because icons are displayed on the theme level, themes will have to conform to the icons framework if they wish to use icons. An icons-enabled theme would present in its .info file a list of icons that it supports. This will again determine the interface for the theme at admin/build/icons. The theme would then place the icons in its template files using class names and the background-image CSS property, alternatively using <img> tags and the $icon_ array that will hold the URLs of all selected icons.
Module developers may also provide icons for their own modules. If a module contains new icons, it must expose those to the Icon module through its .info file. Any icon may also be placed directly into HTML output using something like a theme('icon', $icon_name) call. Using this call, developers may take advantage of the available icon packs' existing icons, without having to provide their own. This is particularly useful on action links such as View, Edit and Delete, but the use cases are endless.
There will be many issues to tackle along the way, and the devil is in the details. To better understand how to solve a certain problem, I will look at how other Drupal developers have solved similar issues in the past. I think the theme system in particular may provide some answers. Looking at the code of core developers is always a good way to learn.
The Icons for Drupal group on groups.drupal.org will be used to discuss the project with members of the community and to post updates of my progress.
DELIVERABLES
Well described
I don't find any serious glitches in this. The reader gets a good impression at what you're up to.
The thing reminds me of Nokia Theme studio - I changed Icons for my mobile theme recently. As I understand, this is going to work in a similar way. But oh shit - you need to put some work into the UI or get someone assist you ;) Just joking, I'm sure this will be done.
Who decides if a proposal is accepted? Well shame on me, it is sure easily found in the SOC Guidelines...
Life is a process
Life is a journey, not a destination
I'm In
I'll be helping ximo as a mentor for this project. Thanks ximo!
That's great
I'm offering my help as well. As I'm not a coder at all, I don't know if I'd be fit to mentor, but I'd like to be involved. And: go ximo!
Perfect - thanks!
Perfect - thanks!
Also thanks to yoroy for wanting to help out! I think it's a good idea to have on board a non-developer (designer/icon/usability person), as this project affects the user interface and themes directly. Maybe Morten.dk also wants to be a mentor (how many can there be?), as he's put a lot of thought and effort into getting icons in Drupal.
go ximo go ximo go ximo
go ximo go ximo go ximo doing the we-want-this-module-done-dance
ill be happy to offer any help to get this module done :)
/morten.dk king of rock
morten.dk | noget med ILD
/morten.dk king of rock
morten.dk | geek Royale
Wooo! Yay ximo, and Nate
Wooo! Yay ximo, and Nate for mentoring! This will rock!!
~~~
{ TopNotchThemes | Fusion Drupal Themes }
Congratulations
Sometime, in this summer, look around you, maybe also see out of your window, and say "hello" to someone.
Good luck with the project
From all of us in Drupals supportteam (DiN)
Drupal i Norge - (DiN)
Ole Martin
http://www.drupal.no
I know this is a rather old
I know this is a rather old topic, but referencing http://drupal.org/node/1948240