Expression editor in watsonx Orchestrate
Visual + interaction design
Automation / AI solution developers were being forced to use a legacy, proprietary language when coding in watsonx Orchestrate. It was time to transition to a more developer-friendly language, and with it, a redesign of the expression editing experience.
Role
Sole designer
Status
Delivered
2 months
Timeframe
01 Business context
Business Action Language (BAL) is a language built for rules engines (software that help businesses define and automate the logic behind their business processes like IBM ODM and IBM Automation Decision Services).
watsonx Orchestrate adopted BAL as its expression language when it absorbed some of the technology in IBM Automation Decision Services (ADS), but there were issues with this decision that warranted change.
Persona Discrepancy
The persona for ADS was a business analyst, so the product and the BAL language worked well for someone who might not be familiar with coding. However, watsonx Orchestrate is a platform for developers, and BAL wouldn’t meet developers’ expectations of modern coding languages.
Steep Learning curve
Most developers can pick up another coding language pretty quickly but not BAL. Since BAL was developed in-house and was meant for non-technical users, it had a steep learning curve and our users were frustrated. They wanted a language and experience that wouldn’t require poring over documentation.
Too verbose
BAL is very verbose. The language reads very close to natural language, and developers trying to write expressions to transform data quickly are not trying to write full sentences. Our users complained that BAL was too wordy and were asking for options to code in a language with syntax and paradigms that were closer to common coding languages like Python.
Market fit
Most competitors were either adopting common languages like Python into their platform and/or were providing comprehensive in-product editing experiences that helped and guided users as they tried to write expressions/code. We weren’t doing that and definitely needed to start.
02 As is
The language
Take a look at the expression written here. The syntax makes this code read almost like a sentence.
While this might work for a non-technical user, it would definitely be frustrating for an experienced developer to learn the rules of this language just to do something simple that they’d know how to do without documentation in a more common coding language.
The experience
The experience isn’t terrible, but it isn’t great either. It looks and feels like the type-ahead experience of an IDE, but worse — less organized, less visual guidance.
watsonx Orchestrate isn’t an IDE, though. It’s a modern low-code automation and AI platform, so the experience should look and feel like that!
03 Iterations
Our product team decided to go forward with JSONata as the coding language that watsonx Orchestrate would use across the platform. As JSONata uses syntax, semantics, and paradigms common to other programming languages, I had to design an expression editing type-ahead experience that aligned with developers’ expectations, matched the low-code positioning of watsonx Orchestrate, and was still efficient and helpful for users.
This expression editor component had to do a few things — whenever a developer has to pass a value into a parameter, they need to be able to:
Pass in a literal value
Pass in a variable from the larger scope
Pass in an expression with a combination of functions, literal values, and variables
UX iterations
How do I show functions and variables together? Do I preserve the structure of complex variables in the editor? Do I preserve it with type ahead? How can I show a function’s documentation?
What happens when the user starts typing? Do we show them only exact text matches (top left)? Do we search within complex variables for child variables with an exact text match (bottom)? Which type-ahead functionality is feasible?
Maybe I have separate “modes” of the component, a “function mode” (left) and a “variable picker” mode (right).
Microinteractions
After showing some iterations with stakeholders and evaluating existing functionality, we solidified some interaction decisions and started thinking through microinteractions.
Maybe we could use key characters to trigger the two modes.
Once a mode is entered, a user’s typing would search for matches. Only in variable mode would we search along the structure of a complex variable.
Default type ahead behavior would search for functions and variables at the top level, but would not search along complex variable structures. Dot notation would be a trigger for the expression editor to search one level deeper into a complex variable if applicable.
04 Deliverable
I made some more decisions on microinteractions with product management and development, got some opinions on visual styling from our team’s visual designer, and started working on a final deliverable. Take a look at the prototype below to see the visuals, interactions, and microinteractions in action!
The expression editor component I designed aligns with expected behaviors and micro interactions that developers expect when working with modern programming languages. It’s dynamic, context-aware, and keeps up with a user’s interactions.
A good example is the documentation changing depending on the location of the user’s cursor. In the prototype above, the user is working in the “average()” function. While the cursor is within the parentheses of the “average()” function, the corresponding documentation appears. When the cursor is within a nested function, “add(),” the documentation changes accordingly.
Overall, this deliverable was about the details. The visual cues to the user, the micro interactions that correspond with the user’s clicks and keyboard gestures — it’s the small things that make this expression editing experience look and feel modern, efficient, and up to par with what developers expect.
Evolution
In an effort to further modernize watsonx Orchestrate, the product is evolving its editor / canvas experiences with more modern patterns and modalities, including inline editing. I recently started to evolve the visuals and modality of the expression editor component so that it could be triggered inline from anywhere. It’s evolved to be functionally modular, feel lightweight, but still preserve the functionality defined in the deliverable above. This is still a work in progress.
