One of my favorite clients, whose site launch we’ll be announcing here soon, asked me to customize his SmugMug Pro installation for him. For those not familiar with SmugMug, it’s a hosted gallery application. The Pro version allows people to order prints and photos of your gallery entries, and you can make money with your photography or artwork in a similar fashion to how CafePress works. The printing, shipping and payment collection are done by SmugMug, and you get the profit over their base price. A VERY cool concept.

One of the things the SmugMug team touts is the fact that they use xhtml/css throughout their hosted gallery. This is true. They also tout the fact that it is totally customizable. This is much less true. Why is that? The system is set up in a very convoluted way. Rather than having access to the xhtml and css that runs your site so you can customize it, instead you have to OVERRIDE what’s there, which is vaguely possible in the css, and only in a few places in the xhtml. Now I do understand that this is a hosted situation, and that always imposes some limitations. But what I found was . . . um . . . interesting.

Since this was my first time customizing a smugmug site I wisely decided to start with an existing theme that was very close to what we wanted, and alter it for Scott’s smugmug site. The first thing I found out was that there is a stylesheet that gets loaded into the page that’s around 1300 lines of code and that defines pretty specifically almost every html element that gets fed to you. Now, I don’t know about you, but most of my stylesheets to run sites run around 300-400 lines of code for the entire site. Now, 1300 is HUGE. But it’s worse than that. The theme you use has its own stylesheet that adds another few hundred. Then the customizations you do are OVERRIDES of that 1300 line monster that are done as embedded styles in the head of every smugmug document (those styles aren’t cached.) Add to this fact that these sites are photo and image gallery sites and you’ve got something that it’s almost guaranteed will be a nightmare for someone on dialup, which is still, believe it or not, around 45% of the US population.

It gets worse. Most structural elements in that 1300 line css monster had heights defined. That means if you want to make sure stuff shows up when you alter it, you have to override it on every element for which a height is defined. My feeling is that whoever wrote this had little understanding of how the height attribute really works. Then there’s font sizes. In the majority of structural elements the font sizes are defined in pixel sizes, probably because of the defined heights. This means that in IE the fonts aren’t scalable but in other browsers they are. So you resize the font to be larger in firefox, and you narrow the browser window, and the text is cut off. The developer definitely did not follow best practices or accessibility guidelines when it comes to font sizing! Coupled with the height attributes, this is a nightmare.

If you know css well, and know how inheritance works, then when you look at the css that defines smugmug sites you’ll realize that inheritance was rerely used to shorten this behemoth. Many times when things were defined in that 1300 line monster they just plain didn’t need to be. That’s code bloat, pure and simple, and a very clumsy implementation.

This is just the tip of the iceberg. There are a WHOLE LOT of IE6 hacks that are going to most likely break every smugmug site when IE7 is released as a priority update through MS. The developer who wrote the smugmug xhtml/css code that you have no choice but to use or override did not follow best practices for IE hacking, and all the hacks are directly in the stylesheet that all versions of IE will use, which means every SmugMug site will likely look like a pile of manure in IE7.

I did get the customization more or less the way Scott wanted it. It was extremely counterintuitive to override pre-existing code in order to make things work and took me at least three times longer to do the work than if I had had more control over templating. Find/replace sure got a workout, something I rarely have to use in a well organized 300 line css file. I truly wish the devs for this ap would look at the way the ModX devs have set up templating in their ap. Maybe they could learn how it SHOULD be done, with a master html template and css file, totally editable through the interface, and subtemplates for specific areas, also editable.

Bottom line is that SmugMug is an absolutely wonderful idea. The actual backend works quite well. The galleries are very attractive when viewed “stock”. It’s obvious a whole lot of thought went into the backend. But if you want to really get into the nitty gritty of frontend customization, and you’re a frontend code snob like I am, you will be absolutely horrified.

Technorati Tags: SmugMug, xhtml, css, IE7

This entry was posted on Monday, July 31st, 2006 at 11:31 am and is filed under Web Design. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.