I got to help UXmatters with print styling

UXMatters print pageA few months ago I contacted UXmatters online magazine to let them know of a problem I had printing out articles with Firefox. The first page would print, but that was all. I could switch to Safari and print fine, but that just didn’t seem right.

I found out that they were a little shorthanded on specialized web help, so I  volunteered to assist. Pabini Gabriel-Petit, the publisher and editor-in-chief, graciously accepted my offer.

Creating print CSS is usually simpler than web page layouts, because the goal is typically to have the content of the page print out well on standard size paper. Multiple columns and site navigation are usually uncalled for.

My first try was to revise the existing print CSS file. After half an hour at that, I decided it would be simpler to start from scratch. The original print CSS was quite complex, and it seemed I was searching for one issue: why did the pages stop printing after page 1?

So I rewrote the CSS, simplifying the CSS code greatly. I had the layout in good shape, but oddly still had the 1 page issue.

I went back to the main screen CSS file and begin sifting through it, looking for clues. Then on a hunch, I found the issue.

The global CSS file is thick. There’s a ton going on there to defend against various cross browser issues. One particular rule I saw repeatedly was the use of overflow: hidden. That rule is used for a few reasons, but one of them is to force a floated box (div or what have you) to expand when it wants to collapse, vertically. This allows things like backgrounds to show through properly.

One of the selectors that this rule was used on was actually a wrapper for much of the page content. It made sense to me, in a way, that this could confound a browser into hiding paged content that went beyond a page.

So the real key to the much simpler CSS file was to add in an overflow: visible to a large set of selectors to override that overflow: hidden for printed pages.

I sent Pabini the new code, and over the following weeks she tested it and added some details I had missed. About a month ago she deployed the new print CSS code  to the website.

This little evening project was a fun puzzle, and I’m glad I was able to help make such great content on the UXmatters website print out better for more people.

(Back in 2002 or 2003, I forget when, I wrote an article on print styling for web pages.)

Nephtali web framework creator talks FP

Nephtali project website screenshotAdam Richardson of Envision Internet Consulting has been a long-time collaborator and good friend of mine, and over the last few years I’ve seen him pursue knowledge in web programming with persistence that I’ve never seen from anyone else.

One of Adam’s projects is Nephtali: a web framework that focuses on security and considers the usability of the framework itself. Adam has labored over details in his latest version of Nephtali that will make life better for developers. For instance, he planned the naming convention and namespaces for functions so that in an IDE like NetBeans, the functions appear grouped logically in an easy-to-access format.

Nephtali is up to version 3.0.5 at the time of this writing, and the earlier versions were completely Object Oriented PHP. In version 3, Adam re-thought Nephtali away from the OOP base and rewrote it utilizing FP, Functional Programming.

For the last month or so, Adam has been lobbying various hosts to upgrade to PHP 5.3 or higher, because Nephtali requires at least that version. It is right on the cutting edge. I asked Adam a few questions about Nephtali, and that dialogue follows.

Davin: Nephtali requires the latest version of PHP, version 5.3 or higher, but many hosting providers don’t provide that yet. What about PHP 5.3 is worth waiting for?

Adam: PHP 5.3 includes many enhancements and bug fixes, but the features that facilitated Nephtali’s general approach and architecture were support for namespaces and the new Functional Programming (FP) capabilities.

Davin: I’m familiar with object oriented programming, but you’re talking about “functional programming.” Can you summarize the difference, and explain why you decided to go with FP instead of OOP with Nephtali?

Adam: Most programming languages offer the ability to define functions, however that doesn’t necessarily make them functional programming languages.  It’s easy to to get into flame wars over what a “true” functional language is, but I’ll lay out some general principles:

  • Functions can be passed around just like other datatypes.
  • Closures allow variables that are in scope when a function is declared to be accessed and carried around within the function.
  • Side effects (changing the value of a variable within a function) are limited.
  • Many FP languages natively support currying (the ability to define a subset of a functions arguments and then allow other functions to finish defining the others.)

PHP now supports the first 2, and with some discipline, you can limit the impact of side-effects within your code (there are even some clever hacks for the currying issue.)  But the big question is, “What does this buy you?”


Object Oriented Programming (OOP) bundles variables with the functions (methods) that directly interact with the variables.  This does provide a degree of encapsulation, as the accessor methods make sure that instance and class variables contain what is expected.  However, the issue often isn’t “What” a variable is changed to, but rather  “When” a variable is changed.  This problem of “When” is most glaring for OOP developers when implementing parallel processing, an issue that has produced many complex, clunky answers.

Taking an FP approach simplifies the question of “When”, as you move from a paradigm of altering variables to one of acting on values returned from functions.  Relatively speaking when following general FP conventions, writing unit tests is simple, writing parallel processing apps is simple (see Scala, Clojure, Erlang, etc.), and as it turns out, writing a capable web framework is simple, too.

Davin: What about models? So many of us in the web field have become familiar with the MVC (model, view, controller) architecture in frameworks, and it seems like Nephtali doesn’t use the models concept at all. Is that right, and if so, what do you do about databases?

Adam: Simplicity.

In terms of DB interaction, I like PHP’s PDO capabilities and security.  Performing simple DB work is easy in Nephtali, as you can generate code very quickly using the Nedit, the online code generator for Nephtali.  Nephtali provides some simple enhancements (functions that automatically table inserts, updates, and deletes; easy connection management; etc.), but you’re always working close enough to the basic PDO capabilities that it’s still very easy to perform transactions, connect to multiple DB’s, work with existing tables that don’t follow particular naming conventions, and whatever else your unique environment may entail.  One line of code is all it takes to grab a set of rows from a DB.

Second, utilizing the parallel processing capabilities of CURL, Nephtali provides some special capabilities for web requests.  A couple lines of code can retrieve a web request (in parallel with any other web requests) and format the retrieved data into whatever container (object or array) you’d like.

Davin: I saw the post on the Nephtali blog about Nephtali’s parallel processing for web requests. Can you explain when that would be useful, and when I should not run ahead and parallel process everything?

Adam: If you have a page that only makes use of one web service, you don’t gain anything.  However, if you have a page like Nephtali’s homepage, which makes a request to Google Code for the latest download and also makes a request to the WordPress blog for recent entries, you can gain a significant performance improvement by processing those requests in parallel.  Instead of ending up with serial calls to the two services (GoogleCodeRequestTime + WordPressRequestTime), the parallel request now equals the greater of the two requests (GoogleCodeRequestTime -OR- WordPressRequestTime.)

Nephtali handles the processing for you automatically.  Always use the request() and response() functions, and Nephtali will make things faster when they can be faster.  That’s it.

More about Nephtali

Learn more about Nephtali at nephtaliproject.com. When you’re there, check out the screencasts on using Nephtali. One of the great features on that site is NEdit, a tool that you can use to write up a lot of the code you’ll need for Nephtali pages.

Oh, and don’t hesitate to use the contact form. Adam loves talking with people about Nephtali, and I’m sure he’ll happily answer questions or respond to comments about the framework.

How WordPress falters as a CMS: Multiple content fields

WordPress is amazing and keeps getting better, but I want to be clear about an inherent limitation that WordPress has as a content management system (CMS). That limitation is that WordPress doesn’t handle multiple content regions on web pages.

Too strong? With WordPress, you can try to use custom fields or innovative hacks like Bill Erickson’s approach to multiple content areas using H4 elements in his excellent theme “Thesis”. Unfortunately, neither of those approaches really deals with the depth of the design problem that often requires multiple content areas for pages.

As an information architect/user experience designer, I’ve been involved in many projects that required more types of content on any single screen than WordPress is designed to handle.

Let me draw out what I’m talking about here.

Exhibit A: Page content that WordPress is designed to handle

In a standard WordPress page or post, you’ll see these author-controlled pieces of content.

  • Post/page Title
  • Body
  • Excerpt (often not-used)
Standard WordPress content fields include the title, excerpt, and body.
Standard WordPress content fields include the title, excerpt, and body.

There are other sets of data for a page or post that an author can control, too, but these are meta-data such as tags, categories, slug (shows up in the URL), and possibly search engine optimization information like title, description, and keywords.

For a normal blog, many online trade journals, and a lot of basic websites, this really covers the bases. The body contains the bulk of the content including images, video, and audio that can be intermingled with the text itself. This model is very flexible, and it has definitely proven itself.

Exhibit B: Page content that pushes WordPress too far

In 2009, there was a small project at work to develop the website Covenant Musicians, and because the person who would keep the site updated was already using WordPress, we made the decision to build this site with WordPress too.

Well, if you look at one of the destination pages for this site, the musician profile page (here’s one for example), you’ll notice some different pieces of content which may or may not be present on any particular musician profile page. When they are present, they need to be in certain places and sometimes with certain content.

This custom WordPress page uses fields in addition to the standard options: Musician Image, URL, and Video.
This custom WordPress page uses fields in addition to the standard options: Musician Image, URL, and Video.

The problem is, to control those extra pieces of content: the video, the band image, the link to the band’s website, the site owner needs to use WordPress’s custom fields in very precise ways, without the benefit of WordPress’s content editing tools. What a drag!

To make life easier for the site owner, we ended up recording screencast instructions on how to use these fields and delivered those help files with the site itself. (We used Jing by Techsmith, by the way.)

It would’ve been better had the interface been clear enough so that we didn’t feel the need to document the process of updating these destination pages, but that’s the trouble with stretching WordPress beyond its default content fields.

Ask too much of WordPress and ease-of-use is the casualty

Do you see the difference? When an effective design solution requires multiple types of content per page, using WordPress will actually make your website difficult to manage. WordPress is usually so easy to use that when you hit this wall, it is very apparent.

When you’re at that point, WordPress is probably not the right CMS to choose.

Should WordPress improve in this area?

Whether through the core application or through an excellent plug-in (is there one already that I missed?), if WordPress is going to grow in the content management systems field, this shortfall will need to be addressed.

However, WordPress is really excellent at what it does already, and the better course might be to decide to keep the features in check and let other systems compete in the mid-to-enterprise scale CMS arena. Scope creep never stops, and a good application strategy knows when to say “no.”

Am I wrong?

Am I off-base here? This is just one aspect of WordPress that should limit its use. Another that should cause designers to think twice is when dealing with faceted-navigation which requires more than one dimension (tags can probably handle one dimension). But, again, those are more complex design requirements.

I’m not a WordPress consultant, and I’ll bet some of you would like to point to the errors in my thinking. Let’s hear it.

Let’s stop playing Frankenstein

Consider the monster from Mary Shelley’s Frankenstein:

The creature is described as being about eight feet (244 centimeters) in height, with translucent yellowish skin that “barely disguised the workings of the vessels and muscles underneath”, watery, glowing eyes, flowing black hair, black lips, and white teeth. (http://en.wikipedia.org/wiki/Frankenstein%27s_monster#Appearance)

I read that phrase describing the skin of the monster, that it “barely disguised the workings of the vessels and muscles underneath.”

My hands have worked on Web pages that were little more than that yellowish skin.

It’s no wonder customers fled in terror.

By now, most of my nameless monsters have died off, thanks to the hyper-life-cycle of the Web, but recently I gained a new perspective of how ungainly, ill-proportioned Web sites are created.


If you want to create a monster of a Web page, the trick is quite simple: Work, work, work at it, one page at a time. Write the code, make it work, make sure the forms submit. Whip up some error text, insert some confirmation screens. Check the boxes on your to-do list of functional requirements. Light it up, and let it out onto the world.

But wait…isn’t that how most of us get our jobs done? These days, we like to call this kind of heads down, busy-work “Agile.”


Step away from the keyboard, Doctor.

Pick up a pencil. Draw out the whole process from the point of view of each actor, be it a person or some agent like a search engine robot. Draw pictures using easy graphics, like Garrett’s visual vocabulary palette, and be sure to include every point of contact with an actor.

Having done this recently, it became clear immediately that there was a series of email messages interspersed amongst Web pages, and that those emails were as important as any single Web page.

Also, the timing of those emails was important. For instance, Jim uses a Web page to send an email message to his friend Bob. Jim then sends an instant message to Bob asking if he signed up yet, assuming that Bob did in fact receive that email message and was able to decipher it. Those are two tough assumptions.

Each piece of a larger process overlaps with its adjacent pieces in a series of feedback and feedforward communications. Once we have these communications, these pages, emails and so forth, laid out with balance, proportion, and clear purpose, a more beautiful creation can take hold.

Nurturing and shaping this flow of interactions between people using a system is a great step in putting an end to the monsters we’ve become so good at creating.

Once we’re into this process, we invariably realize there are many more questions to ask, but the point is this: Design processes, not pages.

Marking up breadcrumb navigation

Breadcrumb navigation is a secondary navigation system that usually represents a site visitor’s current position in the site, showing other pages above the current one in the site’s hierarchy.

In some sites, like those built with Dokuwiki, breadcrumbs actually show the history of the user’s session instead of the hierarchy of the user’s current position in the website.

Breadcrumb navigation is typically found at the top of a content region, and usually below primary tabbed navigation.

History? Bah, yesterday’s newspaper.

In his April 10, 2007 Alertbox, Breadcrumb Navigation Increasingly Useful, Jakob Nielsen declares, Breadcrumbs should show the site hierarchy, not the user’s history.

For the purposes of conceiving of solid, semantic markup, let’s agree with Nielsen. Breadcrumbs represent position in a site’s hierarchy.

Semantic values: hierarchy, location, current position

In hierarchical breadcrumb navigation, the following aspects of information are important.

  • Steps in the hierarchy that show broader sections of the site related to current position, i.e., the ancestors of the current page
  • The order of those steps
  • The ability to immediately jump to any ancestor page
  • Indication of the current page, which should not be linked

The markup

So, with those in mind, here is an example that provides just enough code and semantics, and little else.

<ol id="breadcrumbs">
<li><a href="../../../../../../">Kim Jong Il’s Favorite Widgets, LLC</a></li>
<li><a href="../../../../../">Military</a></li>
<li><a href="../../../../">Nuclear</a></li>
<li><a href="../../../">Warheads</a></li>
<li><a href="../../">Just for funsies</a></li>
<li><a href="../">2006</a></li>
<li class="current_page">Gilju, Hamgyong province, 0136 GMT</li>

This markup is fairly lean, yet does communicate the order of steps via the ordered list.

Note that the Project Cerbera website provides a nice discussion and some other examples of breadcrumbs markup that are in line with this approach.

The examples at Project Cerbera also show nested lists to indicate the nested nature of the links, but that is over-the-top. The simple ordered list sufficiently communicates the order of steps in the hierarchy, without providing additional markup noise for a screen reader to announce or a designer to style.


The breadcrumbs should strive to follow conventions.

  • Take up one line
  • Use a standard separator between steps, like >
  • Each step links to an appropriate page using standard link indicators (underlined and colored)
    • Except for the last step, which should be unlinked and represent the current page

Unstyled example

  1. Kim Jong Il’s Favorite Widgets, LLC
  2. Military
  3. Nuclear
  4. Warheads
  5. Just for funsies
  6. 2006
  7. Gilju, Hamgyong province, 0136 GMT

Styled example

Minor variations could include having the current page item be in a bold font, however, breadcrumbs are secondary navigation. They don’t need to attract much attention.

To reference the Project Cerbera site again, the examples there use a greater-than background-image on the list items. That technique may stand better in cross-browser tests than the use of the after pseudo-class used here.

Trouble with PHP5 and SQLite 3

After fiddling for a while with SQLite 3 and PHP 5.0.4 on the Mac PowerBook (OS 10.4.2) I’ve been using, I just saw that the current version of PHP does not include support for SQLite 3. Only for version 2. Dangit.

I don’t think I’m going to bother installing SQLite 2 just so it can work with PHP. Hopefully a new version of PHP will be released that includes the support.

I have PHP and SQLite working fine on a Windows XP system at MSU, so I’ll just use that for now. I’m just looking into it to learn it at this point.

Prognosticating on LAMP vs .NET, J2EE

Dvorak wrote an article on PCMAG.com, “Windows Vista: Where’s the Buzz?,” in which he made some predictions on the future of web technology. It all started with his observation on the lack of excitement about Microsoft naming their coming OS as “Vista.”

Linux/Apache will own the server space and with the emergence of MySQL and PHP as the hot development tools over Microsoft .NET and J2EE there will be no way to unseat it. In popular parlance this is commonly referred to as LAMP.

It’s an interesting statement because MySQL and PHP are not as full-featured technologies as .NET and J2EE. So, from a large-scale developement perspective, they aren’t as strong options. They’re getting better with recent versions, but they still just don’t have the features.

But, that said, MySQL and PHP are both available at no-cost (though total cost of ownership is another debate) and they are easier to learn, in part because of the fewer features. The barrier to entry is lower. This fact alone may make Dvorak’s prediction come true.

And, there are some pretty impressive and large-scale web sites out there that use MySQL and PHP, so while they don’t have the depth of the more mature technologies, you can’t really scoff at them. They get the job done.

Dreamweaver MX 2004: Less than great for dynamic web applications

So, I’m supposed to teach a course in Dreamweaver Dynamic Web Applications and one in Dreamweaver/PHP Web Development. In preparation, I’m working on a little project that should help with some internal LCTTP record keeping as well as give me practice using DW to build web apps.

Here’s the trouble: Web applications generally require some custom coding, and with a properly designed database, the SQL queries can prove challenging for DW to handle.

Dreamweaver works by setting up a database connection file, and then you can create what DW calls Recordsets that are based on the database connection. Each Recordset includes the query itself and the code used to retrieve the information. The Recordset then becomes a data resource that can be used to bind specific values to specific elements on a web page.

The trouble is, when you go in to the code to tweak the recordset, DW loses the Recordset. It just disappears from DW’s panel of Application Bindings. This is frustrating.

For a specific example, I was putting together a basic user login screen. I set up the Recordset fine, but I needed to apply an md5 function to a password value that was used in the query. Adding that one line of code to the Recordset causes DW to lose the recordset–which means I then cannot use it for any other data bindings.

My challenge is this: How do I decide to teach this course? Do I discourage people from using DW’s recordsets? That would negate a lot of potential value of using Dreamweaver. Certainly not all value, but it makes much of the GUI pointless. In what other ways is DW a helpful tool for creating dynamic sites? Of course, that is an easily answerable question, but I just need to get my thoughts in order.

Change is afoot in the web…More foundational than when the first graphic showed up in a web browser…

What an exciting time to be in the Web industry. I just read an essay by Janice Fraser of Adaptive Path that really got me thinking.

Major change, like questions of what happens to our bookmarks when we lose our current definition of a web page? In 2002, Luke Wroblewski of the NCSA published a book (SITE-SEEING: A Visual Approach to Web Usability) that referred to the unified model of the Web, a model that we have internalized and includes concepts like clicking a link “takes” us somewhere, like we can go back and visit a page using a bookmark, our browser keeps a history of our session, which we can navigate, etc. This model frames (ahem) some hostility to new windows, especially pop-ups, as well as framesets, because a user may not always realize that they’re ability to bookmark a page has been undermined (in the case of frames) and that they’re browsing history has started anew when the new browser window appeared, whether or not they know it

Sorry, it would seem this post has been cut short, likely during a transition from one blogging platform to another. -drg