shrinkImage continued

This is part 2 of an article I wrote about a theoretical technique to reduce the filesize of PNG images with alpha-channel information by about 70% to 80%.

As this project has left the „proof of concept“ phase in the meantime this article will be far more practical than its predecessor and give you a fully functional jQuery plugin and additional sources to implement the automatic generation of the reduced images.

The best and only way I found to avoid multiple requests but keep the result easily usable in javascript was to use JSON as a container format for the compressed files.

The shrinkImage jQuery plugin

The plugin for jQuery 1.7.2 should work on all major browsers across all operating systems and gracefully fallback to the original PNG image in case canvas is not supported or the AJAX request fails for any reason. As the plugin normally requires other jQuery extensions I developed I combined them all in this package. The plugin uses strict mode and passes jsHint linting with checks for bitwise operators and defined but unused variables disabled.

How to use the plugin

<script type="text/javascript">
;(function($, window, document, undefined) {
    'use strict';

    $(document).ready(function() {
		$('img[data-shrinkimage],.shrinkimage').shrinkimage({
			attribute: 'data-shrinkimage', // default
			debug:     false,              // default
			quality:   80                  // default
        });
    });
})(jQuery, window, document);
</script>

<!-- Foreground image -->
<img alt="" data-shrinkimage="img/example.png" />

<!-- Background image -->
<div class="shrinkimage" style="background-image: url(data:image/shrink,img/example.png);"></div>

<!-- Foreground image with non default quality -->
<img alt="" data-shrinkimage="img/example.png?quality=75" />

<!-- Background image with non default quality -->
<div class="shrinkimage" style="background-image: url(data:image/shrink,img/example.png?quality=75);"></div>

<!-- Foreground image with non default storage location -->
<img alt="" data-shrinkimage="img/example.png?target=img/custom.shrunk" />

The passed options reflect the plugins built-in default options so could be left out in this case. Remember to not use the images src attribute for this plugin because if an image has this attribute it will be requested no matter what you do afterwards. If „debug“ is set to true the plugin will fallback to PNG. I implemented this because during development any kind of DOM inspector (Firebug or Chrome built-in) can become annoyingly slow due to the massive attribute values.

One thing to note is that shrinkImage always checks for the presence of a background image set via CSS and also tries to shrink it. For the same reason the images src-attribute cannot be used for foreground images shrinkImage requires a special form of data-URI for CSS background images (see example above).

You can also listen to the custom (namespaced) events shrinkimage provides to e.g. show a loading animation or whatever comes to your mind. See the following example to learn how to use shrinkImages‘ events:

<script type="text/javascript">
;(function($, window, document, undefined) {
	'use strict';
	$(document).ready(function() {
		$('img[data-shrinkimage],.shrinkimage')
			.on('requested.shrinkimage', function(event, file) {
				// do something when shrinkimage requests the
				// shrunk image
			})
			.on('queued.shrinkimage', function(event, file) {
				// do something when shrinkimage queued a request
				// because the same resource is already requested
			})
			.on('cached.shrinkimage', function(event, file, compressedSize, originalSize) {
				// do something whenever shrinkimage adds a
				// shrunk version to its temporary cache
			})
			.on('loaded.shrinkimage', function(event, file, usedCache, usedFallback) {
				// do something when shrinkimage loaded/processed
				// the shrunk image (includes cache hits)
			})
			.shrinkimage({
				attribute: 'data-shrinkimage', // default
				debug:     false,              // default
				quality:   80                  // default
			});
	});
})(jQuery, window, document);
</script>

 

ShrinkImage stores all processed shrunk images in a temporary cache at the latest processing stage possible to not have to request and/or process them again and therefore further reduces time, requests and resources needed for subsequent requests of the same file.

A practical example

Recycling the example from the previous article this is what the plugin comes up with (original image is left, compressed one is right):

Unbenannt3

Note: Again, the background pattern assigned is not part of the images but only used to visualize transparency.

Automatic serverside generation

.htaccess redirection

As mentioned in the prior article a little .htaccess magic is needed to make automatic generation possible. Make sure you have mod-rewrite enabled in Apache and put the following lines into the corresponding section:

AddType application/json .shrunk
AddType application/javascript .shrunk.jsonp

<IfModule mod_rewrite.c>
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteRule ^(.+.q(?:[0-9]+).shrunk)$ shrinkimage.php?file=$1 [QSA,L]
	RewriteRule ^(.+.q(?:[0-9]+).shrunk.jsonp)$ shrinkimage.php?file=$1&jsonp=1 [QSA,L]
</IfModule>

<Ifmodule mod_deflate.c>
	AddOutputFilterByType DEFLATE application/json application/javascript
</IfModule>
</pre>


What these lines do is very simple: Whenever a file with the prefix ".shrunk" is requested and the file does not already exist on the servers filesystem that request is redirected to a PHP script (in the webservers root directory in this case). Requests to a file with the prefix ".shrunk.jsonp" will, in contrast, always get redirected because of the custom callback name required for JSONP. The other lines define proper content-types and enable gzip compression if supported by the requesting client.

PHP image processing

The PHP file doing all the hard work is also part of the download package and is, in the end, only an advanced example of how the processing can or has to be done. I will not go too much into details in this article but will only very briefly summarize (as promised) what the file does:

At first the file checks if the compressed version already exists. If it does not exist it will be created and stored in the directory where the original image is located (so make sure PHP has write permission to these directories). Afterwards the script will output the compressed version as JSON or JSONP, depending on what the jQuery plugin requested.

The PHP file from the download package assumes being stored in the webservers document root which might not be suitable in your case. If that is the case simply alter line 12 of the file according to your needs and also adjust your .htaccess!

Download shrinkImage package

If you would like to stay up to date I also set up a GitHub repository for all my experiments.

 

Keep it Simple. Keep it Fun.

We believe that neither a framework nor a CMS should be difficult to install, configure or learn, nor should they make anyone program in a rigid or cumbersome way. In other words, they should make programming more – not less – fun. It should however take away a lot of the tedious stuff – the things that distract you just when you were getting some really good ideas.

The philosophy of making software for developers

Eliminate the tedious. Well that is basically the idea of a framework. We want to give you a frame that takes care of the boring things that are always there and let’s you do your stuff. All frameworks should fulfill this function, otherwise they don’t deserve to be called frameworks.

Don’t take away the interesting work. We want to let you, the developer, write your own code in your own way. We want you to have fun programming. Most developers enjoy programming and don’t want all the work taken care of.

Don’t make the developer do awkward things, like dealing with complicated class systems or even learning a new scripting language or templating markup, just to work with one particular framework or CMS. Of course, learning is necessary in order to work with any unfamiliar system, but it can be kept to a minimum and the more you can use what you already know, the better. Keep it simple, don’t just say it is simple. Don’t organise because of a misguided love of organisation or because that is “the way it is supposed to be done”. Inheritance is great, but hard to follow in a framework. Conventions only help those who have memorized them.

Never implement features that “might” be useful. Make what is needed, when it is needed. A basic “getting real” principle, worth gold in a project by developers for developers.

Because of these principles – or at the beginning at least a vague idea of them – we set about making a new framework, and later built a new CMS.

Are these ideas so unique? Certainly not, but we have seen few examples of products for developers that follow them, and lots of tools that are difficult to install, learn and are useful only after extensive learning. Tools that lead developers to describe themselves according to being able to work with them. We don’t want developers to write „MorrowTwo Developer“ in their CV instead of „PHP Developer“. That doesn’t make sense. Any more than an illustrator describing himself as a „pencil pusher“.

A philosophy of simplicity has found broad acceptance in web development, an approach that begins at the birth of every new project. But it seems that tools for developers are still expected to be complicated and full of features. Maybe because developers have a hard time thinking „simple“ and, to be honest, it wasn’t easy for us either.

Re-programming and avoiding featuritis

Morrow – the forerunner of our framework “MorrowTwo” – began as a project our own use. The first ideas came about as we started combining the systems we had each created for ourselves as individual developers. Starting in a kind of pair-programming process, we created Morrow – a full framework, that we considered more of a proof-of-concept than a finished version. After using Morrow in dozens of real projects, we sat down and discussed all that was good, and all that bothered us.

First of all we re-defined the way classes were to be used and refactored the way controllers work. But going further than that, we realized that we still took too much of the programming away from the developer. We had created a lot of conventions that allowed the developer to do things in a single line of code. The problem with that, was that the developer had to learn these conventions in order to use the features. Therefore we threw them all out. The consequence is that you, as a developer, have to write more code, but it is code that you write without having to refer as much to the documentation.

When we started working on our CMS “/f/” (pronounced “SlashF-Shift7”*  or just “SlashF”), we had already gained a lot of experience with working with eachother and had learned to look for the signs of featuritis creeping in. For every feature one of us wanted to add, the other asked the question: Do we need it? Do we need it now? Most of the time, the answer was “no”. It was actually quite like a game.

The results of these processes, I would now like to decribe in some more detail in the next two sections.

The products

MorrowTwo: efficient web development

What does efficient mean? It means no set up and no configuration of the framework itself. It means understanding quickly how the system works. It means the basics are taken care of and the developer can program his in his own way.

What are the basics? In our opinion they are: a simple controller/template setup. It includes a simple handling of user input, provides speaking URLs automatically, helps in the generation of valid links and navigational elements. Also multiple language and locale handling are a must. Multiple projects and sites should also be possible. And of course logging and debugging should be simple and ready to use. Ah what else? Of course, session handling and output to different types of views with the appropriate headers.

When all that is basic, what could possibly be optional?

There is quite a few left over. But instead of giving you a complete feature list now, I would like to refer to the project wiki, which provides you with the documentation of the classes we provide with the framework. If you feel like anything is missing, you can create your own classes, or use classes provided by other developers.

There is one more very important feature to mention. Programming easily isn’t everything. The product you develop also needs to be efficient. We have trimmed MorrowTwo for performance. The entire code has been analysed with XDebug and then optimised. To increase output speed even more we have implemented a soft HTTP-Caching with automatic generation of ETags. You don’t have to do anything for this. But if you really want to decrease the expenditure of your own code you can also implement hard caching by using the classes we provide for that.

SlashF-Shift7: Just managing content

Managing content is a difficult topic. We decided to make it easier. Not just for the editor of the content, who should not be confronted with too many options and ways of doing things, but also for the developer. Our goal was to allow you to set up the content managing part by creating a few configuration files. That’s it.

As a main concept of the CMS we separated the management of content from its presentation. In order to present the content, you, the developer, can use a framework, like MorrowTwo, or just write your own PHP code. You can get the content then either directly from the database or can use a class that we provide to access page data. The two biggest advantages of this are that the output is not limited to HTML and you have complete freedom to program in the way you are used to with the technologies you are used to using.

For managing the content you have a range of fields that you configure to your needs. You group these fields together to form data sets for pages or list items. If you need your own custom fields you can add these by extending classes that we provide. The result is an interface that is easy to understand for those who will be adding and editing content.

Keeping ourselves to the essential features, the decisions we made were initially based on experience. We only put in features that we have actually needed for real projects, but not ones that sounded like good ideas, but we have never actually used. The list was then adapted to needs that came up in the subsequent projects we realised for ourselves and our clients.

At the current stand, we have a preview and publishing system, simple group permissions, automatic support for “speaking URLs”, and simple file management including IPTC field editing, to name a few features. Of course,  /f/ has been set up to handle multilingual content from the very beginning.

Currently /f/ is in the refactoring phase. When that is finished we are also planning to provide it for you for free.

Creating and sharing

Basically it is not hard to program for developers. From the beginning on, you are making something for yourself. When the goal is to make something that you can enjoy using, if you remember – and keep reminding yourself – to only implement the necessary and keep in mind that others could use your application and that they should also have fun with it, then you are likely to create a great product.

MorrowTwo has been used for years now by Ministry employees and freelancers working with us. The feedback we have received has supported the ideas above. Once you have tried MorrowTwo yourself, we would greatly appreciate it, if you would share your thoughts and feelings about the framework:morrowtwo@ministry.de.

If you would like to be notified when /f/ is availible to the public, write us at slashf@ministry.de.