Developing Modern Browser-Based User Experience (UX)
Temenos Senior Product Manager, Simon File, discusses the evolution of browser-based custom elements, the challenges associated with continuous improvement and how to mitigate risk in the ever-changing world of UX.
As a developer with over 35 years’ experience, what changes have you noticed in UX?
There’s a saying about the only constant in life being change. UX is no different; it’s always evolving. And while there are obvious benefits to continuous improvement, you can’t have yin without the yang?
Are you referring to negative aspects of technological advancement?
Yes. Over the years, I’ve seen the world of UX reinvent itself repeatedly. We develop applications using the latest technology only to replace them almost immediately with bigger, better, faster solutions like Apache Struts, Turbine, Java Sever Faces, and GWT. And now we have Angular, REACT, Vue, and many more. New generations of developers arrive and conceive of the next UX framework technology. Architects extol the virtues of these, and we create a new wave of applications – and so it continues.
Surely, striving to improve UX is a good thing?
Yes, but there’s a flipside: a graveyard of apps in old technologies builds up over time, and it becomes harder to find skilled staff to maintain them. And all the while, developers are doing what they’re trained to do, chasing the next best thing – the latest technological developments.
Is this simply the price of progress?
For one-off projects, this might be a justifiable cost, but for software product development, technology churn is a massive problem. The cost of rewriting a whole product in a new technology is enormous. The regression implications are huge. How do you manage a complete rewrite? You would end up with parallel versions; bugs would need fixing in two places. Sales prospects would delay purchasing because they’re waiting for the latest version. Even if you manage to deliver a bug-free replacement, you’re then faced with maintaining two versions in different technologies.
“A graveyard of apps in old technologies builds up over time, and it becomes harder to find skilled staff to maintain them.”
Also, prospects may have a particular preference for certain web development technology. They might prefer REACT to Angular because their own dev team uses it, and they’re the ones who are expected to customize the product.
How do you improve UX while mitigating risk?
There’s no easy answer. Keeping software products up to date is essential. The key is to minimize fallout, and not put off a significant proportion of the market, like Angular or REACT.
Can this be achieved in a progressive manner, avoiding the complete rewrite scenario, and can multiple products from different platform technologies actually share components?
Yes. Any solution would obviously have to be user friendly plus easily digestible by as many web toolkits and platforms as possible. You’re looking for a universal language or the lowest common denominator across all the various web development platforms.
“Keeping software products up to date is essential. The key is to minimize fallout, and not put off a significant proportion of the market...”
What’s the Temenos Solution?
Unified UX or UUX. It’s a library of Web Components we’ve developed to help partners build web applications with Temenos APIs. We’ve developed them in Typescript using Google's Lit library. We also extend many of the Google Material Web Components to leverage existing functionality. You can find out more at Unified UX.
What are Web Components?
What about older versions?
These are supported using extra code.
Which web development platforms and toolkits are compatible with Web Components?
Almost all of them, which is why many leading software companies are using them, including:
- Adobe Spectrum Web Components
- IBM Carbon Web Components
- Salesforce Lightning Web Components
- Red Hat One Platform Components
- VM Clarity Core
- Oracle JET Web Components
How easy is it to get started with Web Components?
Very. And there are plenty of excellent tutorials online. The development tools needed are industry standard – and free.
Describe a typical Web Components learning schedule for a developer
- Follow a custom element tutorial like Using Custom Elements – about two hours.
- Complete a Lit Tutorial – about four hours.
- Learn Typescript – basics Typescript Tutorial – about one week.
When using Web Components, what are the main design considerations?
It depends on what you’re trying to achieve. Should they be a library of fancy widgets like an amazing date picker, a specialist input field, or a large-grained business component with many fields?
Also, it depends how much you want to re-use. If you’re aiming at a large-grained business component, should the design expect the containing application to source the data and then push it into the web component, which then displays it? Or should it just provide an API location and the component invoke the API itself?
Are there disadvantages to using UX or Web Components?
All technical architecture decisions are compromises, and Web Components are no different. Many developers and industry leaders like IBM, Oracle, SAP, and Salesforce believe advantages outweigh any concerns.
There’s plenty to read online, but a good place to start is developer Émile Perron’s: Web components in 2021: the Good, the Bad and the Ugly.