My Vaadin application mostly provide configuration screens for the many entities which make up my company’s online game.
Most of the screens provide a single table containing a list of entities of a certain type, along with a NEW, EDIT and DELETE buttons.
Today, clicking on NEW opens up a Modal Window containing a UI-Form, OK and CANCEL buttons.
Clicking the Buttons close the Window, of course.
An alternative option is to have NEW change the view from “Customers Table” to “New Customer”. Clicking on OK/CANCEL buttons will change back to the “Table View”
I’m wondering which is best?
Did you find Vaadin more easy with either option?
I wish we could see more demos of applications using Vaadin.
Mostly those apps are not open-public.
It really depends on your users and the data which you want to present. Which option do you think your users would prefer/expect? Which method do they find “less confusing”? Large/small amount of fields?
There are lots of things to consider with modal windows.
They block other operations/data access
Multiple/stacking windows quickly becomes confusing
Singular point of focus/attention
Window placement/movement/size (what happens on browser resize?)
etc. There are lots of articles you can read on the usability of and alternatives to modal windows online.
On the other hand, if you change the view upon clicking “NEW”, will that confuse the user? Will he/she know where in the application she is? Is navigation locked? Will they know how to “go back”, and so on.
Every solution has drawbacks and positives. IMO, modal windows aren’t always horrible if kept in check and done with taste. Other possible solutions would be master-detail, “inline-editing” etc. Again, they all have their +'s and -'s.
Master-Detail (consisting of a table top or left, and a form for viewing/editing on the bottom or right), as mentioned above, is a popular pattern for this type of UI.
A SplitPanel could be used to allow the user to adjust the proportions of the two sides, if there is a need for that.
Since the item displayed in the form can be changed without closing the form, it is important to handle unsaved changes in a smart way, e.g. by displaying a dialog that asks if unsaved changes should be saved or discarded, if the user selects another item without explicitly saving the form firs.