I’m a self-taught web programmer, and I’ve noticed that to a degree all technical books, inevitably, present best-case examples, in which programming is starting from scratch, and the project is fairly simple and well-defined. That’s a reasonable fantasy to use for didactic purposes. After all, it would be distracting for an author, or a reader, to address the points of a programming language or framework or whatever the topic of the book may be if the author had to make the scenarios in which the knowledge is put to exemplary use realistic. It goes without saying, though, that actual experience is different.
I’d like to offer a little peek, then, into my own application of some new technology I’m trying to master–Web 2.0 techniques using Javascript–to a project that seems typical of the kind of work journeyman programmers like me tend to do–a small online store and content site with a small budget. The interesting thing about the work is the way I’m using a fairly inflexible but fully-featured online store package as a CMS and publishing system to produce skeletal HTML and then layering over that somewhat HTML a platform of unobtrusive Javascript and CSS that handles layout, presentation, behavior, and occasional asynchronous communication with the server.
I’m hoping that writing about it will bring my own thoughts into focus and might help other programmers confronted with applying technical knowledge to their projects’ actual conditions.
My project is for a fine arts publisher that sells magazine subscriptions, back issues, prints, and art books. They had an existing site, with an online store, but they were dissatisfied with their web presence. The staff of the magazine is small, and maintaining a website is time-consuming for them. They want to sell their products online with a minimum of fuss. They want to present lots of content, mostly imagery, to showcase their products. They also want their site to arrest viewers with its visual sophistication and considerable set of functions and to please them with its ease-of-use and beautiful content. To meet these ends, they needed something new. And they don’t have a big budget, not enough to do a lot of custom programming or buy sophisticated software or hosting packages.
My approach thus far has been to find the best off-the-shelf solutions available and to try to extend them as much as possible to accomplish my client’s goals for the site. I proposed selecting a shared hosting package at my client’s existing service provider, and the software that came bundled with the package, instead of going to a shared virtual server and picking custom software. This was more economical month-to-month, and it saved me the time and them the expense of installing software and getting myself up to speed on it. The hosting package came with online store software, ShopSite 8.1. Although not the greatest software (its page templating system is fairly inflexible and produces ugly HTML), it is well-documented, mature, and has sufficient points for customization and extension. We were able to get the cart and checkout running on it in a matter of days.
The pages that would be considered product listings, though, remained flat HTML. ShopSite doesn’t offer very inspiring default page templates, and they certainly don’t support dynamic HTML or Ajax functions. Happily, ShopSite does have respectable custom template support, so I went to work on prototyping HTML .
I’m not trying to make it sound more impressive than it really is, but practically speaking what I’ve done, I think, is to reduce the published HTML to merely content, to structured information, whereas the javascript layer handles presentation. Normally, separating content from presentation is a concern on the server-side. That’s what all the talk about models and views is about. But I don’t have a server-side application layer. I have an online store publishing system that accepts text and filepaths in an online form and then publishes HTML according to the templates you provide it.
So here’s a snippet of what the HTML looks like, for a book listing page. First, I put div elements that will outline the contents of the page and give my javascript and CSS something to work with. But I leave those div elements empty:
<div id="book_title"></div><br />
<div id="shopper_info"></div><br />
<div id="details_display"></div>
Then, a little lower on the page, I set up a structure of div elements to hold raw content. The outer div element will be styled display:none so that all this ugliness stays hidden:
<div class="ds" id="books_info">
<div id="ds_melville_moby_dick" class="ds_book_id">
<div class="ds_title"> Moby Dick </div>
<div class="ds_artist_name">Herman Melville</div>
<div class="ds_itemnum">1001</div>
<div class="ds_price">$45</div>
<div class="ds_add_to_cart_link">http://myclntsite.com/cgi-bin/blahblah</div>
<div class="ds_details">
Moby Dick, or The Whale by Herman Melville<br />
Introduction by Thomas Pynchon<br />
Commentaries by Robert Penn Warren, John Bonham, and Gene Roddenberry<br />
A So and So Book, published by Such and Such<br />
Hardback, 8 x 10 inches, 744 pages,<br />
15 illustrations<br />
ISBN 123123-11-8 <br />
</div>
...
So that’s all I’m having ShopSite produce, just a skeleton of page structure, without content, and then content with semantic structure. Javascript will take the content, process it, and place it inside the structural elements. The “book title” element will get the book’s title, obviously, and the “details_display” div element will show the contents of the “ds_details” element, probably without any alteration. But the “shopper_info” div is more interesting. It’s going to have the price and a link to purchase the product. I could perhaps template that out in the HTML somewhere, but for now it’s coded into the Javascript. My CSS files will handle layout of the structural divs once the content is in them and they’re ready to display. I’m using a lot of absolute positioning to lay content out precisely and give the interface a desktop application feel.
Whereas a typical product listing page would show several items in limited detail, the visual design for the page provides a sort of product browser: multiple items appear as representative thumbnails, and one item at a time is displayed in detail. The user can scroll through the thumbnails and, on selecting one, bring the associated item’s content up. My solution thus far is to load in all the products’ information and then use a combination of DOM manipulation and source and value updating in javascript to power the UI’s browsing functions.
This just scratches the surface of what I need to do with Javascript. I hope to write future installments on this topic.
- Image path building with Ajax and JSON: There are numerous images to load for each book. Indeed, the page design calls for a way to flip through these images. It would be very clumsy and error-prone to store multiple image paths in ShopSite’s product form, so I’ve created a product code that is entered into one of ShopSite’s “custom” fields. All the product’s image files will have to contain this image code. An Ajax call will hit the server, where a custom script I’ve written will report back a structured list of image paths. In fact, it will send back a JSON (JavaScript Object Notation) string ready to be evaluated.
- Just-in-time content fetching with Ajax and static HTML pages. My strategy of writing out all the products’ data into those hidden semantic div elements is fine with books, of which there are only a dozen or so, but other categories hold many more items. Plus, the books have long descriptions, which I didn’t show in my snippet. In time, I’ll need an Ajax solution that calls out for large blocks of text, probably from static More Info HTML pages that ShopSite generates, and does so just when the content is needed, not all at once up front.
- Complex content condensation and storage in ShopSite. The books’ authors, for instance, will each have an information page that my book template needs to link to. magazine issues will have multiple articles, each of which in turn has photos and authors to keep track off. I like using ShopSite as one CMS interface for products, but how will all this get stored in the custom fields it offers.
- And, what about people who turn off Javascript, or people who use adaptive technology like screen readers? Those folks should be able to at least get information about the products and have an easy time buying them if they want to. I’ll need a separate but complimentary page strategy for them too.
Stay tuned.