Recipe sites have this tendency to cram so much stuff on their pages that instead of being helpful, they get in the way of finding the perfect dish for that meal you’re planning. These sites, however, are redefining the culinary experience by providing beautifully-designed and user-friendly experiences on the web, and hopefully in your kitchen.
Gojee is all about personalization: you have to be signed up to their website to take advantage of its features. Enter the ingredients you “crave”, “have”, and “dislike” to get a list of handpicked recommended recipes, whose photos are displayed in full. You can browse back and forth using the arrows on either side of the page, or the arrows in your keyboard—the up and down arrows toggle recipe details at the bottom right. The use of translucency and large imagery gives a stylish, high-end feel to the site.
Recipe Finder takes the Google approach to finding recipes through a minimal search engine interface with an almost playful look between its cartoon logo, polka dots, and stripes. You have the option to view recipe results as text or images, and narrow them down with advanced filters. Meta information such as calories, servings, and preparation time are also listed.
Recipefy is built on the contributions of its community and other social aspects, like inviting friends and following fellow users. You can explore recipes with the color-coded tabs on the left side, and the icons to the right of the page heading, then like or add them to your own cookbook. The woodgrain background and warm color palette definitely gives the site a homey vibe.
Websites are built almost solely on its communities. In the case of blogs, the communities hang out in the comments section. That’s where all the socialization and exchange of ideas take place. But writing a thoughtful comment alone is difficult enough. Don’t make it any harder for your readers.
This is one of the most horrifying comment areas out there:
Now that’s a long scroll. This isn’t from a product landing page or a shopping site with pages upon pages of “special” offers. This is a blog, for crying out loud!
Let’s assume for a second that only the top box (which is the actual comment form) exists and focus on that. It’s just too busy! My eyes were all over the place with the sprawling combination of boxes and text.
I know it takes effort to align form elements. (Or not, since this particular site uses tables to do that.) But it would be much easier on the eye if all the input fields appeared in a linear fashion, one after the other, to minimize the confusion.
Linear is not always necessary, but always keep forms as simple as possible, if you can help it. Take a cue from Smileycat’s comment form design showcase and note how functional and uncluttered those forms are.
Okay, so you get through the ordeal of leaving a comment, but this blog says you’re not done yet! It continues to nag you with the “Blog this at your site” and the “Tell a friend” sections. It doesn’t help that the lack of comments subconsciously discourages the reader from actually commenting. Even if there are any comments, those two extra panels have already separated the reader from the “leave a comment zone” since the comment box is now too far away.
Since the comment form above belongs to a blog in a blog network, many more readers will be turned off and confused by this comment form on several different blogs. It’s not too difficult to elminate this usability problem: Don’t complicate the process. Don’t ask too many questions. Don’t look desperate. Just let them comment.
In the left corner: Tyler Tate’s 1KB CSS Grid, a lean framework sporting 14 classes and the familiar conventions for enforcing a visual grid via CSS.
In the right corner: Vladimir Carrer’s 1-line CSS Grid, an experimental framework sporting a single class to cut nested column widths in half. The solution is mindblowingly brilliant, but does it work? Design tends to work in thirds, not halves. You decide.
Whether or not it’s a coincidence I chanced upon these two extremely simple CSS grid frameworks just days apart, news of these two solutions makes the CSS framework “scene” a lot more interesting. And accessible. I can imagine many front-end developers shying away from heavyweight frameworks because there are too many features, most of which won’t be utilized, and there are too many conventions, most of which aren’t easy to remember.
I’m not even going to get into how using these frameworks leads to unsemantic, presentational class names and lots of
<div> soup reminiscent of
<table>-based layouts. Let’s just be glad people are streamlining the application of design principles for the Web, namely grid layouts. When a better way comes out—maybe it’ll be
display:table, maybe it won’t—we’ll adjust then.
Actually, since list-style blog posts on design trends and other pretty things have been popular for a few years now, I’m sure the backlash has been happening for a while.
Now, it does make sense to organize your a complex article into easily digestible chunks, especially in a not exactly 100% comfortable to read environment such as the Web. It’s good to keep tabs on great new typefaces and graphics in your arsenal.
However, list articles have gained a bad reputation for other reasons because quality is put on the backburner. And there are a number parties responsible:
- The marketers: It’s easy to thank SEO for this phenomenon. A significant portion of internet marketing involves social media, and high-traffic sites like Digg just love the list format. It’s killer linkbait.
- The readers: The problem is lists don’t always contain what people need to truly learn. A lot of these people don’t know any better, and the explosion of lists distracts them from laying the foundations first.
- The internet: Why? There are great lists out there; people will need to separate the wheat from the chaff. But maybe, it’s the very nature of the Web that mutates the need to find the good stuff into the need to find as much stuff as possible or the quickest, easiest solution to a problem.
Whether experienced first-hand or heard of in cautionary tales, everybody is familiar with the horror of not being compensated for one’s work and not being able to do anything about it. Enter a possible solution: a remote kill switch, which gives web designers a back door into a client website via PHP, AJAX or CSS to disable it in case something goes wrong, i.e., one doesn’t get paid.
Avoiding the technical details and instead focusing on the general idea of a remote kill switch, let me say this:
It’s a sad, sad reality that people have to resort to these methods, but it’s just a symptom of a bigger problem. I also see it as designers and developers defending themselves with tools they are familiar with, rather than legalese that could only throw them for a loop and might not even work. Which isn’t to say they should abandon the usual way of going into a project altogether; the kill switch can just be an additional safety net.
Is it unethical? There is no reason to use a kill switch underhandedly, or consider it as a sign of distrust or respect. It’s not about having the upper hand or treating clients unfairly, it’s about protecting one’s business. But to earn your keep you need to stay professional, not paranoid. Integrating a kill switch into a contract, where the client is fully aware of the consequences should it be breached, sounds fair and should achieve those two things. One must remember, however, that once both parties complete their respective deliverables, the kill switch must also be killed.
I wonder what percentage and type of web professionals incorporate this into their business process. This is a controversial issue for sure, but I think people can avoid the unnecessary drama if their intentions are sincere. What do you think? Apart from a contract and this kill switch, are there any other ways to protect web professionals from clients running off with their work?
Jeffrey Zeldman’s article, The vanishing personal site, brings to light what many of us have been wondering about in the back of our heads for a while now. Social networks that provide features often found in a personal website captured our fancies and stretched our virtual personas in all directions. That goes for both the knowledgeable and not so knowledgeable in web development.
It’s not really a bad thing, which Zeldman also stresses. The question is, now that you’ve scattered yourself all over the place, how are you going to put yourself back together?
Not that you need to; I’m sure not everyone would be interested in painstakingly picking up the pieces one by one and gluing them together. That’s why FriendFeed became an instant hit. But if you ask me, using another social network to put them all together does not feel good. Not one bit. I’d consider it another convenient (even organic) way to spread my own content. But that’s it. I still dream of the day I manage to tastefully put my stuff together in one place. Like these websites:
Will Harris shares some insight on working with designers. We often read about tips for designers by designers, but not tips for clients by clients. Still, both parties should read it (and print out the PDF, too!).
Designers (and professionals in related fields) will get great gems of advice that will make them go “oh, thank goodness he said that!” because it’s so common for clients to just sit there and say “I don’t like that” without giving any real reason behind their preference. A design project (again, this can apply to other fields) is the responsibility of both the designer and the client. They have to work together.
But let me digress a little bit. One thing that struck me while reading the article was Will’s first suggestion:
Choose your designer carefully. Look at their previous work. The best designers don’t have a “signature look.” Their sites look as different as their clients do. Awards don’t necessarily mean the design worked for the client. If you’re not sure about a design, go to sites they designed and ask their clients.
Do you agree that designers with more diverse-looking projects are better than those who maintain a signature look? On the one hand, it immediately leads a client into thinking that the designer has a wider skill set and can more easily meet their requirements especially if they’re fickle.
On the other hand, clients opt for designers with a consistent style exactly because they want to emulate that look on their own projects.
I think that in general, professionals start out not knowing exactly what they want to do, and try everything out first. As they grow older they start to specialize. As time passes, you’re supposed to be more sure of yourself and should be able to hold a distinguishable reputation among your peers. This can be said not only about the styles you create, but the skills you specialize in, the clientele you work with, and so on. I wouldn’t say this is the only way to go, but it seems to be the trend.
Umbrella Today, which is a beautifully crafted site (CSS parallax effect!) that tells you whether or not you should bring an umbrella outside, does not work for me. See, it asks for a zip code—presumably limited to the United States only. But I don’t live there.
Now, I know, there are countless websites that exclude a certain demographic in every imaginable way, not just by geography. After all, on the Internet you’re free to do anything you want. But if you don’t like how something is working (or isn’t working), you’re free to blog about it as well.
Go local, be successful, then branch out
To all the developers out there: going local is a good strategy, but if you can help it, try to make your nifty little web app more accessible than just for your neighborhood.
And I’m not just talking about the one-person startups but also the bigger fish in the pond. I wonder how long it will take for Google Maps to completely and accurately cover the planet. (I don’t know if we should be excited when it does, either, but that’s a different story.)
True usability and accessibility
When we mention the term usability in terms of web development, we look at how comfortable users are in using and interacting with the interfaces that are created. Closely associated with usability is accessibility, which champions the idea of never leaving any differently-abled user out.
Doesn’t true usability and accessibility cover my dilemma with Umbrella Today, since I’m left out of its target userbase?
I do hope the makers of Umbrella Today and other people like them stop discriminating by zip code and start reaching out to other parts of the world.
Again, this is if they can help it. Because if there’s one medium that can make it possible, it should be the Web.
Here’s the conclusion that all the web gurus seem to have drawn over the past months: HTML5 is the future, and that future is slowly creeping into our midst. This article by Dave Shea is the latest proof of that. Then there are inspiration galleries and blogs dedicated to the use of HTML5 for markup, plus hardly any mention of XHTML2 anywhere else.
rel and more meaningful links
But I’m not going to get into the war between the two here; I’ll just focus on a specific development in the arena: link relations. There’s more to it than
rel=alternate. About a dozen more.
For example, the Google-imposed
rel=nofollow will be officially added in HTML5, but the seemingly convenient
rel=feed may be dropped due to browser implementation. Other interesting link relations mentioned are
rel=search, which obviously points to a search page, and
rel=sidebar, which refers to a document “shown in a secondary browsing context (if possible), instead of in the current browsing context.” More are being proposed here, including
rel seems to be what plugins are to web browsers, so it’s interesting to see how they can make a markup language as extensible as possible.
rev and a less rotten web
Still related to link relations is the
rev attribute, which stands for a “reverse link”. It hasn’t been as popular as its cousin
rel up until microblogging boomed, and consequently, URL shorteners and the threat of link rot.
Considering just how popular Twitter is these days, particularly as a social media marketing and SEO tool where links are the mode of currency, using
rev=canonical to indicate one URL is a shortened version of the other:
rel="canonical" recently. It’s a way of pointing from an alternate URL back to the canonical URL of the current document: the relationship of the linked document to the current document is “canonical”.
If you’re linking from the canonical URL to an alternate URL (like, say, a shortened URL), you could use rev=”canonical”: the relationship of the current document to the linked document is “canonical”.
People are also advised to check long URLs at this RevCanonical app to determine whether they already contain shortened ones.
Ben Terrett of Noisy Decent Graphics has written a list of things that describe what “his Internet” is like. From an encounter with a technologically-challenged executive comes an inspiring exercise to get everyone on the same page first.
…I thought it might be a nice idea to get everyone to describe ‘their internet’ at the first meeting of any new client. Like they do at school when the new kids arrive mid term. Get everyone up to the same level. That way, everyone would know the ‘level’ of everyone else and there would be no clangers later on.
The list is not only informative, it’s also prescriptive (in a sort of passive-agressive way!). It addresses the little things clients don’t really take into consideration when they describe what they want for their websites. But the thing is, you’re the expert, so grab the opportunity to teach what thoughtful and usable design is. Some of my personal favorites from the list:
- Not using Flash for anything other than videos
- Giving simplicty and clarity top priority
- Not reinventing the wheel
You may not agree with everything on Ben’s list, but the idea is not just to yell at your client for “not getting it”, but to explain why you’re doing “it” that way. It strengthens the relationship you have with your client, and ensures clear communication pathways in between.