IBM UX Screen Flow Manager provides a mechanism to guide users through a well-defined sequence of screens where they can perform a number of steps or tasks in the appropriate sequence.
Introduction
Customers often have to implement portal- or portlet-based solutions that guide users through a well-defined sequence of screens. These sequences route users along paths that interconnect user interface artifacts, such as forms or masks, so that the users can accomplish specific tasks. From a user perspective, stepping through such sequences feels to the users like working with wizards. It relieves them from thinking about the right sequence of going through the screens and processing them.
The need for such solutions arises across all industries. In the insurance industry, screen flow modelers might need to model flows for processing policy quotations or claim submissions. Quoting a vehicle insurance policy might be composed of steps such as vehicle selection, vehicle data specification, insure data collection, tariff characteristics selection. Similar applications can be required for banking, help desk, or travel applications.
When developers write portal based solutions, the screens and the functions behind them are usually provided by portlets. But the mapping of individual screens to portlets can be difficult, as it impacts both the user experience and the reusability.
As of today, customers usually must select between two extremes:
The IBM® UX Screen Flow Manager provides operators, developers, and dialog modelers with the best of two worlds: It provides the basis for developing fine-granular, small split portlets, which can also be declaratively interconnected and managed by IBM WebSphere® Portal. This way, it provides an answer to the tradeoff decision by providing both strict user guidance and high reusability.
Customers often have to implement portal- or portlet-based solutions that guide users through a well-defined sequence of screens. These sequences route users along paths that interconnect user interface artifacts, such as forms or masks, so that the users can accomplish specific tasks. From a user perspective, stepping through such sequences feels to the users like working with wizards. It relieves them from thinking about the right sequence of going through the screens and processing them.
The need for such solutions arises across all industries. In the insurance industry, screen flow modelers might need to model flows for processing policy quotations or claim submissions. Quoting a vehicle insurance policy might be composed of steps such as vehicle selection, vehicle data specification, insure data collection, tariff characteristics selection. Similar applications can be required for banking, help desk, or travel applications.
When developers write portal based solutions, the screens and the functions behind them are usually provided by portlets. But the mapping of individual screens to portlets can be difficult, as it impacts both the user experience and the reusability.
As of today, customers usually must select between two extremes:
• On the one hand, they can decide to have one single portlet provide all necessary screens and the entire set of functions that is required to accomplish a specific task. This approach where one portlet fits for all implies developing one single monolithic application. Due to its complexity and its non-modular character, such a portlet does not scale well, is hard to maintain, and difficult to reuse. However, this approach provides developers and screen flow modelers with the highest control for guiding users through the flow.
• On the other hand, they can decide to develop a single dedicated portlet for each of the individual screens and functions that are required to accomplish a specific task. This approach with one portlet per screen offers more flexibility and increases the options for reusability. However, guidance for the users is less strict and less controllable, which in turn increases the danger of erroneous navigation. Therefore, developers need to write "hard-wired" portlets. Such hard-wired portlets reduce flexibility, or users need to find out about the intended flow, which increases the risk for incorrect usage. In general, there is no single right answer for the right granularity. This issue often leads to time consuming discussions and decisions, depending on the actual scenario that is to be implemented.
The IBM® UX Screen Flow Manager provides operators, developers, and dialog modelers with the best of two worlds: It provides the basis for developing fine-granular, small split portlets, which can also be declaratively interconnected and managed by IBM WebSphere® Portal. This way, it provides an answer to the tradeoff decision by providing both strict user guidance and high reusability.
No comments:
Post a Comment