Unicorn is the newly minted Unified Validator from W3C. One-stop shop for CSS, HTML, and RSS feed validation.
Are you the type of person who loves to read Top 10 lists, and then link them up on Twitter ad nauseam? Do you love Smashing Magazine and the tuts+ network (psdtuts, nettuts, …)? If so, this post is for you.
My latest pet peeve involves people who post and share links to web design and development tricks and “quick hit” tutorials. What are the odds that the list or tutorial is going to help you with your current work? Also, did you actually go read the list and follow the links and do the tutorial and launch a site based on it and can you show that product to me? What did you actually learn?
The tendency toward listmania is misleading at best and damaging to the web design and development community at worst. It promotes superficial knowledge, quick fix schemes, and small-minded solutions.
If you want to do quality work and be proud of your craft, avoid these sites and lists. The quick trick can’t make you a better web craftsman or -woman. There isn’t a shortcut or quick fix to learning web design and development fundamentals.
Instead spend time actually making awesome sites yourself. Build something and launch it to the public. Go to An Event Apart. Learn by doing: your experience will teach you more than any top 10 list ever will. The critical thinking and solid skills will come from your hard work, not from the latest, hottest tut.1
More fuel for the fire:
Here is the thing. While it’s fun to learn the latest way to vertically center a div on a page using jQuery, HTML5 and your mom, you’re wasting your time. You may use that what, 1-2% of the time in your projects. Your fundamentals are what is important. Positioning, layouts, typography, spacing, etc. Master those things. Tricks are just tricks. Fundamentals win the game. —Noah Stokes
One can only really learn by doing, by making mistakes, and not by following someone else’s abridged instructions. The tips might get you a quick ‘n’ dirty result, but after that, you’re none the wiser and will need more hints to get you through the next problem. To anyone with genuine aspirations to be great and to really improve themselves, drop the ridiculous lists of quick fixes and shortcuts and start learning for yourself by doing and by making mistakes. —Contrast blog
There is a “quick hit” culture amongst net junkies, where they read the bare minimum and foolishly believe they’re getting value or insight. These are the same people who bookmark links “to read later” but never do, and order piles of amazon books to sit on shelves forever. Someone thinking they’re getting value of 10 sentences along the lines of “Launch early, launch often” or “Your brand is beyond your control” is in need of far more than a top 10 list in my opinion. —commenter on the same Contrast post
1 And, this is silly, but I hate the word “tut” so much. Argh! ↩
I recently came across a wonderfully rich resource on search engine optimization (SEO) called Google’s Search Engine Optimization Starter Guide. Originally written by Google for their internal teams, they decided to generalize the recommendations so that it would be useful to any website author or owner.
While the recommendations might already be known to you, they are still worth reviewing. Among Google’s tips for good organic SEO:
- Create unique, accurate page titles
- Make use of the “description” meta tag
- Use appropriate URL structure
- Make your site easier to navigate
- Offer quality content and services
One notable omission is the recommendation to use the “keywords”
meta tag. That’s because Google does not use the “keywords”
meta tag in web ranking, and has in fact ignored it for years due to abuse.
Our web search (the well-known search at Google.com that hundreds of millions of people use each day) disregards keyword metatags completely. They simply don’t have any effect in our search ranking at present.
For more on the “keywords”
meta tag see Google does not use the keywords meta tag in web ranking from the Google Webmaster Central blog (posted Monday, September 21, 2009).
If you are a web designer or web developer with clients who look to you for SEO-related advice, consider giving them a copy of the Search Engine Optimization Starter Guide—it’s a great summary of how to optimize websites for search engines, and it’s available for reuse under the Creative Commons Attribution 3.0 License.
There is a lot of excitement right now in the Tucson web design and development scene. Tucson Digital Arts Community is rocking the house with monthly workshops, local companies like Bookmans are innovating with their agile web development and engaging user-centric website, and there is a buzz of energy around getting together, sharing ideas and best practices, learning, networking, and improving our community.
Local web ninja Jared McFarland summed it up nicely in Capitalizing on the Tucson Tech Community.
We, as a community, can work together to educate and inspire one another. We can enjoy the same benefits as the people in major tech centers simply by knowing each other and inventing ways to work together. It isn’t about vast numbers of people, but small passionate groups. The web brings like minds together globally, but we can now use the web to find each other and act locally. We can turn Tucson into something intentional, and beautiful, for ourselves and the city.
The larger Tucson community is also bubbling with social events like Ignite Tucson and the myriad of Twitter meetups (“Tweetups”). Just search Twitter for #tweetup #tucson to be amazed. These events cover a much broader range of topics than web design and development but they all share a common goal: to mingle, network, and share with others.
This is how I think it breaks down: socially, the larger community wants to meet itself and technologically, web designers and developers are joining together to improve the tech community. All of this energy and enthusiasm is contagious!
In contrast, I want to share the story of the Tucson Geek Meet1, a group I was personally involved with for four years. Started as the Tucson Web Standards Group in 2003 by Molly Holzschlag, the Geek Meet slowly lost momentum over time. Instead of growing and expanding, it stayed a small core of five or six people.
Don’t get me wrong, because of those meetups the five or six of us are now steadfast friends, and several of us have had the opportunity to work together. Now that we are friends we can socialize anytime—we don’t need to call it anything. The idea of the Geek Meet isn’t going away, it’s just being replaced by ad hoc Tweetups and other social happenings around town.
What I want to encourage, and I think Jared hit on this, is not just the social aspects of meeting together but the educational and inspirational benefits of sharing code, experiences, and real-life examples of our work. TDAC is spearheading the effort by organizing workshops and collaborative coding days to get people together to educate, inspire, network, and improve. I’ve been a part of TDAC for six months now, and the tech community in Tucson isn’t just soaking it up, it’s clamoring for more.
We’re hoping soon to have a Refresh Tucson—our neighbors in The Valley have had a strong Refresh presence for three years—we can do the same here in the Old Pueblo. So please participate: join up, tweet up, meet up, share, and pass the word to your colleagues and friends.
Let’s do it, Tucson.
How to get involved
Tucson networks to join and participate in
- Tucson Digital Arts Community
- Further Tucson
- Refresh Tucson
(Coming soon… For now join the TDAC Refresh Tucson group to give your input.)
- Search Twitter for #tweetup #tucson and come join the fun.
1 The Tucson Geek Meet is no more, it’s pushing up the daisies, it’s kicked the bucket. This meetup is not pining for the fjords, it’s gone to meet it’s maker. It’s… OK, enough of the Monty Python!
For posterity, here is a brief history of the Tucson Geek Meet:
2003(?): Started by Molly Holzschlag.
2007: Changed the name to Geek Meet.
2008: The infamous Hooter’s incident. D’oh! (Yes, Molly gave us a good lashing for that, and it was deserved.)
2009: Called it quits in favor of other local groups and Twitter meetups.
This post was originally titled “Rest in Peace, Tucson Geek Meet” but I decided that it was just a small part of the burgeoning Tucson web design and development scene.
Alkaline is a new Mac application from Litmus that allows you to “tests your website designs across 17 different Windows browsers right from your Mac desktop.” It works as a standalone app, or with Coda and TextMate using plugins. The free version tests in Firefox and Internet Explorer 7, and if you sign up for a paid Litmus account you can test in all 17 browsers.
ChangeOrder: The User is Out is an insightful take on why designers shouldn’t be called on to speak for users. Instead, ask the users themselves.
Of course, it is a bonus when you are your own client—if you use your own product, then you can answer user experience questions from both a professional and a personal perspective.
Recently I received a question from a colleague regarding image theft and how to prevent it. The sad truth is that you can’t. There are techniques to discourage downloading and reuse of your preciously-crafted images, but they generally aren’t 100% effective or user-friendly for your normal site visitors.
The reality of unwanted image downloads is a bit depressing: there is no guaranteed way to protect your images from being taken—the most you can do is discourage it.
First, make sure your copyright notice is clearly posted on each page indicating that downloading or using images without permission is not allowed. In doing so you are legally holding your site visitors accountable if they steal and reuse your content.
If you suspect that image search engines or IE-only users are the culprits, using client- and server-side techniques might help alleviate the problem. But if you are looking for a universal solution, editing the images is your best bet since all these techniques can be circumvented by taking screenshots, using screen scraping tools, or simply viewing the locally cached images.
- Disable the right-click menu
- Disable the shortcut menu in Internet Explorer
- Use a transparent image overlay
Another technique—which Flickr employs—is the transparent image overlay. This involves layering a transparent GIF over the top of the image you wish to protect. When the image is right-clicked and saved, the person assumes they are downloading a JPG but instead get the transparent GIF.
From Flickr’s download prevention help text:
Preventing people from downloading something also means that a transparent image will be positioned over the image on the main photo page, which is intended to discourage people from right-clicking to save, or dragging the image on to their desktop. By “discourage” we do mean simply “discourage”. Please understand that if a photo can be viewed in a web browser, it can be downloaded. The transparent image overlaid on the photo will not keep your images safe from theft, and is intended only as a slight hindrance to downloading.
Using Flash to display images is another method to discourage image theft (since Flash right-click menus can be customized), but it isn’t foolproof. Just like these other techniques, people can simply take a screenshot to capture the image.
- Block image search engines
- Disable image hotlinking
Image search a popular way to access images. If you notice a lot of traffic from image search engines, try blocking them with a rule in your
robots.txt file. See Remove an image from Google Image Search for more details.
I also recommend disabling hotlinking by adding rules to your site’s
.htaccess file. Doing so will not only potentially save you bandwidth costs by stopping other sites from reusing your images and content, it will prevent directly linking to your images without your permission.
Image content editing
- Add watermarks
- Use very low quality images
Although altering the image affects how it looks and works on your site, it is quite a bit more effective than simply trying to disable downloading or saving. Again, this is only a means to discourage theft — skilled graphic artists can remove a watermark and still have a usable image.
Using low quality images could also help, but finding a good balance between impressing your customers and deterring theft can be difficult.
If someone really wants the image, they will get it. Using the techniques described above will discourage most people from downloading your images, but remember that posting your images online means you run the risk of anyone downloading and reusing them.
As a user-centered designer and developer I am always looking for ways to improve interfaces to be useful to all people, including color-blind people. Particletree has a great guide, Be Kind to the Color Blind [editor's note, October 2012: link now offline], that nails the essential pitfalls and best practices in designing for color-blindness.
My rule of thumb is to use color only as a secondary indicator. This means that an important detail in my user interface should not rely on color alone to indicate meaning.
This type of design decision came up recently in my work on DF Studio. As part of a redesign for version 5 of the software, the design called for colored icons to show status for a photographer’s online portfolio. A green icon for an active portfolio and yellow icon for a disabled one (a disabled portfolio is not accessible to public viewers).
The problem with the icons being only differentiated by color is that a color-blind person that can’t distinguish yellow versus green would not be able to easily know the portfolio’s status.
The solution was simple: add a lock overlay to the disabled yellow icon. You can now easily tell that one is “locked” and one is not.
It is always good to run your design through a color-blind testing tool like Colorblind Color Filter or Vision Simulator. The DigitalFusion development team is fortunate in that the CTO of the company (who is also our product development manager) has a color vision deficiency; since he is constantly looking at the interface we have a way to find color-blindness issues in early stages of development.
If you work on websites or any kind of visual user interface, I would highly recommend reading the Particletree article, including the Additional Reading links. Knowing about the problem is half the battle, and you’ll be able to keep color-blindness in mind when developing and designing your interfaces.
Google now offers a guide in PDF form to get you started with SEO best practices. The guide is chock full of great tips on navigation, meta elements, website promotion, headings, and much more.
So, the next time we get the question, “I’m new to SEO, how do I improve my site?”, we can say, “Well, here’s a list of best practices that we use inside Google that you might want to check out.”
Read more and download the PDF guide at Official Google Webmaster Central Blog: Google’s SEO Starter Guide.
From the Important Topics in Running a Web Design Business Dept. I’d like to share a recent conversation with a colleague about whether or not it’s a good practice to include mockups in a possibly unpaid bid for a project. I’m posting it here for reference and to continue the conversation.
Colleague: I’ve seen on Twitter… times where you said that you’d finished a mockup for a client. And by that, I’m assuming you mean a mockup of a website that you’re proposing to build for them…
Lance: My situation might be different than other web professionals in that I generally work with the same clients over and over (my last “new” client was Summit Hut in September 2007). So, the mockups I do now are for paid projects that have budgets and buy-in from clients. And, these projects aren’t typically new websites; although in one case that I talked about on Twitter the mockups I presented were for a complete overhaul of a web application’s user interface.
In the “real world” of trying to land gigs or client projects, mockups and prototypes can play a part, but be very careful when people ask for that type of work without pay.
If that’s the case, when you do your mockups, do you just do straight HTML (so the look is there, but not the functionality), build it in Photoshop (or something similar) or something else?
As far as the “how” of mockups, I almost always jump from paper sketches and basic ideas into HTML and CSS. That is my strength, and I am very fast from concept to working website, so it’s my best use of time and energy. I use Photoshop and Illustrator for design elements such as backgrounds, buttons, and icons with an occasional—but rare—entire mockup in Photoshop that I then flatten as a PNG and use as a mockup or starting point for coding.
Skipping Photoshop doesn’t work for everyone, but it can be a timesaver if you are more comfortable working with other tools. Check out Why we skip Photoshop, a great take on this by 37signals. Most “graphic” web designers take offense to this type of approach, since they say that those kinds of designs tend to look alike in their boxiness, and that you are constrained by CSS basics, etc. I don’t agree—I think creative and good design work can happen in non-visual tools. Overall, I think you should do your work where it is fastest and more efficient for you; for me that is coding HTML/CSS and tweaking the display right in the browser, not in an image editor.
The big advantage for me for moving from paper and ideas directly to code is that I can get a working demo up faster and into my clients’ hands that much quicker.
And also, if you’re doing a proposal for a client (bidding on a project and/or expanding upon a bid you already sent), do you generally give them a mockup of what you’re proposing and do you charge for your time to build that mockup and the bid?
My advice, and the standard industry practice, is to never do work “on spec,” meaning those design mockups should never be for free. If you get client buy-in and establish the mockup and design process as part of your workflow, you won’t get bit by people backing out after you sink time and energy into it. There are those occasional clients who want ideas for free, and they will use you to that end. Of course, those folks might be few and far between, but be aware that they are asking you to do unpaid work.
There is a lot online about this already, so I won’t harp on it too much. From the master Zeldman himself, read Don’t design on spec. For a perspective from a respected graphic web designer, Veerle Pieters, I recommend Free of charge please!, and there is even an entire website dedicated to the topic: NO!SPEC. Besides reading what other web professionals have to say, I’d also recommend picking up a copy of Graphic Artists Guild Handbook: Pricing & Ethical Guidelines for some great advice and case studies (Amazon).
If a client asks for work up-front with no payment, my tendency is to run like the wind! If you feel they are a worthwhile client, and you really want to work for them, spend some time educating them on your workflow and process, and explain why the mockup and design iteration phase is an important part of the project cost and budget. That education will pay off many times over, giving more value to all the parts of your web design work, not just the “expert” parts such as coding and testing.
For example, in my typical web design project process I have clients read and sign off on each step, including brainstorming, planning, content organization, and design mockups. Giving each stage in the process a monetary value can help you feel good about spending time to get things right, and gives the client a reason for all the charges you bill them (or all the line items in an estimate beforehand).
This is a very important topic—if you are a freelancer it would do you good to define your stance and “official policy” on spec work. Let’s educate ourselves, our colleagues, and our clients on why spec work is unprofessional, and share this conversation with others.