jonathan stegall

It’s that time again. If you make websites, you should take the survey from A List Apart. It’s a beautiful thing.

I’ve written a few posts about the issues that arise, and things that can be learned, through spending one’s time working on a very large website.

One of the most significant issues that I have not yet mentioned is passion for design. A good web designer is an artist. An artist needs to have passion, or as far as I’m concerned she is no longer an artist. That passion will lead a web designer to be concerned that her designs are of the highest quality, that she is aware of current technologies, current trends (both so that her designs are not out of date, and so that she can continue to push or go against those trends), current issues and advancements, and so on.

One of the things I have learned about working on a very large website is that it can be difficult to maintain a passion for design. Many large websites have decision-makers that don’t care about design at all, and are in charge of deciding how websites look, how they function, and what kind of changes or additions get approved. Many other large websites have lots of people that care about design, but they may be on different skill and competency levels, or have different levels of authority, or simply have clashing tastes.

When these kind of issues arise, a web designer that is passionate about his art can run into various roadblocks that can prevent work of the highest quality. Subjective decisions may be passed down from superiors, or financial decisions may prevent certain things from happening, or technological decisions may prevent other things from happening.

When any of these things happen, a designer can find it difficult to maintain that passion. It can get easier to give up on important issues, or feel like design does not get the importance it deserves, or any number of other emotional and mental issues may arise.

I’m aware that this also happens outside of large websites, and have experienced it there. I believe, though, that it is a different issue on large websites because these designers don’t get another client the next week, or the next month, or the next quarter. What kind of solutions can maintain this passion on the same website, month after month, decision after decision?

Recently, I’ve become acquainted with Josh Brown (and Anna). Kiera and I, I think, resonate strongly with them. I’d easily put them among the favorite people I’ve met since being in Atlanta. To follow his precedent, I raise a glass to them.

Anyway. Recently, Josh wrote about Revolution Money Exchange as part of the Indian Taxi Fund. At the moment, we are not able to offer a whole lot to this, but I want to encourage you to learn about it, and do what you can to get involved.

Moving to the place where design and business meet theology and ministry to help make the world a better place, as Josh is doing, represents the best of what I see happening in activism. And you could, of course, change design to some other discipline, or even change theology and ministry to something else. People who follow Jesus need not be afraid to join up with people who don’t, in attempting to change the world.

There is no limit to the possibilities that can come out of these kinds of combinations. Several years ago, I was driving from Tampa to Lakeland on I-4 when I heard an NPR story about Muhammad Yunus of the Grameen Foundation, when he was about to win the Nobel Peace Prize. I learned of his efforts to empower the disenfranchised through micro-lending, and set people free from poverty. Immediately I thought, “The heart of God is in that.”

This concept of micro-lending began with people like Muhammad Yunus. It is continuing and expanding with the concepts of people like Josh and the power of things like blogging.

If you are able to join with Josh at this time, please do. If you are not, consider creating an account through Revolution Money Exchange at the button below, or at the button Josh has on his own site. When you do so, you give me (or Josh) $10, and receive $25 for yourself. You could then, of course, get your own referrals. This alone could give you something to contribute, which is the purpose of a post like this.

I want to continue with my thoughts on creating and maintaining CSS on very large websites. In my last post on the subject, I mentioned that there are at least ten different layout conventions that I deal with on a regular basis.

For what it’s worth, I want to add a little context and say that those layout conventions (and ten is a rough estimate) power somewhere around four hundred pages, give or take a few. Certainly, the website is much larger than that number, but again those are the ones with which I have significant interaction.

Again, none of this is new to someone who works on a very large website, but all of it was new to me. In light of this, I want to shed a little more light on some of the techniques I use or have used.

Structured Sections of Styles

I began to practice this technique when most of my days were spent working with relatively small sites, that typically had a total page number of less than fifty. However, many stylesheets don’t do this, so I think it’s worth mentioning.

Structuring sections of styles allows the designer to keep things in logical places within the stylesheet: such as layout styles, link styles, typography, browser fixes, and so on. An example goes like this:

HTML:

<div id="wrapper" class="layout-a">
   <div id="subContent">
      <p>content</p>
   </div>
   <div id="mainContent">
      <p>content</p>
   </div>
</div>

<div id="wrapper" class="layout-b">
   <div id="subContent">
      <p>content</p>
   </div>
   <div id="mainContent">
      <p>content</p>
   </div>
</div>

CSS:

body {
   background: #fff;
   font-size: 76%;
   text-align: center;
}
/* Layout Styles
_____________________________________________________ */
/* constants */
#wrapper {
   width: 760px;
   margin: 0 auto;
   text-align: left;
   font: 1em normal Verdana, Arial, Helvetica, sans-serif;
}
/* end constants */
/* layout-a */
.layout-a #subContent {
   width: 260px;
   float: left;
}
.layout-a #mainContent {
   width: 400px;
   float: right;
}
/* end layout-a */
/* layout-b */
.layout-b #mainContent {
   width: 400px;
   float: left;
}
.layout-b #subContent {
   width: 260px;
   float: right;
}
/* end layout-b */

/* Link Styles
_____________________________________________________ */
/* constants */
a:link, a:visited {
   color: #f00;
   text-decoration: underline;
}
a:hover, a:focus, a:active {
   color: f00;
   text-decoration: none;
}
...

Thus, styles become very nicely organized and can easily be found by another designer, or a developer, or someone learning from your source code.

Multiple stylesheets

Most large websites already do this, but it is important to mention that multiple stylesheets are an amazing organizational tool, beyond (but not replacing) the need to structure the stylesheets themselves.

Example:

<link rel="stylesheet" href="reset.css" type="text/css"
media="screen, projection" />
<link rel="stylesheet" href="site.css"> type="text/css"
media="screen, projection" />
<link rel="stylesheet" href="businessUnit.css"
type="text/css" media="screen, projection" />

For myself, I use Eric Meyer’s great reset stylesheet to remove default browser styles (as well as, in my case, default styles from the CMS that conflict with my needs). There are several others around the internet. Use whatever fits.

In my situation, several different business units have very different styles for their respective sections of the website. So, its beneficial to add these in separately when they do not overlap. Often, each business unit has several different layout conventions, hence the use of layout-a and layout-b, and so on.

Calm down

Unfortunately, most large websites do not validate, neither in their HTML or their CSS. This can be a constant source of frustration for standards-aware designers and developers. Multiple people may maintain the code. Some of them may be serious back-end programmers who don’t care about what the browser actually receives at all. Others may be non-technology people who barely know what a browser is, but have the responsibility of maintaining code for one reason or another.

And that has to become okay, at least to an extent. Otherwise, jobs become depressing. Certainly, work for better support of web standards. Push the fact that even the IE team wants to support standards. Push for accessibility, and the fact that major websites are being sued for accessibility violations. These things are important.

But every once in a while, take a flight for a few hours. Rejoice in the fact that, at least for now, people can’t call your cell phone and tell you that the world is ending, and expect you to do something about it. They’ll have to wait till you land.

I could see this becoming a series of posts, but for now I’ll start with one. I spend my days, to a large extent, dealing with HTML and CSS on a very large website.

I used to spend the majority of my days dealing with XHTML and CSS in relatively small websites. Rather than having, say, four or five different layout conventions, I now deal with at least ten different layout conventions. There are sections of the site that are of varying ages, and sections that were designed at different times and by different people in the company’s history. Any very large website is likely to have these kind of issues.

One of the results of this shift in my work situation is that I now have very large stylesheets. While there is a large amount of re-used code, re-used styles, and so on, there is so much going on that it is difficult to have efficiency.

There are a number of CSS frameworks that have come out in recent years, from YUI to Blueprint to others. This trend is similar to the trend of JavaScript libraries, of course, and it is seen as both a good thing and a bad thing, depending on how it is used.

One of the things that I have lately begun to make use of, though, is the YUI convention of creating several different layouts based on one selector. Thus, we might have the following:

<div id="wrapper" class="layout-a">
   <div id="subContent">
      <p>content</p>
   </div>
   <div id="mainContent">
      <p>content</p>
   </div>
</div>

<div id="wrapper" class="layout-b">
   <div id="subContent">
      <p>content</p>
   </div>
   <div id="mainContent">
      <p>content</p>
   </div>
</div>

The benefit of this is that layout-a and layout-b can share an identical structure in their HTML, and be styled to match almost any layout convention with less code and more efficiency than, for example, creating different divs for all of the sections.

Any styles that are shared between the layouts are, of course, shared. They don’t have to target layout-a or layout-b. As I begin to implement this, I find code becoming more efficient and I feel that it would be much easier for someone else to come along and have to deal with it.

When I first began working on this type of site, I was very good at HTML and CSS, but apparently I was not very efficient. This degree of efficiency simply wasn’t necessary, although it certainly could have been beneficial. I post all this because I have a feeling that I’m not the only one who could benefit from this kind of thought shift.

I’ve been a bit lazy with posting, as of late. So, I want to provide a bit of an update of what’s going on. As these things continue to develop, they may possibly provide some material for more posts. Exciting.

Projects

I have several projects that will be happening over the next few months. Currently, a new site is being created for Revolution Atlanta. Hopefully, it will continue to go well. A few other projects are also in the works, and more details will be coming about some of them.

Also, I’m finally making progress (very slow progress, albeit) on creating a design concept for this website. Yes, this blog. I know I said I might have it designed by early 2008, and I also know that “early 2008″ is almost over. So, let’s shoot for mid 2008, and see what happens. I feel very happy about the general direction things are proceeding with this design.

Issues of the spirit

Recently, I mentioned on this blog that God has been working with me concerning the issue of prayer. He has faithfully brought it to my attention, over and over again. Recently, I finished reading The Great Omission by Dallas Willard.

It is an amazing book, and through it, especially, I feel like I am beginning to see a bit of the bigger picture of what is being said to me. The book covers the kind of authentic discipleship that is typically missing from the Western church, which is essentially the kind of discipleship that Jesus had in mind for his followers. We in the Western church have entirely skipped a lot of it in favor of things that are easier and less powerful.

As he examines this kind of discipleship, Dallas Willard brings together the teachings of Jesus on how to follow him. He looks at various spiritual disciplines; how they can influence a life to authentically experience and grow in the experience of God.

The hardest, and thus probably the most relevant, issue for me to learn about was the issue of solitude and silence. Learning to practice the presence of God by spending time away from other things.

I’m not any good at this. I see the deep relationship that it has to new monasticism, especially, and other parts of emerging things that God is doing in the world. I see the deep, paradoxical relationship that it has to spiritual community.

Interestingly, as I work on a website that I hope will express who I am to the fullest extent possible, I am also beginning to see the relationship that this kind of authentic spiritual experience, leading through silence and solitude to prayer and awareness of God, has to art and creativity and design. I’m beginning to see that, the more I get of this, the better a designer I will be.

That’s not at all to say that the best designers have to care about spiritual things, or that they would be better designers if they did. But it is to say that I, personally, will be a better designer if I can better integrate my life, and better learn to slow it down and be more aware of spiritual things.

I’ve been reluctant to post these thoughts, as they’re still a bit murky. I’ve had many of these thoughts for years, but I feel as though they are beginning to work together in ways that they may not have in the past, and that leads me to believe that it’s worth posting them.

As I’ve been thinking about the new default behavior that Microsoft announced for IE8, it occurs to me that there are a lot of reasons for Microsoft’s decision. In light of these thoughts, I want to look at the reasons that I think are likely possibilities.

Standards as a whole

Microsoft, especially in the last year or two, has made a lot of moves toward standards, web and otherwise. They announced the Interoperability Principles. They announced the ASP.NET MVC Framework, which finally allows programmers to control the HTML generated by ASP.NET. IE8 will pass Acid2, and any number of other things.

While I’m not optimistic that any of this will cause Microsoft to act in any unexpected ways with respect to its attempts to acquire Yahoo, it is clear that a shift is occurring, to whatever extent.

Noise from the web standards community

Advocates of web standards have made a lot of noise about the original decision, and it is clear that Microsoft listened. Many people made logical arguments for why IE8, especially from a long-term perspective, should not default to IE7 behavior, while understanding that the option for IE7 behavior was a good thing.

Legal issues

It’s entirely possible that this is partly related to Microsoft’s various legal troubles, and that they are trying to appear as a better business citizen to help their case.

Future versions of IE

I think one of the most significant benefits, both from the perspective of future versions of IE, as well as future versions of Firefox, Opera, Safari, etc., is that the need for version targeting will probably become much less because IE8 is the default behavior. People who create sites that break in IE8 will, certainly, have the option of targeting IE7, but in order to do that they’ll have to learn that they can.

Most people who will run into the issue will probably not have the interest (or the time, possibly) to find out this kind of solution. The ones who do find out about the solution will find out that Microsoft doesn’t see it as the ideal solution, and will probably feel at least some pressure to learn proper ways of doing things. Thus, in a few years, it is entirely possible that versions of Internet Explorer that follow version 8 will be met with a majority of sites that do not break.

That’s not to say that the majority of sites will follow web standards. I’ve seen innumerable websites that didn’t break when IE7 came out, because they had such disregard for web standards that none of the changes affected them. I suspect we’ll have to deal with this for a long time. But that’s fine with me, as the future of web browsers can continue to look forward.

See this press release:

“IE8 has been significantly enhanced, and was designed with great support for current Internet standards. This is evidenced by the fact that even in its first beta, IE8 correctly renders the popular test known as ‘Acid2,’ which was created by the Web community to promote real-world interoperability,” said Ray Ozzie, Microsoft chief software architect. “Our initial plan had been to use IE7-compatible behavior as the default setting for IE8, to minimize potential impact on the world’s existing Web sites. We have now decided to make our most current standards-based mode the default in IE8.”

The web standards world has been abuzz for the last few weeks, following the announcement that Internet Explorer 8 (and, presumably, any number of future releases) would have the default behavior of rendering websites in the same way that Internet Explorer 7 does. Causing the browser’s behavior to advance would have required that designers and developers direct it to do so with a meta tag.

Many standards-aware designers and developers were very understanding of the decision to allow websites to target IE7, avoiding issues with badly-programmed websites that break when browsers move forward. However, many of these designers and developers made a lot of noise wishing that Microsoft would allow the default behavior of websites to advance as the browser does, and require those who want to target IE7 to read a little bit and find out about the meta tag.

Apparently, Microsoft listened to the noise. I’m amazed and pleased by this change in strategy. I hope they will be able to spread the word enough, so that websites that will break with IE8’s improved standards support will learn about their options (1. learn how to write standards-compliant code, 2. include a one-line meta tag). I feel pretty confident that this is unrealistic, but I hope that it will happen to the extent that Microsoft doesn’t have to go back on this decision.

Here is a nice article examining the typefaces used by the various presidential campaigns, and what those typefaces communicate. I love good typography. The web is plagued by abysmal typography, but there is a lot of evidence that many people, especially standards-aware designers, have really begun to care about this kind of thing.

Anyway. I think the article analyzes the various typefaces and what they represent very accurately. Worth a read.

I don’t write about CSS as much as I’d like to. I spend a lot of time working with them on an advanced level, however, both in my day job and in any side projects.

I spent a few minutes looking around on Google for issues that arise when designers need to work with and use CSS within the confines of a CMS that does not allow access to things inside the head of the document. Apparently, this is not a rare issue, so I’d like to post a few solutions that, while they are not ideal, do work.

Disclaimer: these options do not validate. The only valid way to include a CSS is inside the head of the document

Option One

Use inline styles. This method is, unfortunately, still the most common way of doing this. A designer might have the following code in place:

<div id="myDiv" class="myClass">
<p>foo. I'm a div with an ID and a class, but my ID
and class don't do what I want them to do.
Bah.</p>
</div>

If the div is, for example, defined with its ID or class as a very small div floated to the right, but it needs to be a very large div floated to the left, a designer might do this:

<div style="float: left; width: 500px; margin: 5px;">
<p>foo. I'm a div without an ID and class, and I have
ugly inline styles.</p>
</div>

Option 2

Option 2 allows the designer to access the head of the document through JavaScript. There are a number of techniques for doing this, but they have significant issues.

Mainly, this breaks the separation between content, style, and behavior that provides much of the underlying theory of why a designer would want to use CSS in the first place. In addition to this, it breaks the accessibility of the page. Anything that doesn’t have to be done with JavaScript, shouldn’t be done with JavaScript.

Option 3

This is the option I spend a lot of time using when working in this situation. A designer might have the following scenario:

<head>
<link href="a stylesheet I cannot access"
rel="stylesheet" type="text/css"
media="screen" />
</head>
<body>
<div id="myDiv">
<p>foo. I'm a div that needs some styles. I might be on
thousands of pages across this site.</p>
</div>
</body>

<head>
<link href="a stylesheet I cannot access"
rel="stylesheet" type="text/css"
media="screen" />
</head>
<body>
<link href="mycss.css" rel="stylesheet"
type="text/css" media="screen" />
<div id="myDiv">
<p>foo. I'm a div that has styles, even though
they're not where they should be. I might be on
thousands of pages across this site.</p>
</div>
</body>

The benefit of this is that it works in all major browsers and on all major platforms and, at least, mobile devices (this statement counts Linux and the iPhone as major platforms, for what it’s worth). Also, of course, there is the benefit that the given stylesheet can be called throughout the site, which inline styles do not allow.

There are a few downsides to this technique. Browsers, for one, have to work a bit harder to do this kind of thing. When they encounter style information outside the head, whether it’s in an external file or in the page, they have to break their normal flow of rendering content, and thus this causes pages to be slower. This slowdown, however, is not usually noticeable.

Of course, because browsers have to work harder to do this, and because it does not validate, it is possible (though it is highly unlikely) that future versions may not support this kind of functionality.