Back to it – and hasn’t it flown since the summer!

I’m still here, but after a summer taking it easy and spending more time than planned doing some rework on eaForms, it was all too soon back to some real world projects, helping others, which have kept me busy, and hence this meant I haven’t had too much time to be exploring EA.

It seems that after summer there is renewed energy and an eagerness to get stuff done.  I can’t complain it can be really exciting but of course before you know it it’s Christmas; already in the UK we are seeing Christmas goods in the shops and it’s not the end of October year! This also means a new deadline appears – must be done before the holiday season.  I am sure it was never like this when I was younger, but I suspect that is the view through rose tinted glasses.

However, the eaForms rework was really good fun – not that I always enjoy refactoring code, but after a few years it was good to go back to the design, and with the knowledge gained from use and customer feedback we have been able to streamline some of the internals.

It was also the chance to clean out some deadwood.  For those who may have seen eaForms a couple of years ago, the initial design used an EA diagram for the form design and keep everything within EA (see example of our initial design), it was fun (especially some of the synchronisation needed), but it didn’t give users the near WYSIWYG experience expected.

Use Case form defined in EA diagram

Use Case form defined in EA diagram – as it used to be done – now we have a WYSIWYG form builder

Removing the need to support this functionality really did help with the rework – it simplified an awful lot and allowed eaForms to become more decoupled from EA in a positive way.

This work reminded me of the many projects over the years where I had written code to fulfil requirements for functionality that was really never used.  In our case, we thought it was cool to use an EA diagram, but users didn’t!  It’s all too easy to add a requirement because it seems like a good idea but really isn’t of value to the customers, however without a crystal ball there is no easy answer.  I’ve worked in organisations who do lots of research when defining products, and I’ve seen that doesn’t guarantee success.

Apart form doing work on the internals of eaForms we added some more features to meet customer needs, notably:

  • Datagrid control – which presents collections in a flexible table format with display, editing and adding capabilities.
  • More script capabilities have been added, for example running a script on form load (so checks can be made before the user even sees the form)
  • Workflow / “Wizard” like functionality allowing the editing to be split across multiple eaForms sequenced with a defined workflow.

For those who may be interested, I’ll put together some short posts on some of these new features in the next few weeks, but if you eager to have a look today you can pop over to eaWorkplace and simply register with them to download a trial version.

It also worth noting that all of these were added to meet incoming requirements, for which I’m always thankful, as it also indicates that there is a need for eaForms.  And of course far better than me trying to double guess what users really need.

If your an eaForms user, and eaForms doesn’t do what you want, let me know – no guarantees we can do it but unless we know we can’t even try!

Be back soon