Monthly Archives: December 2013

Deciding on yet another UI model – it’s not obvious!

A few weeks ago I wrote about the UI for my eaForms AddIn.   As I said then I had tried various different option, all trying to stay close to what I think of as the “EA approach” which lead to the use of a special diagram type with an associated MDG toolbox.  The argument for this model was the idea of maintaining a UI that would familiar to existing EA users and not confuse them with a new approach. 

Sorted – I made my early access trial version available – and wait for feedback.

I got feedback about little bugs, due to different environments which meant a few additional checks but the most surprising was the feedback which suggests I really need to have a WYSIWYG designer; the idea that an EA diagram can translate into a windows form doesn’t seem to click with all.  

Although my initial experiments used EA diagrams as the foundation it wasn’t the obvious solution.  It was the discussions with colleagues that convinced me to take the EA diagram route, not least due to implicit familiarity to EA users plus EA’s drawing tools.

From a technical standpoint trying to use an EA diagram as the template and create a diagram that accurately reflected the run-time form is a challenge, for which no easy solution exists as the AddIn’s don’t have access to the EA UI.  I suppose I could have started to use shape scripts to provide a better look and feel but …

And so I’ve added a WYSIWYG eaForm designer (now available in the trial download).  The great fact of this approach is that a lot of the code that is used to generate the run-time forms is also used in the eaForm Builder, and hence they should present in a vary similar manner.

Now that doesn’t mean the EA diagram approach is lost or does it? Not yet – both remain in the AddIn as Designer clients – and furthermore both coexist and can be used together if needed.  A designer can use the eaForms diagram or eaForms Builder and even switch between them as I keep the form data in sync.

With the multiple design client model the current AddIn is a toolset which has many options. Hence I’m now and looking to getting the feedback that helps me understand if I continue to provide these options or do I simplify and go back to a single WYSIWYG designer and pull out all the other code?

Of course, if I’d settled on the WYSIWYG model in the first place the design and coding would have been much simpler, however the approach I have taken means I’ve a more flexible model which has potential for expansion beyond the current form designer requirements, and of course in the process I’ve enjoyed learnt more about EA:-

  •  developed MDG’ using the new wizard – really worth the effort but will take days to get to grips with
  •  discovered lots more of the EA-AddIn model and used virtually all of the EA AddIn broadcast events
  • developed a flexible architecture that caters for design functions within EA and the generation of windows code
  • found some “really not so nice” bits of EA
  • produced a range of workaround to compensate for either a lack of capability within EA or a lack of documentation which often leads me to “play safe”

So what next – more coding to enhance this new Form Builder – whilst waiting for feedback that will help me decide on what is and isn’t useful for future versions.  (I’ve already got lots of ideas but as a tools developer rather than a full time EA user these days I could easily build a tool that just isn’t needed!)

Developing this AddIn has been a great experience, and, although the time taken could be seen as frustrating, it probably means that I’ve thought more about the product. All in all better all round.

With this post I’ll wish you all the best as we move into 2014 for another year of exploringEA.



EA automation with Java – part1

I was asked a question the other day about using Java with EA and admitted I didn’t know all the answer.  It’s been a long time since I developed in Java, not through choice, but as customers wanted something else.  So I was inspired to have a look a quick look at what is possible, not least as I like to check things out, and feel comfortable that whatever information I provide has some background.

Now it must have been about 10 years ago that I used Java, so the first task was to get the relevant tools.  Clearly all changed – so a quick check and seemed like I should give eclipse a go as it appears to be a major player – and hopefully as easy to use as previous tools.

So armed with enthusiasm for my new experiment I downloaded eclipse and within an hour or so (time flies when having fun) I had installed a new JDK and IDE application and was able to run the Java code samples provided by Sparx.  Just got that glow when things go right.

Just in case you want to do the same, here are the steps I went through:

  • Download and install Java JDK – (
  • Download and install eclipse – I installed eclipse standard
  • Copy the EA Java code samples from under the Sparx EA installed directory to a suitable working location e.g. under the workspace configured as part of the first time run of eclipse.  I spent 30 mins with the eclipse getting started tutorial as it was completely new to me and was really worth while to get to know the UI.
  • Create a new eclipse project for the sample; and Importantly set the references to the EA Java libraries (on my system C:\Program Files (x86)\Sparx Systems\EA\Java API) – the readme file describes what is needed.
  • Run project – with a few minor issues with ensuring package names were correct (eclipse clearly indicated the errors) – it all worked.
eclipse set up for EA examples

eclipse set up for EA examples

So the samples work but can I write some code.

In looking at the sample code, Sparx have set up a framework supports the running of their examples, so the obvious route was to add another example supporting the interfaces that has been defined. The process was to create a new example using an existing example as the template and:

  • create a new class
  • copy the key parts from and existing example; insure it implements IExample interface
  • edit the toString and getDescription methods
  • change the runExample method to perform the functions you require – add other methods/classes etc as needed

It took me a little while to become accustomed to the way eclipse works, especially the lack of auto-complete that is provided in VS – but apart from that it all worked fine as I incrementally built and tested my example app. No big problems or surprises for me.

So I had verified that I a Java client could work and I could add some of my own functionality – build block 1 done.  I did find that running the Java app appeared a lot slower than using other windows apps, but without delving deeper not sure if this is just eclipse or EA’s library or a combination associated with my environment  – so not judgement on this yet.

Having demonstrated to myself that the basics work I’m happy.  I know I can’t develop a Java Add-In as Sparx don’t support that (yet?) – but what about calling Java applications from EA? Does this work – are there other ways of interacting?  Can a Java applet access EA?

Well I’m off to do some more experimenting to see what can be done – and hope to report back soon.


Deciding on a UI model for an EA Add-In

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:

eaForms - early version of 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.

Current version of UC diagram

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.

Example of Control Definition 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 ( – 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.

The Use Case editor at runtime

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.