Managing Composed objects - admin workflows. Input appreciated . . .
Anyone got any opinions about good workflows to enable this? Lets take the events with multiple composed tickets (and I want to differentiate this from associated objects - such as where a product is associated to multiple categories but isn't composed within it).
Simplest solution is you go to the event manager, add new event, then go to the ticket manager and add ticket, selecting the appropriate event. This is very easy to implement in the general case but not very usable.
Maybe the next step up is at the bottom of the "add event" form to have two buttons - "add event" and "add ticket to event". The first will add the event and go back to the event list. The other will add the event and then display an "add ticket" form which will have two links at the bottom - one to "add ticket to event" and another to "add more tickets". First will add ticket and go back to either event list or event detail (displaying composed tickets as a master detail screen). The second will add the ticket and display another add ticket screen.
Another approach would be to ajaxify this a little bit. You could add a "add ticket" button with a pop up window for adding tickets right on the add event form, but then the question comes as to how you associate the tickets to the event if it hasn't been saved yet. Maybe the "add ticket" button both saves the event *and* displays the add ticket window?
The main issue that makes this complex is that in the general case sometimes you come across composed objects that in themselves have composed objects - n levels down. Lets say that you added a project, a project had composed teams, teams had composed events, and events had composed tickets. How do you provide a usable interface that allows you to easily add tickets to the events that you're adding to the teams that you're adding to the projects?! Obviously a bit of an edge case, but has anyone ever come across use cases where they had to step down multiple levels of composed objects in that way and what kind of UI did you find to be most usable?
Any input on good approaches to this problem appreciated.
Although I have to admit that I am not sure I understand the difference between the two by the way you've described them. But still, let's assume there x number of availble options to the event object. Does that help at all?
I don't have anything significantly valuable to add regarding the UI, other that it sounds like you need some sort of drill-down. It seem like I would have a tree representation in a left-hand pane and the current selected detail in the right hand pane.
Hmm . . .
For more levels of composed objects then the approach might be a hybrid of something like this plus the more conventional approach you described.
That is one approach I've been considering. Any idea whether it's possible to do that when some of the fields are date pickers, TnyMCE WYSIWYG editors, etc? That was my only concern - whether I could js those in or not . . .
Another approach to the UI is to consider usage - a long winded wizard (Spectra PLP anybody?) is bearable as long as you give the users the ability to clone their parent objects (i.e. this is the same event as last year, just change the venue and the date and lower the cost...)
Again, linear workflows, although unappealing to us RIA nerds can appear easier to the user, especially if they map an offline process.You can avoid page reloading with tabpanels / accordians too.
Getting the basics right is also important - plenty of help/tooltips, clear navigation and explanations of what they have done and what they can do next and where they are going, and the ability to back out of a process etc.
In some ways it's like code, simply implement and refactor, whilst looking to avoid repetition (i.e. repetitive tasks). If you want to be clever you try some kind of code completion style interface like developers are used to, where you try and guess what the user is going to do next.
Phew. My 2c anyway.
Peter