Archive for January, 2009

CSS class subset selector

January 30th, 2009 by Bobby Whitman

I made a cool little CSS discovery recently that I have already found to be quite powerful.

Using the class selector is done with the “.” character.

.foo { color: #ff0000; } makes any <div class=”foo” /> have red text. Likwise, .bar { font-size: 50px; } makes any <div class=”bar” /> have really really big text.

With CSS, it is possible to apply multiple classes to the same element by separating them with a space. In fact, <div class=”foo bar” /> will have really really big text that is also red in color.

But what I recently discovered is that it is possible to define a style that only applies to those elements that have all of the specified classes set. This means we can create a style that is only seen when an element has both class ‘foo’ AND class ‘bar.’

This is done like so,

.foo.bar { background-color: #ff00ff; }

Now, <div class=”foo” /> and <div class=”bar” /> will both take the background of their parent, but <div class=”foo bar” /> will have a rockin’ magenta background.

Pretty cool.

This is just a simple example. What is really going on here is that we are giving a style to a set of classes. And this style gets applied whenever that set is a subset of an element’s classes.

<div class=”a b c d e f”>Hello World.</div> (This element has a class set of {’a', ‘b’, ‘c’, ‘d’, ‘e’, ‘f’})

.c.b.a { color: #00cc00; } (This CSS style has a class set of {’c', ‘b’, ‘a’}).

Since {’c', ‘b’, ‘a’} ⊆ {’a', ‘b’, ‘c’, ‘d’, ‘e’, ‘f’}, our <div> will get this style.

Hmm, I feel a set theory post coming on.

That’s not fair

January 26th, 2009 by Bobby Whitman

The majority of our time as web developers is spent writing markup (xhtml and css). Because we are committed to building the most functional, usable, and accessible sites, we do our best to adhere to web standards. So, we often refer to the CSS 2.1 Specification, a 384-page document fully defining and explaining the many properties of standards-compliant CSS programming.

Now, this document is great, but it is still up to the browser and device creators to support all of the properties set forth in the specification. And, we know that certain properties just aren’t going work in certain browsers.

With great care, we learn the ins and outs of the specification and the idiosyncrasies of all popular web browsers, then write code accordingly. Of course, we still must diligently test and tweak our code and make sure that it does in fact look just as intended.

Then comes IE6 to ruin the day. IE6 is an out-dated piece of technology that just won’t die even though Microsoft released the next generation of Internet Explorer long ago. IE6 is the bouncer that throws you out of the club for no reason at all. You are being a respectful gentlemen, following all the rules then suddenly IE6 comes up behind you, grabs you by the collar, and tosses you out onto the street.

And we deal with this, we have a laundry list of IE6 workarounds that force it to act right. Throw in a little more tweaking and cleaning up of code and before long we have IE6 displaying our work as it should be displayed.

So, last night I was a bit distraught when we received an e-mail from a client with the following IE6 problem.

The list of videos on their site was displaying a bullet next to each video when it should not have been. The client sent a screenshot of the problem and luckily she was savvy enough to have the “About Internet Explorer” dialog open displaying the browser version detail. It was version 6.0.2900.5512.xpsp_sp3_gdr.080814-1236 to be exact.

Next, I opened up IE6 on our computer and I saw no bullet. So, I opened up the “About Internet Explorer” and found that we too were running version 6.0.2900.5512.xpsp_sp3_gdr.080814-1236.

Client IE6 View dynamIt IE6 View
Client IE6 View dynamIt IE6 View

That’s not fair.

We work too hard to have IE6 render pages on a whim. How am I supposed to solve this when IE6 refuses to play nice?

Do all of us web developers a favor by finding one non-tech-savvy friend and assisting them in downloading Firefox or Opera.

Web Design vs. Print Design

January 23rd, 2009 by Phil Franks

Designing for the web versus designing for print can be a completely different experience for a graphic designer. Embracing the medium as something different from print, and understanding how design works in digital media is the first step that most designers need to take. Specifically, come to grips with the fact that, on the Web, design is not a method for implementing narrative, as it is in print, but rather it’s a method for making behaviors possible.

I had to take this step when I got the opportunity to work at dynamIt after undergrad. I ventured out into the design world gripping a degree that was based in print, with little knowledge of design on the web, but eager to get my feet wet. I’ll admit it, I wasn’t very good at what I do now a couple of years ago, but I can say that now because I have learned and embraced the intricacies of designing for web. Given this experience in the web industry, and specializing in user interface design, I have grown to appreciate the differences between print design and web design. The reality is that the web is not print, it’s not a great big graphic, and trying to force it to be that is just a bad idea.

If you’ve designed more than a couple sites for people, you’ve almost certainly heard a comment or two that sounds something like this: “That would look better if you moved the graphic down about 5cm or so.” or “I’d really like that blue to be as rich as it is on paper, can you do that?” The problem with this attitude is that it is based on a fallacy. That fallacy is that you can design a web page that will look identical and pixel perfect no matter where you view it. With most print projects this theory would most certainly be true, but that’s not the case with web design. What most fail to realize is that there is going to have to be compromise from the PSD (or whatever program you, as the designer, choose to use) to the final product. These compromises are inevitable and are most apparent in categories like audience, layout, color, fonts, and graphics.

Audience

Whether the web designer is working on an interface design, email newsletter, or banner ad, he or she is going to have to consider the audience and how they are going to interact with the design. When beginning a project, it is important to think about the experience of your audience, which differs greatly between print and web design. At the most basic level, the web is interactive and print pieces are usually not.

In print, the designer is focused on getting the marketing message across, and these usually turn into forced tangibles like business cards, magazine ads, or product packaging. One of the benefits of print design is that you are dealing with a physical product, so physical properties such as texture and shape can help you achieve your design goals.

On the web the designer has to think about the overall experience, putting themselves into the user’s shoes. The overall goal is typically to keep the user on a page/site for as long as possible, while also making the experience easy, user-friendly, and visually appealing all at the same time. While I classify print design as being somewhat of a ‘forced tangible’, I see web as being even more difficult as a ‘voluntary intangible’.

Layout

Both print and web design require clear and effective layout. In both, the overall goal is the same, use elements of design (shape, line, color, type, etc) to present content to your audience. The differences start in the available space to create your design. I have always said that print design is designing with boundaries, and web design is designing to infinity.

In print, the designer knows what space, measured in inches, that they have to work with. This could be as small as a business card or as large as a roadside billboard, but the designer knows the space allowed from the start, and that the finished product will look the same to everyone who sees it. There is a lot more to consider than just the bleed line and safety areas when designing for the web.

First off, web designers live and die by the pixel, inches are erroneous. Second, a web designer is faced with the challenge of designing a site that looks good on all monitor sizes and monitor resolutions. Since the space with which a web designer has to work with is an estimate, you have to cater to the statistics, while keeping in mind the people who haven’t embraced newer technology. Over 50% of people who own computers have their web experience at 1024px by 768px or higher, and a mere 9% are at a lower resolution (800×600 pixels or lower).

Color

Dealing with color can be tricky for both web and print designers. It’s first important to understand the color models such as CMYK and RGB. The RGB color model is used when designing for the web, while the CMYK color mode is designated for print design.

In print the designer must consider how the colors look from the monitor to paper, but print proofs can ensure the desired result. When preparing the file for print, the designer will often choose ’spot’ or ‘process’ colors for the printer to use. These are colors you choose from a palette and identify with a pantone code that you provide to your printer.

Now when a web designer tackles a color palette and carries it throughout a design, there can’t be a guarantee that the end user will have the same experience. Colors on the web are not referred to by pantone codes, but by hexadecimal values (6-digit numbers), for example: black (000000) and white (ffffff). A web designer has to consider the difference in colors from monitor to monitor, and how color will be affected by brightness and contrast changes. If you use a CRT monitor the colors you see are much more washed out than others see on a newer laptop or LCD flat-panel displays.

Fonts

When a print designer adds the typography touches to a poster or package design, they can dig through their font libraries without any inhibition (unless the project has specific specs). When designing for print there are really no worries with what fonts the designer chooses to use, because in the end the final product will be seen the exact same by everyone who views it. Another small, yet overlooked difference between print and web design.

Choosing fonts for a web design is a much more delicate process, and unlike print design, there is no guarantee that the end user will see it the same way. Since there is absolutely no way one could predict what fonts the end user has installed, the web designer is forced to stick with ‘web safe’ fonts. These are fonts that are present on a wide range of systems, and are used to increase the chances that the content will be displayed in the original font. There is a work around, but it takes some programming from a developer, and it’s an open source Javascript and Adobe Flash based technology called sIFR. The reality of web design is that unless you’re planning to make every page of your site one large graphic, your page will have text on it.

By now, you’re probably thinking “but why not go the easy route and make the site all images?” After all, with a bunch of images, you can control the fonts and layout. There are several reasons why this route is a dumb idea.

Graphics

Sure using an entire page of images would be super easy to lay out, and you could use any font you desired, but there are things that most print designers fail to realize:

  1. File size and download time. With a site that is 100% graphics, yes, the HTML file size would be small, but unless you create very tiny Web page graphics, it will take forever to load.
  2. Accessibility. Images are fairly inaccessible without alt text, and unless you’re planning on reproducing your entire site contents in one giant alt tag, your site will be completely blank to the typical screen reader.
  3. Search Engine Optimization. For much the same reasons as accessibility, if your site is a giant image, search engines will not read it, or won’t read it very well.
  4. Links. Sure you could use image maps, but that’s just a pain.
  5. Maintenance. If you find a typo, you have to find the original image, edit it, resave the image and then reupload. With text, you’d just edit the text directly and be done.

Web design is not print design. The styles are different, the way each are executed is different, and the way the end user interacts with each type of design is different. Not understanding, appreciating, or acknowledging the gap between web and print can cause a lot of headaches, especially for developers (I have seen it happen…a lot!). While it is possible, with CSS, to get very precise layouts, it will never be as precise as print. Take the time to educate yourself a little before diving into a web design, there are plenty of resources out there to get you up to speed on best practices and trends. Here are some of the sites I use daily to keep up on design and the web, check them out:

http://www.smashingmagazine.com/

http://www.abduzeedo.com/

http://www.webdesignerwall.com/

http://www.sixrevisions.com/

http://www.webdesignledger.com/

If that’s not enough and you want some more, check out these sites that showcase even more invaluable resources for design, inspiration, and productivity.

Those are some good rolls.

January 14th, 2009 by Bobby Whitman

Back in November, dynamIt was contracted to develop a site for Sister Schubert’s Homemade Rolls. Find it here: http://www.sisterschuberts.com.

This company has an interesting problem, because they ship a perishable product they must require that two-day shipping is used on every order. This makes shipping to far-away places expensive. Sometimes, it can even be more than the total price of the order. Yet, people still buy.

Then, another one of our clients saw this site in our portfolio and being from Alabama, the home of Sister Schubert’s, was familiar with these rolls. He talked our ear off on exactly how good these rolls are.

Then, I found these rolls at WalMart and had to purchase a pan.

I now see the light. I baked the pan of 20 rolls and in one sitting consumed 17 of them by myself. Needless to say, they are delicious.

Good.Web.Costs.Money.

January 13th, 2009 by Nick Seguin

A Little Story

I was having lunch the other day with a principal at an interactive agency here in Columbus (Shift Global) and the waitress overheard part of our conversation (just some shop talk). I had been avoiding eye contact with her and my order was quick [more on this later]. As she set the check down she asked if we ‘did websites’, to which Bill answered yes, we both did.

She proceeded to tell us that she needed someone to ‘do her website’. She had engaged a firm months ago to get a site/app built, but they went out of business while under contract. They refunded her money in full and she was now looking for someone to dev it for her so she could ’start making money’.

She was really frustrated because the original firm had quoted and accepted a contract for $5,000 and she was now getting quotes for 3x, 10x, 15x this amount [will connect to this later too]. She knew that “these prices were ridiculous and that it could be done for the original quote” (perhaps there was a reason the original firm went out of business?) She asked if we had cards. I sheepishly said I didn’t have any on me.

Why had I avoided eye contact? Why didn’t I hand over a card? Well, dynamIt has a policy to give at least a half hour of time to nearly anyone who gets in contact with us. We may know, immediately, that they don’t have the budget or the expertise to make an idea work (or we may know that the idea has either a) been done before or b) is just a bad idea), but it’s our practice to hear them out, at least for a while.

The funny thing is - this waitress had been at our office 2 weeks before, had detailed the idea and situation to me. She didn’t have a revenue model (I asked how she was going to make money and she gave me one of those “oooohhh yaaaa…revenue” looks) but did want some rather complex inter-user interaction. I’d given her a ballpark which I knew she probably couldn’t and wouldn’t go with. She had responded to the ballpark in an annoyed way, and we left it at that. Thus, my lack of excitement to see her again.

My point - GOOD.WEB.COSTS.MONEY.

This doesn’t just happen with individuals who have ideas that “rival Facebook and Google”. This happens with clients big and small, startup and established. In general, we find there are few cases in which people have a concept for what good web costs.

Because people have a Hotmail (gag) account, have searched Google before and may be able to purchase something off of eBay, they assume they know what goes on in web development and how much it should cost. I’m not saying that everyone needs to have intimate knowledge of the industry (my colleagues and I would certainly be out of work), but, people, PLEASE!

Good web is strategic. Good web is architected, is planned, is built, tested and strengthened. And, one thing that good web most definitely is, it’s NEVER DONE. You get what you pay for. There aren’t many industries where this is more true than web. A holistic and anthropological solution requires dynamic minds, critical thinking, problem solving and execution. People should and do pay for this. 

Oh, and another thing - we’re not going to take shortcuts, hack things together and simply react to a problem. Not only our reputation, but good, sustainable and extensible web (the industry/platform) is dependent upon well-built applications and solutions. So, as I say, we aren’t going to simply react to a problem with budget and timeline in mind and risk compromising the product. Rather, we’re going to respond to a problem with a solution. Response and solutions cost money.

that is all.

one.

nick

dynamIt peace of mind starting at just $200 per month

January 7th, 2009 by Bobby Whitman

So, I have been tossing this new product offering around in my head. I like to call it dynamIt Peace of Mind. It is quite simple really, all you need is an existing website that is at least moderately attractive and functions well, and some expendable budget.

It works like this. You select the plan that fits you the best. Then, you pay dynamIt, a quality web engineering and design firm, $X per month. Before you know it, you begin feeling better about your web presence. That all there is to it.

It is sort of like the placebo effect for web. Because you have a qualified web firm listed under your operating expenses you figure your website must be getting better. Makes sense, right?

Yes, it sounds crazy, but from time to time in working with clients we hear stories that are not far off. Recently, we were told by a corporate organization who was not too familiar with CMS that their last campaign site cost them about $35,000 annually and that afforded them two updates all year!

Luckily, dynamIt takes a different approach. More to come on this soon.

But seriously, if you are interested in dynamIt Peace of Mind, you know where to find us [wink].