Magneto

Magento was my first port of call as it does look head and shoulders above any other free offering and indeed the feature set looks rich enough to compete with many commercial offerings. What I discovered rather quickly and frustratingly was that Magento is horribly complicated to skin and manipulate. The learning curve of Magento is quite possibly the steepest I have ever come across in open source product. I’d love to get to grips with Magento and really learn the ins and outs but it seems that Magento skinning and tweaking is a skill picked up over the course of months and months rather than days which is really what you need when you are coming into a project that is already on a tight budget.

Magneto Commerce

osCommerce / Zen Cart

osCommerce seems to be going strong after many years of open source development. The issue I always had with osCommerce however is that it feels badly put together and not entirely secure. The organisation of the source files and the admin interface were always pretty shabby. Now in osCommerce’ defence the last time I used a release was many years ago but unless there has been a complete overhaul I can’t see this being much improved over that version.

Similarly Zen Cart seems to suffer the same fate. The admin interface screams osCommerce and if Zen Cart is simply osCommerce re-labeled (not confirmed but likely) it will more than likely have osCommerce like issues.

osCommerce | Zen Cart

Cubecart / X-Cart and similar

Cubecart, X-Cart and similar sit on on a level above the free offerings but below the full blown commercial offerings. They are solid products but are still commercial offerings which deduct, however minor, from a project’s budget. Had I not found the next open source product in this list I would have probably stumped for one of these or one of there many derivatives which are all fairly similar in features and set-up. Again solid offerings but not within the open source range.

CubeCart | X-Cart

OpenCart

My saviour. Quite frankly not a great deal seems to have changed with regards to open source ecommerce products since the break through of Magento apart from this neat piece of development.

The structure of OpenCart follows MVC, Model View Controller and in general the code is nicely put together and feels clean as well as secure. Following the MVC convention makes OpenCart as flexible and as complex as you need or want it to be. The admin interface is clean and rather aesthetically pleasing whilst being packed with features.

The only grumble I have over OpenCart is that it’s realtively young and as such the community and documentation is not quite on par with say, Magento or osCommerce. As the product matures however I am sure that this will only improve.

The most impressive feature of OpenCart is without doubt the lack of bloat. Possibly a positive knock on affect of its young age, the simplicity of the code and the way it is structured in comparison with the punch it packs is quite glorious.

OpenCart

In Summary

As I’ve mentioned above major players in the open source community don’t come and go overnight particularly not in a category as crucial as ecommerce development. So it wasn’t particularly surprising to find that there was not a great number of new stable ecommerce offerings to choose from.

Magento I feel is a definite market leader and something that every self respecting developer should take the time to understand if they are working regularly with ecommerce projects that require open source assistance. OpenCart for my money however can not be beaten for feature set versus learning curve. OpenCart apart from the usual road bumps in using a new open source package has been delightful and will be a project I keep an eye on for any future ecommerce projects.

If I’ve missed any great open source eccomerce offerings, please do let me know in the comments or via the contact page.

Now I’m not exactly an early adopter when it comes to social tools. I have a Twitter account that I seldom use. Although the concept of Twitter interests me the lack of desire unfortunately leaves me with a sparse account page with no followers or followees.

Again my interest was aroused in a similar way yesterday when I awoke to find that the new Buzz feature had been added automatically to my Google Mail account. After poking around for a few minutes I soon discovered what it was all about. Admittedly if there was a big banner in the UI that said “Buzz is Twitter but with videos and images in line as well as integration with your inbox” the penny would have dropped sooner. I think because of the striking similarities to Twitter it actually took me longer to work out what Buzz was. I was looking around for something that wasn’t to there to be found ie. something so different it wasn’t just twitter with caveats. Note – I still haven’t got my head around the public facing profile side of Google Mail, how it ties into your Google Account etc.

So what I was looking at was a Twitter clone with bells and whistles. That’s not to say that Buzz doesn’t offer an improved service to Twitter. The promise of the precise locating and review tools Ala Foursquare are certainly exciting as are many other improvements over Twitter. I love the fact that you can follow a conversation between two users on the same page. Incidentally the improved functionality of comments in comparison to Twitter brings me to one of the little annoyances of Google Buzz. It’s messy! Surely Google could have spent a little bit of time and added a little bit of shine to the public facing profiles. I mean look at the way the comments are formatted, how much time would have really taken to have just place a dividing line between one comment and the next or alternating row colours.

I saw a great tweet on the subject, it went something like “Google Buzz just looks like a messy version of Twitter”. Is this going to be the general consensus among Twitter users? If so Google need to fix it because lets face it Buzz’s early success will depend on Twitter users jumping ship. Will Twitter users actually use two micro-blogging social networks? I can’t see it.

This brings me to the reason why I’m personally going to hang-fire on Google Buzz for the time being. People have spent time building up relationships and followings on Twitter and with no import feature and no way of carrying that over to Google Mail I don’t think many people will be interested in making a switch just yet. Nor (as I stated earlier) do I think people are going to use two services as similar as Buzz and Twitter at the same time.

It is going to be interesting to see how this one shapes up over the coming months. I think we’ll get a similar divide between the two as we did with Facebook and Myspace but who’ll come out on top is much less obvious this time around as both offer such quality services. If Google can convince the everyday email user that Buzz isn’t a waste of their time then Buzz could become the every-man’s Twitter and Twitter may become a niche community, Twitter a nice community?! Well stranger things have happened.

My ‘beef’ is not with CSS3 itself but more with the countless lists of cool stuff you can do with CSS3. As a language adds more and more features and the complexity of the code expands there needs to be some grounding. Those that know CSS and know it well will already but fully aware of the great additions CSS3 adds to the previous versions. Those that don’t know CSS too well are just being fed more and more code to copy and paste and this is where the problem starts.

CSS3 isn’t a new language that replaces the previous versions of CSS, it is merely an enhancement, an improvement of what has come before it. The original ideas and the underlying philosophies are still the same. With the limitations of CSS decreasing, the opportunity for sloppy, bloated code increases. The original premise of CSS of course being lean code that separates presentation and layout.

I suppose the point I’m trying to get at is that as a community we should still be encouraging people to go back and understand the basics of CSS before writing up another list of ‘cool’ techniques using CSS3. Les’ we forget that CSS3 is still a good few years away from being a viable language that is usable cross browser. Progressive enhancement you say? Folk concerned with progressive enhancement don’t need another ‘cool’ list, they’re already there, they aren’t reading these ‘cool’ lists posts because they don’t need to.

My original fix, like many, was born out of pure necessisity. I needed a solution to allow me to present smoother embedded type faces for Internet Explorer. What I found, I shared and hopefully it’s been of much to use to people.

On Firefox & Safari

Despite being able to disable ClearType in Internet Explorer it would seem there is no way to do the same in Firefox or Safari. This leaves an issue in Windows Vista and Windows 7 as they have ClearType forced on system wide by default unlike Windows XP. Dependant on your Firefox/Safari visitor percentage this may not be an issue. Some fonts do however fare better …

Hinting

A major factor in how well your font face will render under ClearType is to do with how well the font is hinted. Some are good, some are bad and some just aren’t ready or were never intended to be rendered on screen using embedding techniques. Again the only real way to determine this is by thorough testing. Font Dragr is a fantastic tool for quick testing of fonts and how well they embed. Also be sure to take a look at Front Friend.

Current Solutions

Unfortunately there isn’t anything that can be done right now for Firefox and Safari in terms of disabling ClearType. The key at the moment is selecting a well hinted font face and tireless testing. Experimenting with text-shadow has produced mixed results for me but I’d definitely recommend you give it a try. It may help alleviate some of the jagged nastiness should you come across it. For this you may also want to look into detecting if font smoothing is actually being applied on your visitors machines. There’s a great piece of Javascript that you can use for this here.

Future Solutions

As always there are people and organisations already working towards fixing these issues. More and more fonts are being reworked and properly hinted for embedding purposes. Below I’ve outlined two other solutions/advancements that may be of interest.

CSS 3 – font-smooth

A little known part of the CSS 3 specification and as of now completely unsupported by any browser is the CSS font-smooth property. Reasons why this is unsupported could and probably are complex and varied. This being implemented even just in Firefox could be a godsend for front end developers dealing with the issues mentioned in this post. See more about font-smooth here. As yet there hasn’t be any news of when and indeed if this will ever be supported by browser makers.

DirectWrite rather than GDI

This advancement is a little more technical than a simple CSS property but does look promising. This tip comes courtesy of Charles Roper in the IE7/8 ClearType fix article comments.

From what I understand, at present ClearType is currently implemented using a GDI technology which isn’t great at anti-aliasing the Y-axis of embedded font faces. An innovate alternative which is currently planned for use in FireFox 3.7 and Internet Explorer 9 using DirectWrite improves substantially on this. Some writeups and examples are presented at the links below:

• GDI vs DirectWrite
• Better Postscript CFF font rendering with DirectWrite

Also interestingly a browser using DirectWrite over GDI can use a fix to disable ClearType. I’ll post more on that at the time. At the moment both Firefox 3.7 and IE 9 look a while off.

If you have anything to add to the above please feel free to add in the comments.

Up until now a viable way of embedding attractive typefaces in web pages has been elusive. SIFR, cufon and other replacement techniques gave us designers a hope and a glimmer of what could be but they also gave us our fair share of stress and frustration.

So what has changed? Recently? Quite a lot actually, I was first alerted to something possibly big coming down the pipeline when the FontFont foundry (one of the biggest and most popular type houses around) changed their eula to allow certain types of embedding. Now these changes still don’t allow web embedding via @font-face but they had effectively acknowledged SIFR (but not cufon) and similar techniques and deemed them legal. Why they only just changed is beyond me, given the age of SIFR and related techniques. A few more questions – Seeing how SIFR has only just been effectively legalised by them, does that mean using FontFont fonts in SIFR has been illegal thus far? If so what have been the consequences? Has there been any high profile legal action against web sites using FontFont’s fonts via SIFR? As you can see the change created as many questions as it did answers.

What this change in eula did show, however, was that embedding fonts was being looked at closely and would be addressed sooner rather than later. Despite being frustrating to not have a direct answer to @font-face related queries this change gave a hint that something more to come.

Introducing WOFF

WOFF is a font format that has now been given full backing by FontFont and a whole host of other type houses. It’s also gained traction with the W3C, Firefox (from 3.6) and many more influential figures. FontFont’s marketing director Ivo Gabrowitsch on the subject -  “FontShop International—home of the world’s largest collection of original, contemporary typefaces, the FontFont Library—supports WOFF, since users, designers, and foundries all need a Web fonts format.”. So it does look as though a realistic solution for all is just around the corner.

Basically WOFF isn’t an entirely new font format rather it’s a wrapper for the existing open font type that allows greater compression (good for embedding) and more importantly; allows font creators to add additional meta data to the existing font properties. WOFF can therefore be set to only allow embedding on one domain and isn’t as easy to download and use as a system font, which is the problem of the currently completely open @font-face specification.

The final plan looks to be for font foundries to distribute web only versions of their fonts maybe at a reduced price for web use only.

There has been no word yet of implementation for web-kit and other rendering engines but with so may pros it must only be a matter of time before other browser vendors grab a hold of this and run with it. Take a look at the mozzila blog post on woff for a more in-depth explanation. This really could be the breakthrough that designers have been begging for for years.

So that’s great, but what about right now?

There’s an answer for that also. Just before the news of WOFF started to sweep the web I came across an amazing tool from Font Squirrel, which will no doubt become as useful as any other online tool or application I use on a daily basis. The @font-face generator can take any font file and return a kit ready for embedding that is supported on every browser your likely to be testing on. In my last post about @font-face I complained about the impossibility of creating .eot files to serve to Internet Explorer but this generator completely eradicates the problem. Of course the same licensing issues apply to any font face you send through the generator but with so many free fonts available this tool gives designers a fantastic amount of freedom. The generator also includes a .woff file with every kit but at the moment I’m guessing its pretty much the same as the True or Open type font file.

If you haven’t already I strongly suggest you get over to Font Squirrel and see what they have to offer. Also take a look at their pre-packaged @font-face kits.

To sum it up …

Things are definitely looking up for font embedding, since my last post a mere two months ago we now have a solution to get @font-face running cross-browser, albeit still without commercial fonts and a embedding solution in the works that should allow designers to buy and embed commercial fonts to there hearts content.

PS – Font as service

As I was writing this article the thought of font as service providers popped into my head. I think it’s safe to say with the future looking so bright for embedding and a usable alternative to font as service offerings available right now the future looks rather bleek for the like of Typekit and co. Assuming they have deals in place with font foundries already and get off the ground, I can’t see people going through the pain of using their application when they can go straight to the type foundries themselves and effectively cut out the dependency  ona middleman out.

It just goes to show how quick things can change online. My guess is font as service providers are quite worried about recent developments and could well be buried by technology advances if they can’t change there plan around quick enough.

For a full and frank summary of the debate so far take a look at this round-up on w3.org. Said round-up is dated as being written in 2008 but the information it contains is still relevant up to the very second of writing this article.

As it stands Firefox, Safari and shortly Opera support @font-face and this allows you to embed otf and ttf files within your stylesheets and pages with relative ease, see webfonts.info for a good guide on this. Internet Explorer have allowed font embedding from IE in versions as early as IE 4 but here’s the problem, embedding in IE must be done using a proprietary Microsoft file format known as eot.

This is where the frustration starts because Microsoft make it practically impossible for you to create these files. They have software that is supposed to convert .ttf (note no .otf support) font files to .eot but guess what it’s completely unusable – to the point where I wouldn’t even link to the software to save anyone else trying to use it.

Now the idea behind Microsoft’s eot format is incredibly sensible, they are in effect putting the type foundry first. EOT is designed to provide as much protection as possible for font creators, something that undeniably @font-face doesn’t.

So the solution is …

In short there isn’t a solution and unfortunately it doesn’t look as though there will be one anytime soon.

Your options as a designer are to use @font-face as a perk for visitors with modern browsers and risk licensing issues with various fonts or continue to use a current font replacement technique such as sIFR which again has its pros and cons.

Finally another option that may be available very soon and I’m increasingly encouraged and worried by at the same time is the ‘font as a service’ option, take a look at this great article on the subject from Elliot Jay Stocks for more information.

The positives to be taken from all this hoopla is that at least now we are talking about web fonts and everyone is listening. Everybody in there own way is now trying to find a solution to the problem of web fonts and that can only be a good thing.

Whether it is @font-face, eot or some other type of open embedding, font as a service or a more intelligent replacement technique I get the feeling we are closer to improved web typography now more than ever.