During the development of my eaForms Add-In one of the biggest challenges has been a UI model that is both intuitive and helpful for the eaForms designer. The difficulty with getting it right was brought home with the release of the early access trial, and the feedback I have received from those who were completely new to the product.
I knew when I set off that the UI would be an issue. I’ve seen so many products where the UI just doesn’t work. I’m not saying that the UI’s were wrong but when presenting potentially complex ideas it’s not easy, users are different, have different backgrounds and have different expectations.
I am often been reminded that the aim in developing products is to present the information, however complex the concepts, in the least astonishing way which I interpret as meaning:
- It is natural for the individual user
- It doesn’t make invalid assumptions
- It helps the user understand the concepts used
We know that users are different so that’s the first hurdle. So my approach follows the principles of trying to
- use clear symbols
- have short, structured menus
- validate essential data – at least help the users get it right
- minimise the clicks needed to perform actions
- maintain a context to helps users understand where they are, how they got there
With eaForms I thought a valid assumption was that the user had some degree of knowledge of EA.
My first UI was based on a class simple EA diagram – here is the screen shot for a Use Case form:
Each element placed on the diagram had attributes that defining properties such as the source of information or action required that would be used to defined the run-time editor. Using the EA diagram and drawing tools to define the size and layout of the items. It worked however,it relied on knowledge and some discipline to ensure the integrity of the elements and their attributes. And so making these assumptions could easily lead to failure as the user could enter information that would result in a form that wasn’t quite as they intended.
The second UI model took a wizard like approach taking the user through the different steps of the process, and as they added items to the form, present them with a dialog which collected and to some extent validated their inputs. It address the issue with getting valid data but failed in that it added unnecessary complexity as well as moving away from familiarity of EA. So what next.
The third UI – well I took a long look at what I could assume about users. And in the end concluded that I should as far as possible should stay with the EA UI model as far possible. Hence, I produced a eaForms toolbox and diagrams. Users can create an eaForms diagram and drag and drop items onto a diagram as they do for all other frameworks. Of course, I needed to ensure the integrity of the design so:
- Created an eaForms diagram that only understand eaForms items – thus minimises the risk of odd items being placed on the diagram, and subsequently ignored.
- Created an eaForms toolbox with the valid items (called controls within the Windows and eaForms worlds) that could be added to an eaForm.
- When eaForms controls are added the user is prompted for information that is relevant to the control – thus try to minimise errors and subsequent surprises.
So the current trial version uses this approach. The screen shot displays a Use Case design.
There are some changes in look and feel but not that significant. And the core underlying data structures and form generation have remained the same, allbeit with some additional gadgets thrown in.
Well immediate feedback was that this diagram didn’t look like the run-time editor form I am expecting. So is my assumption about following the EA diagram approach the best strategy.
Would designers rather have a full WYSIWYG designer?
And then when they come to edit the detail for any item using a double-click and item they are presented with a suitable editor.
Is this too complex?
Will the designer have enough understanding of what they have on the form and the detail they may wish to change. Is that valid?
It does come back to the knowledge the user has before they start to use the tool. Will they be astonished by the information that is presented to them. Are the concepts all familiar? Do they see what they expect?
Now of course, most of my trial users have had no training for eaForms, and although I provided a few videos (https://www.youtube.com/user/eaforms) – they are not 2-way and leave questions unanswered.
So some of my early learnings have been that users may have seen the output of eaForms – as this screenshot below, and expect that they will see this as they construct the form in real-time. Well that’s perfectly valid – and raises the question of how I evolve the UI.
It starts to bring me full circle to the points made earlier about what users know and expect. And as with all complex software – what training and support are needed?
How many people started using, and continue to use, EA without ever having some EA training? I haven’t – I’ve learnt on the job. And with such a complex and diverse product we know the documentation doesn’t answer all the questions, but fortunately we seem to survive, not least because there are very active user forums.
So have lots of questions for which I don’t have the answers:
- Is it reasonable to ask users to spend 10-15 mins watching a short video before using a product?
- Does the software need to provide more “intelligent” guidance?
- For a UI product is WYSIWYG essential?
- Do you dumb down a the basic version of the product to make it easier to use, restricting access and potential confusion of some more advanced, and useful features?
- What, if any, examples should be provided?
If you want to provide feedback on these and other aspects of eaForms do check out the eaForms early access trial – I’m keen to get more feedback.
I’ll end this post at this point with the feeling that there is more that can always be done to improve the UI – and hoping that the feedback over coming weeks provides the inputs I need – and with the final song from the musical Oliver playing in my head – “I’m Reviewing the Situation” – I’ll press publish.