by Kyle Weems 9.May 2008 08:10
Variety in donuts is cheap. Part of the appeal to working at Mindfly is the close proximity to Rocket Donuts. Although this hasn't done my waistband any favors, it does make it altogether too easy to buy a baker's dozen of donuts for under $12.
In the browser world, variety gets expensive after a point. Like any developer studio, Mindfly has several browsers on hand to see how our websites are rendering. Granted, we're very web standards oriented (I feel like I should capitalize that for emphasis). Although this means in theory a website should look mostly the same in every browser, in practice we all know this doesn't work out so well (as I've ranted frequently about in the past). In particular, IE6 and IE7 (which sadly have the largest share of the Internet Pie... which is something I now want to bake) are renowned for sort of taking standards like guidlines that can be conveniently ignored.
Mindfly is a Windows-based shop (I'm sure plenty of you designers don't believe that's possible, but it is!) so it's free/easy for us to test our sites on IE7, IE6 (via the virtual pc), Firefox, Opera, and Safari/Win. However, our token Apple's operating system isn't up to date, so we don't have the newer version of Safari/Mac to test. Furthermore, although it's a small piece of the pie, we don't have any Linux boxes to test the million different browsers supported by the various Linux flavors.
What do we do? Ignore the problem and tell Apple to shove it? Spends lots of money on tons of computers?
No.
First, designing with standards fixes the vast majority of potential problems before they happen.
Secondly, if you need to confirm any visual glitches on a website in a browser you don't have, you can check out Browsershots.
I've had it pointed out to me just recently, but it's a neat little site that you can give any url to check out, and after some processing time it shows you how that url renders on a cornucopia of browsers (quite a few more than a baker's dozen, I might add). I'm not sure that I need to know how a site renders with Kazehakase 0.5.4 on PLD Titanium. But if a client is complaining of an issue in Safari/Mac, I can give it a quick look.
There's severe limitations, of course. It's just doing a screenshot of the page, so there's no interaction. And it's not practical to do edits, take a snapshot, do edits, take a snapshot, etc. But used appropriately, I can see Browsershots being the sort of tool that helps spot glaring issues before a client does.
by Kyle Weems 30.April 2008 14:07
I had the (mis)fortune to watch the 1983 fantasy 'classic' Krull yesterday. With the amount of laser beams and white-clad troopers in the film, it feels like someone put Sleeping Beauty with Star Wars in a blender, then had Lewis Carrol write the dialogue. I enjoyed it immensely, but then, I am apparently sick in the head.
The premise goes as follows (I swear there's a point to this): Prince Colwyn goes to marry the princess of an opposing kingdom so their lands can unite to defeat 'the Slayers', an invading army from space. During the wedding everyone but him is killed, and he's rescued by an old man that I'll call Obi Wan Kenobi's Doppleganger (or OWKD for short). OWKD tells Colwyn that he needs a mystic weapon called "the Glaive" to defeat "the Beast" that leads the Slayers and rescue the princess. So Colwyn proceeds to climb tall mountains, stick his hand in lava, recruit criminals, get a couple of seers and OWKD killed (and a cyclops) and so forth before finally confronting el Beasto in it's asteroid/fortress lair. Finally when the time comes for him to defeat the big baddy, he manages to wound and knock it down with his Glaive (always capitalized in speech) only to have the beast get back up and proceed to look like a bad acid trip. All would be lost, but at the last moment he and the princess realize (with little clues as to how) that the way to beat the Beast is their true love, which manifests in this case as a magic flame that was part of their wedding ceremony. Colwyn then proceeds to kill the Beast, destroy the fortress, and wipe out the Slayers with the magical love flames.
*deep breath*
So what was the point? The point was that OWKD, experienced savant and mystery man, totally misled Colwyn into an unneeded super journey by telling him that the Glaive was needed to kill the Beast, when in fact all he needed was his magical wedding love flame.
I experienced a much less epic version of this recently when working on a client's site. (Ok, by less epic I mean that I had no troops following me, no magic weapon, no cyclops friends, and a distinct lack of enemy fortresses, so the comparison may be a bit strained.) In particular, the client has a list of files on various pages on the site, and the list was to be decorated by icons depicting the file types used. This feature was requested late in the stage of the project, so the code responsible for generating the list didn't provide any classes on the anchor tags based on the type of files linked to.
Ever since I attended a workshop at WDN08 by Andy Clarke I've been drooling more and more over CSS3 attribute selectors, and thought this would be the perfect solution.
Attribute selectors are conditional modifiers that can be added to CSS selectors to make them apply to an element that matches certain values in certain attributes. The notations vary depending on the type of attribute selector being used, but they range from e[attribute] (which matches an element e with the attribute listed in it) to the more commonly used e[attribute="value"] (which matches e only if it's attribute has the value contained in it) to the awesome CSS3 attribute selectors like e[attribute*="value"] (which will match e if the value appears anywhere within the attribute).
In the case of this particular project, I needed a different icon for all items linking to .PDF files versus an icon for any other file type. So the obvious solution was to insert selectors to the effect of a[href$=".PDF"] for the pdf files (it matches any anchors that have an href that end in .PDF] that would override the icon style for the generic a. My glee came grinding to a halt when I encountered the following in the SitePoint CSS Reference that I was using as a source: "Internet Explorer 7
doesn’t support the partial matching of attribute values." with a little visual graph indicating that no version of IE supported CSS3 attribute selectors yet.
Curses! Once again, the evil, scaled beast that is Internet Explorer (also known as Darimikanius the Devourer) has reared its head and sent good design standards running.
So bemoaning the unfairness of it all, I spent an hour polishing my rusty JavaScript skills and plugged a script into the site that would add a class to the anchors if their href attributes linked to a pdf file.
Was it as hideous as fighting Slayers in a swamp next to a cyclops? No. But time equals money, and as it turned out, my mentor was as incorrect as OWKD was to Colwyn.
You see, after I'd finished up that project, I started working on a generic JavaScript that would provide CSS3 attribute selector support for IE7, thereby allowing me to use those selectors in future projects. Partway through the coding process, I put together a test page that I'd hang the script on to test it, and loaded it up in my browsers prior to adding the script to make sure everything was looking proper.
To my shock and horror (or relieved surprise, I'm not sure which) IE7 was rendering the selectors all on it's own.
SitePoint had lied to me!
Well, perhaps it merely made a mistake. But after getting over the sheer waste of time I'd spent on the project, I found it funny how accustomed we are as web developers to IE's standards-compliance issues that we're willing to accept that it doesn't support a feature without first testing it ourselves.
Consider my lesson learned.
To prove I'm not insane, check out the following test page in IE. Like all the other browsers, it's properly using all the attribute selectors, including the CSS3 ones. So I could have saved the client an hour instead of inventing an unneeded script.
There is a catch (as always). IE6 doesn't support any attribute selectors at all, including the CSS2 ones. Don't take my word for it, load up that test page in IE6. This is unfortunate, but it isn't precisely a disaster. I personally think that it's ok to have a different appearance for your page in IE6, as getting a site identical on all browsers is a holy grail that'll never be acquired. But if the need arises for as similar an experience is possible, it turns out that someone has done all the hard work of making IE6 work properly. I'm speaking, of course, of Dean Edwards. His IE7 script has undergone a lot of upgrades recently, but it still does all the wonderful things it's done in the past. I've added the script into a second test page, which if you view in IE6 will render properly.
So save yourself some grief and check how a style works before taking IE's poor performance for granted.
Oh, and someone get SitePoint to update their CSS3 attribute selectors page.
by Karina Beattiger 29.April 2008 14:53
There's a handful of sharp-edged burdens that martyrdesigners must carry, but chief among them is probably the designer-to-developer crossover. The one thing I've heard Heather say repeatedly -- whether she knew anyone was listening or not, I may yet never know -- is that the spacing gets all crazy from the proof to the cut stage. Though we do our best to eyeball and, sometimes, flat out use the CS3 selection tool to measure the exact padding measurements, there's a lot -- a lot! -- of room for error. Or, ahem, developers' judgment.
Just recently, Heather enlightened me to the secrets of the "design column" -- a way of using columns not as text layout objects, but as visual cues for what elements should go where. I'm sorry, but until you have passed the 100 Trials of the Wayward Peacock and returned to me with the diamond-tipped hairpin of the seventh sister of the Lost Shogun, I can't say anymore.* (They're always watching...)
Enter Eric Puidokas' Firefox extentions, GridFox! This little gem of an add-on (sorry, IE'ers) allows the user to input the measurements of the designers' design columns. The add-on then overlays a shadowed opacity in the exact shape of the columns and gutters, providing immediate visual cues as to how far off the designers' intent we really are. A quick glance at the screen can show that your header, which should be 10 pixels from the left edge, is actually something like 20px, and that just isn't right.
Now, it also gives, in my unasked for opinion, feelings of severe complacency: don't let this handy tool take away your own eye for "how things work" on the web! The biggest disconnect between those who are primarily designers and those who are primarily developers is the translation of "what looks awesome" to "what will look less (or more) awesome, but still work on the internet". It'd be far too easy to mimic the designer's intent exactly, forgetting to keep an eye out on those layout issues that could crop up and affect usability and interface.
A seamless blend, that's what I promote. Inner peace and outer harmony, spiritual well-being between those who design, those who don't, and those who do a little bit of everything.
Having spent the past couple of weeks dealing with a particularly
sharp-eyed client, I can't share enough how something like this, when
used in conjunction with a designer who actually uses the design column
method, would have come in extremely handy.
* Stay tuned for future post explaining columns, if I can't find a better description on another website first. Shhhh.