On Wed, Apr 9, 2008 at 8:51 PM, Jessica Enders <[EMAIL PROTECTED]> wrote:
> > Any opinions on when one approach should be used over the other and > whether the inconsistency matters? > Hi Jessica, I've done some work on an existing web-based product configurator that does something similar - you save your changes but intentionally commit later. Although this makes sense from an engineering perspective, this intentional commit has been the cause of some long-winded product support calls. The main problem turns out to be that the application's committed/uncommitted state is not clearly indicated. A secondary problem is that the importance of committing changes is not obvious. Application users go along happily thinking that they've done their thing then wonder why no changes have taken effect in the system. I'd recommend in this case that you bring the product support team a box of doughnuts and ask them to tell you the things they get lots of calls on. If they don't mention the commit problem outright, ask them if they ever get calls related to it. Alternately, if you're setup to do quickie usability tests for the application, grab a couple newbies and see what happens. >From my perspective, though, inconsistent save and commit behavior is more of a problem than a solution. Hope this helps, Michael Micheletti ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
