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.