On Demand Interfaces
Robert | 11.13.2005 @ 2:48 PM
Permalink | 0 Comments
What is an “on-demand interface”?
The term “on-demand interface” (ODI) is how we refer to all the AJAX- and Flash-based applications being created as part of Web 2.0 to change the web and produce a paradigm of productivity, contribution, and control on the web. Instead of being able only to read, see, or do, users can now produce, contribute to, and control their own web spaces in a way that enables them to use the web to genuinely improve their daily lives. And they're doing it with on-demand interaces.
An ODI (pronounced “oh-dee”) offers users the features they need – where they need them and when they need them. For example, rolling over a page title in Backpack reveals an Edit button. Clicking it converts the page title text into an editable text field so you can edit the title. Clicking Save updates the displayed title text, and the process is complete. The title updates on the fly. In other words, the ability to change the title of a page is right where it needs to be, right when it’s needed. It’s not buried on another page. It’s not in a Preferences page. It’s right there – right where it’s most convenient. This is how an on-demand interface works.
On-demand interfaces are Fitts’ Law interfaces. By putting Fitts’ Law into practice, interfaces become more intuitive and easier to use. If the easiest spot to click at any point is the spot where the mouse pointer currently rests (which it is, according to Fitts' Law), then access to the feature you need at any moment should be available at that very spot it’s needed. In ODIs, this is true more often than not.
How do AJAX-based applications play a role in the creation of on-demand interfaces?
AJAX itself is very simple. It’s nothing more than a couple of JavaScript functions used to load and parse XML and write new data into a page in an on-demand fashion. But AJAX is being used in truly innovative ways to generate ODIs. The AJAX approach is being used in conjunction with DHTML (Dynamic HTML, which consists of JavaScript, HTML, and CSS) to create applications like Backpack, Basecamp, Blinksale, JotLive, and many others. AJAX, when used with DHTML, enables the creation of on-demand interfaces, and smart designers everywhere are finding ways to use AJAX requests and DHTML to make the web a better place.
How does Macromedia Flash facilitate on-demand interfaces?
Macromedia Flash is more than capable of facilitating on-demand interfaces. And naturally, it’s all about how the tool is used. For example, in a simple contact form, ActionScript can be used to set focus on the first empty input field in the form (so the user can immmediately start typing instead of clicking into a field first), save unfinished messages should the browser crash or the internet connection be lost, retain user information such as name and email address so the user does not have to re-enter the information on return visits, and provide in-context feedback, such as a “Your message has been sent” screen and warning messages that a field must be completed to send the message.
Flash can also be used, quite effectively, to make on-demand server calls to retrieve and submit data. It can also enable users to filter data, visualize data in innovative ways (beyond simple graphs and charts), and provide adaptive application states to guide users through a process, improve conversion rates (such as the conversion from visitor to subscriber), and even offer design elements that handle situations where something goes wrong.
In the case of the rhjr.net eReader application, the user steps through a series of “pages”, each of which displays within the same application shell. The user never leaves the HTML page to move from one state to another. The application simply displays new data based on user-interaction. This is another example of an on-demand interface.
What’s it all mean?
On-demand interfaces allow users to interact with an application in a way that facilitates productivity. They adapt to the user. Functionality is provided when and where the user needs it, exposing features in an on-demand fashion. As a result, user-experience is improved dramatically, and user-satisfaction is taken to much higher levels.
Creating ODIs means putting your users first, and putting your users first means you’ll have happier and more loyal users.
Any advice on how to design an ODI?
Naturally!
First, keep it simple. If a feature does not absolutely need to be in your application, get rid of it. Strip the application down to its bare essentials. Only build what’s absolutely required for the user to do what he or she needs to do and move on.
Second, listen to the users every step of the way. Put the simplest form of your application in front of usrs as soon as possible, and let them tell you what’s working and what’s not. Let them tell you what they need and what they find annoying. Let them tell you how to build the application they want. Put something out there as soon as possible, then iterate, iterate, and iterate again. Keep iterating until users have what they need, and then only make additions if they are in high demand and are really necessary. Occasionally, strip out old, unused features, eliminating the need for you to maintain them, and getting them out of the way of your users.
Less features = more focused and usable applications.
How ’ bout some examples?
Certainly. Here is a list:
Backpack
Basecamp
JotLive
Blinksale
Writeboard
And the first release from 33Inc …
Dashboard HQ
Permalink | 0 Comments
What is an “on-demand interface”?
The term “on-demand interface” (ODI) is how we refer to all the AJAX- and Flash-based applications being created as part of Web 2.0 to change the web and produce a paradigm of productivity, contribution, and control on the web. Instead of being able only to read, see, or do, users can now produce, contribute to, and control their own web spaces in a way that enables them to use the web to genuinely improve their daily lives. And they're doing it with on-demand interaces.
An ODI (pronounced “oh-dee”) offers users the features they need – where they need them and when they need them. For example, rolling over a page title in Backpack reveals an Edit button. Clicking it converts the page title text into an editable text field so you can edit the title. Clicking Save updates the displayed title text, and the process is complete. The title updates on the fly. In other words, the ability to change the title of a page is right where it needs to be, right when it’s needed. It’s not buried on another page. It’s not in a Preferences page. It’s right there – right where it’s most convenient. This is how an on-demand interface works.
On-demand interfaces are Fitts’ Law interfaces. By putting Fitts’ Law into practice, interfaces become more intuitive and easier to use. If the easiest spot to click at any point is the spot where the mouse pointer currently rests (which it is, according to Fitts' Law), then access to the feature you need at any moment should be available at that very spot it’s needed. In ODIs, this is true more often than not.
How do AJAX-based applications play a role in the creation of on-demand interfaces?
AJAX itself is very simple. It’s nothing more than a couple of JavaScript functions used to load and parse XML and write new data into a page in an on-demand fashion. But AJAX is being used in truly innovative ways to generate ODIs. The AJAX approach is being used in conjunction with DHTML (Dynamic HTML, which consists of JavaScript, HTML, and CSS) to create applications like Backpack, Basecamp, Blinksale, JotLive, and many others. AJAX, when used with DHTML, enables the creation of on-demand interfaces, and smart designers everywhere are finding ways to use AJAX requests and DHTML to make the web a better place.
How does Macromedia Flash facilitate on-demand interfaces?
Macromedia Flash is more than capable of facilitating on-demand interfaces. And naturally, it’s all about how the tool is used. For example, in a simple contact form, ActionScript can be used to set focus on the first empty input field in the form (so the user can immmediately start typing instead of clicking into a field first), save unfinished messages should the browser crash or the internet connection be lost, retain user information such as name and email address so the user does not have to re-enter the information on return visits, and provide in-context feedback, such as a “Your message has been sent” screen and warning messages that a field must be completed to send the message.
Flash can also be used, quite effectively, to make on-demand server calls to retrieve and submit data. It can also enable users to filter data, visualize data in innovative ways (beyond simple graphs and charts), and provide adaptive application states to guide users through a process, improve conversion rates (such as the conversion from visitor to subscriber), and even offer design elements that handle situations where something goes wrong.
In the case of the rhjr.net eReader application, the user steps through a series of “pages”, each of which displays within the same application shell. The user never leaves the HTML page to move from one state to another. The application simply displays new data based on user-interaction. This is another example of an on-demand interface.
What’s it all mean?
On-demand interfaces allow users to interact with an application in a way that facilitates productivity. They adapt to the user. Functionality is provided when and where the user needs it, exposing features in an on-demand fashion. As a result, user-experience is improved dramatically, and user-satisfaction is taken to much higher levels.
Creating ODIs means putting your users first, and putting your users first means you’ll have happier and more loyal users.
Any advice on how to design an ODI?
Naturally!
First, keep it simple. If a feature does not absolutely need to be in your application, get rid of it. Strip the application down to its bare essentials. Only build what’s absolutely required for the user to do what he or she needs to do and move on.
Second, listen to the users every step of the way. Put the simplest form of your application in front of usrs as soon as possible, and let them tell you what’s working and what’s not. Let them tell you what they need and what they find annoying. Let them tell you how to build the application they want. Put something out there as soon as possible, then iterate, iterate, and iterate again. Keep iterating until users have what they need, and then only make additions if they are in high demand and are really necessary. Occasionally, strip out old, unused features, eliminating the need for you to maintain them, and getting them out of the way of your users.
Less features = more focused and usable applications.
How ’ bout some examples?
Certainly. Here is a list:
Backpack
Basecamp
JotLive
Blinksale
Writeboard
And the first release from 33Inc …
Dashboard HQ
Use the Tools
Manage bookmarks in lists- Create custom content
- Keep it all as your homepage