[Admin: This content comes from the original mobile-friendly PDF.]
Introducing UX: Still confused or curious?
If you have any questions about UX that weren’t answered in this article, feel free to reach out to your IBM TRIRIGA representative or business partner. In the meantime, here are some more background questions and answers that might help to fill in the gaps or give you a better idea of what we’re trying to do. Or if you want, I’ll go ask Mike or Ryan.
|Why should we redesign our forms?||Current IBM initiatives emphasize SaaS and mobile, both of which require a simple and intuitive UX. But in today’s market, our existing form UI technology is becoming less nimble, and is designed for desktop, not mobile interfaces.
A new UX framework can enable you to more easily meet business requirements with an intuitive UI, compatibility with touch interfaces, and improved performance.
With this goal in mind, MVC is the most widely-used pattern for web development. So we’re adopting the MVC pattern for our TRIRIGA application-building framework.
|Why haven’t we made these improvements already?||Our existing platform metadata components — forms, workflows, business objects — are too coupled to each other. This makes it very difficult to make changes quickly. For example:
|What is MVC?||MVC is a programming pattern that consists of a model, view, and controller. This pattern allows applications to have multiple views that use the same data and business logic. In other words:
|What will the new MVC model look like?||You might be wondering if it’s enough to reuse business objects from Data Modeler as the model. Unfortunately, business objects are not flexible and would require complex data models to render a rich view.
Instead, the model could contain many data sources such as business objects, queries, and even integration data. In addition, the model could also contain “actions” that the user can perform via the controller. These actions could be imported from business objects and queries.
|What will the new MVC view look like?||The view could support many types of views such as a form view, mobile form view, and maybe even an API view and custom view.
The form view could be rendered from a flexible hierarchy of form-layout components that are sourced by the model. For example, a single field type could be included in several different components and have several different renderings. More complex components could include graphics components and custom components.
|How do we decouple the workflow logic from the view?||Our existing technology uses Modify Metadata tasks that couple our business logic to the view and make it difficult to make changes to the view without changing the logic.
Instead, to decouple the business logic from the view, we could restrict or remove our dependence on the Modify Metadata task. In its place, we could develop a variety of layout components, field elements, and action-button elements to render a dynamic view.
|How do we build applications in the new MVC framework?||While we can’t promise any specific dates, we plan to develop a new “model designer” or “model builder” metadata construct that supports the model.
Similarly, we plan to develop a new “view designer” or “view builder” metadata construct that supports the view.
Fortunately, we don’t need to develop a new metadata construct for the controller since existing workflows and state families can already serve this function.
Meanwhile, if we store the new platform metadata as records that can be accessed through forms, we can more quickly react to business requirements and add features.
|How do we simplify the interface or view?||Our existing technology ties forms to “things” like people and locations. So why not change the pattern so that views are tied to “actions” like creating and submitting requests?
This change could be accomplished by designing views that are specific to a user role. Then we could still reuse our existing business objects and workflows to support the new role-based interfaces.
|What happens to our existing applications?||Our existing applications and forms will continue to work as they did before MVC.
Unlike advanced integrations that require customization, the new renders will be “bolt-on” views that can be quickly added or removed, and will still use our existing application data and workflows.
|What happens to our existing user documentation?||Our existing documentation will continue to support our existing applications as they did before MVC.
But new MVC-based documentation could be rendered within the same flexible hierarchy of form-layout components as custom “info components”. Unlike HTML topics or PDF files in our external IBM Knowledge Center, this content could be accessed within the new framework.
|What happens to our existing customers?||Because the new views will be “bolt-on” interfaces that are “bolted onto” existing applications, customers who don’t choose the new MVC framework won’t be affected.
But for customers who choose the new framework, results could vary depending on how new role-based interfaces are applied and how much the application is customized.
Fortunately, a flexible MVC model would offer customers a more efficient customization and upgrade strategy. For example, customers could add their own business objects instead of adding fields to our shipped business objects. This scenario would be easier to track during upgrade.
My many thanks to Ryan Koppelman, Mike Herbert, Chris Jones, Raphael Marcondes, Tracy Fletcher, Casey Cantwell, Kenny To, and the rest of the IBM TRIRIGA software team for their valuable source material, feedback, and insights. The finer details of this article are subject to change. Also, my views don’t necessarily reflect those of the team or IBM in general.
Jay Manaloto is an IBM TRIRIGA information developer. A technical writer since 1996, he enjoyed writing for TRIRIGA from 2005 until its acquisition by IBM in 2011. Now a member of the IBM TRIRIGA software team under the IBM Watson Internet of Things business unit in 2016, Jay also runs several blogs including TRIRIGAFEEDIA.