by Janae Wiedmaier 27.August 2008 08:57
As I sit at my desk on this relatively dreary Wednesday morning, I can't help but still feel the need to continue this overlying dance into the heart of Chicago. I can't help but feel some sort of kinship with Roxy and her big dreams. Don't get me wrong, I'm not going to go out and murder someone to become a big star... not that it really works out all that well for her, so lesson learned! But hey, every girl has to be allowed to have her dreams, right? Well, I've always had the dream to do web design. So, imagine my embarrassment when I come to work for Mindfly and felt somewhat in the dark ages when it comes to how the big guys do stuff.
A great example of this is image replacement. Looking about on the web, there are a lot of different ways to do image replacement, and I'm happily going to factor it into finishing up our vector buttons (You were wondering when I was going to get back on topic, weren't you?). For the sake of making a meaningful button, I decided to add some text on top of our flower. You can put in whatever you'd like, and I just tried to put something cute and fun on that was simple. No need to be complex when you're learning the system, right? Remember when you go to save your image to Save for Web... and to save it as a PNG-24. This will ensure that it will retain the transparency. Also remember to save a copy with the hover on and the hover off. I named mine vectorFlowerHome.png and vectorFlowerHomeHover.png using the Camelback Method.
Rewind for a moment back to image replacement. Since I was clueless as to the uses of it, or how it worked, my first question was, of course "Why?" Why, indeed, when you can just use the images rather than going through (what seems to be) a complex process to instead have text that is then replaced by an image and requires more CSS and... Okay, deeeep breath. The reason for using image replacement is so that Google's algorithms can find the content on a site. If all they see is images (they aren't searching through the html for the long detailed image names that you've done similar to my own). If you're using an image for your company name or web page name or some name that's floating out there around in tiny molecules like it's hovering inbetween giant and mini chocolate bar size, then all Google is going to see is an image not the name of your company, or your web page, or whatever name you have floating out there in the void.
This is the point in which the lightbulb went off for me and hovered over my head. I hope that it is at least flickering up there for you, dear reader.
To start out your image replacement, now that you have your files all saved, you're going to need to have your html. You can see by Example 1 that all you really need to have to start with is a link.
Now, the idea behind this is, of course to have an image. We've already discussed why we're not using an image here. We want Google and other search engines to know that this is a link to the home page, hence the very obvious and not so subtle title. You have a few options for how you want to go about applying your image to this. You can give it an id and add id="home" to the html or a class="home" but since the link already has a title, I've decided we can just use the attribute selector to make things simpler.
In your <style> at the top, you'll want to add the following:
a[title="Home"],
a[title="Home"]:visited
{
display : block;
width : widthofyourimage
height : heightofyourimage
background: transparent url(yourimagelocation) no-repeat top left;
}
You can see all this CSS applied here in Example 2!
Now, to answer a few of those "Why" questions that are rolling around:
Why a and a:visited? This helps prevent some bugs from occuring in IE6, as well as applies the style both on the regular link and if someone has already been to the page. It basically ensures that the style will continue to work properly.
Why display block? Links are naturally an inline element so without giving it a display: block the width and height wouldn't be able to be applied properly and the link would still only focus around the text itself rather than the image. This means that you'd only see the top tip of your flower.
We're almost done, so bear with me! The next step is to apply your image replacement to the CSS. You can do this by simply adding underneath your background style in the CSS, the following: text-indent: -9999em;. What is an em? W3Schools has a nice explanation of it here.
You should now see the text removed from the screen and only the image remaining, per Example 3.
I know what you're thinking. "Well?! Does Billy win the case? Does Roxy get away with murder? How does it end?!" Please, stop with the choking motions. I can't type if I'm turning blue in the face. What you really want to know, dear reader, is how to apply that darned hover style, isn't it? A fittingly dramatic ending to a dramatic case.
Simply copy the CSS you used before to a new spot below it, remove the a[title="Home], and change the a[title="Home"]:visited to a[title="Home"]:hover and, last but not least, change the url in your background to the image that you want to be the hover. Your CSS should look something like the following:
a[title="Home"]:hover
{
display : block;
width : widthofyourimage
height : heightofyourimage
background : transparent url(yourimagelocation) no-repeat top left;
text-indent : -9999em;
}
Okay, so maybe it wasn't a dramatic ending after all... However, the Final Product is lovely and works just fine, so all thoughts of drama aside, I think we can say that court is now adjourned.
--
To see the previous discussions on vector button creation, go to:
Give 'Em the Old Razzle Dazzle (Making Buttons in Vector, Opening Argument)
Give 'Em an Act That's Unassailable! (Making Buttons in Vector, Cross-Examination)
by Kyle Weems 25.August 2008 08:12
When it comes to discussing web-related topics on the Internet, your average person that makes websites frequently comes across as something of a drunk rugby player in a china shop with a disagreement with the shopkeeper. Conversation gets very heated very quickly, and there's usually collateral damage.
I attribute this to a combination of passion on the subject and the relative safety provided by conversing with someone hundreds of miles away by text. Carolyn Woods goes over this tendancy to bad behavior (and solutions to stop it) in her A List Apart article Putting Our Hot Heads Together. But I'm not here to discuss bad behavior.
However, I am going to discuss of the many topics that seems to attract so much vitriol: dropdown menus (or mouseover menus, or whatever you'd like to call them).
There's a lot of problems with this navigation technique. The first major issue is that they're not terribly effective at what they're supposed to do (namely, helping someone navigate a site). Don't believe me? Then perhaps some experts on the subject can dissuade you (like Jeffrey Zeldman, Jakob Nielsen, and the very guru of UI's, Jared Spool). I'll let the experts speak for themselves, but the heart of the matter is that dropdowns work against the way people naturally try to interact with the data presented on a page, and prove to be an obstacle to navigation, not an aid.
However, as I've noted, dissent is practically a hobby for website creators, so these little gems of the web keep showing up. Worse yet, non-experts who want a website are frequently very adamant about what they want on their websites, research be damned, so at various points in their careers virtually every web developer is going to have to make a dropdown menu or two (or ten, or a thousand. They breed like rabbits.)
So when the time comes to make one, you might as well make one correctly. This would seem an easy proposition, especially for people with even a bit of CSS under their belts, but the reality (as always) is never the same when it comes to developing for the web.
In a perfect world, we could use simple, clean HTML and CSS to make a dropdown menu. We don't exist in such a place, but for argument's sake, take a look at Example #1 to see how something like this would work. We've got a series of unordered lists to hold our menu. The highest level list is the main menu, and always visible. The secondary lists are the sub-menus, which we hide with ul#ulMenu ul {display: none;}
To make the submenus appear on a mouseover is a surprisingly simple, taking advantage of the :hover pseudoclass. ul#ulMenu li:hover ul{ display: block;} causes the selected submenu to appear when you hover over it's parent list item (animal, vegetable, or mineral in my example). It's as easy as that.
Well, in a perfect world.
Unfortunately, we live on a blighted sphere that is frequently troubled by a writhing, unholy, juggernaut of flawed design; a black beast that lives well past its natural lifespan by burrowing through the Earth to collect the souls of the unenlightened.
I speak, of course, of Internet Explorer 6, which was not only horribly flawed in its standards implementation on the day it was first released, it has managed to persist into the modern era where its standards implementation is positively anachronistic and deeply problematic. Why is it still being used? Mostly we can blame corporations and schools afraid of the cost and risk of upgrading their software. But rather than continuing to pontificate on my soapbox, let me just get to the point: approximately 25% of Internet users are still making use of IE6.
This means that in most cases we as website creators need to ensure that our contstructs can operate in the twisted rendering engine that is the black soul crouching at the heart of IE6. Unfortunately for our little dropdown menu, IE6 does NOT support the :hover pseudoclass on any element other than anchors. Which means that 25% of your users can't see your submenus if you're using the example above.
This is unacceptable in professional development.
So what now? Well, we could form some sort of web creator suicide pact and just depart this cruel world while stepping off an appropriately tall tourist destination. But rather than follow down that grim path, I'm going to suggest that we get creative.
Or borrow from people that have. Dropdown menus have been around for more than a little while, and so several clever people have come up with various solutions to the IE6 problem while only making use of valid HTML and CSS.
And more specifically, Internet Explorer's conditional comments.
In particular, I want to thank Stu Nicholls, who by all accounts pioneered the technique, and the fellow(s) at GRC that smoothed out the conditional comments a bit more with their navigation menus. The following example borrows heavily from their ideas and examples.
With credit given, let's take a look at Example #2. It still uses all the same techniques for compliant (or in IE7's case, mostly compliant) browsers. However, we've added a good deal of extra html behind conditional comments.
What are conditional comments, you ask? I've actually discussed this delicious topic before in my cleverely titled post Say Goodbye to the Stars. Go take a gander if you're not familiar with the topic. Once you are, let's continue.
The main obstacle with IE6 and the first example was the :hover pseudoclass only working on anchors. The solution is using conditional comments to create a tiny table inside an anchor tag for each submenu (by using conditional comments we preserve the validity of our markup for the major browsers). We need the table for IE6 so we can have the submenus appear when we hover on the main lists anchor tags.
Say what?
That's correct, since anchor hover styles work in IE6, we're shoving our submenus inside the anchor tags for that browser only, then using IE6-specific CSS to make those menus appear on a a:hover ul{display: block;} rather than the li-oriented style we used for our first example. However, due to various browser quirks, we need to put those submenus inside tiny tables so they actually display (without which, the ul's won't show).
There's some major advantages to this technique, chiefly that it requires only valid HTML (technically) and CSS to work on all browsers. The problem is that to make it valid and still work on IE6, we're using a whole lot of conditional comments, which really should be used sparingly. This is a great technique for a site that we need to ensure the menu works even if the users don't have Javascript enabled.
Although the solution is effective, it's not very elegant. However, we've got a third option: Using CSS & Javascript.
Some designers are quite opposed to making use of Javascript for page elements like navigation, due to the fear that it will make the page unusuable by users with their Javascript turned off. To this I've got two responses: 1. your dropdown menu shouldn't be your only navigation technique (see beginning of post) and 2. Javascript market penetration is pretty much universal at this point in time.
As I've mentioned many times before, a good man by the name of Dean Edwards has used Javascript to create a 'patch' that can fix many of the standards compliance issue that IE6 has. This script (called IE7 confusingly enough), is relatively small-impact on a page's load time, and among other things fixes the :hover pseudoclass limitation. So, by including it on your site with your menu from the first example, you get a site that is (1) valid, (2) clean, and (3) runs on every browser including IE6.
Example #3 shows this in action.
So, which technique should you use? Until IE6 has shrunk to the point of obscurity, you should probably avoid #1 on any site expecting normal traffic. Whether to use #2 or #3 depends a lot on your preference and your client's needs. I think that #3 is the cleaner solution, and many modern sites rely on Javascript to make the site render properly in IE6 these days anyhow, so you're usually fixing more than one problem with this technique. However, #2 is guaranteed to work on pretty much any browser regardless of whether they've disabled Javascript or not, and is completely valid (if only technically so).
However, I say use none of them. Beg and plead your clients to use a more reliable navigation technique. That said, since we've proven we're not in a perfect world, use the solution that best meets your needs and your client's demands.
by Theresa Carpine 19.August 2008 16:36
Something that most people don’t know about me is that I love to eat. Really. I spend an inordinate amount of my day thinking about what I am going to eat later on. And ironically, eating helps me to focus; I am pretty sure that my snacking abilities sustained me through four years of college lectures. So while you’ll usually find me munching on something at my desk, there is nothing quite like sitting down to a hearty meal with friends after a long day at work or play.
Unfortunately, I also possess very limited cooking abilities. So besides simply eating, another one of my favorite activities is eating out! While eating out is decidedly taxing (literally) on the pocketbook, my bad habit also provides the inspiration for this blog post: restaurant websites.
As with any business, what an owner includes on their restaurant’s website depends on the individual establishment. But here are some of my suggestions, as a seasoned restaurant website surfer, for the most important information to include, and some other fun ideas.
All the essentials (name, address, phone number and hours of operation) should be easily found on the homepage because a potential client is probably searching for one of those four facts. Including a photo or graphic of your restaurant’s marquee, so patrons will recognize it when they drive by, is also a good idea. A few quality images of your restaurant will also make the website more interesting visually. A contact email can also be included, but only if you’re going to check it and respond to it on a regular basis.
If you’re going to have a website with multiple pages, I suggest including the menu to give people a quick glance of what you have to offer. A word of warning, however, on menus: make sure that the menus are updated frequently to reflect changes in seasonal fare; I find it a little irritating when I’m looking at a restaurant’s “winter” menu in June.
Providing a menu on a website is especially useful your restaurant offers a call ahead service for To-Go orders. If you really want to get fancy, you could even include an online order form, as seen on the website of the oft heralded Mindfly neighbor, Rocket Donuts.
Finally, I would encourage restaurateurs to provide a personal message about the history of their establishment on a website. Yeah, it’s kind of cheesy, but a lot of people, like me, like cheese (mmm...cheese), especially if they’re interested to know if you use locally-produced and organic ingredients, or if there are any local charitable organizations that your restaurant regularly supports. And, of course, a blog is an easy and personal way to inform people of special events at your restaurant, like live music, and to keep your website’s content fresh and current.