A technical walk-through of how the college catalogue is set up in our CMS, Cascade Server. It started as a note to another Cascade user, and might be helpful to others. A less Cascade-specific description of how the catalogue is set up is planned.
Just wrapped up an all-day meeting about Best Practices, including a little time for discussion about HTML5, CSS3, and support for IE6. Here are today’s major decisions and accomplishments.
- We’ll use the sprint halfway meeting for BP chats (meet once/sprint instead of once/week as we used to)
- Deprecated old BP checklist; BPs now served by SAMPLE SITE ADVANCED, wiki, and Campfire chats, with blog posts providing the glue; Best Practices Queue page in Backpack is a good place to toss ideas
- Component samples: SAMPLE SITE ADVANCED folders (we made two today: Flash, Tabs)
- Component versioning: in SAMPLE SITE ADVANCED, versions inside a “versions” folder, indexed on component page (just an idea right now)
- Identified high/low traffic sites for Universal IE6 candidacy, agreed that we’d begin using UIE6 (with a “how to” BP chat next sprint)
- Could not quite articulate a general strategy for bringing sites up to BP; it depends on a variety of factors, and may change altogether depending on how old we let sites live to be
- Figured we should wait on HTML5 until there’s more support; useHTML5 for one fairly low-traffic site to gauge impact on older browsers (possibly ColRel Editorial Style Guide, with all of its various content)
- Agreed to try and share experiences about advanced CSS selectors we had rarely used before, but can now use freely because we will drop visual support for IE6
Aside from the folks we routinely discuss (Gruber, Kottke, Zeldman, JSM, etc.), here are a few folks I have enjoyed reading recently. I included some Twitter accounts too.
Started following Andy, an iconic web standards pro, about a month ago when he shared very thoughtful posts about web typography. He also posted Universal Internet Explorer 6 CSS, which is pretty cool.
I had seen Mandy’s blog once or twice before, but I remembered her because I had seen her in a forum recently and when I revisited A Working Library it had been beautifully redesigned. I read some, and I have continued to read. The blog does look good, but I subscribe for the writing.
Trying this feed out for a while. His posts are long, but pretty good. He talks about process a lot, and seems to look at everything from the ground up, and that’s an interesting perspective.
Trying this feed out for a while. This guy’s posts are more succinct. Sorta bookmarky, and on the technical side. It’s quite good. If he keeps sharing and sharing, that’ll be something.
Webfonts.info from Ralf Hermann
Ralf is very in tune with web typography and aware of bothW3C happenings and opinions on Typophile.
Josh Porter is a genius. For me, he’s in a category with folks like Brian Oberkirch, Chris Messina, and Clay Shirky. If you follow him seeking an occasional dose of forward thinking, you will not be disappointed.
- bokardo on Twitter
“A living, open curriculum based upon web standards and best practices.” Not sure about this yet, but it looked too good not to follow.
- waspinteract on Twitter
SVA Interaction Design
A bunch of web folks in New York are teaching at SVA, starting this fall. Keeping an eye on this program.
In today’s web meeting, we discussed a few different ways to handle a specific kind of website: mini-sites. Most of our websites represent a department, program, office, or institutional umbrella, but mini-sites are different. They usually arise out of the need to publicize a particular project or effort that is very time-sensitive and/or hard to get information about. Often, the combination of urgency and last-minute information leads to stressful moments (sometimes full days) devoted to finding a place for all of the new stuff we’ve been given. We can’t predict what will be thrown our way … and yet, it has to be online in an organized fashion.
So far, we have tackled situations like these in one of three ways:
- We create a new website in which to house the information
- We create and repeatedly tweak a press release, including related links and photos
- We add (or revise) a section in an existing website, where the content makes contextual sense
To these, let’s add a fourth alternative – the idea that arose in our meeting this morning – posting information in chunks, as “more info” secondary pages (announcements) and tagging them in some way so they produce a subnav and thus “see” each other. Kind of like automatically making a mini-site out of related pages, but without the effort (and grace) of crafting a mini-site design or architecture.
This approach reminds me of Times Topics. The Times just writes articles. If there’s more to say, they write more articles. If there are infographics to add, or videos, or slideshows, they each come into existence one by one. When there’s enough stuff, it makes sense to start referencing the appropriate Times Topic from the bottom of each new article or piece of multimedia. Each topic isn’t a new, crafted subsection of the Times; it’s an automatic place where related stuff naturally collects.
Take a look at the items in the Most Popular Topics list. Each varies in the kinds of things that appear in their sidebar areas, suggesting that this system can serve a variety of purposes.
The Times Topic page on Credit Crisis includes latest developments, an overview, multimedia, links to related topics, and article navigation.
To aggregated topics, there is occasionally static information added to provide an overview. For instance, see the Times Topic on Mergers, Acquisitions, and Divestitures, which is merely a list of articles, and compare with the Times Topic on Swine Flu, which includes latest developments, an overview statement, resources, documents, photos, multimedia, and coverage from elsewhere around the web, in addition to articles.
Might any of our past efforts have been handled in this way? First we post a press release, then another, then an event, then a document, all connected by topic and evolving to form a whole. At first, we might link from the Vassar homepage to the initial press release; but after that, we might link to the topic page that has accumulated the various related stuff. And if that’s not a clear enough message, we write out a short blurb that – if it exists – the topic page is all ready to display. Last, perhaps we add a list of resources and/or related Vassar websites.
Who Cares about Semantics Anyway? On semantic markup, conveying its usage to those who generally don’t need to care, and a reusable markup guide for your enjoyment.
“Just educate your clients”, you may think. I hope you understand why this doesn’t always work. As an analogy, compare and contrast these situations:
- You just built a site for a plumbing company, complete with a CMS. You tell them to make sure to use
<ol>elements for parts lists, and
<h2>elements for product names on their respective pages. 6 months from now, you check the site and find a ton of
<br />elements to separate the list items, and headers in
<font size="5">tags. D’oh.
- In exchange for your work on the site, the plumbing company gives you some advice on your kitchen remodeling. They suggest copper pipes for your water lines running through the exterior walls, with a small length of flexible CPVC inside the house. You decide to go all CPVC because it’s slightly cheaper. 6 months later, your pipes burst during a particularly cold winter night. D’oh.
In both cases, a little bit of education goes a long way. In both cases, the client needs to take a little initiative of their own to ensure higher quality. In both cases, there will be people looking for shortcuts who simply won’t take the advice of the expert.
It brings up an interesting issue—I think we should discuss whether we’ll need such a guide when a CMS is in place. Most users won’t see any HTML, but they will need to know how to select styles, and which styles are appropriate for which bits of content.
On another note, I’ve had an idea kicking around in my head that we should have a basic document containing dummy text for viewing how style sheets handle all the various elements that get used in our sites (from paragraphs to definition lists.) I’ve wanted to create such a document, but just haven’t worked it in yet. It’s something to help with maintenance, but also to help with design to see if any elements need tweaking. I know having a default style sheet, or a specific list of elements to include will make sure everything has a style, but I’m looking for other issues: how nested elements look, and how multiple elements on a page look together.
Take this page for example. It contains many, many nested lists. As long as the styles for
li aren’t too complex the nested lists won’t need extra consideration. But if you’ve tweaked the list styles (padding and margins and such) it might look funny when there are nested lists. Another issue is what happens when there are many headers on a page. Most pages just have the title and a sub-header, so just
h2. But what happens when a document requires more sub-sections, like
h4. How do these look on the same page?
Actually, I asked for such a style guide from N+S for the Admissions site and was told it was far too complicated to create quickly. (??? but if they have a style sheet wouldn’t it be easy to set-up a page that tells us what the styles should be on an end-page verses a section home page?)
For future discussion.