I've noticed recently that both of the Web messaging apps I use the most, Gmail and Facebook, have introduced what I'm calling Scroll Shadows. (Maybe they're actually called that, I don't know! lol) The purpose of a Scroll Shadow is to subtly indicate to the user that the content they are scrolling has now scrolled under another page element. In Gmail, this effect looks like this:

Before scrolling...

gmailcontentnoshadow

After scrolling...

gmailcontentshadow

In Facebook the effect looks like this:

Before scrolling...

fbmessagesnoshadow

After scrolling...

fbmesagesshadow

In general, I think it's a great idea. It's minimal, it serves a discrete function and it has the potential to add some depth to a page. So what's my beef? I don't think either of these was implemented very well. How do I know? Because one of these sites did implement the concept well, on a different part of the very same page! Can you guess which one? If you said testing-subtle-variations-is-our-middle-name-Google, then you're right! Here's what the Scroll Shadow for the Ad section of the same Gmail message page looks like after scrolling:

gmailadshadow

It's a subtle difference:

  • Gradients: It's hard to see directly but the Ad version has four shades of gray in it's shadow (Facebook has one and the other Gmail version has two). This makes the transition in the Ad version "under" the top element much smoother and "believable" as a shadow than in the other two variations.
  • Edge: Both the Ad version and the Facebook versions have a defined darker "edge" (the other Gmail version has no edge at all). The edge serves to deleneate the "thing" that is casting the shadow. Without it, the shadow looks a little out of place.
Here's a close up of the Ad version:

gmailadshadowmax

It's hard to know why Google is using two different shadow styles on the same page (could be A/B testing, could be different teams working on different sections) but I know what I like: the style used in the Ad section is the best implementation of this idea.

 

If you leave comments on Wordpress blogs, or a growing number of other sites lately, you may have noticed lately that sometimes your photo shows up beside your comment even though you didn't upload it to that site. That's because a service called Gravatar is working behind the scenes to "translate" your email address into your picture. How does it do that? Well, it simply serves up the photo you associated with your email address through your Gravatar account.

"But wait a second", you're saying, "I didn't set up a Gravatar account in the first place but I still see my picture."

Neither did I! Looks like Gravatar is scouring public profiles that might be associated with your email address to make sure it has something to serve but, the picture it finds may not be the picture you still want associated with your email address. Granted, this isn't *that* big a deal since presumably you chose the image Gravatar found in the first place, but if your want your online "persona" to stay current, you should create and update a Gravatar account.

 

As a developer, it's often difficult to give a client a sense of how an application will behave without actually building it, by which time it's often too late to get any useful feedback.

You often have to resort to hand drawings to illustrate what you want to build, but that approach often ends up looking like a very nerdy puppet show when you actually try to show how different screens will interact. (I mean no disrespect D7UX team, they're doing some MUCH needed work on making Drupal more usable). I recently faced this problem myself.

I have been using a system called ePresence to capture live presentations for on-demand web distribution lately. (In a nutshell, the ePresence system allows you to capture live video and synchronize it with a speaker's presentation slides). The system works very well but the interface would sometimes let you easily make mistakes that required a lot of effort to correct. I wanted to give the developers some meaningful feedback, but writing a long email to try to illustrate my "pain points" seemed like a lot of work which could be easily misinterpreted. So I started looking around for an alternative and I found iPlotz.

iPlotz elementsiPlotz let's you easily create "wireframe" interfaces and add some basic interaction to create a sense of how an application will behave, without having to build it! You start with a blank canvas and you add interface elements such as text fields and buttons through simple drag-and-drop. This approach lets you iterate a design very easily because changing it is as simple as creating it, and iPlotz features a large library of elements to quickly build up your web (or iPhone) application. All of this with zero coding!

That functionality alone would have been enough to impress me but the iPlotz team went further by making it easy to share your wireframes (you can see the one I built here) and to manage the process of actually building your design. With iPlotz, I was able to communicate *exactly* what I had in mind, with a minimum of effort and with very little chance of being misinterpreted. The feedback from the ePresence team was that they appreciated the thoughtful input, and they now plan to implement some of my suggestions. Smile

The only "complaint" I would have is that the free version only allows you to build a maximum of 5 screens before upgrading to a paid version. That seemed a little stingy to me, but certainly in this economic climate I can't blame them for that. 5 screens turned out to be the exact number I needed, but it would have been enough to evaluate the product's features before buying.

I highly recommend iPlotz, but I feel the need to disclose that part of my motivation in writing this review was that they offer a year's license for honest reviews of their product (did I mention the current economic climate?).

Tragically, there are literally millions of people out there who believe deep in their hearts that putting white text on a black background is somehow "cool" or "edgy." Some have even gone so far as to try to make an environmental case for this practice (disputed). Can you tell, I'm not a fan?

Here are Luis's top 3 reason not to use white text on a black background:

  • It hurts! After about a minute of looking at a full page of text styled this way your eyes will begin to feel bad from reading.
  • It proclaims to the world that your web site was designed from the depth's of your parent's basement (or your own).
  • It's not impossible to use this style without affecting legibility, but you're probably not a cutting edge designer (sorry).
Trust me, if you're considering using this combination on your web site, you should reconsider. You'll only end up hurting the ones you love: your users!

Ambiguity is the enemy when you're developing a Web page or application. The client and developer meet to discuss work ahead. Both take notes and go home thinking they now have a shared understanding of what's required. Unfortunately, when using written language to describe something like a Web page, something almost always gets lost in translation. This opens the door to ambiguity and the resulting mismatch between what the client was expecting and what the developer delivers.

This is why I really like the idea behind the Firefox Pencil project. This project aims to make it easy to create a non-functional mock-up of a Web page using standard widgets for common elements such as drop down menus and radio buttons. If there is some debate regarding what needs to be built, generating a visual representation of what's required is a snap, helping client and developer speak the same language, at last!

The Pencil Project

Page 2 of 3