Type is an interesting segment of front end development. It’s always felt like an untamed beast, but that’s gotten better over the past couple of years with the adoption of @font-face and the number of foundries now offering Web fonts.

While that handles the font faces themselves, actual layout on page is still quite arbitrary. CSS3 has a number of properties that can and will help with that.

Advertise here with BSA

This is a neat little script you can use during development that might make your life easier. It’s sole responsibility is to refresh the CSS of your site at the time the stylesheet is saved, preventing you from having to refresh the browser to see a style update.

Check out the source for a closer look into what it’s doing and give it a whirl if you’d like.

Advertise here with BSA

A sprite is a conglomeration of all the (non-repeating) image assets of your design into a single image to be referenced and obscured and in doing so having a single HTTP request to retrieve any number of pseudo-’images’. The trouble with spriting is that it takes planning and can be tedious. Luckily, spriting can be automated to a certain extent, and tools like Spritemapper make that a bit easier.

Spritemapper seems very well put together, and I can not wait to find an automated solution that will help me not have to keep track of my sprites manually.

Advertise here with BSA

This is neat. Holmes is The CSS Markup Detective:

Holmes is stand-alone diagnostic CSS stylesheet that can highlight potentially invalid, inaccessible or erroneous HTML(5) markup by adding one class.

I like this because it’s in a way passive, but really useful. When I was really getting into Web Standards, I had a number of Firefox Add-ons that would light up, blink, and cause a bit of chaos when things were invalid or errors were present. I’ve outgrown that to an extent, but I like the idea of this. I’ll be keeping an eye on it, keeping yourself in check is still important.

Advertise here with BSA

Like nearly all discussions with CSS from the past year or two, the underlying thought processes isn’t completely new, but what I love to see is the heightened level of discussion going on from post to post.  What’s even better is that we’re thinking about these issues as though we’re engineers instead of designers. We’re thinking about the impact a plausible decision would have on The Big Picture and that’s beyond awesome.

The latest discussion considers a :parent CSS selector. If you haven’t had a chance to read about it, you’ll be caught up after reading:

• Why We Don’t Have a Parent Selector
• CSS Selector for :parent Targeting (Please)

If you consider yourself a front end developer, engaging in this thought process and conversation should be eye opening.

I’d also like to take a minute to ask if this type of thinking is commonplace for you as you work; do you think about how possible it is for your ideas to impact something so significant? That’s one of the many benefits to working in an industry like ours, it’s still The Renaissance.

Advertise here with BSA

I like the business end of Web design. I’ve come to the conclusion that one of the reasons I like it so much is due to my enjoyment of problem solving. Web design as a business is a problem, plain and simple. Everyone has their own way of doing things, we’re working in a medium that many of our clients don’t fully understand, and it’s sometimes very difficult to completely resolve the final terms of an agreement and be fully confident you’ve covered all your bases. This is something I like thinking about, something I like dealing with. If you’re not in the same boat, I hope you don’t plan on freelancing being a walk in the park. The business end is just as big of a deal as the design/development end. You want to get paid.

Style guides? For code?

A style guide is a straight and to the point document that outlines how you should be formatting your code. It covers indentation, alignment, spacing, tabs, naming, and just about every other aspect of writing code apart from the logic itself.

Whether you’re writing a script, some markup, or programming, you have a way of doing it. You put your brackets in a certain place because either it looks better to you, or your teacher told you to write it that way. The same goes for the spaces you include in your arguments list, your array declarations, and so on. These are important details to consider, especially when you’re looking at someone else’s code.

Even if you didn’t realize you did it yourself, looking at someone else’s code can just come off as… unorganized. At first you can’t quite put your finger on it but you’ll find yourself asking “how the heck does this even work?” If you’ve ever had one of those moments, you’ll appreciate a good style guide in your workflow.

Structuring your style guide

There isn’t a real set of rules to writing your style guide(s); they will probably undergo a long series of revision as you realize the little details you’ve forgotten over time. I think coming up with a style guide is really good team based exercise, something I plan to finalize with my team over the coming weeks.

At my company, we’ll need four style guides to cover our workflow:

• HTML
• CSS
• JavaScript
• PHP

Currently these style guides are a work in progress, but as small snippets look something like this:

HTML

Our HTML style guide will cover things you’d expect to find in other code style guides, but certain aspects of formatting will be included in nearly every example. Things like the ‘closing’ comment for block level elements based on their class or id.

Block element with class

<div class="group">

</div>
<!-- /group -->

Block element with ID

<div id="address">

</div>
<!-- /address -->

Block element with class and ID

<div class="group" id="services">

</div>
<!-- /services -->

CSS

Probably the biggest rule to cover in a CSS style guide would be whether you’re going for single line or multi line, a debate that will carry us through the end of time. Front enders seem to be very passionate about their decision to go with one or the other, so we’re lucky to have a number of tools that will convert from one format to the other on the fly.

Comment Basics

/* ================ */
/* = MAIN SECTION = */
/* ================ */

.main { width:100%; }

	/* Child section */
	.child { border:1px solid #f00; }

Selector property value formatting

.section { width:200px; height:200px; }
.section #child { border:2px solid #f00; }
.section p { margin-bottom:1.2em; }
.section ul { list-style:disc; }
.section ul li { margin-bottom:0.6em; font-size:1.1em; }

JavaScript

We’re a jQuery house, so a significant portion of our JavaScript style guide will include jQuery-specific notes. Along those lines, more generic JavaScript instructions will be needed as well.

Conditionals

if( $('#address').height() < 100 ) {
	do_this();
} else {
	do_that();
}

Chaining

$('.group')
	.find('> p')
	.removeClass('someclass')
	.addClass('newclass')
	.find('ul')
		.addClass('targetclass')
	.end()
.end()
.slideDown();

PHP

I’ve always liked the way CodeIgniter writes PHP. Their guide is extremely in depth and I’d simply like to use that as our style guide as well. One of the best things about CodeIgniter’s style guide is that both correct and incorrect usage is outlined.

Bracket and Parenthetic Spacing

// INCORRECT:
$arr[ $foo ] = 'foo';

// CORRECT:
$arr[$foo] = 'foo'; // no spaces around array keys

Do you use style guides?

I’m becoming increasingly comfortable with the idea that at least some form of style guide, whether on a team or individually, is an extremely important part of the process. It helps with everything from readability to quality control and especially helps a team become that much more cohesive. Are you/is your team using style guides? Have you found them to be helpful, hurtful, or ineffective?

Advertise here with BSA

See also: Not Supported by Jonathan Snook.

It’s issues like these that have me concerned about whether or not we’re ready for CSS3. Sure, writing a few extra styles isn’t really that big of a deal, right? Yes and no. We’re coming into an age that is accepting a more radical implementation of CSS every day. With that comes even more variance as to how properties (and their values) are implemented. That could very well result in an endless combination of vendor prefixes as well as values that create a major headache for the people actually working with the styles.

PPK goes into quite a bit of detail pleading his case. I urge you to take note.

Advertise here with BSA

When it comes to personal projects, I often wait for serious inspiration to strike, as I find it much more likely to actually end up with a finished product. As such was the case with the latest version of Monday By Noon.

Inspiration

Over the past few months, I’ve had a strong calling to redesign the site, as I felt it was no longer a representation of where I’m at with Web design and development. It wasn’t until recently that I was able to better define exactly what it was I felt inaccurate about the then current version of MBN. When I originally pushed the design, I was really in to minimalism for the purpose of concentration. I wanted readers to be able to truly focus on the article at hand, the conversation that followed, and that was it.

I felt the old design catered to that, but it began to wear on me. When viewing the site, I no longer saw the minimal elegance I originally shot for, I saw sterility. The design remained clean, organized, and structured, but to me it had moved beyond that to an extent. The minimal design was pushed roughly 18 months ago, and I think that’s quite a shelf life given a designers inherent need to change things on a very consistent basis. I accepted the challenge of redesigning in 2010.

As I mentioned, the redesign came to exist much out of the blue. As I sat down one evening to take care of some overflow work, I had a simple urge to start sketching a few wireframes for MBN. I wanted this design to be different, to get back to the roots of the first design to ever grace Monday By Noon. Four years later, I would definitely not call it graceful, but it did something I really liked; it promoted exploration.

The conversations in response to some of the articles I’ve written in the past enrich the overall message in such a way that isn’t otherwise possible. I know many writers prefer to omit the entire comment exchange, but I can’t imagine MBN without it. I truly value the response of the readers, and it’s great to have a targeted conversation on a specific issue every week. I wanted to make it a point to push comments and commenting where applicable as much as possible.

As I was sketching, inspiration came flooding in. I thought about the applications I use every day, and what they all have in common; sidebars. Sidebars in application design are nearly essential. There is always a combination of information and interaction that’s valuable no matter what you’re doing or what you’re looking at. It’s the hub of the UI that facilitates easy access to anything and everything, and it’s always in eyesight. I wanted something like that.

It then came down to figuring out what’s truly essential for a website like Monday By Noon. First things first is the brand. Brand was super important, so it went without question that was to be included. I want to try and push MBN to be the best it can be in 2010, and that means trying to attract new readers, so I planned on sticking with the quick blurb describing the purpose of the site as well. It’s quick and easy to digest, and can simply reinforce MBN to veteran readers.

With the minimalist design, I received some positive feedback about the ‘personal favorite articles’ section on the home page. Some people felt it was nice to know which pieces I’ve enjoyed most, and I thought that would be something nice to include in this redesign, but in a different way somehow.

I also find it easier to become hooked to a website when the people behind it aren’t obscured too much. Personally, I really like seeing a photo of an author, just to get that much more sense of who they are. That was a must. Also, since Twitter isn’t going anywhere fast, I wanted to include something referring to @jchristopher for new readers as well. Last, and definitely not least: search is a must. With my list in place I started sketching.

From the first quarter page sketch I was already pumped on the new design and I knew I was going to like the direction this was heading. To be honest I didn’t even make it to a full page wireframe sketch before hopping into Fireworks and playing around.

I skipped back and forth between Fireworks and sketching quite a bit that first night, and nearly lost enthusiasm just as quickly as it had come on. It wasn’t the first time something like that had happened, but a good nights sleep helped to clear my head and the next evening things really began to snowball.

Process

I’m hooked on 960.gs. Long time readers may be wondering what the heck I’m talking about since many people feel that I hate CSS frameworks. That never was (and never will be) the case, I simply have a specific stance on using a CSS framework, and 960 really caters to that for me. The grid set the stage for the design, and I chose to use the latest variation from Nathan, a 24 column grid. Things quickly began to take shape and I was really pleased with the structure of everything during the initial stages. The only problem was, I was drawing a blank on a color scheme.

If there’s one thing that’s remain constant about Monday By Noon’s brand, it’s the red. Since the first version launched, I’ve based the entire MBN brand on #960000, and I used that as a platform. Until now, the designs have been a mix of red, black, grays, and white, but I wanted something different this time. I’ve been a sucker for tan since forever, and thought “What better time than now?” So I went for it. I poked around until finally settling on a blend of two tan/brown combinations that I felt suited the look and feel I was going for.

I’ll be the first to admit that the previous MBN designs lacked a bit of character. The most recent (minimal) design had a bit of style, but that was one of the focal points I chose for this round. Not too long ago Hoefler & Frere-Jones released Tungsten and the design community went nuts. Me too. In fact I became nearly obsessed with the type. To me it simply comes across as an authoritative, strong, and intriguing. I wanted to use it. With the design community in such a frenzy I nearly put it out of sight out of mind in hopes of remaining as unique as possible, but I couldn’t resist.

After playing with the type I knew that Tungsten was going to become integral in portraying the look and feel I was going for. This redesign also brings something new to the table that MBN has never seen; article copy set in a serif. With Tungsten being the sans-serif it is, a serif, in my opinion, complements it really well. A serif helps Tungsten to become that much more elegantly tough, without a modern feeling many other sans-serif typefaces bring with them.

Iconic

The other part of the inspiration flood was Iconic. Iconic is a free icon set designed and produced by a good friend of mine, P.J. Onori, a.k.a. @somerandomdude. From the second I laid eyes on the icon set I knew it was for me. I wasn’t quite sure where it was going to fit, but the mood set by the type combination I chose for this version of MBN simply called for Iconic in a really strong way.

P.J. has made waves with Iconic, and the set couldn’t have arrived at a better time.

What’s New

Along with the design updates, I wanted to really take advantage of what WordPress has adapted since the last redesign. I’ve been meaning to incorporate threaded comments forever and a day, as I think it really facilitates a conversation as opposed to a generic comment thread. To put it simply, I’m glad I won’t have to be typing @replies to comments anymore!

The other novelty I wanted to include was something I find myself using on Wikipedia all the time: a random article link. While I don’t expect it to be one of the most popular features ever included on MBN, I do think it may help both new and long time readers alike at some point.

What’s Left

I’m far from done with this redesign. In fact I’ve already got a few new ideas coming to fruition in the background already. For example, I struggled a bit with the Archive and ended up shelving the work I had done with it in favor of something as simple as possible. There’s both a benefit and a drawback to publishing once a week, and that’s publishing once a week. I’m determined to design an effective way to browse the archives no matter what mindset you may be in.

I also plan on going back to each and every old post and optimizing the content for the new design. It’s definitely the worst part of any redesign, but I’ve got some things I’d like to do to future-proof against having to do much of that maintenance when the next redesign comes about.

Happy 4th Birthday, MBN

As it turns out, Monday By Noon turns four years old in just 3 days, so the redesign coming to be so quickly worked out nicely as a decent birthday gift if I may say so myself.

I’ve had a blast writing weekly throughout the past four years, and can’t wait until I’m writing a similar article on the 8th anniversary. I hope you all enjoy the changes around here, I hope it’s a great beginning to a great 2010 for MBN!

Advertise here with BSA

I’m having an honest-to-goodness back and forth with myself on this issue because I sympathize with two opposing sides to the same issue. I’ve thought about it so much that I’m not sure it’s as much of an issue I’m making it out to be, but would definitely love to have a targeted conversation about it.

I’d like to review the four rules I’d more than love to use without a second thought on every project I work on for the rest of my life, and explain the issues I’ve come up with (so far) regarding each.

Before (and after) I get to the list, however, I’d like to make my stance on CSS3 clear. I love the fact that it directly helps us as designers make a project go that much more smoothly. It helps us reduce the time we take to engineer the front end, allowing us to spend more time designing. I understand that if people are not able to, or choose not to upgrade their browser, it’s something they’ll have to deal with as the Web continues to mature and grow. It makes perfect sense that the faster we all adopt these “bleeding edge” technologies, it puts that much more pressure on the browser makers to implement things properly.

There’s an element of realism, however, that I feel sometimes takes a back seat to the wonderful things CSS3 (and HTML5) are currently offering us.

Border radius

By far the most popular design treatment you’ll find on the Web is rounded corners. I’d be willing to bet that there are more (completely different) ways to achieve rounded corners on the Web than any other design treatment, if such a statistic existed. The creativeness that has gone into the dozens of ways to best round the corners of a div blows my mind. The point here, though, is that it shouldn’t be such a pain to accomplish. With such a popular and generally accepted design treatment, there should be an easier way. Many designers have taken comfort (and a sigh of relief) through border-radius.

As a quick review, border-radius will automatically provide rounded corners on the referenced element. You have independent control over each corner, giving you a wide range of possibilities when adjusting your borders.

Being able to round the corners of a design element using a quick CSS3 rule is inspirational as it stands on it’s own. Combine that with my arguably favorite ability for border-radius to easily round the corners of images as well as elements with background-images and I’m head over heels.

Taking a step back and examining it, I don’t see a tremendously huge problem with using border-radius today on a production website. I’m not able to take advantage of it on client work, however, because no matter how hard I try to convince a client that visitors with less capable browsers won’t know any different, they’re still going to see a less elegant design. And that’s something I completely agree with.

I am not yet comfortable with putting a client site out there that degrades to the point, although completely accessible and usable, it looks unfinished and utilitarian.

Text shadow

The rise of OS X Leopard brought us the wildly popular text inlay effect achieved through a clever drop-shadow treatment to text. Tons of tutorials cropped up rather quickly with instructions to replicate the effect, and it’s something we see fairly consistently in new designs from both big names and small. We can all understand why, it’s a nice looking, elegant treatment that can improve things both aesthetically as well as improve readability when used properly.

Moreover, text-shadow can help on many levels when it comes to readability, and that’s one of the major reasons I’d like to start using it consistently today. It’s something that can be implemented on a very subtle level, and at the same time return some really excellent results without many people noticing.

Truth be told, unless the absence of text-shadow will morph type into something more difficult to read, I think using it is just fine on a client production site.

Multiple background images

If there are any two opportunities CSS3 brings that I would most like to use, it’s border-radius and multiple background images. I can’t begin to fathom the number of divs I could have saved over the past year alone.

CSS3 gives us the ability to layer multiple background images on a single element which can build upon any existing background properties. It’s useful on so many levels, I can’t begin to explain how excited I’ll be when it becomes standard practice to use.

Unfortunately, this is a property I only use on a select few personal projects simply because the degraded result produced is far too different to deem acceptable in my opinion. That is of course unless you’re simply adding just another layer of very subtle refinement. While some intentional results can be put in place with a clever combination of cascading background properties, in my opinion (at this stage) your time is better spent accomplishing your goal the “old fashioned” way.

Pseudo selectors

Pseudo selectors rock. It’s great that they’re so old, many have been implemented in modern browsers, but you can’t become too comfortable with them quite yet. Of anything CSS3 has to offer, pseudo selectors are something I use on nearly every project.

When it comes to pseudo-selectors, I still think of them as a method of progressive enhancement. The way I use them, the selectors provide that extra level of detail to a design that brings it to the next level. Using that approach, I think using pseudo-selectors is absolutely acceptable, and I’d even go so far as to fully recommend that they be used to tighten up the front end on any project. The changes they provide will definitely not be missed by viewers with non-supporting browsers unless you’re so aggressive with implementation, the render is drastically altered by their absence.

While I do tend to use pseudo-selectors, I find myself only relying on a few for the fine details I’m looking to apply.

When it comes to clients

Again, just to reiterate my stance here; these observations should be taken with a grain of salt. I’m only looking at the big picture, not taking into account the nearly endless variables and circumstances that come with every project that graces our monitors.

The biggest hill to climb by far, in my opinion, is getting the blessing of your client to go ahead with this more aggressive approach. After all, we were hired to produce a certain caliber of work. Unless your client is extremely Web savvy, and is somehow opinionated on the topic of how limited we are when it comes to CSS, their main concern will be that the investment they’re making with you will reach the widest audience possible.

The latest argument to skirt this issue is to simply present your comps after you’ve already began front end development. That is to say, some designers feel that presentation of a static comp is no longer applicable directly as a result of wanting to use progressive features such as CSS3. The idea behind it is this: if your client is using a substandard browser, the production site will look exactly like the approved comps simply because they’re using the same underpowered browser the whole time. Meanwhile, visitors with modern browsers will be graced with the much more pleasant version. As the client upgrades their browser, they’ll be elated that this new browser made their website look that much better! Although I’ve never tried that approach, I can’t quite stand behind it.

In my experience, clients are extremely detail oriented. They’re going to ask for more should they see the design in IE6, even if you took the time to beautifully degrade. At that point you have two choices; you can revert to the old school, or you can trek down the path of explaining CSS3 and why they need to trust you on this one. All the while eating those hours.

As I mentioned, this is something I’ve been going back and forth with for some time now, and I think having a conversation on the subject using realistic circumstances and case studies would be superb. What’s your stance on the issue, specifically when dealing with clients and not your personal projects? Do you think CSS3 is simply ready for prime time given the many repercussions involved? At what point will it be acceptable to implement CSS3 and not have to focus on fallbacks and graceful degradation?

Advertise here with BSA

Book giveaway!

Zoe’s publisher, New Riders was generous enough to donate two copies of Flexible Web Design for giveaway, so I’m going to do just that!

If you’re interested in reading Flexible Web Design, just leave a comment below and I’ll choose two winners at random. Winners will need to have a US or Canada based mailing address. Entries will be accepted until Sunday, December 13 11:59pm EST at which time two winners will be randomly chosen.

Advertise here with BSA