Patch #23980

Replace images with icon fonts

Added by Marius BALTEANU 9 months ago. Updated 5 months ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:UI
Target version:Candidate for next major release

Description

Icon fonts have some advantages over the classical images:
- being vector graphics, they are scalable an can be resized without losing quality.
- can be customized directly from CSS (size, colour, etc)
- less HTTP requests to server because they are loaded only with one or a few requests. Now, Redmine make a request for each image.
- some of the current custom themes already use icon fonts (Abacus theme, Minelab, PurpleMine2, our custom theme and I think the theme from plan.io).

We're interested to contribute with a patch that implements the FontAwesome icons, but because there are at least two ways to implement them, we want some feedback before from Redmine contributors and/or users.

1. Using i tags:

Advantages:
  • Is the recommended way on their official page
  • We can use all the build-in rules available in the FontAwesome CSS.
Disadvantages:
  • it'll be required to add the i elements in views.

2. Only from css

Advantages:
  • the views will not be modified
Disadvantages:
  • The build-in rules must be reimplemented in the current CSS
  • The icons will be defined using their unicode. For example, the fa-pencil icon (similar with the current images for icon-edit) has the unicode f040.

Only for demo purposes, I've attached a patch that replaces the icons from issue page with font awesome icons (using i tags).

font_awesome_icons.patch Magnifier (15.3 KB) Marius BALTEANU, 2016-10-04 02:06

font_awesome.png (263 KB) Marius BALTEANU, 2016-10-04 02:19

use_font_awesome_icons_for_all_elements_that_use_icon_class.patch Magnifier (399 KB) Marius BALTEANU, 2016-10-09 12:11

replace_images_with_fa_icons.patch Magnifier (15 KB) Marius BALTEANU, 2016-11-29 01:33

font-mfizz.zip (243 KB) Marius BALTEANU, 2016-11-29 02:05

fonts_folder.png (92.8 KB) Marius BALTEANU, 2016-11-29 02:06

admin_fa.png (142 KB) Marius BALTEANU, 2016-11-29 02:09

issue_fa.png (236 KB) Marius BALTEANU, 2016-11-29 02:09

activity_fa.png (293 KB) Marius BALTEANU, 2016-11-29 02:09

overview_fa.png (191 KB) Marius BALTEANU, 2016-11-29 02:10

projects_fa.png (124 KB) Marius BALTEANU, 2016-11-29 02:10

issues_fa.png (319 KB) Marius BALTEANU, 2016-11-29 02:10

repository_fa.png (324 KB) Marius BALTEANU, 2016-11-29 02:10

roadmap_fa.png (211 KB) Marius BALTEANU, 2016-11-29 02:10

replace_images_with_fa_icons_v2.patch Magnifier (15.6 KB) Marius BALTEANU, 2016-11-29 02:40


Related issues

Related to Redmine - Feature #5830: Replace famfamfam icons with the fugue set New 2010-07-07
Related to Redmine - Feature #11757: Add support for HDPI screens (retina) New

History

#1 Updated by Marius BALTEANU 9 months ago

Marius BALTEANU wrote:

2. Only from css

Advantages:
  • the views will not be modified
Disadvantages:
  • The build-in rules must be reimplemented in the current CSS
  • The icons will be defined using their unicode. For example, the fa-pencil icon (similar with the current images for icon-edit) has the unicode f040.

The "disadvantages" word should be after the first advantage. Like is in this comment.

#2 Updated by Marius BALTEANU 9 months ago

Attached a screenshot also.

#3 Updated by Jan from Planio www.plan.io 9 months ago

Hi Marius, thanks for proposing this. I think replacing the current icon set with an icon font is a great idea. As you noticed, we're using Font Awesome for the new Planio design.

Marius BALTEANU wrote:

because there are at least two ways to implement them, we want some feedback

Before implementing our new design, we were discussing this intensively. We decided against using <i> tags and in favour of adding new CSS rules, for the following reasons:

  • Changing all icons in Redmine to <i> tags would be a very large patch touching almost all views in Redmine (as you probably already noticed while preparing your demo patch).
  • Using <i> tags would require all plugin developers to change plugins as well and there would be a (potentially long) period where plugins would still use the "old" icons while Redmine is already usig "new" icons making the overall user experience inconsistent.

Implementing new CSS rules for all icons using Font Awesome, however, would be less of a change to existing Redmine code (we would be able to leave views alone) and would apply to all existing plugins using standard Redmine icons (like edit, delete, etc.) at once, so plugin developers would have few things to change or nothing at all.

To respond to the disadvantages mentioned:

The build-in rules must be reimplemented in the current CSS

I actually see this as an advantage: implementing Icon style can be encapsulated in a defined place within the CSS and does not happen all over the place.

The icons will be defined using their unicode. For example, the fa-pencil icon (similar with the current images for icon-edit) has the unicode f040.

From our experience in working with Font Awesome in our new UI, it isn't much of a problem. The icons can be looked up easily via http://fontawesome.io/icons/ and we could use CSS comments to note the Font Awesome icon names next to the unicodes.

One sidenote: At Planio, we're using Rails' Asset Pipeline with Redmine and are thus using SCSS and the fontawesome-rails gem which is a tremendous help.

#4 Updated by Marius BALTEANU 9 months ago

Jan from Planio www.plan.io wrote:

Hi Marius, thanks for proposing this. I think replacing the current icon set with an icon font is a great idea. As you noticed, we're using Font Awesome for the new Planio design.

Marius BALTEANU wrote:

because there are at least two ways to implement them, we want some feedback

Before implementing our new design, we were discussing this intensively. We decided against using <i> tags and in favour of adding new CSS rules, for the following reasons:

  • Changing all icons in Redmine to <i> tags would be a very large patch touching almost all views in Redmine (as you probably already noticed while preparing your demo patch).
  • Using <i> tags would require all plugin developers to change plugins as well and there would be a (potentially long) period where plugins would still use the "old" icons while Redmine is already usig "new" icons making the overall user experience inconsistent.

Implementing new CSS rules for all icons using Font Awesome, however, would be less of a change to existing Redmine code (we would be able to leave views alone) and would apply to all existing plugins using standard Redmine icons (like edit, delete, etc.) at once, so plugin developers would have few things to change or nothing at all.

To respond to the disadvantages mentioned:

The build-in rules must be reimplemented in the current CSS

I actually see this as an advantage: implementing Icon style can be encapsulated in a defined place within the CSS and does not happen all over the place.

The icons will be defined using their unicode. For example, the fa-pencil icon (similar with the current images for icon-edit) has the unicode f040.

From our experience in working with Font Awesome in our new UI, it isn't much of a problem. The icons can be looked up easily via http://fontawesome.io/icons/ and we could use CSS comments to note the Font Awesome icon names next to the unicodes.

Totally agree with you, I'll try to create a patch using only CSS.

One sidenote: At Planio, we're using Rails' Asset Pipeline with Redmine and are thus using SCSS and the fontawesome-rails gem which is a tremendous help.

I know that were some discussions about the Rails' Asset Pipeline (I can't find the ticket now) and enabling this feature is not an option because will add some complexity. If I'm wrong, I'll be very happy to use that gem.

Thanks for your feedback.

#5 Updated by Marius BALTEANU 9 months ago

I've attached a first patch which:
  • adds the Font Awesome fonts
  • replaces the images icons with font awesome icons for all elements that have icon and icon-* classes

Some observations:

1. Currently, there are some specific programming images for file types like text-x-php, text-x-c, text-x-java and so on. Because FontAwesome doesn't have these types of icons, I see 3 ways to solve this problem:
1.1 use the current images
1.2 use the generic file code icon provided by FontAwesome for all of these files.
1.3 add Font-Mfizz which is an extension of FontAwesome icons and provides the required icons.

IMHO, I prefer the second solution because:
  • it doesn't add new fonts
  • it doesn't require to keep the rules related to background images in icon class
  • it doesn't require maintenance when a new type of files appears (in this patch I've added a new class named "application-javascript" in order to recognize the javascript files)

2. I'll add separate patches that replaces the current images with FontAwesome icons in other pages like: administration, project overview, etc..
3. In the last patch, I'll remove the unused images.

Any feedback is appreciated.

#6 Updated by Alexander Meindl 9 months ago

I would prefer the Font-Mfizz solution. It does not require much more server load using it (there are a lot less server requests compared to the background image solution). Main reason for this solutions is, that the usability and the user acceptance would be higher. A lot of technical teams are working with Redmine and SCM, and these people will be certainly happy to see file type specific icons.

#7 Updated by Toshi MARUYAMA 8 months ago

  • Description updated (diff)

#8 Updated by Marius BALTEANU 7 months ago

We discussed internally in Zitec and we are going to implement the solution with Font-Mfizz but for the moment we are waiting for some feedback on issue #24313 because having that ticket commited, it will be much easier for us to implement this one.

#9 Updated by Go MAEDA 7 months ago

  • Related to Feature #5830: Replace famfamfam icons with the fugue set added

#10 Updated by Go MAEDA 7 months ago

  • Target version set to Candidate for next major release

#24313 has been implemented.
I am looking forward to seeing this feature in 3.4.0. Setting target version to "Candidate for next major release".

#11 Updated by Marius BALTEANU 7 months ago

Go MAEDA wrote:

#24313 has been implemented.
I am looking forward to seeing this feature in 3.4.0. Setting target version to "Candidate for next major release".

The patch that replaces the images with fa icons is ready, but I want to take some feedback from our users regarding the icons color. Now all the icons have the same color (# 169). Please let me know if you want to test it as it is now.

#12 Updated by Marius BALTEANU 7 months ago

The attached patch (replace_images_with_fa_icons.patch) replaces the images for all regular icons (that have the classes "icon icon-*") with font-awesome icons.

Because the git binary diffs are not supported by the patch command, I wasn't able to add the required fonts as patches, but I've documented bellow the necessary steps:
1. Create a folder fonts in the public directory from redmine.
2. Unzip the attached font-mfizz.zip in the new fonts folder.
3. Because the font-awesome archive is bigger than the maximum allowed size for attachments (600kb), the zip can be downloaded from here. If the official link is preferred, the fonts must be extracted from the archive (folder fonts) to a folder named font-awesome in the same folder fonts from public directory.

At the end, the fonts folder from public should have 2 directories:
  • font-awesome
  • font-mfizz

There are still some elements that are using images (like classes expander, asc, desc), but I think that is safer to replace them with FA icons in another ticket (requires more changes). Also, I think the images should be removed in a later major release (for plugins compatibility).

Any feedback on the chosen icons is welcome.

#13 Updated by Marius BALTEANU 7 months ago

Some screenshots.

#14 Updated by Marius BALTEANU 7 months ago

Updated to include a fix for the responsive mode (the left padding is no more required).

#15 Updated by Marius BALTEANU 6 months ago

Any feedback on this patch? FTR, I tried to create a single patch with all the changes with Subversion too but it didn't work.

#16 Updated by Go MAEDA 6 months ago

  • Assignee set to Jean-Philippe Lang

Screenshots looks nice for me.
Jean-Phillipe, is there any possibility that this patch will be merged?

#17 Updated by Marius BALTEANU 5 months ago

Jean-Philippe, do you have any feedback on this?

#18 Updated by Go MAEDA 5 months ago

  • Related to Feature #11757: Add support for HDPI screens (retina) added

Also available in: Atom PDF