Programming Aids
Easy to use MATLAB function signatures
Programming Aids is a feature that enables MATLAB users to write code efficiently without errors. I worked alongside back and front-end developers, Documentation specialists, UX Research and other designers to produce a high quality design.
Year
2018
Role
UI + Interaction Designer
Team
UX Researcher, Developer, Documentation, QE
Problem Definition
MATLAB is an un-typed language that is compiled at runtime. Despite the many customer requests for function specific syntax inline help, up until now MATLAB provided very little guidance on this matter. MATLAB’s loose syntax was the biggest challenge and the main reason why MATLAB didn’t have suggestions for the arguments of a function.
Users would have to access function documentation in order to correctly implement it and that is time consuming and represent a significant amount of context switching on their task and workflow.
Goal
Our team wanted to provide casual and advanced users a better coding experience by enabling function syntax suggestions in-place and at the right time hence removing most of the context switching that happens every time they need to access documentation. That would represent a great improvement on efficiency and overall performance and flow.
High-Level Requirements
- Be discoverable and show at the right time.
- Show both the full function signature and completion of the current parameter.
- Match the function signature to the user input
- Be efficient with screen real estate
Benchmarks
We analyzed several other products that provide similar functionalities, such as autocompletion and code aids, so we can have a better understanding of the trends and mental models that we could leverage on our design. Unfortunately, most of these products did not satisfy some of our requirements.
Sublime Text
Atom
IntelliJ IDEA
Visual Studio Code
Ideation and Iterations
Iteration 1
Our first approach consisted in displaying a list of all available syntaxes when the user types the open parenthesis. When the user starts typing the first argument, the popup filters possible values.
While this design would satisfy some requirements the biggest problem was that it was failing to allow users to change signature while the popup was visible. Early tests also showed that in case of more complex signatures the design would not be efficient in terms of real estate.
Iteration 2
When observing the results of the first design I had the idea of creating a different visual representation of the signature. Instead of displaying a vertical list with repeating arguments, could we display all possible arguments horizontally? This became the “Pill Design”.
This was a very promising design as each “pill” represented one argument and combined pills represented name/vaule pairs. We then created a set of visual cues to indicate completion and a notion of past and present. Gray pills were already inserted arguments and blue are the current possible arguments. The dashed border pills represented optional arguments.
While this design worked very efficiently for certain functions, it was failing to provide a useful solution when we had to deal with alternative arguments. Because MATLAB code is computed only at runtime the program couldn’t identify variables’ data types and therefore could not filter the signatures accordingly.
To display the alternative arguments, we introduced the “|” character to separate possible alternatives.
This design turned out to be extremely hard to reason. Our tests showed us that users were confused with the repetition of arguments and was leading them to false assumptions. Complex signatures were hard to use, introduced a fair amount of cognitive load and we saw a clear challenge in addressing horizontal real estate.
We decided to add two additional requirements and went back to the drawing board:
While this design worked very efficiently for certain functions, it was failing to provide a useful solution when we had to deal with alternative arguments. Because MATLAB code is computed only at runtime the program couldn’t identify variables’ data types and therefore could not filter the signatures accordingly.
To display the alternative arguments, we introduced the “|” character to separate possible alternatives.
High-Level Requirements
-
- Be discoverable and show at the right time.
- Show both the full function signature and completion of the current parameter.
- Match the function signature to the user input
- Be efficient with screen real estate
- Be accurate, yet concise.
- Do not overwhelm the user with too much or obscure information
Iteration 3
In order to satisfy these new requirements and to reduce complexity, we decided to go back to showing only one valid signature at a time. We used statistical data usage insights to display the most frequently used signature while providing a way to access alternative signatures (pressing the down arrow on the right).
The design improved substantially, but two issues kept surfacing during usability testing:
- Discoverability rate of alternative syntaxes was not satisfactory
- This visual representation was unfamiliar and differed too much from how documentation depicts code in the editor.
So, once more we added another new requirement:
High-Level Requirements
-
- Be discoverable and show at the right time.
- Show both the full function signature and completion of the current parameter.
- Match the function signature to the user input
- Be efficient with screen real estate
- Be accurate, yet concise.
- Do not overwhelm the user with too much or obscure information
- Represent syntax in a way similar to documentation and use common conventions to represent function signatures
Iteration 4
In our Fourth and Final iteration we updated the display to use a more familiar representation as well as introduced visual affordances to help with some of the observed discoverability issues:
- Reverted to a traditional comma-separated list
- Displayed the values for the current parameter in a separate list
- Displayed “1 of N” right before the dropdown icon
