Swarm - Website Design & Digital Media Agency
Welcome to the Swarm website! Swarm Media is a digital design agency based in Leeds & York in the United Kingdom. We specialise in many areas of digital design including website design, graphic design, web development, Flash animation, search-engine optimisation and web hosting. If you want quality digital design solutions, then look no further.
Blog / Updates
Colour Profiles, Wide Gamut and Websites
It has been several months since my last few posts, so I've decided to write something new. Nothing about code this time, as much as I love it.
A while back, I searched for some guidance on this subject, and whilst there are plenty of articles discussing colour profiles in general, and a few on their applicability to web design, none of them really answered all of my questions so I had to do some experimentation.
Colour profiles are something which graphic designers are most likely already familiar with (and if not, they should be). Web designers on the other hand, have probably never had much experience with them. They are basically little pieces of information which are attached to image files to tell the monitor (or other device) how to display the colours used in the image. This is necessary to achieve consistency across devices which may display colours differently to each other.
In the past, this was primarily relevant to graphic designers producing print work, as the same colour value often appears significantly differently on a computer screen compared to on paper or other materials.
Web design only deals with screens, so until recently this meant colour profiles were of little concern. With the introduction of so-called "wide gamut" monitors however, colour profiles are becoming increasingly important because wide gamut monitors can display a wider range of colours than standard gamut monitors. For example, the colour hex value #FF0000 means "the most saturated red possible" to the monitor. Since wide gamut monitors can display a greater level of saturation, this same colour value will look much more saturated on a wide gamut monitor compared to a standard one.
In practical terms, this means any images created using a standard gamut monitor, which have no colour profile embedded, will look substantially more saturated on a wide gamut monitor. Conversely, images created on a wide gamut monitor, with no colour profile embedded, will look substantially less saturated on a standard gamut monitor.
It is only by embedding correct colour profiles that one can achieve consistency across monitors with different colour gamuts. For websites, the only colour profile you should really be using is sRGB (standard RGB). sRGB can be displayed by both standard and wide gamut monitors, and so covers all bases.
Most of the above information is easy to find on the Internet, as well as information on how to properly calibrate your monitor and how to actually embed the colour profiles into the images you create. What I've been unable to find, is information about the relationship between colour profiles and colours on websites; particularly those defined using CSS.
Since CSS uses actual colour values, such as the bright red mentioned above, and since there is currently no way to attach colour profiles to CSS stylesheets, colours defined by CSS are inconsistent across monitors. The latest Internet browsers do have colour management built in, however it does not seem to apply to CSS, only to images.
With this in mind, using sRGB colour profiles in images will cause issues on wide gamut monitors (such as my own). Any images which have to work seamlessly with CSS colours, for example a gradient background which fades into a particular colour, will be noticeably incorrect, particularly if the colours are saturated. The only solution then, is to not embed colour profiles in any such images. Images which are separate from the design of the website, for example photographs, can be given an sRGB colour profile, but any images whose colours have to match the CSS can not.
I'm unsure as to why so few people have encountered this problem or suggested solutions for it, but there you go. Perhaps it will be noticed when more people have wide gamut monitors which include only the most expensive models at the moment (upwards of £500 in most cases).
Spaghetti Code
I've recently gone over a few related topics to do with programming and/or web development. The pejorative term "spaghetti code" gets thrown around a lot, however I think many of the people who use it don't really understand what it means. Some use it to describe where HTML, PHP, SQL, CSS and Javascript are all intermingled; but this isn't (necessarily) spaghetti code. Similarly, others use it to describe the lack of a layered architecture or framework (such as MVC) where particular functionalities are separated; but this isn't (necessarily) spaghetti code either.
Spaghetti code specifically refers to code that is a tangled mess, meaning that it is incredibly difficult to follow and understand. For example, a script might have random includes, functions and objects scattered throughout it which make it extremely difficult to follow the code through in sequence, and nigh on impossible to continue working and building upon. Such an issue is often made worse by weak or non-existent documentation.
A lot of developers seem to think that avoiding writing "spaghetti code" means having to adhere to a particular architectural pattern, framework, or methodology. I strongly oppose this view because part of what makes web development and programming in general enjoyable is doing things your own way and coming up with your own solutions. Whilst programming obviously has a wholly logical foundation, that doesn't mean there isn't room for artistic license. There are a lot of supposed "best practices" which are questionable at best; one example being the non-mixing of different languages mentioned above.
Whilst I do not suggest one should carelessly mix three, four or more distinct languages together in an unreadable mess, I would argue that it is completely possible, and often beneficial to keep PHP and HTML (for example) intermingled without creating "spaghetti code". Abstraction and compartmentalisation, whilst both powerful and useful, can make things more complicated or bloated than they need to be. There are ways in which code can be organised and structured as to make it perfectly understandable and cohesive whilst at the same time mixing languages together (or doing other things which would make certain purists cringe).
Since the whole point of architectural patterns and coding conventions is to make things easy (or at least easier) for the developer, it doesn't matter if pattern X or convention Y is used, so long as the code is logically structured and consistent in both structure and style. If a developer finds it easiest to keep everything together, as to closely reflect the order in which things get processed and sent to the browser, then there is no reason to change. There seems to be a tendency to use particular coding styles or frameworks simply for the sake of using them, rather than because they offer any real benefit to the developer.
In summary, spaghetti code is very bad, but some of the things which are often wrongly labelled spaghetti code, are not bad at all.
The MVC Pattern
MVC stands for Model-View-Controller and is an architectural pattern used in programming. The intention behind the pattern is to separate presentation from logic, much in the same way that CSS stylesheets separate the visual elements of a webpage from the structural HTML markup. Models represent the data, the view represents how the data is displayed to the user and the controller deals with the interaction between the two.
Before I go any further, please be aware that this blog entry is aimed at MVC in relation to building websites, not MVC in general.
In my previous blog entry I discussed PHP frameworks. Many of these implement the MVC pattern and so it is becoming quite popular amongst web developers. However in general, I remain unconvinced that it is really the best approach to use.
Whilst I am keen on object-oriented programming which separates code into manageable blocks, I find that the MVC pattern needlessly complicates things. For example, the MVC pattern requires one to separate what would otherwise reside in a continuous, ordered sequence, into multiple files.
Whilst a non-MVC approach is not necessarily entirely procedural, the three MVC elements are generally integrated together, so one might fetch some data from the database and then cycle through the results and display them all in a few consecutive lines of code. The MVC approach would be to move the database functions to a separate file, move the visual functions to a separate file, and then request these external files via the controller functions.
In a situation where multiple developers are working on a project over an extended period of time, where some may be tasked with developing the visual front-end elements and others may be tasked with working on the database functions, the MVC approach is useful as it allows work to be done separately with less chance of breaking something. However, if all the developers involved have a strong understanding of all these elements, or if the project is quite small, MVC becomes a hinderance rather than any help.
I personally favour using integrated "controllers", where the flow of the application is exactly as you see it. Of course, objects can (and should) be used to avoid needlessly repeating the same code many times, however these objects are used for specific functionality. Rather than dividing things based on whether they handle data or presentation, I prefer to group functionality based on its specific function within an application - so a controller which handles blog entries, a controller which handles portfolio items etc. - including both the data management and presentation aspects of these components. If I need to fetch something from the database I will do it directly and exactly where it is needed (fetch the data, display the data). MVC on the other hand requires you to use the controller to fetch the model which fetches the data, then use the controller to fetch the view, and then feed the data into the view which then displays the data.
I'm not massively opposed to MVC, I just prefer a more cohesive approach because it seems more logical to me.
Further reading:
MVC Wikipedia Entry
MVC: Not a good architecture for websites
Occam's Razor
As may be indicated by the title, I'm a big fan of Occam's Razor. For anyone who has never heard of it, it's a philosophical principle which states "entities should not be multiplied unnecessarily". Basically; keep things as simple as possible, because the simplest answer is probably the best answer. Although the principle originally applied to scientific and philosophical hypotheses, I strongly believe it is highly applicable to web design and development.
Over the past few years pre-built frameworks and content management systems (such as WordPress, Drupal and Joomla) have become very popular and widespread. Essentially these are pre-written libraries of code which are intended to make the development of a website much faster and easier by providing a lot of commonly used website elements and functionality. In the case of CMSs, this means that all the developer has to do is set some configuration options and a website can be made live in 10 minutes.
I've experimented with several PHP frameworks including CakePHP, CodeIgniter and Kohana, and I've dabbled in all the most popular content management systems (mentioned above). I can certainly see why one might want to use them; they provide a lot of great functionality, and they're especially good if you're not an expert in PHP because a lot of the groundwork is done for you. In the end though, I'm in agreement with the inventor of PHP Rasmus Lerdorf when he says "their "jack-of-all-trades" attitude leads developers down the wrong path by not using what is best for the job." If you use either a framework or (especially) a content management system, you start off with a library of between 300 and 10,000 files (perhaps more), the majority of which you probably don't need for that specific project. This is bloat, plain and simple.
Another problem, leading back to Occam's Razor, is the fact that it will be highly unlikely that a developer using a framework will be able to go into any given file and fully understand what any given piece of code does. This makes customisation trickier than it ought to be, and it makes it harder to fix something that goes wrong. Some are easier than others, but learning a framework or a CMS is often like learning a whole new language with its own rules, syntax and structure, and to me the whole process seems unnecessary. Obviously there are definite up-sides to using a framework, but I personally hate being forced to work in someone else's paradigm and prefer to write all my code from scratch and in my own style.
If I had to pick a framework to use though, it'd probably be Kohana at the moment. CodeIgniter is also good, but I wouldn't use it until it drops support for the ageing PHP4.
Occam's Razor isn't only applicable to frameworks and content management systems though. I've seen lots of examples of sites where the code has gotten completely out of hand. I've seen vast blocks of code spread across dozens and dozens of files which do not seem to achieve anything; at least, nothing that couldn't easily be achieved with a far smaller amount of code. A lot of developers seem to just completely lose sight of the practical objectives of a project and assume that "more equals better". Well, it doesn't; quite the opposite actually.
I distinctly remember my GCSE English teacher telling me that I had a talent for writing succinctly, and I think this has carried through to my programming. Efficiency is (or should be) a paramount consideration in any kind of computer/web programming - and Occam's Razor is the perfect philosophical principle to reflect that fact.
My thoughts here are somewhat echoed by Alberto Gutierrez in his blog entry "For god's sake! Keep it simple!" The KISS (Keep It Simple, Stupid) principle is another name for this approach and has been promoted by many great minds throughout history.
Albert Einstein: "Everything should be made as simple as possible, but no simpler."
Leonardo Da Vinci: "Simplicity is the ultimate sophistication."
Antoine de Saint Exupéry: "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away."
Horribly Coded Sites
As the Technical Director at Swarm, it's my job to make sure everything is coded nicely to ensure firstly that everything we make runs efficiently and bug-free, and secondly that future development will be relatively straightforward. Being a massive perfectionist is pretty useful here because it means I've adopted a very strict coding standard which I use for every project.
Over the past month or so I've been tasked to work on some websites that have been built by other developers in order to improve them, but in the end I decided it would be quicker and more beneficial in the long-term to just completely re-do these websites from scratch because the code was absolutely abysmal.
PHP (the language that I primarily use to make functional websites and which is used on over 20 million websites) is quite relaxed, in that it's very easy to write horrible code which still works. Apparently, even supposedly professional web developers have a tendency to write horrible code, and worse they can get away with it because clients will rarely have the technical knowledge to know what "bad code" looks like. It's like a lot of professions where the amount of technical or specialised knowledge is quite high; car mechanics, electricians etc. Since clients often don't know what's going on, they also don't know if a good job has been done, so it allows so-called "cowboy builders", "cowboy car mechanics" etc. to exist. Well, cowboy web designers exist too.
The level of inconsistency, poor naming conventions, seemingly random indentation and complete absence of code commenting (somewhat of a necessity if the developer wanted to come back in a year and continue work on the site) that I've seen is really staggering. A lot of the code seemed to be just copied and pasted in. I don't know if this is down to sheer inexperience/incompetence, or just a complete disregard for the client and an attempt to quickly churn out a site as fast as possible in order to get paid, but either case is quite disheartening.
I really do hope these sites aren't representative of web development as a whole, but I fear they are.
In contrast, I take a lot of pride in the code I write, and if a client ever wanted me to show it to them and explain exactly what it does, I'd be delighted to do so.
