1 Reply Latest reply on Sep 10, 2007 10:32 PM by stu2

    Usefulness of Conversations?

    delphi'sghost

      First off, this isn't against Seam, or any implemented feature in seam, just some general thoughts on the usefulness of conversations in real world environments. In particular, I'm thinking of some of the aspects that Seam gives us such as the non-modality of conversations (open in new window/tab) versus the constrained application which forces you to work modally, and all in the same window by using buttons instead of links.

      Many of these issues address concepts that we as developers should, or should not allow in applications. The users can only screw up if we give them the means to, well, ok, I'm sure they can, but you know what I mean. Usually, when I'm developing an app, I'm thinking about how a user will use something, and how many helpdesk calls it's going to end up generating.


      1) Multiple conversations - since we are going to end up with users who click to edit the same thing a couple times, we are going to end up with multiple conversations of the same thing. This means storing the same data a couple of times over. This can be addressed using business conversation Ids, which has its own problems as mentioned later. Also, when they are editing the same widget twice in separate windows in the middle of a bunch of other windows, it is not hard to imagine they will edit the widget, save it, come across the other window, possibly make further edits, and save it. Versioning will prevent the second save as it should, but it doesn't strike me as a great user experience when the user can get bogged down in so many windows, they don't know which they have already saved, and which are redundant.

      2) Workspaces - The idea of workspaces is nice, except that again, it is flawed by how the user will end up using them. The notion of a workspace implies that you can start one thing, then go off and do another, and come back to what you started. As conversations have a finite lifespan, they will see their workspaces disappear over time as they time out. Users often get fussy if we don't ask them to confirm that they want to cancel their changes if they actually click the cancel button. They'll have a fit if they start silently losing changes in the background as conversations time-out.

      3) Conversation Business Ids - Conversation Business Ids are great in the way that they reduce the number of conversations by forcing unique conversations based on the business id. You can't edit an object more than once, and if you try, the old conversation will resume. Again, this is flawed by the chance that the user will end up with two windows editing the same conversation. Additionally, conversation Ids can get sticky when creating a new object, since it doesn't have an Id at the creation time unless you save it. By saving the widget, to get an Id, you put the widget in the pool of widgets, so you can go to the widget list page, and see your new widget that you havent' yet saved. Furthermore, you need to put in additional code to handle the removal of new widgets if changes are cancelled, or the conversation times out without the widget being saved.

      4) Benefits of modality - I know there are plenty of reasons to object to modality, but at the same time, modality keeps order. We are considering introducing more modality, or at least not letting the user go off and do anything else in the application from every other single point in the application. Modality also gives you a cleaner conversation demarcation since if you must leave one page to get to the next, then you know whether the previous page must keep its conversation or not. Alternatively, if the user can open the next page in a new window, the previous page could still be active in the old window, and therefore the conversation must carry on.

      I think conversations still have their place, but I'm starting to see more and more that it is about aiding the programmer with managing object lifetimes and function specific features such as wizards, rather than giving the user free reign to edit as many instances of objects at the same time as they want in a controlled manner. At the end of the day, Seam's conversation management can keep up with it all, but I doubt the users can.

      What say ye?

        • 1. Re: Usefulness of Conversations?
          stu2

           

          I'm starting to see more and more that it is about aiding the programmer with managing object lifetimes and function specific features such as wizards, rather than giving the user free reign to edit as many instances of objects at the same time as they want in a controlled manner


          That's what I find is valuable about conversations. Having a scope tied to a pageflow's lifetime is an elegant approach that avoids manual state management, and adds leak safeguards in the form of timeouts. The whole workspace/multiple windows thing is a side effect which may or may not be useful depending on how the UI is designed.