Send to KindleI have written twice now about taking over the maintenance of Jack Kapanka’s website. There were three distinct phases of working on the site:
- Fix the broken links
- Change the home and store pages (adding PayPal support)
- Redesign (rebuild) the site from scratch
All three phases are now done, though there is no trace of #1 or #2 left, now that #3 is complete.
I have zero design skills. I have very limited experience building websites. Therefore, I struggled mightily along the way. I had to Google my brains out, and still had a number of false starts and long debugging sessions.
So, I decided to write this post for two reasons:
- I’m sure I’ll be building other sites in the future, and I could easily forget some of the things I discovered along the way
- While everything I did was discovered through the web, I found different bits on different sites, so I might save some poor soul a few minutes in the future if they stumble on this post
I did not take notes along the way, so this will most definitely not be exhaustive. If I later recall anything that is material, I wll come back and update this, again, just for posterity.
The site I inherited was being hosted on a shared system, running Windows Server, with IIS serving up the pages. As far as I know, I have no access to the IIS instance (which is likely shared, though I don’t really know). I have no shell access, just web and FTP.
The site was coded a long time ago, was optimized for 800×600 resolution, and was stitched together with a complex web of HTML tables, with images in different cells, which had been sliced up from original PSD files, to create a look and feel. Everything was an image, but they weren’t uniform in size. Some spanned multiple columns, other multiple rows, etc. Rearranging anything on the stite was a nightmare (for me, with my limited skills!).
The menu system was 100% JavaScript (JS). Each menu item had an image background, with the top level menus having images for the labels. Many other navigation elements on the site were JS-based, giving little or no feedback to the user that clicking would take them somewhere. There were no scroll bars for any long content (like the Bio), as they wanted the neatness of an 800×600 design, so you paged a few paragraphs at a time with JS controls.
Having nothing to do with code, the site was typical of many artist sites, very dark (in this case brown), and completely image-laden. I am sure that they think it’s edgy and cool, and perhaps it is. That said, it’s also often hard for people (especially older people, who might actually have disposable income) to see well or navigate. Lois and I prefer lighter themes, with less images, when possible.
Many of the links on the site were broken, and the reasons varied (target was missing, link had a typo, target was renamed, but still existed on the site, etc.). Some of the important content needed to be updated to reflect updated contact info and to correct typos as well.
So, the first sweep of the site was straightforward, but painful. I fixed the broken links and the content. The only thing that made that painful was tracking down the right targets or deleting the links, and finding the content which was buried deep within nested tables, while ensuring that I didn’t disturb the flow in the small viewport.
Once the site was stabilized, the next priority was getting a PayPal button on the site, and an embedded YouTube video of Angel In My Arms (perhaps Jack’s most famous and successful song) right on the front page. Most people who visit the site are looking for that, and for the ability to purchase a copy to use for the Father/Daughter dance at their wedding.
I had never incorporated PayPal into any site before, but this turned out to be the easiest part by far. Once you have a PayPal account, which Jack did, you basically log on to your account there and fill in a small form and they generate a button and the associated code that you simply cut and paste into your site. It just worked, the first time.
Embedding the video on the home page was much more painful. I didn’t have the skill (HTML or image manipulation) to embed it into the existing table structure, possibly requiring a different slicing and dicing of the background images. I wrote a separate post about Table2CSS describing this amazing tool that helped me accomplish that. Basically, Table2CSS turned the home page into a CSS-based page (no tables whatsoever), with every cell from the original table becoming a named DIV.
This allowed me to position things with much greater accuracy, at the CSS level, without having to worry about spanning rows and columns. As I said in that post, this is not a good way to code a production site, but it was the perfect way to quickly accomplish my goal, and buy myself time to consider the real redesign.
Once that was done, I was ready to consider the new site. I have direct experience with two systems for building websites: Zope and WordPress. Opticality.com is built in Zope, and this blog is built in WordPress. Both of those systems are designed to produce pages dynamically, assembling the pieces with programming logic and content that is typically stored in a database. They offer tremendous power. Zope and WordPress are but two of dozens of extremely popular Content Management Systems (CMS). They are designed to handle this exact type of problem.
Unfortunately, they are also typically designed to run in a slightly higher-grade hosting account (shared is still fine), with WordPress being more available on some lower-level hosting accounts. Neither seemed to be a good option for this account, and I didn’t want to be one of those people who told Jack “You have to upgrade your account, because I have a hammer, and therefore all problems are nails…”
Also, while I wanted/needed the benefit of a template-based solution (on the existing site, the JS-based menu was embedded directly in 50+ static HTML files!), it didn’t need to be a dynamic template system, since for the first cut, there was no need for personalization (i.e., different users don’t get different views of the same URL).
So, the first two decisions that I made (after way too much Googling, reading and a bit of experimenting) was to select the YUI Grids CSS for the base CSS layout engine and the htp: HTML pre-processor for the static templating system. The live site uses both, so those initial decisions stuck. That said, along the way, the YUI Grids frustrated me enough that I nearly bagged it, and went so far as to implement another one before switching back.
The entire YUI system (of which Grids is but one small piece) is very powerful, elegant, and well-documented. Unfortunately, I didn’t want to have to read for days, to create a simple layout, so I didn’t. In not reading, I missed one crucial piece, which none of the examples or Layout generators included. As a result, while the layout looked exactly like I wanted it to, the reset portion of the Grids system (amazingly, I actually knew what that meant) 😉 wiped out all styles. So, lists didn’t look like lists. Headings didn’t look different than normal text, etc.
Fixing it turned out to be trivial, but not when I had no clue as to what was going on. The fix meant including just one more YUI component, Base (which redefines all of the various HTML elements to a sane default that Yahoo feels works well in most browsers). I agree, and for the most part have kept their defaults, but I was pulling out my remaining single hair until I realized what I was missing.
I looked at a number of template systems, and I am completely used to the concept of templates in both Zope and WordPress. This was the first time I used a static template system. Basically, you assemble the final production page from a variety of different inputs (page fragments that can be stored in separate files, variables, blocks, etc.). You run the preprocessor on a template input file, and create the resulting static HTML file to be put on the live site.
HTP is quite powerful, yet unbelievably simple to use for the use-case that I had. I couldn’t be happier with my choice in that regard. I have a single master template for the entire site (at the moment). That one template includes a number of different files: the head section of each page (where CSS files are referenced, etc.), the header (where the Jack Kapanka graphic is placed on every page), the menu (so that I can change the menu in one place and regenerate all of the pages with a single command!) and the footer. The template then references variables and variable blocks, which fill in the title of each page and the main content and right sidebar content.
I can restructure the entire site (navigation or look-and-feel) simply, or change the content or sidebar for any individual page just as easily.
To make my life easier, after struggling for a while, I gave up on trying to pin the footer to the bottom of the actual browser page. Not only do I know that this can be done (I found many excellent working examples of how to do this), I have even done it before on other projects. What I couldn’t do was get it to work within the confines of the YUI Grids CSS, without reading tons of stuff. I just gave up, and put in scrolling content in the main viewport, ensuring that no page was too large. I’m not thrilled with the result, but it got me to where I wanted to be much more quickly, so the tradeoff was reasonable (from my personal perspective).
Aside from the YUI CSS, there are only two other CSS files. One for the menus and the other for the content. Pretty simple to maintain and both are relatively small.
Because I am sensitive to people who have poor vision (after all, I live with someone who is essentially legally blind), I coded the various CSS elements to be sized in ems, rather than pxs. This way, if people resize the content by pressing Ctrl+ or Ctrl-, the page resizes fairly elegantly (at least it did for my hundreds of tests on four different browsers, YMMV).
Finally, I also tracked down a flash-based MP3 streaming embeddable object (the first one that I used worked fine in all but IE), and used that to stream the 30-60 second snippets of a variety of Jack’s wonderful songs.
Right before making the site live, I considered that I was putting up a vastly reduced number of pages as well as renaming some basic pages from .htm to .html. That meant that links that people had bookmarked, or perhaps more importantly search engine indexes, would break on nearly every page. That just didn’t feel right.
Redirecting would be trivial in a real CMS, where the headers get spit out by the CMS, and writing logic to catch all missing pages (404s) is generally built in or trivial to write. That wasn’t the case here, and there were roughly 30-40 pages that needed to be redirected (not necessarily to a direct replacement page, but to one of a variety of catch-all pages for each category).
I found the answer on a number of sites. It involved making a directory called XXX.htm (for example). In that directory you create a single file called default.asp. In that file is a tiny VBScript that calls two functions that redirect the page. It was trivial, though tedious to do for all 30+ pages.
I’m sure I’m leaving tons of stuff out (e.g., along the way, to debug the CSS, I ended up installing the Firefox plugin called “Web Developer”, which very nicely complemented Firebug). It was a godsend to be able to change CSS on the fly, and see the result in real-time in the browser window. I also made very heavy use of the JS Console window in both Google Chrome and Safarai (on Windows). They are very similar (with Safari being more sophisticated, but Chrome being much faster).
Like I said above, if I realize that I’ve left out something material, I’ll come back and edit this in the future…
Leave a Reply