We’re very close to the launch of Think Vitamin Membership, so I wanted to give you a preview of the kind of video courses that will be available.
Here is a five minute video that will teach you some advanced CSS3 Box Shadow techniques. We will be adding 70+ videos like this per month to the Think Vitamin Membership Training Course Library.
As a little treat, the next 10 people to signup at membership.thinkvitamin.com will receive 50% off their first month. Yay!
Cats and dogs. Cain and Abel. Designers and developers. These are just a few of the great historical face-offs.
Designers and developers often seem to come from different planets and have completely different brains.
Developers want a website to work right, designers want it to look right.
While these goals have a lot of overlap (and, of course, I’m stereotyping here a bit), the differences often come down to the designer and developer’s expectations of success.
Managing expectations is a matter of communication: making points clearly to the other side, finding common ground, and agreeing on goals.
Okay, so maybe it’s not that easy, but it is important for both sides to at least try to understand each other.
In an effort to promote goodwill between designers and developers, I will share some pet peeves I have encountered and explore the issues that lead to them and their solutions.You create a great-looking design and hand off the comp to your developer, but when you get the site back, it looks like a patchwork quilt of what you designed.
Issue
Comps are not Web pages; they are not a mixture of HTML, CSS, and JavaScript code. Photoshop, Fireworks, and Illustrator can do a lot of things that are impossible (or at least wildly impractical) on the Web, which often means that developers will have to scale down the design.
Solution
Talk to your developer while you are designing, not just afterward. Ask them whether an effect you are using will be easy to accomplish or whether a better alternative exists. Also, as you learn more about Web development, you’ll be able to better tell the difference between when your design is impractical and when the developer is just slacking off.
You don’t choose colors arbitrarily, but developers seem to think that “close is close enough.”
Issue
I don’t know whether this is true of all developers, but I once worked with a developer who was red-green color-blind (he was a huge fan of our content manager, who sent all of her emails in pink text on a lime-green background). However, being color-blind didn’t stop him from being a kick-ass developer.
Solution
If you want the colors to be right, then spell out all of the color values on the page. Don’t rely on your developer to eyeball the color values or to sample the colors in Photoshop.
You also need to consider that the problem may not be with the developer but with you. Colors look different on a Mac and in CMYK (if you happen to accidentally enable that color space). Make sure that your document color mode and proofs are set to generic RGB by default.
You’ve left plenty of breathing room around elements to create a fluid eye path and improve readability, but the developer crams everything together, telling you, “It’s the only way it will all fit.”
Issue
I once complained to a developer that he left no space between the border of a module and its content, making it really difficult for most people to read. He replied, “I don’t care about other people. I can read it.” While most developers are not quite so callous, they have not been trained in the fine art of mixing positive and negative spaces to guide the visitor’s eye around the design.
Solution
If you really want your designs to be as precise as possible, don’t just give the designer a comp and expect them to figure out the spacing. Specify the exact widths, heights, and lengths in a design specifications document. This serves as a blueprint that you and the developer agree on for how things should be spaced.
At the very least, define general rules for margins and padding. For example, “All modules must have a minimum of 10 pixels of padding between the content and the border.”
You look at the site in Firefox and it looks fine, but when you switch to Internet Explorer it falls to pieces.
Issue
You have to be sympathetic to the plight of developers when it comes to making designs look consistent across browsers. Each browser has its own quirks with spacing. Things are getting better (especially with the slow death of Internet Explorer 6), but getting them all to completely play nice with each other is still hard.
Solution
I generally allow a few pixels of wiggle room in my designs to accommodate cross-browser issues, but it helps to know what these issues are while you’re designing, so that you can help the developer avoid them.
Don’t be afraid to point out cross-browser problems to the developer and expect them to be fixed. But resolving some of them may require that you tweak your design.
Nothing is more depressing than burning the midnight oil on double-time to get your part of a project done on schedule, only to get back a development LOE (Level of Effort) that puts the project release date back a month from the end of eternity.
Issue
In a classic episode of Star Trek: The Next Generation, Scotty explains the facts of engineering life to Geordi La Forge: “You didn’t tell him [Captain Picard] how long it would really take, did you? Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker.” Some developers think of designers in the same way that Scotty thinks of Starfleet Captains.
Solution
Developers know they will encounter unforeseen problems and so tend to grossly pad their estimates. This also makes them look really good if they get their end done a lot earlier than estimated. Haggle with the developer down to a reasonable timeline and then hold them to it. As you get to know a developer, you will hopefully find your own way to be a “miracle worker”.
Or worse:
“The developer thinks they’re a designer!”
It’s bad enough when developers seem to simply refuse to see the designer’s point of view, but that difference of opinion can usually be mediated (usually by a good project manager). However, when the developer thinks they know more about design than the designer, tempers can flare.
Issue
I’ve had to deal with more than one developer who read an article by Jakob Nielson and then wanted to lecture me about good design practice in the middle of a meeting. This not only shows disrespect for the designer but slows down the project as debate ensues.
Solution
Working with know-it-all developers is tricky, and the way to handle these situations depends on the size of the ego you are dealing with. Generally, I find it best to simply listen to what they have to say and then, if they have a point, acknowledge it and move on. Avoid arguing with them if possible.
Often their complaint is about a design “rule” that’s been broken. Don’t be afraid to acknowledge that you broke a rule—that’s what innovative designers do—but make sure you can justify why you broke it.
Whenever I find myself in this situation, I think back to my review days in design school, when I had to defend my work against some pretty brutal criticism. These sessions were often ego-bruising, but they taught me how to quickly defend my decisions while keeping my cool.
It may seem humiliating to have to constantly justify your decisions, but the more you show the “method in your madness,” the more you will find that your colleagues value and trust your judgment.
What burden you might ask ? Well front-enders, are seen like jack of all trades. We sometimes do what the designer or the back-end developer don’t have time to do. Because, well, we are the middle guy, we can do all this, don’t we?
It’s not that I don’t like to do either of these. I have interests in both actually. I really like web design, even if I am not that good at it. I visit mostinspired.com 3 times a week, and I always want to learn new stuff about programmation and new cool scripts. Ajaxrain and Ajaxian are great for that.
Even in our own company, some peoples don’t really understand what we do, i can’t frikking design professionally don’t ask me too, some front-end might, i don’t! I am not a designer nor a fully experienced c# or php developer. I’m glad to help, but when you put me under pressure for these things it’ s just not fun anymore.
Most of the time we also have to integrate all the website content in the CMS. Which sometimes means 50 pages+. And I can tell you that it’s not going to make us throw big smiles of fun. Being in a small company, that often happens to me.
That is our burden.
We are the masters of XHTML/CSS, PSD slicing, website architecturing, HTML semantic, Javascript and CMS. We know what’s possible and what’s not from the start as term of design and features. We are the masters of debugging every browser, even internet explorer 6…
But we’re sometimes designers, developers and secretaries. Just don’t expect us to code a back-end application in an afternoon or to become a traductor/writer because the content guy didn’t do is job properly.
Tip No. 1
Study and read everything possible about advanced SEO techniques right from the start of your project.
Tip No. 2
keep in mind that designs are cool, but what is equally important is the code that goes behind it.
Tip No. 3
keep the code optimized, check for W3C compliance right from the start.
Tip No. 4
the basics, titles, meta tags are still important if not ignored, so keep space for them.
Tip No. 5
Keep a horizontal directory structure, don’t go too deep with them, the search engines likes easy access to any file in the quickest time.
Tip No. 6
When you name the files and directories, keep it descriptive and simple. Keep away numbers and weird characters.
Tip No. 7
Images better be optimized for size, and quick loading. If you can’t keep away from loading that fancy graphic, mix it with the page elements. Don’t make them look blunt.
Tip No. 8
Make room for a lot of text. As you already know, search engines love text, lot of them.
Tip No. 9
Flash files are cool. And Search engines have found better ways to crawl and index them unlike old times, but that doesn’t mean you can use them extensively blocking access to relevant text info. So if you are keen on using flash, keep alternate text versions ready.
Tip No. 10
If you have dynamic content, make sure you keep it simple and split to parts. Also, make sure you have optimized static pages for your primary keywords.
Tip No. 11
Always do a bit of competition analysis. See what your competition is, if they have a minimalistic design you don’t want to have a flash design, and leaving no room for improvement. Stalk your competition.
Tip No. 12
Many web designers make the mistake of using a template through out the site and many a times this includes repeating the same title or similar page titles all over the site. Get over this, use descriptive page titles everywhere possible.
Tip No. 13
Keep the page titles to 65 characters or less in count. Nothing wrong is going over it, but you could avoid a spill over.
Tip No. 14
The meta descriptions are supposed to be mini ad-copies that should be descriptive of what the page is about. Don’t keep them the same for all pages.
Tip No. 15
Keep the JavaScript away from navigation menu. Navigation menu is a good resource for gathering information about what your site is about, and using javascript can make it less crawlable by the engines.
Tip No. 16
Use CSS based navigation if you want fancy effects. Pretty much all of the javasript stuff can be done on CSS, in a more search engines friendly way.
Tip No. 17
Use the header tags effectively. Don’t limit yourself with H1 and H2. Use H3, H4 and beyond and use it wisely on the page.
Tip No. 18
Use strong tags wisely. Don’t let them stand out like bolded text, within the content, style it down to show up as normal text within the content.
Tip No. 19
Use the footer effectively. Of course, you can use it for all your TOS/Legal stuff, but also use it to link to the important pages on your site. It helps.
Tip No. 20
Identify the most important pages on your site as seen by the search engines, and leverage them to promote other resource pages.
Tip No. 21
Link well internally, and use descriptive anchor text instead of “click here” and “check this out” like phrases.
Tip No. 22
Use al tags, Title tags on images and use descriptive filenames. They help search engines find more information about them.
Tip No. 23
Use a SEO friendly layout, at least one that does not block or hinder the crawling of crucial areas on your site.
Tip No. 24
Find out the important areas on your website, like the content rich area in the center and keep them above the fold. Not only helps the engines but the user as well.
Tip No. 25
When designing dynamic pages, try to stick to pages with descriptive URLs and not the one with session ids and other parameters. Google can still get it’s head around them, but its good if you can stick to SE friendly, descriptive ones.
Tip No. 26
When dealing with CMS’s there might be instances where you have to keep the page URL the default way with the extra parameters. Use URL rewrite mod to re write the most important pages URL’s to SE friendly form.
Tip No. 27
When using AJAX, load the modules in parts split across pages and not in one single page. Although this defeats the purpose of using AJAX in the first place, you might be able to provide more information to the search engines using other on site SEO parameters.
Tip No. 28
If you want to block any particular area on your site from the reach of Google spiders, use either Robots.txt commands, or else set up a login access. This is the safest way to block crawlers from spidering vital information.
Tip No. 29
Keep the meta descriptions descriptive and precise to about 150 characters.
Tip No.30
Use an SEO simulator to test your design through out the process. And make sure no part of the design blocks/hinders any part of information being accessible to the search engines.
So essentially, web designers got to ensure that while their designs are unique and eye-catchy, making sure that there is enough information available in the form of text is always recommended, and leveraging this information by using all the possible SEO metrics in a healthy and balanced way to cater to the search engines is the right way of designing a search engine friendly web design.
Sometimes it’s the result of sloppy coding from the start, sometimes it’s because of multiple hacks and changes over time.
Whatever the cause, it doesn’t have to be that way. Writing clean, super-manageable CSS is simple when you start off on the right foot and make your code easier to maintain and edit later on.
Here are 11 tips for speeding up the process, writing CSS that is slimmer, faster and less likely to give you a headache.Just like anything else, it pays to keep yourself organized. Rather than haphazardly dropping in id’s and classes in the order in which they come to mind, use a coherent structure.
It will help you keep the cascading part of CSS in mind and sets your style sheet up to take advantage of style inheritance.
Declare your most generic items first, then the not-so-generic and so on. This lets your CSS properly inherit attributes and makes it much easier for you to override a specific style when you need to. You’ll be faster at editing your CSS later because it will follow an easy to read, logical structure.
Use a structure that works best for you while keeping future edits and other developers in mind.
Let others know who wrote your CSS, when it was written and who to contact if they have questions about it. This is especially useful when designing templates or themes.
Wait a minute… what’s that bit about swatch colors? Over the years, I’ve found that adding a simple list of common colors used in my style sheets is extremely helpful during initial development and when making edits later on.
This saves you from having to open up Photoshop to sample a color from the design, or look up colors in the site’s style guide (if it has one). When you need the HTML code for that specific blue, just scroll up and copy it.
Once you’ve settled on a structure to use, strip out everything that isn’t generic and save the file as a CSS template for later use.
You can save multiple versions for multiple uses: a two-column layout, a blog layout, print, mobile and so on. Coda (the editor for OSX) has an awesome Clips feature that lets you do this easily. Many other editors have a similar feature, but even a simple batch of text files will work nicely.
It’s insane to re-write each and every one of your style sheets from scratch, especially when you’re using the same conventions and methodologies in each.
You’ll notice above where I declared a couple of column id’s and I called them col-alpha and col-beta. Why not just call them col-left and col-right? Think of future edits, always.
Next year you may need to redesign your site and move that left column to the right. You shouldn’t have to rename the element in your HTML and rename the id in your style sheet just to change its position.
Sure, you could just reposition that left column to the right and keep the id as #col-left, but how confusing is that? If the id says left, one should expect that it will always be on the left. This doesn’t leave you much room to move things around later on.
One of the major advantages of CSS is the ability to separate styles from content. You can totally redesign your site by just modifying the CSS without ever touching the HTML. So don’t muck up your CSS by using limiting names. Use more versatile naming conventions and stay consistent.
Leave position or style specific words out of your styles and id’s. A class of .link-blue will either make more work for you, or make your style sheet really messy when your client later asks you to change those blue links to orange.
Name your elements based on what they are, not what they look like. For example, .comment-blue is much less versatile than .comment-beta, and .post-largefont is more limiting than .post-title.
Older browsers like to get glitchy with underscores in CSS, or don’t support them at all. For better backward compatibility, get into the habit of using hyphens instead. Use #col-alpha rather than #col_alpha.
Re-use attributes whenever possible by grouping elements instead of declaring the styles again. If your h1 and h2 elements both use the same font size, color and margins, group them using a comma.
This:
You should also make use of shortcuts whenever possible. Always be on the lookout for opportunities to group elements and use declaration shortcuts.
You can accomplish all of this:
with only this:
It’s very important that you understand the order in which CSS interprets these shortcuts: top, right, bottom, left. A big clockwise circle, starting at noon.
Also, if your top and bottom, or left and right attributes are the same, you only need to use two:
This sets the top and bottom margins to 1em, and the left and right margins to 0.
Using the above tips, you can really cut down the size of your style sheets. Smaller loads faster, and smaller is easier to maintain and update.
Cut out what you don’t need and consolidate wherever possible by grouping. Use caution when using canned CSS frameworks as well. You’re likely to inherit lots of bulk that won’t be used.
Another quick tip for slim CSS: you don’t need to specify a unit of measure when using zero. If a margin is set to 0, you don’t need to say 0px or 0em. Zero is zero regardless of the unit of measure, and CSS understands this.
Save yourself troubleshooting headaches and write CSS first for Gecko browsers (Firefox, Mozilla, Netscape, Flock, Camino). If your CSS works properly with Gecko, it’s much more likely to be problem free in Webkit (Safari, Chrome) and Internet Explorer.
Make use of W3C’s free CSS validator. If you’re stuck and your layout isn’t doing what you want it to do, the CSS validator will be a big help in pointing out errors.
Separate browser-specific CSS to its own individual style sheet, and include as needed with Javascript, server-side code or conditional comments. Use this method to avoid dirty CSS hacks in your main style sheets. This will keep your base CSS clean and manageable.
You have probably seen these forms of advertisings where you can peel a corner of a website and see a message underneath. It seems most are flash driven, but I decided to try it out using some simple lines of jQuery.
The “pageflip” div will act as the container, mainly used to establish the relative positioning. Then nest the image and the span class of “msg_block” wrapped in an tag. Note - If you don’t have any conflicting absolute/relative positioning properties, you technically don’t need the “pageflip” container at all.
Set the image property to a smaller size (50px by 50px) by default and set the absolute positioning to be in the top right corner. The image will be used similar to the “masking” technique in Photoshop or Flash, where it will be placed on top of the hidden message, so only a portion of the message will be shown. Check out the image below for a visual:
The actual message behind the “peeling” effect, is all within the “msg_block” class. By default, it will start at 50px by 50px, positioned on the top right corner of the page. The text-indent will shoot the text off of the page for anyone with CSS enabled.
#pageflip {
position: relative;
}
#pageflip img {
width: 50px; height: 52px;
z-index: 99;
position: absolute;
right: 0; top: 0;
-ms-interpolation-mode: bicubic;
}
#pageflip .msg_block {
width: 50px; height: 50px;
position: absolute;
right: 0; top: 0;
background: url(subscribe.png) no-repeat right top;
text-indent: -9999px;
} Note that the “msg_block” height is off by 2px compared to the image property - this is taking in consideration of the drop shadow that the image has.
All we are doing here is expanding the image and msg_block on hover, then retracting to its default size on hover out.
$("#pageflip").hover(function() { //On hover...
$("#pageflip img , .msg_block").stop()
.animate({ //Animate and expand the image and the msg_block (Width + height)
width: '307px',
height: '319px'
}, 500);
} , function() {
$("#pageflip img").stop() //On hover out, go back to original size 50x52
.animate({
width: '50px',
height: '52px'
}, 220);
$(".msg_block").stop() //On hover out, go back to original size 50x50
.animate({
width: '50px',
height: '50px'
}, 200); //Note this one retracts a bit faster (to prevent glitching in IE)
}); The concept is very simple and may come in handy one day. If you have any questions or know of other techniques, please don’t hesitate to let me know~