Archive for November, 2011

Twitter Tools and Tutorials For Designers and Developers

Posted: November 4, 2011 in Uncategorized

50 Twitter Tools and Tutorials For Designers and Developers

Twitter appears on innumerable personal and professional websites nowadays, whether it is a simple “Follow me” badge in the header or a display of the author’s latest tweets in the sidebar. No longer a fad, Twitter is now a necessity for every website, not just for sharing your thoughts and keeping in touch with people, but also for marketing, advertising and even searching. But you may be wondering, How can I make Twitter work the way I want on my website?

Below, we present Twitter Web Designer and Developer Toolbox, API and Tutorials, a series of tutorials, links, references, libraries and plug-ins that will help you do everything you’ve always wanted to do with Twitter.

[Editor’s note: Have you already got your copy of the Smashing Book #2? The book shares valuable practical insight into design, usability and coding. Have a look at the contents.]

Twitter Development Links

Twitter Web App

Twitter Technology Blog
If you’re writing an application for the Twitter API or just curious about the code, tools and practices, this blog has something for you.

Twitter API Wiki home page
Download the Twitter API here, and it’s also a great reference for developers.

Twitter API Announcements – Google Groups
This website is updated only when changes to the Twitter API are released or there is a pending release.

Twitter Development Talk – Google Groups
Discussion about the development and use of the Twitter API

Follow Twitter Development via Twitter
Keep up to date with all news via Twitter.

Introduction to the Twitter API

Twitter Web App

Twitter API for Dummies
This is an easy-to-follow tutorial with several examples based on different Web technologies. It has just enough for you to start your own Twitter project.

Using the Twitter API
This is an excellent introduction to using the Twitter API. The API offers many different ways to connect to your details including XML, JSON, Atom and RSS. This tutorial uses XML, PHP and cURL.

Get Started With the Twitter API
If you’re looking to try out an API for the first time, Twitter’s is a great one to start with. Its API is simple and easy to use. The only thing to keep in mind is that Twitter limits you to 70 requests per 60-minute intervals, so remember to cache or otherwise store your results.

Getting Started with the Twitter API
Twitter’s API lets you read and write Twitter messages with minimal coding in nearly any programming language. In fact, you can use this API without doing any programming. A slightly more advanced tutorial than the previous three.

Building Your Website Around Twitter

Build Your Own Social Home!
Many of us have not only our own websites, but also Twitter, Flickr, ScrnShots and Facebook accounts, too. This tutorial brings all of these together neatly on one page.

Twitter Web App

How to Create an RSS-Enabled Micro-Blog with Twitter
Have you ever wanted to create a simple multi-person blog but didn’t want to bother setting up an entire WordPress installation? If so, this tutorial is for you. By combining Twitter Search, Atom feeds, hash-tags and PHP, you can create an RSS-enabled, micro-blog using Twitter and be up and running in less than 10 minutes.

Twitter Web App

How to Make a Unique Website for Your Twitter Updates
Twitter offer a little JavaScript widget that automatically uses the API and returns simple HTML of your recent tweets. This tutorial shows you how to design a unique website for your Twitter updates using this widget.

Twitter Web App

How to Build a Maintainable Website Using CushyCMS and Twitter
In this tutorial, you build a simple one-page website and then, in less than 5 minutes, set it up with a Twitter feed for daily updates and with CushyCMS for general content.

Twitter Web App

Send Message from a PHP Page Using the Twitter API
This is a very simple tutorial (really just a few lines of codes!) that explains how to post a message using the Twitter API from a PHP page.

Twitter Web App

How to Run Multiple Twitter Feeds on the Same Page
What if you want to display the Twitter feed of someone you admire or perhaps the feed of another author on your blog? This tutorial shows you how.

Twitter Web App

Add Twitter to Your Blog (step by step)
This is a simple but great tutorial: a “step-by-step guide to adding Twitter to your blog without it hanging your website”. Great description.

Twitter Web App

Scripting Twitter with cURL
cURL is a versatile command-line utility designed to script Web page interactions. As a little demo, this tutorial shows you how to use it to easily to overcome the shortcomings of Twitter’s API. You can also view the Perl + LWP version of this tutorial here: Scripting Twitter with Perl + LWP

PHP + Twitter + Google Calendar + SMS
This tutorial shows you how to add an event to Google Calendar by text message. It shows you how to hook up your Twitter account to Google Calendar using their APIs.

TwitterZoid PHP Script
TwitterZoid is the name of this PHP script for parsing Twitter RSS feeds. This tutorial shows you how to successfully implement this.

Twitter and AJAX Tutorials

Tweet! Unobtrusive jQuery Twitter Widget Tutorial
Tweet is an unobtrusive, fast-loading, feature-rich jQuery plug-in that lets you easily display your tweets on your website.

Twitter Web App

jQuery Plug-in for Twitter
This is a simple, unobtrusive and customizable client-side method for easily embedding a Twitter feed on a Web page. From Coda, you know it’s going to be smooth. View demo here.

Twitter Web App

PHP and Ajax with the Twitter API
This tutorial shows you how to use jQuery, PHP and a little AJAX to connect to the Twitter API and return results.

Twitter Web App

Authenticating Twitter API Calls with PHP and jQuery
In this tutorial, you are shown how to authenticate the API calls to your Twitter credentials (to be able to return your favorites).

Twitter Followers Counter Tutorial
Here, you are taught how to create your very own Twitter counter, showing how many followers you have. View demo here.

Twitter Web App

Juitter – jQuery Plug-In to Put Twitter Live on your Website
Juitter is a small and fast-loading plug-in. It not only shows tweets to or from a user, but can be filtered to show tweets containing a specific word or restrict searches by language. You can also show avatars, which makes this jQuery plug-in quite unique. View demo here.

Twitter Web App

Twitter Emulation, Using MooTools 1.2 and PHP
What most people probably don’t know is how simple it is to emulate Twitter’s functionality. Using PHP, MySQL and MooTools JavaScript, you can implement a Twitter-like status system in no time.

Twitter Web App

Sidebar, Widgets and Badges

Create a Twitter Box in Your Sidebar
In this tutorial, you’ll learn how to easily create a fancy box that displays your latest Twitter rants in your sidebar, without having to turn to clunky plug-ins that bog down your blog.

Twitter Web App

How to Create Your Own Twitter WP Plug-In
In this tutorial, you will be shown how to write a simple widget to allow your readers to share your posts on their Twitter accounts.

Twitter Web App

How to Display Your Twitter Status Message in a Speech Bubble
Display your latest tweet in a nice speech bubble. It can be a pain in the neck creating this with pure CSS and images, so this tutorial will help. A nice effect.

Twitter Web App

Unobtrusive, Lazy-Loading Badge Using the Twitter API

Twitter Web App

A Resizable CSS-Based Twitter Website Badge
If you find the official Twitter badges too big and clunky, then this tutorial is for you. Display your latest tweet in a neat CSS-designed widget that resizes depending on the size of your tweet.

Twitter Web App

Custom Twitter Badge Tutorial CSS
If you’re struggling to get Twitter to suit your website, then this tutorial will show you how to customize the different elements and create your own Twitter badge. View demo here.

Twitter Web App

Building My Own Twitter Badge with RSS
In this tutorial, you will make your own Twitter badge with PHP by reading the RSS feed that Twitter provides. The default Twitter badge uses script tags that do not display when a user has JavaScript disabled. This code will render no matter what and still displays links and the names of tweeters.

Official Twitter Badges
Display your latest updates with a customized widget (or “badge”) from Twitter itself.

Twitter Web App

30+ Twitter Icons And Badges
A large collection of Twitter badges, buttons and icons, available for free download.

Twitter Web App

Building a Twitter Application

How to Build Your First Flash Twitter Mash-Up in Four Lines of Code!
Build a Twitter mash-up in four lines of code? That’s all you need, according to this tutorial, to get the latest public timeline updates from Twitter into Flash.

Twitter Client for Android
A tutorial showing how to create a Twitter client for Android (i.e. how to make XML-over-HTTP calls).

Building an Application with the Twitter API
Twitter API libraries are available for most popular programming languages, and they’re opening up new possibilities for publishing information. In this tutorial, you will use a short Python script to create tweets when the Dow Jones Industrial Average (or any stock or index you like) makes a big jump.

How to Build a Twitter Agent
In this article, you will build a useful Twitter service to track the blogosphere.

Twitter Web App

Building Your Own Twitter Client with Fluid and jQuery
Here, you will learn how to build your own Twitter client using Fluid (which contains Web apps in their own process/window), to see if it is possible to build a completely open-source, ad-free Twitter-like client on a single Web page, using only JavaScript and HTML.

Twitter Web App

Twitter Libraries of Note

Twitter Web App

TwitterScript (Actionscript)
This is an ActionScript 3.0 library for accessing Twitter’s APIs. This was originally code from Twitter, but it is being open sourced so that it can be maintained and kept current.

QTwitLib(C++)
QTwitLib is currently in a functioning stage, which allows a user to make calls to the library, which in turn makes POST/GET requests to Twitter and returns a message and status code for the action request.

java-twitter (Java)
A Java wrapper around the Twitter API.

jtwitter (Java)
JTwitter is a small library providing easy access to the Twitter API. Set and get your status, manage your network of friends, message friends, etc.

My Twitter (PHP)
This class can be used to set and retrieve a Twitter user status.

TwitterLibPHP (PHP)
An object-oriented PHP interface for the Twitter API.

PHP Twitter (PHP)
A Twitter class for PHP, forked, modified and enhanced.

PHP Twitter (PHP)
PHP Twitter is a (wrapper) class for communicating with the Twitter API.

python-twitter (Python)
A Python wrapper around the Twitter API.

twitty-twister (Python)
A twisted client for Twitter-like APIs.

Twittery (Ruby)
Twittery is a lightweight Ruby class that interfaces with Twitter’s API to make interacting with Twitter as simple as possible.

Advertisements

MVC Architecture ….

Posted: November 4, 2011 in Uncategorized

Model View Controller

Probably the widest quoted pattern in UI development is Model View Controller (MVC) – it’s also the most misquoted. I’ve lost count of the times I’ve seen something described as MVC which turned out to be nothing like it. Frankly a lot of the reason for this is that parts of classic MVC don’t really make sense for rich clients these days. But for the moment we’ll take a look at its origins.

As we look at MVC it’s important to remember that this was one of the first attempts to do serious UI work on any kind of scale. Graphical User Interfaces were not exactly common in the 70’s. The Forms and Controls model I’ve just described came after MVC – I’ve described it first because it’s simpler, not always in a good way. Again I’ll discuss Smalltalk 80’s MVC using the assessment example – but be aware that I am taking a few liberties with the actual details of Smalltalk 80 to do this – for start it was monochrome system.

At the heart of MVC, and the idea that was the most influential to later frameworks, is what I call Separated Presentation. The idea behind Separated Presentation is to make a clear division between domain objects that model our perception of the real world, and presentation objects that are the GUI elements we see on the screen. Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentations, possibly simultaneously. This approach was also an important part of the Unix culture, and continues today allowing many applications to be manipulated through both a graphical and command-line interface.

In MVC, the domain element is referred to as the model. Model objects are completely ignorant of the UI. To begin discussing our assessment UI example we’ll take the model as a reading, with fields for all the interesting data upon it. (As we’ll see in a moment the presence of the list box makes this question of what is the model rather more complex, but we’ll ignore that list box for a little bit.)

In MVC I’m assuming a Domain Model of regular objects, rather than the Record Set notion that I had in Forms and Controls. This reflects the general assumption behind the design. Forms and Controls assumed that most people wanted to easily manipulate data from a relational database, MVC assumes we are manipulating regular Smalltalk objects.

The presentation part of MVC is made of the two remaining elements: view and controller. The controller’s job is to take the user’s input and figure out what to do with it.

At this point I should stress that there’s not just one view and controller, you have a view-controller pair for each element of the screen, each of the controls and the screen as a whole. So the first part of reacting to the user’s input is the various controllers collaborating to see who got edited. In the case that’s it’s the actuals text field so that text field controller would now handle what happens next.

Figure 4

Figure 4: Essential dependencies between model, view, and controller. (I call this essential because in fact the view and controller do link to each other directly, but developers mostly don’t use this fact.)

Like later environments, Smalltalk figured out that you wanted generic UI components that could be reused. In this case the component would be the view-controller pair. Both were generic classes, so needed to be plugged into the application specific behavior. There would be an assessment view that would represent the whole screen and define the layout of the lower level controls, in that sense similar to a form in Forms and Controllers. Unlike the form, however, MVC has no event handlers on the assessment controller for the lower level components.

Figure 5

Figure 5: Classes for an MVC version of an ice-cream monitor display

The configuration of the text field comes from giving it a link to its model, the reading, and telling it what what method to invoke when the text changes. This is set to ‘#actual:’ when the screen is initialized (a leading ‘#’ indicates a symbol, or interned string, in Smalltalk). The text field controller then makes a reflective invocation of that method on the reading to make the change. Essentially this is the same mechanism as occurs for Data Binding, the control is linked to the underlying object (row) and told which method (column) it manipulates.

Figure 6

Figure 6: Changing the actual value for MVC.

So there is no overall object observing low level widgets, instead the low level widgets observe the model, which itself handles many of the decision that would be made by the form. In this case, when it comes to figuring out the variance, the reading object itself is the natural place to do that.

Observers do occur in MVC, indeed it’s one of the ideas credited to MVC. In this case all the views and controllers observe the model. When the model changes, the views react. In this case the actual text field view is notified that the reading object has changed, and invokes the method defined as the aspect for that text field – in this case #actual – and sets its value to the result. (It does something similar for the color, but this raises its own specters that I’ll get to in a moment.)

You’ll notice that the text field controller didn’t set the value in the view itself, it updated the model and then just let the observer mechanism take care of the updates. This is quite different to the forms and controls approach where the form updates the control and relies on data binding to update the underlying record-set. These two styles I describe as patterns: Flow Synchronization and Observer Synchronization. These two patterns describe alternative ways of handling the triggering of synchronization between screen state and session state. Forms and Controls do it through the flow of the application manipulating the various controls that need to be updated directly. MVC does it by making updates on the model and then relying of the observer relationship to update the views that are observing that model.

Flow Synchronization is even more apparent when data binding isn’t present. If the application needs to do synchronization itself, then it was typically done at important point in the application flow – such as when opening a screen or hitting the save button.

One of the consequences of Observer Synchronization is that the controller is very ignorant of what other widgets need to change when the user manipulates a particular widget. While the form needs to keep tabs on things and make sure the overall screen state is consistent on a change, which can get pretty involved with complex screens, the controller in Observer Synchronization can ignore all this.

This useful ignorance becomes particularly handy if there are multiple screens open viewing the same model objects. The classic MVC example was a spreadsheet like screen of data with a couple of different graphs of that data in separate windows. The spreadsheet window didn’t need to be aware of what other windows were open, it just changed the model and Observer Synchronization took care of the rest. With Flow Synchronization it would need some way of knowing which other windows were open so it tell them to refresh.

While Observer Synchronization is nice it does have a downside. The problem with Observer Synchronization is the core problem of the observer pattern itself – you can’t tell what is happening by reading the code. I was reminded of this very forcefully when trying to figure out how some Smalltalk 80 screens worked. I could get so far by reading the code, but once the observer mechanism kicked in the only way I could see what was going on was via a debugger and trace statements. Observer behavior is hard to understand and debug because it’s implicit behavior.

While the different approaches to synchronization are particularly noticeable from looking at the sequence diagram, the most important, and most influential, difference is MVC’s use of Separated Presentation. Calculating the variance between actual and target is domain behavior, it is nothing to do with the UI. As a result following Separated Presentation says we should place this in the domain layer of the system – which is exactly what the reading object represents. When we look at the reading object, the variance feature makes complete sense without any notion of the user interface.

At this point, however, we can begin to look at some complications. There’s two areas where I’ve skipped over some awkward points that get in the way of MVC theory. The first problem area is to deal with setting the color of the variance. This shouldn’t really fit into a domain object, as the color by which we display a value isn’t part of the domain. The first step in dealing with this is to realize that part of the logic is domain logic. What we are doing here is making a qualitative statement about the variance, which we could term as good (over by more than 5%), bad (under by more than 10%), and normal (the rest). Making that assessment is certainly domain language, mapping that to colors and altering the variance field is view logic. The problem lies in where we put this view logic – it’s not part of our standard text field.

This kind of problem was faced by early smalltalkers and they came up with some solutions. The solution I’ve shown above is the dirty one – compromise some of the purity of the domain in order to make things work. I’ll admit to the occasional impure act – but I try not to make a habit of it.

We could do pretty much what Forms and Controls does – have the assessment screen view observe the variance field view, when the variance field changes the assessment screen could react and set the variance field’s text color. Problems here include yet more use of the observer mechanism – which gets exponentially more complicated the more you use it – and extra coupling between the various views.

A way I would prefer is to build a new type of the UI control. Essentially what we need is a UI control that asks the domain for a qualitative value, compares it to some internal table of values and colors, and sets the font color accordingly. Both the table and message to ask the domain object would be set by the assessment view as it’s assembling itself, just as it sets the aspect for the field to monitor. This approach could work very well if I can easily subclass text field to just add the extra behavior. This obvious depends on how well the components are designed to enable sub-classing – Smalltalk made it very easy – other environments can make it more difficult.

Figure 7

Figure 7: Using a special subclass of text field that can be configured to determine the color.

The final route is to make a new kind of model object, one that’s oriented around around the screen, but is still independent of the widgets. It would be the model for the screen. Methods that were the same as those on the reading object would just be delegated to the reading, but it would add methods that supported behavior relevant only to the UI, such as the text color.

Figure 8

Figure 8: Using an intermediate Presentation Model to handle view logic.

This last option works well for a number of cases and, as we’ll see, became a common route for Smalltalkers to follow – I call this a Presentation Model because it’s a model that is really designed for and thus part of the presentation layer.

The Presentation Model works well also for another presentation logic problem – presentation state. The basic MVC notion assumes that all the state of the view can be derived from the state of the model. In this case how do we figure out which station is selected in the list box? The Presentation Model solves this for us by giving us a place to put this kind of state. A similar problem occurs if we have save buttons that are only enabled if data has changed – again that’s state about our interaction with the model, not the model itself.

So now I think it’s time for some soundbites on MVC.

  • Make a strong separation between presentation (view & controller) and domain (model) – Separated Presentation.
  • Divide GUI widgets into a controller (for reacting to user stimulus) and view (for displaying the state of the model). Controller and view should (mostly) not communicate directly but through the model.
  • Have views (and controllers) observe the model to allow multiple widgets to update without needed to communicate directly – Observer Synchronization.

    Ref : http://martinfowler.com

UI Design Patterns

Posted: November 4, 2011 in Uncategorized

<!–

–>

UI Design Patterns You Should Be Paying Attention To

Design patterns were first described in the 1960s by Christopher Alexander, an architect who noticed that many things in our lives happen according to patterns. He adapted his observations to his work and published many findings on the topic. Since then, design patterns have found their place in many areas of our lives, and can be found in the design and development of user interfaces as well.

In short, design patterns are solutions to recurring problems. By extension, UI design patterns are solutions to common user interface problems. This article goes over 10 interesting UI design patterns that you can use in your own projects. In fact, you may already be using them now without knowing it.

You may be interested in the following related posts:

1. Lazy Registration

To fully appreciate the problem of registration, we should consider an annoyance that has led to the opinion that sign-up forms must die. This certainly doesn’t mean they should be completely omitted but rather that they should be only one part in the process of introducing users to a system, and should come late in the process. Such an approach is called “lazy registration” and relates to the account registration pattern.

When would you actually use lazy registration? Although it may seem like lazy registration could be used all the time, some circumstances are ideal:

  • When users are allowed to try out your website product or service before making a decision (which not every website permits, though).
  • When it is important to familiarize users with your system before they sign up, which can be a crucial step in their process of deciding whether to register.

Amazon.com shopping cart
Amazon lets you browse and add products to your shopping cart before signing up.

This pattern is meant to allow users to use your system and take action before registering. If satisfied with your service so far, users will regard this quick act of registration as just another small step in the entire process and not an obligation. The shopping cart is a good example of this pattern: users can browse and choose products and only have to register when they proceed to check out.

Picnik.com sign-up form
Picnik is another good example of lazy registration. Users can use all of the service’s functions to edit their photos online. They are asked to register only before saving their work.

Recommended reading

2. Progressive Disclosure

This pattern is used to show only the information or features relevant to the user’s current activity and to delay other information until it is requested. By hiding more complex or infrequently used features, you de-clutter the user interface; by revealing them only as they are needed, you help users perform a complex, multi-step process on a single page.

The goal is to show only essential information in the first step and then invite users to take the next step. When the user completes a step, you reveal the information in the next step, keeping all previous steps visible. By keeping previous steps visible, you allow users to change what they have entered. And the data they input in the current step can affect the behavior of the next step.

Digg.com comments
Digg uses progressive disclosure in its comments section. Users can read a comment and, by clicking on the “Replies” link, see all of the replies to that comment. The link also tells you how many replies will be shown.

Digg.com replies
Once the replies are revealed, users can not only read them but also reply to and rate them. Comments below the viewing threshold are collapsed by default and are revealed by clicking “Show.”

Examples of progressive disclosure are everywhere. A simple “Show more” link that reveals more information is one of the simplest forms of progressive disclosure. But it can be used for more complex cases, such as filling out Web forms. Try to open an account on Picnik (which we mentioned in the lazy registration pattern) to see how progressive disclosure can be used at a more complex level.

YouTube customize section
YouTube uses progressive disclosure when users customize the look of the video player. When a user clicks the icon, customization features open up below.

Recommended reading

3. Forgiving Format

Search functions can offer users various options and sometimes be complex. When searching weather and street maps, for example, users can use such criteria as city name, street name and zip code. To indicate to users that they can use several criteria, interfaces tend to show multiple options and become overly complex. Instead of adding clutter to the interface, use the forgiving format pattern, which lets users enter data in various formats and leaves it to the system to parse the data.

Yahoo weather search
Yahoo weather search allows users to search by city or zip code.

To convey which formats are supported, give users hints on how to search, whether by listing all available formats, as in the example above, or by providing a link to a help page, as in the example below.

Google maps search
Google Maps allows users to search by city, street, zip code and even latitudinal and longitudinal values.

The forgiving format pattern significantly simplifies user interfaces. However, it may require a lot of work from back-end developers. The more options users have, the more difficult parsing becomes.

4. Clear Primary Actions

Simple Web forms often allow just one action (“Submit,” “Save” or “Send”). The user knows exactly what their final action in filling out the form will be, because they have only one option. However, users may sometimes be faced with several options and have to distinguish between primary and secondary actions.

Clearleft contact form
Clearleft makes a distinction between primary and secondary actions with color.

What are primary and secondary actions? Primary actions lead to the completion of a form; for example, clicking “Save” or “Send.” Secondary actions usually do not lead to a form’s completion; these include clicking “Cancel.” There are exceptions, though. Which are the primary and secondary actions when you see “Save,” “Save and continue” and “Publish” buttons all in a row? When users have several options, highlighting primary actions and de-emphasizing secondary actions are good practice.

This can be done in two ways:

  • By giving primary and secondary actions different colors; for example, giving primary actions a vibrant color and secondary actions a shade of gray.
  • By styling primary actions as buttons and secondary actions as links.

Flickr upload images form
Flickr highlights the primary action by putting the secondary action in a small label below.

Both ways clearly distinguish between primary and secondary actions, relieving the user from having to think about which option to choose in order to complete their task.

Recommended reading

5. Breadcrumbs

Breadcrumbs show the path from the front page of the site to the current location of th users in the website’s page hierarchy. They are a form of secondary navigation that helps users understand the hierarchy and structure of the website. Breadcrumbs start with the home page and end with the page currently being viewed. Each label in a breadcrumb trail is linked to its respective page or section in the hierarchy, the exception being the one for the current page, which should just be an unlinked label.

Apple breadcrumbs
Apple’s breadcrumbs are graphic elements that fit the overall design of the website well.

Breadcrumbs take up minimal space and are usually positioned at the top of the page, below the header and above the content. They would serve no purpose on the home page and so should not appear there. Breadcrumbs can appear simply as text links separated by the “>” sign, or they can be graphic elements, like the breadcrumbs on Apple’s website:

Recommended reading

6. Account Registration

The definition of this pattern varies from place to place, but we can say that it solves three somewhat related problems:

  • Certain content is accessible only to registered users,
  • Users need to re-enter their personal data often,
  • Users need to be able to access personalized content on a system.

The solution to allowing users to access protected content is to have them register for an account on the system and store their personal data, to be reused later. The benefits are numerous. For instance, users can be shown personalized offers, as seen on Amazon. Users could also perform tasks more efficiently if the system reused the information submitted during registration. Storing shipping details is just one example. Because filling out forms is not a favorite task of users, requiring only necessary information is important. Another important thing is to clearly highlight all of the benefits users will receive, so that they become more willing to register.

Vimeo.com sign-up form
Vimeo has a simple but attractive sign-up form.

Tumblr.com sign-up form
Tumblr requires only minimal information of the user to sign up.

Recommended reading

7. Required Field Marker

Making the user interface obvious is essential. This applies just as much to Web forms. One of the best ways to make the interface of Web forms obvious is by marking required fields. The purpose of these markers is to alert the user to information they will need to provide. This way, users won’t feel they have to fill out the entire form to avoid seeing an error message.

Ideally, you should remove all optional fields and let the user type only the information that is necessary for the interaction. A rule of thumbs: the simpler and shorter a web form is, the better is the user experience. Another interesting idea is to make it possible for users to remove all optional fields – you can find more about how to implement it in practice (as well as a ready-to-be-used-script) in Andy Clarke’s article Trimming Form Fields.

Haveamint.com contact form
Haveamint.com puts “Required” markers next to field labels on its contact form.

You can position required field markers in one of two places:

  • Next to labels, allowing users to scan the form quickly,
  • Next to or inside input fields; if the fields are the same width, users will be able to scan the form quickly.

When deciding on which fields to require, take into account the total number of fields in the form. If the form is complex and most of its fields are required, the user will likely see it as unnecessary clutter.

8. Steps Left

This pattern is widely implemented when users have to fill in data in multiple steps. The purpose of this pattern is to:

  • Guide users,
  • Explain the scope of the process by clearly stating how many steps are needed to complete it,
  • Show the user’s current position in the process by visually highlighting the current step.

StatementStacker sign-up process
StatementStacker clearly shows the number of steps and highlights the current step.

Steps are usually displayed horizontally and connected by arrows, showing the order in which the steps will be performed. Also, each step is usually marked with a large number and very concise description of what users should do in that step. The important thing here is consistency: a progress indicator should always appear in the same position across the pages and show users where they are at.

This pattern is usually combined with the well-known “wizard” pattern to create a multi-step process, such as for registration or a shopping cart.

Delicious sign-up process
Delicious has a good-looking progress indicator that clearly defines the purpose of each step. It also highlights the current step by displaying it in a different color.

9. Subscription plans

This pattern is suitable if the website offers one product or service that comes in different plans and requires regular payments, usually monthly payments. Each plan should be descriptive and provide the following information:

  • Name of the plan, such as “Basic” or “Professional,”
  • Price of the subscription plan and how long it is valid for,
  • List of features (the cheapest plan usually has the fewest features),
  • Sign-up button.

Wufoo subscription plans
Wufoo clearly shows its subscription plans, the prices and the differences between them.

Always show your plans in order. Plans are usually ordered from most to least expensive. You can highlight the plan you want users to buy by using a different color or size.

CrazyEgg subscription plans
Crazyegg’s subscription table draws attention to the “Basic” plan.

10. Hover Controls

When a user interface has many elements in which the user can perform actions, the page can become cluttered and hard to scan. This is especially common in the administration section of Web applications, where users can change table data. A good way to handle this is to hide each element and reveal it when the user hovers over that area.

Facebook
An “Edit” link is revealed as the user hovers over each section of their Facebook profile page.

Hiding controls and revealing them on hover significantly de-clutters the user interface without taking away functionality.

Twitter
Twitter reveals “Reply” and “Favorite” links when the user hovers over each tweet.
Reference: http://uxdesign.smashingmagazine.com

UI VS UX …. A good reference I found

Posted: November 4, 2011 in Uncategorized

UX Design Versus UI Development

“At the heart of the tension between them is the fact that most UI Developers consider themselves—and sometimes rightfully so—to be UI Designers.”

One of the more interesting tensions I have observed—since getting into user experience design about five years ago—is the almost sibling-rivalry tension between UX Designers and User Interface (UI) Developers. At the heart of the tension between them is the fact that most UI Developers consider themselves—and sometimes rightfully so—to be UI Designers. The coding part is like Picasso’s having to understand how to mix paint. It’s not the value they add, just the mechanics of delivering the creative concepts.

When I worked on the Body of Knowledge Task Force for the Society for Technical Communication, the interesting question we wrestled with was: What value does a technical communicator add above what an engineer who writes well offers?UX Designers or UX Architects have the same problem to solve: What value do we add that differentiates us from a UI developer who is user focused? This question strikes to the very heart of what differentiates us, as UX professionals, from UI Developers. If we don’t provide a compelling answer, the only one left is that they code and we don’t. Hmm…, not the kind of value proposition I’d be comfortable with in this economy.

I was recently reminded of the import of this problem, when a UX Designer lamented that he had approached the Product Manager for a new product with the question: “Have you thought about how to ensure the quality of the user experience?” The Product Manager’s answer was: “Oh yes, so-and-so is developing the UI,” where so-and-so was a talented and user-focused UI Developer. So, how do we break into the product-design process when something like that happens?

“It’s not like we have a monopoly on secrets about design patterns and best practices for user interactions.”

I thought about this on my drive home that night—on almost empty roads, because the weatherman had predicted two millimeters of snow for Atlanta, and the town was shut down in anticipation—wondering how to counter in response to a statement like this: “We have a talented developer working on it.” My conclusion: I’d come back with, “Great, he’s good! Where is he going to get his user data?”

I think a mistake we sometimes make as UX Designers is that we believe, if the race starts at wireframing, we will win. But if that’s where the race starts, we have no advantage over a talented UI programmer. It’s not like we have a monopoly on secrets about design patterns and best practices for user interactions. Some UI Developers have the same knowledge and, in some cases, were even the ones who pioneered those patterns and best practices.

In this column, I’ll examine the differences and commonalities between the UX Designer and UI Developer roles and discuss how the two can complement each other rather than compete.

Role Definitions

“The area of shared expertise between the two roles includes knowledge of UI patterns and standards—the widgets and elements that make up a user interface—as well as knowledge about the software development process.”

The following descriptions of roles are a bit oversimplified, but provide a workable framework for a discussion of the respective contributions of UX Designers and UI Developers.

  • UX Designer—One who designs the user experience for applications after doing user and workflow analysis, producing user-centered design artifacts such as personas, site maps, taxonomies, and wireframes. A UX Designer may also conduct usability testing on prototypes or finished products to assess the quality of a user experience.
  • UI Developer—One who builds user interfaces that support the exchange of information between an application’s users and its back-end processes and databases. This could be either a fully dedicated role on a development team or a hat a developer who is also responsible for coding the back-end processes might wear. A UI Developer’s output is functional, testable, shippable code that lets users accomplish their goals when using an application. The UI Developer is also responsible for documentation that allows others to maintain their code.

Figure 1 illustrates the resultant overlap of traditional UX design skills and UI development skills.

Figure 1—Overlap between UX design and UI development skills

Overlap between UX design and UI development skills

The area that tends to fall under the exclusive domain of UI development includes the programming skills and knowledge. If you had a pin labeled Ruby on Rails, the UI development role would be a good place to stick it. The area that tends to be the exclusive domain of User Experience relates to user research and usability testing. Thus, if you had a pin labeled card sorting, the UX side of the diagram would be its predictable home. The area of shared expertise between the two roles includes knowledge of UI patterns and standards—the widgets and elements that make up a user interface—as well as knowledge about the software development process. This diagram is somewhat oversimplified—imagine one where the borders are fuzzy rather than crisp lines of demarcation, and you’d get closer to the truth.

How These Roles View Themselves and Each Other

“If you ask a UX Designer and a UI Developer who is the principal designer of the user experience, expect to hear a resounding “I am!” from both of them.”

As I’ve worked with and listened to UX Designers and UI Developers, I’ve noticed how they view themselves and each other. I am reminded of the crime shows on TV and who is the primary crime solver on each of them. You get a very different impression depending on which show you watch. The CSI shows would lead us to believe that the forensic scientists solve the crimes—including the arrest and interrogation of suspects. Quincy ME tried to convince us that it was the coroner. And patrol cops, detectives, profilers, prosecutors, and defense attorneys might emerge as the central crime solvers, depending on what show you watch.

In short, if you ask a UX Designer and a UI Developer who is the principal designer of the user experience, expect to hear a resounding I am! from both of them.

UX Designers see their validity as coming from the user research that informs their designs. “We’ve talked to the customers, and we know what they want.” UI Developers see their validity as coming from their knowledge of the underlying technology’s capabilities and constraints, along with their knowledge of how to use the widget library at their disposal.

And the tension between the people in these two roles has been known to generate hard feelings. UX Designers resent the disregard developers sometimes give their designs. And UI Developers feel that UX wireframes are too static and don’t take into account what they discover during the process of building a user interface. As a design comes to life, the developers gain new insights—either while interacting with the back-end processes or by testing the interactions they are building.

Another source of resentment that sometimes arises is UX Designers’ feeling that they’re getting left out of the development process as their wireframes move into production and would like to be more involved when changes are necessary. Conversely, UI Developers feel left out up front, where they feel they could provide informative inputs about what the available technology and tools can do and what they constrain.

Complementary Roles

“The professional value UX Designers offer includes their processes and the artifacts they create that help inform and validate design and development around user needs.”

I think the two roles have distinct areas in which they respectively add their unique value.

The professional value UX Designers offer includes their processes and the artifacts they create that help inform and validate design and development around user needs. When we create a wireframe or prototype, it’s our way of communicating data-driven—or at least process-driven—design considerations. Such a design artifact should be a straw man that starts a collaborative process of review and refinement. (Sometimes, being a UX Designer feels like being a forensic sketch artist who draws a nose, any nose, so a witness can say broader, thinner, whatever.) The best case is when a design deliverable both visually communicates data-driven requirements and provides a working space for collaborative input.

The professional value UI developers offer is their use of technology to actually make the best user experience happen. In that role, the UI Developer is a rightful participant in the design process. Bringing a conceptual design to life is a creative function, and a UI Developer can help the design mature and emerge by applying his or her own creativity to the process. If a UX Designer were to insist that his wireframes were unquestionable blueprints, we’d lose the insights that could come from a UI Developer’s craftsmanship in building that blueprint into a functional structure in which a user would want to work.

So, as UX professionals, our ultimate value is that we follow a process that includes data gathering, data validation, collaborative design, and usability testing of our designs. Our process can channel the talents of UI Developers and support their involvement in design by informing them of user needs, then validating that the emergent design meets those needs.

If we think of ourselves just as better UI Designers, we might lose the value proposition to talented UI Developers who can both design and code