What tool(s) do you use when developing a site like this (Adaptive Path)? I’ve read that Dreamweaver MX 2004 has better support and rendering of CSS (if you paste the AP pages and sheets into current Dreamweaver, it’s really impossible to tell what’s going on).

Easy to use, great looking and a seemingly simple design.

I’ve been trying to convince co-workers that we should use CSS only, unfortunatelly most complain that japanese fonts are hard 2 control.

After I bought Eric Meyers New Riders book I realise that css goes way deeper than I thought, actually really want to buy others and learn more.
Keep up the good work.

This usually refers to the ease of maintaining the content and markup, not necessarily the CSS file.

[1] By removing all the presentation junk from the markup, it gets much easier to see content and proper structural tags. Content changes can be made without needing to wade through tons of table and font tags.

[2] With the way I set up AP’s style sheet, they can simply change the body class to switch a two-column layout to a three-column, and vice-versa — no tables to reformat.

[3] Design changes can be controlled site-wide through one file. AP can focus on adding content or making changes to their site, without worrying about the design details and the extra cruft that used to hold their site together.

[4] Most of the site is now pure text, styled with CSS. In the old version, headings, subheads, pull-quotes, and navigation pieces were all made with images (and in some cases where javascript rollovers were used, multiple versions of each image). Now that almost everything is text, AP can simply change it whenever they feel like it, without needing someone to boot up Photoshop, change multiple images, re-export them as gifs, then upload them to the site.

Yes, when you’re doing everything with CSS, the style sheet usually grows larger/longer than some people are accustomed to seeing. This is why I use comments to break the CSS into logical sections. I also try to use easy-to-understand id or class names if they’re needed. It’s important that long style sheets stay as organized as possible, just for the reason you point out: sometimes someone else comes along who needs to make changes to the style sheet. If it’s sloppy, unorganized, and the rules have no consistency to them, it will be much more difficult for a new person to come in, make sense of what they see, and find what they need to change.

When i look at the CSS for adapative path, or any large CSS for that matter that unavoidably sets lots of specific rules, ends up being quite difficult to read.

No doubt it’s less consuming than going into markup and changing things, but at the same time, I see a definite learning curve if you pass on a stack of CSS tags to someone who perhaps is an editor or not familiar with it.

However, if the number of partners happened to go up or down by one, it wouldn’t be difficult to either resize the images so they fit within the same width (or a close one). Or we could resize that column. If the number changed by more than one in either direction, I’d probably just redesign that box somehow, once I knew the parameters.

The whole team photo section is bound to be changing soon anyway, as the partners get more “official” (read: professional) photos taken in the near future.

I’ll admit right up front: The <strong> tags are nested inside the h4s as pure hooks for more complicated styling. I wanted extra “bits” (my term for the small rectangular images which echo parts of the logo) in the design, but I didn’t want these decorative images present in the markup. To do this, I needed an extra element so that I could work with two independent background images which anchored themselves to the left and right side of the browser within the same block. The h4 gets the white/dark-green “bit” image that appears in the right side of the header, and the strong tag gets set to display:block and provides the second element for the large main header image which appears on the left.

The extra span element is used to hide the text via the FIR method, described in this tutorial.

As for whether this hidden object gets marked up as an h4 or h2? In my opinion, this minor text label didn’t warrant the second highest heading level, so I bumped it down two notches.

Your suggestions for the Contact page are dead on though, and worth implementing when we get a chance.

I don’t make any apologies for adding in these extra elements as hooks for additional styling. These elements may be redundant in some cases, but they don’t remove any semantic value. I try my best to keep the code I produce as simplified as possible. But I’m not a semantic purist — look elsewhere for that. I’m a designer. And I’m tyring to work with what we’ve got to produce the most aesthetically pleasing designs I can.

I have a couple of minor issues.

The section headers are coded like this: <h4><strong><span>Services Sections:</span></strong></h4> Shouldn’t the h4s be h2s? And couldn’t you define font-weight: bold for the headings instead of using the (seemingly redundant) <strong>?

On the Contact page, shouldn’t the list of partners be a definition list, similar to the list of services on the Services page? And why not use address for the address?

Hey Leonya, most of the backend for Adaptive path is pretty simple right now. The whole site is controlled by four Movable Type blogs: Appearances, Essays, News and static content.

The appearances blog outputs team appearance content on http://www.adaptivepath.com/team/ and http://www.adaptivepath.com/team/appearances.php.

The Essays blog controls output of the individual essays as well as the essays index and the essays archive index. It also produces a listing of the latest essay by each team member on each of their individual pages. Each entry in the blog is a full essay with excerpt and is categorized by author and subject which makes for easy indexing down the road as well as the conditional output to the team members’ pages.

The most exotic wrestling with Movable Type on the AP site is the news blog which contains all of the other dynamic content on the site (including Articles Elsewhere, Essay Announcement, Interview and News). These seemingly disparate types of information are output differentially using categories (as with the team members essays).

The static content blog is something I started doing recently with Jad Fair (http://www.jadfair.com). Essentially the blog contains no entries, but only templates and template modules. In a perfect world (which AP will reach when we finish up later this year), every single piece of static text and all image tags will be editable through the Movable Type interface obviating the need for anyone to go in an edit files on the file system or to hunt through hundreds of Movable Type templates.

With Jad Fair, I made a gateway page with direct links into every part of the system that Jad would have to use (screenshot). This was important because Jad’s system is even more complicated than the Adaptive Path site is currently and Jad is a novice when it comes to web design so I didn’t want to present him with a very steep learning curve.

If you look at the screen shot, you’ll notice that from that page, Jad can not only access every part of his site, but can also get many different views of all of the entries in the system in every blog. There are also links to create new entries and, in the static content section, links to each template module containing static text. This is essentially what will happen later with Adaptive Path.

We also strived to keep repeating elements out of the templates so every page sets a certain number of variables (main/sub page flag, layout type, and title) and includes the header, footer, announcement box and mailing list box via PHP.

The header file is not static HTML but in fact a full-blown PHP script which sets up functions for use throughout the site and handles differential HTML output between sections as well as top-level pages vs. subpages (e.g. /team vs /team/veen.php) and more…

Lastly the announcement box is a nice piece of coding which essentially dynamically outputs the most important announcement relevant to the current section being viewed. The script initially searches for the top-level (site-wide) announcement file in the web document root directory. If it exists, the contents are read and displayed as the PHP include on a site-wide basis.

If the top-level announcement file does not exist then the top-level section directory is searched next. For instance, if you are loading this essay, then the script would look in the /publications directory for an announcement box relevant to the publications section and that would be displayed regardless of how deeply you descend in that section.

In this way, each section can have its own custom announcement box, or, if there is really big news, they can all be overridden by the main announcement box file.

Needless to say, all of these files can be edited via the static content blog described above.

There are many other things in store for Adaptive Path later in the year, but I’m not going to give away any surprises at the moment. Eventually, as soon as I get some time NOT developing sites, I’ll write up a lot of these things that I do with each client in an article in an online web design zine to be named. I will also explain how, with my most recent client, I pulled together the Movable Type and phpBB user authentication systems for a universal login and seamless integration on the site. Fun stuff!

In closing, I will say that a large part of making PHP and Movable Type work for clients is customizing the MT interface for their needs and making things drop dead simple. After development has ended, my account becomes the administrator account and can be used to control everything and anything but is rarely accessed. All user accounts are set up with permissions to do only the things that are necessary for each blog. On a blog with no categories, no one has permission to edit categories. On the static blog, the only two actions available to people are template editing and rebuilding. This strips down the interface to the bare essentials. Of course, in the case that a gateway page exists, it’s hardly necessary to even navigate with the MT system itself since all links are direct links to the parts of the system needed.

That’s all folks!

P.S. Hey Doug. Sorry to take up so much space… :-)

Update: (inserted by Doug on 15 July 2003) I copied and pulled Jay’s comment up to a main entry a few days ago, which now carries its own comments thread.

the rest is great!

For those who’ve been asking, yes, there will certainly be a write-up coming soon to explain some of the decisions and techniques used for the AP site.

As for the footer, I can’t believe so many folks are that amazed by it — is it really that difficult? I’ve been doing it on SuperfluousBanter for a while now, and I didn’t have to use any tutorials or instruction books, it just worked the first time I tried it…

Of course, now I have to go back to the drawing board for my corporate site design, since you’ve just raised the bar… damn you! ;-)

MNS