Does it look like an XSLT-based website to you?

Arseni Mourzenko
Founder and lead developer
176
articles
February 14, 2015
Tags: interaction-design 9 short 50

The ar­ti­cle talks about the source web­site, the web­site which hosts the source code of pub­lic pro­jects.

Five years ago, I was chal­lenged with a prob­lem re­lat­ed to source code. I had to make it some­how ac­ces­si­ble from any­where, pri­ma­ry to make sure my cus­tomers could get the source, but also to be able to share some pro­jects with the world while keep­ing them on my servers.

Since I was us­ing SVN, the choice was ob­vi­ous: Apache with dav_svn mod­ule. And so I did it, and it was great. Ex­cept that it sucked.

dav_svn has an in­ter­est­ing fea­ture: it al­lows to spec­i­fy an XSLT which process­es the XML files de­scrib­ing a par­tic­u­lar di­rec­to­ry with­in the repos­i­to­ry and gen­er­ates a nice HTML out­put. The goal was to per­son­al­ize a bit the site, so that cus­tomers could vi­su­al­ly iden­ti­fy it as be­ing a web­site of Pel­i­can De­sign & De­vel­op­ment. So came orig­i­nal­ly the logo, and then the en­tire head­er and foot­er, iden­ti­cal to the one which was used on the home web­site.

The trick was to hard­code the head­er and the foot­er di­rect­ly in XSLT, and reuse CSS files from the main web­site. The re­main­ing part was rather dull: for every di­rec­to­ry, the page list­ed di­rec­to­ries in one row, and files in an­oth­er row. Bor­ing, but it does its job. The files were served as is, no head­er or foot­er—there is no way you can ap­ply XSLT or some­how cus­tomize dav_svn re­quests to files.

Dur­ing mi­gra­tion of web­sites to Lin­ux servers (and by mi­gra­tion, I mean a mas­sacre), the source code web­site had to suf­fer a lot. It didn't went down—this web­site was ac­tu­al­ly pret­ty easy to move to Lin­ux, much eas­i­er than web­sites us­ing ASP.NET MVC—but since it re­lied on the main site's CSS files, and those were com­plete­ly bro­ken dur­ing mi­gra­tion, the source code web­site had a rather ugly face with an enor­mous CSS sprite as its head­er, and then an un­styled page. Google bots couldn't both­er less; real per­sons prob­a­bly asked them­selves WTF is go­ing on.

So in­stead of wast­ing my time fix­ing the styles on the main web­site, I de­cid­ed to make a few changes to the source code web­site. A hour ago, I re­leased the new ver­sion of it.

Screenshot of the source website showing syntax highlighting

Same tech­nol­o­gy. Same con­straints. But the new ver­sion has few in com­mon with the old one.

Two ma­jor changes were the abil­i­ty to browse files with­out leav­ing the in­ter­face and the syn­tax high­light­ing.

The in­ter­est­ing part is that there is prac­ti­cal­ly no pro­gram­ming in­volved, and the amount of work for this pro­ject is ridicu­lous­ly small. First, I start­ed by reusing Omega¹ styles, which was fun, since they en­able to get a ba­sic lay­out very quick­ly. This meant that there is prac­ti­cal­ly no CSS to write: just a few for the di­rec­to­ry tree and the main pan­el. The abil­i­ty to use our mini­fi­ca­tion ser­vice to trans­form LESS into CSS (as well as, lat­er, to process JavaScript with Clo­sure Com­pil­er) was also very help­ful.

The next part was to add in­ter­ac­tiv­i­ty. Noth­ing com­pli­cat­ed, giv­en that the most ex­cit­ing part—the syn­tax high­light­ing and the dis­play­ing of Mark­down files—was han­dled by the ex­cel­lent li­braries Prism and marked, that is what is used to pow­er this blog. I didn't even have to think about the way I should add those li­braries: the blog en­gine served as an ex­am­ple (or rather a source of shame­less copy-paste). Re­mained AJAX part which dis­plays the ac­tu­al files, giv­en that this is very easy to do, thanks to jQuery.

I don't think this looks like a pro­ject done in less than a day.

I've of­ten read mes­sages from per­sons com­plain­ing that they have tech­ni­cal con­straints or they don't have enough mon­ey to make things right. This pro­ject is an ex­cel­lent ex­am­ple, for them, of what can be done in a very short amount of time with no much tech­ni­cal skills and with­out the ha­bit­u­al sup­port from a serv­er-side pro­gram­ming lan­guage.

*1* Omega is one of the internal projects; it has also set a common visual style guide and a set of visual elements to be used on the websites of Pelican Design & Development and expected to be used on the next version of the corporate website.