Ref: http://www.smashingmagazine.com

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 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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

Unobtrusive, Lazy-Loading Badge Using the Twitter API

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.

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.

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.

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

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.

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 Libraries of Note

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.

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.

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.

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.

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.

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.

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 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:

• 9 Crucial UI Features of Social Media and Networking Sites
• 40+ Helpful Resources On User Interface Design Patterns
• 10 Useful Techniques To Improve Your User Interface Designs
• Web Form Design Patterns: Sign-Up Forms: part 1, part 2.

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 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 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

• Sign-up forms must die: here’s how we killed ours!
  An interesting article on how 90percentofeverything implemented lazy registration.
• Web Form Design Patterns: Sign-Up Forms, Part 1 and Part 2
  Interesting and useful research that Smashing Magazine conducted last year

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 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.

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 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

• Progressive disclosure
  Excellent insight from Jakob Nielsen.
• Read more… about progressive disclosure
  Good explanation of progressive disclosure, with several examples.

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 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 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 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 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

• Web Form Design: Filling in the Blanks
  Probably one of the best resources for designing Web forms.

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’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

• Breadcrumb Navigation Increasingly Useful
  Jakob Nielsen explains breadcrumbs in depth.
• Simple scalable CSS-based breadcrumbs
  A very good simple tutorial on how to create breadcrumbs.

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 has a simple but attractive sign-up form.

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

Recommended reading

• Web Form Design: Filling in the Blanks
  A must-read book on creating usable Web forms in general.
• User Membership With PHP
  A simple implementation of sign-up and log-in forms.
• Accessible HTML/XHTML Forms: Beginner Level
  How to create an accessible Web form.

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 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 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 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 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’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.

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 reveals “Reply” and “Favorite” links when the user hovers over each tweet.
Reference: http://uxdesign.smashingmagazine.com

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?

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 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

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

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

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

To purchase WDF’s very own jQuery slider, click here.

Content sliders are a great way to show large amount of content or images on a smaller area in a website or blog. They are commonly used in portfolio sites, corporate sites or blogs. You may probably heard that jQuery isn’t very hard to learn. If you are interested in implementing a content slider in your website please check our jQuery tutorials and plugins collection.

In this collection you will find 25 Excellent jQuery Slider Tutorials and Plugins that you can implement into your website.

To have your own slider, simply visit our store and buy one for your site today.

1. Create Beautiful jQuery slider tutorial

2. jQuery Plugin – Feature List

3. Create an Image Rotator with Description (CSS/jQuery)

4. Moving Boxes

5. Using the Wonderful jFlow Plugin

6. Creating a Slick Auto-Playing Featured Content Slider

7. Design An Elegant Featured Content Slider for WordPress

8. jQuery Slider plugin (Safari style)

9. Accessible News Slider

10. Animated JavaScript Accordion V2

11. jQuery UI 1.7 Slider from a Select Element

12. Easy Slider 1.7 – Numeric Navigation jQuery Slider

13. TabSwitch

14. AnythingSlider jQuery Plugin

15. A jQuery Twitter Ticker

16. SlideItMoo 1.1 – improved image slider

17. Making a Google Wave History Slider

18. bxSlider – jQuery content slider

19. Making A Slick Content Slider

20. SlideViewerPro 1.0

21. A Beautiful Apple-style Slideshow Gallery With CSS & jQuery

22. Create a Slick and Accessible Slideshow Using jQuery

23. Coda-Slider 2.0

24. jQuery Multimedia Portfolio

25. Slider Gallery

Thank you for reading this article on jQuery Sliders.

Pass VCP-410 exam on first try with test-king. Our certified 350-001 questions and answers plus live demo tests for 70-680 are extremely useful to pass your certification in single attempt.

PsPrint online printing services – affordable and high quality calendar printing you can trust!
Ref: http://webdesignfan.com

1. Lightbox JS : Original; a simple, unobtrusive script used to overlay images on the current page.
2. Greased Lightbox : Greasemonkey/Creammonkey/Opera user script designed to enhance browsing on websites that link to images such as Google Image Search, Flickr, Wikipedia, Facebook, MySpace, and deviantART.
3. GreyBox : A pop-up window that doesn’t suck.
4. Greybox Redux : Completely unobtrusive – no need to embed Javascript into your site.
5. Leightbox : uses inline div’s instead of AJAX calls.
6. Lightbox Plus : by Takuya Otani
7. Lightbox Gone Wild : at ParticleTree
8. The Lightbox Effect without Lightbox : by PJ Hyett
9. LITBox 2.0 : modified Thickbox made into a Prototype class based off of the Scriptaculous.
10. Multifaceted Lightbox : at GregPhoto
11. Prototype Window Class : at Xilinus
12. Suckerfish HoverLightbox : hover + gallery + lightbox at MondayByNoon
13. Thickbox – One box to rule them all. : by Cody Lindley
14. Slightly ThickerBox : Thickbox with Prev and Next links at Jasons Toolbox
15. WP lightbox JS WordPress plugin : WordPress Plugin by Safirul Alredha
16. Lightbox2 : WordPress Plugin at m3nt0r – beyond the net
17. GreyBox Plugin : WordPress Plugin at aNieto2K

    Ref:  http://webdeveloper.econsultant.com

Below are the list of mistakes that AJAX gives you as a gift.

No Back Button Functionality
By default the browser stores the web page visited in the History Folder, but with AJAX the browser is unable to retrieve the dynamic content.

2. Waiting Endlessly
The AJAX functionality largely depend on the network connection and the bandwidth. AJAX works well with good Internet Connection so if you are using dial-up you will have to wait until the response comes from the server. But if your browser get struck in between the AJAX call irrespective of the internet connection then your browser window is dead until the user reloads the page or opens a same page and writes the same content again and submit.

Using AJAX for the sake of AJAX.
AJAX is a very good feature to implement in todays web world but you also have to make count of the usability of it.

Cross Browser Compatible
If your web application is targeting multiple browser you will have to make sure that the AJAX Application works seamlessly on all the browsers.

Browsers Load
Making too much AJAX calls will degrade the browser performance and it will become slow. This will make the user experience horrible for your site.

Bookmarking
Users cannot bookmark the page having dynamic content fetched using AJAX. The reason is AJAX will fetch dynamic data from the server and the bookmark link will only store the static data stored in the internet cache folder.

Enable/Disable JavaScript
AJAX purely works with JavaScript and if the users browsers has JavaScript disabled then the AJAX functionality will not work.

We can achieve HTML scrapper operation in 2 step operation:

• Call to Remote Web Page and extract the HTML content.
• Match the HTML tags using Regular Expression.

Call to Remote Web Page using PHP:
In PHP there are various ways we can call the remote webpage, for more information on connecting to remote web page we can refer to . But here we will be using CURL to achieve our operation.

$ch = curl_init();
$timeout = 5; // set to zero for no timeout
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$file_contents = curl_exec($ch);
curl_close($ch);

$url holds the Remote URL you want to connect to; and $file_contents holds the HTML content of the remote web page that we have called.

Match the HTML tags using Regular Expression using PHP:
Here we will be using preg_match/preg_match_all to read the HTML tags from the HTML source. Here i am posting few Regular Expression code that will extract the content inside the HTML tags.

Extracting data from HTML tags

    preg_match_all('/<span>[\/\(\)-:<>\w\s]+< \/span>/',$file_contents,$htmlContent);
</span>

Assume that the $file_contents holds the HTML source code and after executing the above preg_match it will extract all the span tags from the HTML source code. Isn’t it simple, so now instead of span we want data from any other tag just replace the tag with that tag.

    preg_match_all('/<span>[\/\(\)-:<>\w\s]+< \/span>/',$file_contents,$htmlContent);
</span>

Assume that the $file_contents holds the HTML source code and after executing the above preg_match it will extract all the span tags having class=”test” from the HTML source code. This will ensure that we extract only those span tags that will have class attributes only.

    preg_match('%<table.*>.*\s*\s*</table>%',  $file_contents, $htmlContent);

Assume that the $file_contents holds the HTML source code and after executing the above preg_match it will extract all the table tags from the HTML source code. This will ensure that we extract only those table tags that will have class=’test’ attributes only. Now we have the table tag content, now we will extract the data inside td tags.

   preg_match_all('#<td [^>]*>(.*?)</td>]*>#is', $htmlContent[0], $td_matches);

Here we pass the extracted table tags details to the preg_match_all, this will ensure that we read all the data that resides inside the td tags.

Ref: http://www.hiteshagrawal.com

NOTE ON MAGIC METHODS:

• Magic methods are the members functions that is available to all the instance of class
• Magic methods always starts with “__”. Eg. __construct
• All magic methods needs to be declared as public
• To use magic method they should be defined within the class or program scope

Various Magic Methods used in PHP 5 are:

• __construct()
• __destruct()
• __set()
• __get()
• __call()
• __toString()
• __sleep()
• __wakeup()
• __isset()
• __unset()
• __autoload()
• __clone()
  __construct()
  This methods gets called whenever an object of a class is instantiated. This method is a part of Object Oriented Programming concept in PHP 5. To know more about this methods refer PHP 5 Tutorial – __construct Method. 

  __destruct()
  This methods gets called whenever an object of a class is destroyed or object goes out of scope. This method is a part of Object Oriented Programming concept in PHP 5. To know more about this methods refer PHP 5 Tutorial – __destruct Method.

  __set()
  This methods get automatically called whenever you assigns data to a undefined attributes of an class in PHP 5. To know more about this method refer PHP 5 Tutorial – __set() magic method.

  __get()
  This methods get automatically called when you try to retrieves the data of undefined attributes of an class in PHP 5. To know more about this method refer PHP 5 Tutorial – __get() magic method.

  __call()
  This methods get automatically called you call and undefined methods of an class in PHP 5. To know more about this method refer PHP 5 Tutorial – __call() magic method.

  __toString()
  This method is called whenever an class object is treated as string and is echo or print(). This methods is very useful if you want to check the object methods and attributes. To know more on this method refer PHP 5 Tutorial – __toString magic method.

  __sleep()
  This methods gets called when you serialize the object in PHP 5. With this method call we can define the way how the data object will be stored. To know more on this method refer PHP 5 Tutorial – __sleep magic method.

  __wakeup()
  This methods gets called when the object is about to be unserialized in PHP 5. With this method call we can do necessary initial operation before starting operation on the received data object. To know more on this method refer PHP 5 Tutorial – __wakeup magic method.

  __isset()
  This methods get automatically called whenever you try to check the existence of the undeclared attributes of the class using isset function of PHP. To know more about this method refer PHP 5 Tutorial – __isset() magic method.

  __unset()
  This methods get automatically called whenever you try to check the destroy or clear an undeclared attributes of the class using unset function of PHP. To know more about this method refer PHP 5 Tutorial – __unset() magic method.

  __autoload()
  This methods get automatically called whenever you try to load an object of class which resides in separate file and you have not included those files using include,require and include_once. To use this method it is mandatory to the PHP filename as that of the class name because this methods accepts the class name as the argument. To know more about this method refer PHP 5 Tutorial – __autoload() magic method.

  __clone()
  PHP5 has introduced clone method which creates an duplicate copy of the object. __clone methods automatically get called whenever you try to call clone methods in PHP 5. This operator does not creates a reference copy. To know more about this method refer PHP5 Tutorial – __clone() magic method.

  Ref: http://www.hiteshagrawal.com

START TRANSACTION [WITH CONSISTENT SNAPSHOT] | BEGIN [WORK]
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
SET autocommit = {0 | 1}

The  COMMIT, and
ROLLBACK Syntax” href=”http://dev.mysql.com/doc/refman/5.0/en/commit.html”>BEGIN statement begins a new transaction.  COMMIT, and
ROLLBACK Syntax” href=”http://dev.mysql.com/doc/refman/5.0/en/commit.html”>ROLLBACK rolls back the current transaction, canceling its changes. The  COMMIT, and
ROLLBACK Syntax” href=”http://dev.mysql.com/doc/refman/5.0/en/commit.html”>COMMIT and completion_type system variable determines the default completion behavior. See Section 5.1.3, “Server System Variables”.

SET autocommit=0;