Category: RealFaviconGenerator

When RFG was released 3 years ago, it barely had more than a few pages. So it started with no navigation at all if not for a few links in the footer of each page.

With its modules for Gulp, Grunt, RoR and others, with its API and other pages, the footer was definitely not enough to handle all this content. So here it comes: a Navigation Bar. And that’s fantastic.

And the old header (with a big RFG logo) is gone, leaving more room for the content. Oh, and what about the ad that used to be in the top right corner of each page? It’s gone, too.

Did you see the latest favicon package created by RealFaviconGenerator? It’s only 5 lines of HTML!

The initial promise: support everything

RealFaviconGenerator was created with the intent of providing support for all platforms. Not only a single favicon.ico for desktop browsers, as other generators did at the time. To achieve this goal, it generated as many icons as possible: all icons for iOS, from the very first iPhone to the latest iPad. All tile icons for Windows 8 and 10. All icons for Android Chromes. And support for all known platforms, such as Google TV.

The outcome? 20 lines of HTML code and almost 30 icons.

The promise was fulfilled: follow RealFaviconGenerator’s instructions and you actually support everything.

This package has become a kind of reference. Soon after the release of RealFaviconGenerator, half a dozen of generators were created. All took this code snippet as a reference. Some existing generators followed the same path.

Although that was a good start, this package was not satisfying. If you’re like me, you don’t like this huge HTML snippet. In particular, the repetitive Apple Touch icon declarations. Too much lines, and also too similar. Something was wrong.

The new deal: support everything, and keep it pragmatic

When RFG was written, support for all platforms was the big plan. This came with a drawback: this huge bunch of HTML lines and this set of files you didn’t want to put in your root directory. This is because two points were completely left behind.

Some platforms don’t deserve to be supported

Whatever the audience of your website, you want support for all major browsers and platforms. Windows Firefox. iOS Safari. Internet Explorer. Android Chrome. And all the others. But some platforms simply don’t deserve support (or not anymore).

The first victim here is Google TV. It’s 96×96 PNG icon is not generated anymore. That’s final. This product didn’t succeed, plus the original reference that described the icon is gone. “Okay but this icon didn’t hurt, why removing it?” Well, it had side effects. Because Firefox loads too many icons, you could have your almost-never-useful 96×96 Google TV icons loaded by your visitors using Firefox. Thus the cost was much higher than the benefit.

There are also deprecated icons. Android Chrome M38 and prior used to pick a 192×192 icon declared in the HTML code. Current version is M51 and it doesn’t need this declaration anymore. And remember the issue with Firefox? Yep, this 192×192 icon was also regularly loaded by FF. So this declaration is gone (although the icon itself is still present and declared by the Web App manifest).

Last item of this list is the tile icon for Windows 8.0 and IE 10. Windows 8.0 has a market share of 2.62% and no chance of growing. This is very low compared to the 26% share of Windows 8.1 and 10 combined. It is not effective to use two lines of HTML code for such platform when W8.1/10 use only one, or even none when browserconfig.xml is in the root directory.

Platforms don’t need all icons

Apart from a few exotic ones, all platforms and browsers must be supported. So how can we significantly reduce the size of the package? An obvious answer, for a given icons family, is to generate only a single, high resolution icon. For example, could we create only a single 180×180 Apple Touch icon, instead of the full range, starting at 57×57? The answer comes in two parts.

First, yes, iOS devices can deal with a high resolution icon. They are able to scale it down to fit their screen (think: non-Retina screens, small screens…). That was the obvious part.

So iOS can scale icons down, but does it do it well? This is not trivial. We could suppose iOS is using a fast, lightweight scaling algorithm, such as nearest neighbor. That would make sense. But if this hypothesis was true it would lead to poor results when an iPad Mini turns a 180×180 icon to a 144×144 one. Tests were run and the conclusion was: iOS does a great job art scaling down. It does as well as any image edition tool such as Photoshop, or ImageMagick to name the tool behind RFG. All in all, by providing a single, high resolution icon, we support all iOS devices and we support them well.

What about Android Chrome? Same conclusion: Android Chrome is using a compelling scaling algorithm. By providing a single icon, Android Chrome support is as great as before.

Windows tiles are another story. Microsoft defines four icons, which serve different styles: three squares icons (small, medium and big) and a rectangular icon. While RFG used to create the full set, it now produces only the medium, square icon. That should be enough for most web sites.

In the end, the new code is only 5 lines of HTML. And we still support everything. No catch with Firefox. This is much better.

Creating a smaller package is the best solution for most websites and developers. However, there are a few drawbacks. What if you want the four Windows tiles icons? What if you are concerned with 404 when iOS devices keep asking for Touch icons in the root directory? (don’t know what this is? Check your server’s logs and look for /apple-touch-icon and 404. See?). All icons and HTML markups are still available, only a few clicks away.

Actually, RealFaviconGenerator will give you up to 40 files if you ask for everything. Hurray!

RealFaviconGenerator is not a mere claim, a promise that all these icons will (probably) find they way in the tabs, bookmarks and home screens or your visitors. The generated code and icons are actually tested before being released.

The compatibility test

RealFaviconGenerator quality starts with the favicon compatibility test. This is a three-forms process that allows anyone to test the generic package created by RFG on his own device(s). The test exposes your browser to two scenarios:

• Favicons files are in the root directory of the web site
• Favicon files are in a sub-directory

Basically, you visit a random site which is equipped with RFG’s code, do a few operations (add to bookmark, add to home screen…) and note the results. When it’s done, I get an email.

Different pics

It’s not enough to check that the tested browser displays an icon. We must find out which icon is displayed. Does Windows Firefox takes a PNG icon declared with a link tag or one of the embedded icons of favicon.ico? Does Android Chrome really takes the icons declared in the Web App manifest or an Apple Touch icon? To be certain, the compatibility test comes with different icons, so you can quickly see which one is chosen.

A dedicated domain name

If you play with favicons, you know how browsers can be stubborn regarding caching. Once they load your favicon for the first time, they won’t reload it before a while. So annoying. For this reasons, the compatibility test is always mounted on a particular domain name, so that each test is run in isolation. At the time of writing, the first test is located on test01-v0-13-attempt-5.test.realfavicongenerator.net. As the name says, we are testing the upcoming package v0.13, and this is the 5th attempt.

Running the tests

Tests are run by generous contributors. Simply go to https://realfavicongenerator.net/favicon_compatibility_test and take the two-minutes tour. When a release is incoming, a little tweet usually ask for help.

Would you help testing the next version? We need non cutting edge devices such as iPhone 4, first generation iPad… https://t.co/2Oti6bkkdA

— RealFaviconGenerator (@RealFavicon) 29 juin 2016

Before a release, there is always a special trip to an Apple Store in order to fill the empty cells.

Results

The compatibility of the current version is available, so you know what you can expect from a set of icons got from RFG.

And yep, next package should be released in a couple of days.

Photoshop is a great tool. Use it and you can expect your pictures to be just perfect. Well, almost perfect.

Let’s see what Apple got when they created their own Touch icon:

$ wget -o apple-icon.png http://www.apple.com/apple-touch-icon.png
$ ls -l
-rw-rw-r-- 1 philippe philippe 4506 Aug 12  2015 apple-icon.png

4506 bytes for a Touch icon? Sounds legit. Now let’s have a look to its metadata:

$ exiftool apple-icon.png
ExifTool Version Number         : 9.46
File Name                       : apple-icon.png
Directory                       : .
File Size                       : 4.4 kB
File Modification Date/Time     : 2015:08:12 19:51:29+02:00
File Access Date/Time           : 2016:05:17 17:00:31+02:00
File Inode Change Date/Time     : 2016:05:17 17:00:31+02:00
File Permissions                : rw-rw-r--
File Type                       : PNG
MIME Type                       : image/png
Image Width                     : 152
Image Height                    : 152
Bit Depth                       : 8
Color Type                      : RGB
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Adam7 Interlace
Software                        : Adobe ImageReady
XMP Toolkit                     : Adobe XMP Core 5.5-c021 79.155772, 2014/01/13-19:44:00
Original Document ID            : xmp.did:15d8a979-1097-4474-accc-90fc2b02fc58
Document ID                     : xmp.did:25F46708355311E580E8DA1A4BE6CE82
Instance ID                     : xmp.iid:25F46707355311E580E8DA1A4BE6CE82
Creator Tool                    : Adobe Photoshop CC 2014 (Macintosh)
Derived From Instance ID        : xmp.iid:d4dcd418-cd4f-4a8e-a9eb-670e43ff2ee8
Derived From Document ID        : adobe:docid:photoshop:3a0c5b59-7dbd-1178-bb27-91c7aa683e3f
Image Size                      : 152x152

Apparently, this icon was generated by Photoshop.

These are a lot of information… What happens if we remove all EXIF data?

$ exiftool -all= -o apple-icon-no-exif.png apple-icon.png
$ ls -l
-rw-rw-r-- 1 philippe philippe 3555 May 17 17:04 apple-icon-no-exif.png
-rw-rw-r-- 1 philippe philippe 4506 Aug 12  2015 apple-icon.png

We’ve just decreased the size of the Apple Touch icon by more than 20% just by removing the metadata!

Now let’s do the same of, say, the Alphabet Touch icon, wisely generated by RealFaviconGenerator:

$ wget -O alphabet-icon.png https://abc.xyz/apple-touch-icon-152x152.png
$ exiftool -all= -o alphabet-icon-no-exif.png alphabet-icon.png
$ ls -l
-rw-rw-r-- 1 philippe philippe 3714 May 17 17:09 alphabet-icon-no-exif.png
-rw-rw-r-- 1 philippe philippe 3714 Apr 21 05:17 alphabet-icon.png

(yep, we took the 152×152 version, because this is the size of Apple’s Touch icon)

Now, the image is 3.7KB, with or without EXIF, simply because RFG does not produce verbose metadata.

Okay, it’s not entirely Photoshop’s fault. It probably has options to not be that verbose. Plus you’re responsible of post-processing your assets before deploying them. But if Apple did the mistake, others probably made it too. But at least not RFG users.

A few days ago RFG started to collect user’s feedback in three areas.

170 visitors filled one of the forms. THANK YOU!!

Platform

The first question was about the platforms you would like RFG to support. The winner is… the Open Graph image, used by Facebook when you share a page.

Beyond the raw results, the social networks are the undisputed winners. Most votes for Coast and Yandex were from people who voted for everything. Whereas many feedbacks were only for OG and Twitter, or OG alone.

Options

Three options were proposed:

• Small pictures: RFG resizes pictures as needed to generate the icons. Regarding small icons (16×16 and 32×32), it is sometimes better to edit them manually, or to draw them pixel-by-pixel. RFG would allow you to upload your very own custom 16×16 and/or 32×32 icon(s).
• Smaller package: RFG generates 20-something icons and about 15 lines of HTML. Many people don’t want to clutter their HTML with so much code. RFG could create much less with very few side effects.
• Embedded instructions: The instructions to setup your favicon (and the HTML) are given by RFG web site. The Zip file itself contains only the images and related files. In other words, the package is not standalone: if you leave RFG too soon, you end up with a useless archive. The package could contain a text file to remind the instructions.

Embedded instructions is the most wanted option. I thought most people would want a smaller package, while I considered the embedded instructions as a nice-to-have. I was wrong, and that’s the point of asking for opinions.

Tools and framework

This is my favorite part. There were less votes here, only 17. I was not surprised: the form was in the result page, where the user is presented the material he came for: the package and HTML code. Most people probably didn’t want to hear about anything else. But I could feel the interest is real. Unlike the platform and options forms, where several users selected everything, all votes here were for one tool or framework. So I could really hear a visitor asking for his favorite solution.

The winner is Grunt, by a short advance. Gulp and Ruby on Rails were nearly as popular. Symfony got no vote, but that’s okay. The test was run for only 3 days (1st day was a Sunday) and the question was asked to people who didn’t come for this.

Thank you again for all this feedback!!

Alright, time to get back to work!

Until now, RFG didn’t explicitly asked for feedback. Users have done it via:

• Email
• This blog
• Social media (especially Twitter)
• Issues on Github

I’ve just started something I should have done long ago: survey users for direct feedback.

During a few days, you will find three forms right in the interface of RealFaviconGenerator. The first one is about the supported platforms.

The second one is about options. Here you will find usual suspects (at least from my point of view).

The third one is for integration. RFG generate HTML, but this is not the only way. What do you use? Build tools such as Gulp? Framework like Ruby on Rails?

Next episode: the results!