Committing changes to a database

9 Apr 2008 - 10:51pm
6 years ago
3 replies
348 reads
Formulate
2007

Hi everyone

I am currently reviewing a desktop (i.e. NOT web) application that
involves mostly viewing and changing records in a database (via a
nice GUI front end).

In some places, changes are "committed" as soon as you enter them, a
bit like how Microsoft Access operates. In other places, the user has
to specifically "save" to commit changes, like MYOB.

Any opinions on when one approach should be used over the other and
whether the inconsistency matters?

Thanks in anticipation,

Jessica Enders
Director
Formulate Information Design
----------------------------------------
http://formulate.com.au
----------------------------------------
Phone: (02) 6116 8765
Fax: (02) 8456 5916
PO Box 5108
Braddon ACT 2612
----------------------------------------

Comments

10 Apr 2008 - 11:10am
Michael Micheletti
2006

On Wed, Apr 9, 2008 at 8:51 PM, Jessica Enders <jessica at formulate.com.au>
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

11 Apr 2008 - 12:23am
Jarod Tang
2007

The important thing here, is what's user's mental model here, more or
less, he's like writing on the paper for fill a paper table, if write
down, it's/should there ( if he type in, it's there), so save in a
just-in-time way meet this very well.

And at the same time, let user could undo what he/her has done before,
this makes the application less scary.

If possible, i would like a software without open/save/save as, these
things just leads to confusing.

for more information, you could ref About Face X.X on Undo/redo topic
( i'm not the book seller)

Cheers
-- Jarod

On Fri, Apr 11, 2008 at 12:10 AM, Michael Micheletti
<michael.micheletti at gmail.com> wrote:
> On Wed, Apr 9, 2008 at 8:51 PM, Jessica Enders <jessica at formulate.com.au>
> 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 ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
Designing for better life style.

http://jarodtang.spaces.live.com/
http://jarodtang.blogspot.com

10 Apr 2008 - 11:36am
jabbett
2008

> In some places, changes are "committed" as soon as you enter them, a
> bit like how Microsoft Access operates. In other places, the user has
> to specifically "save" to commit changes, like MYOB.

The MYOB styles sounds like a case of the technology forcing the
interface into something unintuitive; that is, because the underlying
database uses transactions, with explicit commits, the UI also batches
user operations and requires explicit commits.

I sense that the emerging trend is to continuously store a user's
changes but make it very easy for him to "undo" if he makes a mistake.
The user doesn't need to think about saving or committing or being
careful about his actions -- the data is always safe, and there's always
a way out. From an implementation perspective, it's the hardest, but
from a usability perspective, it's ideal.

-Jonathan

Syndicate content Get the feed