DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 4 FirstFirst 1234 LastLast
Results 16 to 30 of 59

Thread: Bad programming practice? Advice needed ...

  1. #16
    Mark Alexander Bertenshaw Guest

    Re: Bad programming practice? Advice needed ...


    "Michael Culley" <m_culley@hotmail.com> wrote:
    >> Yeah, well that is the way _you_ but are you sure that's the way your
    >> _customer_ sees it.

    >
    >Not just me, pretty much every user is used to a form asking them if they
    >would like to save changes. It really is the standard behaviour. I can
    >guarantee that if I changed this behaviour I would get more complaints than
    >I would gain happy customers.


    I can imagine that some users might think they had screwed up initially if
    that dialogue doesn't appear. However, you could put up a brief modeless
    dialogue saying "Saving..." for a couple of seconds, in an obvious, but not
    obscuring, location.

    >Providing some mechanism to reverse their changes would be complicated.


    Not really. Instead of committing the data to permanent storage, put the
    "invalid" storage on the local machine. That way, you haven't really changed
    anything.

    >Most likely they would not notice for a few days and have to go back
    >through some sort of 'autosave history' to undo their changes.


    Definitely not. Basically, you should have instances of that screen in "invalid
    storage", and mark them as such when the user gets back into the application
    e.g. "You are currently working on x screens that have not been committed",
    and make it easy to locate these pages. Of course, you will have to write
    more code to deal with situations where other users have potentially updated
    the record - but you already handle that, right?

    >You expect me to write code to keep this history for hundreds of possible
    >different forms? This is really going to make them much happier than
    >having to push yes or no to a messagebox.


    Not history - just unfinished screens. And it is not about showing a message
    box. It is about allowing a whole load more flexibility for the user.

    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Chordiant Software, Inc.
    Brentford
    UK

  2. #17
    Dean Earley Guest

    Re: Bad programming practice? Advice needed ...

    > If I can type crap into my Word
    > document, why can't I do the same in a database type application?


    Because to word, crap is perfectly valid data )

    --
    Dean Earley (dean.earley@icode.co.uk)
    Assistant Developer

    iCode Systems



  3. #18
    Jeff Pipes Guest

    Re: Bad programming practice? Advice needed ...


    You're advocating _changing_ the user's data _without_ their permission. That's
    bad ui design. Further, it is not standard behavior. The vast majority of
    applications prompt the user if they try to close a form or program without
    saving.

    -Jeff

    "Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote:
    >I find Amazon One-Click ordering no problem at all. I can go back and
    >cancel the order if I wish. Most of the time I don't unintentionally order
    >something.
    >
    >BTW, Brower based UI has the excuse that it's ability to deliver interaction
    >is steeped in the dark ages of batch based processing. So may be you're
    >right there. Let's just not kid ourselves into thinking that this is good
    >design.
    >
    >--
    >Anthony Jones
    >Nuesoft Ltd
    >
    >



  4. #19
    FrisbeeŽ, MCP Guest

    Re: Bad programming practice? Advice needed ...

    "Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote in message
    news:3c94f3b0@10.1.10.29...
    > Users very rarely make changes they don't intend to keep.


    I agree with this, however you should not exclude such a possibility, even
    if it is rare.

    > Better design is to assume that closing causes the changes to be saved.


    Never assume. I assume you mean (oops, I'm assuming) that by assuming
    something, you're not going to confirm that assumption with the user? Use
    assumptions (dang, got that word stuck in my head now) for defaults, but if
    you don't ask the user, you'll get some angry customers on the phone. Maybe
    99% of the time it's fine, but for that other 1%, which could amount to
    quite a few persons/circumstances, you're going to have some disgruntled
    end-users.


    --
    Bill Hileman, MCP, CPP, BCIP
    Programmer/Analyst, DASI

    Yahoo! Club for Certaholics
    http://clubs.yahoo.com/clubs/certaholics

    Computer Language Comparison
    http://www.boneville.net/programming/default.htm




  5. #20
    FrisbeeŽ, MCP Guest

    Re: Bad programming practice? Advice needed ...

    "Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote in message
    news:3c95a8df$1@10.1.10.29...
    > Yeah, well that is the way _you_ but are you sure that's the way your
    > _customer_ sees it.
    >
    > Self-referential design, 'I know what I would prefer', isn't necessarily
    > going to win the approval of your users.
    >
    > Also, as I said, you wouldn't just save without giving the users the tools
    > to recover from unwanted changes. However, you wouldn't make such tools
    > apart of the normal flow of interaction since normally they do want to

    keep
    > their changes.


    In the examples we are all using here, we are stating that the end-user has
    selected to close the form, and debating as to whether the changes should be
    automatically saved, or ask the end-user. A case can be made that you could
    avoid confusing the user and just save the changes, and provide "undo" type
    tools if they need it. I think the "undo" tools would be more complicated
    than asking the user in the first place.

    Since you can determine (generally) in the query_unload event why the form
    is being closed, there might be several options that need to be looked into.

    If the OS is closing the application, I think it should definitely ask the
    end-user about saving. The app might have been minimized and the user is
    shutting down the system, but forgot the app was even open. Granted, if the
    user selected a normal exit command button, or even the close window button
    in the title bar, you could pretty much assume that they meant to, but
    personally I think if they selected the close window button in the title bar
    as opposed to a more "normal" method of exiting the form, they are more than
    likely in panic mode, and DON'T want to save their changes. Rather than
    make that assumption, however, I will always ask. I don't think I've ever
    had an end-user complain to me because my application saved their butts when
    they exited but didn't mean to, and asked that annoying "are you sure" type
    question.

    Along that line, my query_unload event's message box is quite detailed in
    explanation. Don't you just love message boxes that say something like "Are
    you sure? Yes, No, Cancel" and don't explain the consequences of each of the
    three buttons? What's the difference between No and Cancel?

    In mine, I explain that the current modifications have not been save, and do
    you wish to save the changes. I then explain that selecting "Yes" will save
    the changes and continue exiting, "No" will discard the changes and continue
    exiting, and "Cancel" means "Oops, I didn't mean to exit, put me back in
    there"

    --
    Bill Hileman, MCP, CPP, BCIP
    Programmer/Analyst, DASI

    Yahoo! Club for Certaholics
    http://clubs.yahoo.com/clubs/certaholics

    Computer Language Comparison
    http://www.boneville.net/programming/default.htm




  6. #21
    Jeff Pipes Guest

    Re: Bad programming practice? Advice needed ...


    "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    >
    >Not really. Instead of committing the data to permanent storage, put the
    >"invalid" storage on the local machine. That way, you haven't really changed
    >anything.


    Depends what data you're saving. If it's a simple one record screen, mabye.
    But what about situations where you're talking about thousands and thousands
    of rows of data in multiple tables? Also, you're probably talking about a
    database redesign in many situations. And even then, when the user goes back
    to edit their data, you have to figure out if they want to edit their 'official'
    version of their data or the 'unsaved' version of their data. And how do
    you know which version the user wants? You're going to have to ask them,
    so you're still back to prompting them!

    -Jeff

  7. #22
    Jeff Pipes Guest

    Re: Bad programming practice? Advice needed ...


    "Michael Culley" <m_culley@hotmail.com> wrote:
    >
    >You expect me to write code to keep this history for hundreds of possible
    >different forms?


    Not only that, now you have to provide some sort of interface/screen/prompts
    for the user to go search through all those reams of data to find what they
    want. Sounds like this ends up creating _more_ work for the user, not less.

    -Jeff



  8. #23
    Jeff Pipes Guest

    Re: Bad programming practice? Advice needed ...


    "Bob Butler" <butlerbob@earthlink.net> wrote:
    >
    >It's also annoying when programs continually question the user. Do you

    want
    >to save? Do you want to exit? .... If I didn't want to I wouldn't have
    >clicked the *^%^&%&^ button!


    We're not talking about continually asking the user. We're talking about
    situations where the user has unsaved changes and closes the form without
    hitting the save or cancel button.

    -Jeff

  9. #24
    Anthony Jones Guest

    Re: Bad programming practice? Advice needed ...

    >>
    Not just me, pretty much every user is used to a form asking them if they
    would like to save changes.
    <<

    Only because they have been conditioned by existing software. A person new
    to using computers and completely ignorant of the difference between RAM and
    Disk would not expect this dialog.

    > It really is the standard behaviour.


    Doesn't make it right or good. It is behaviour which serves the limitations
    of the past.

    >>

    I can guarantee that if I changed this behaviour I would get more
    complaints than I would gain happy customers.
    <<

    In that case don't do it. :-)

    >Providing some mechanism to reverse their changes would be complicated.


    I didn't say it wasn't. In fact we have known for many years that there is
    a trade of between ease of use and development effort. I was pointing out
    what may be currently considered 'good programming practise' isn't
    necessarily good design.

    It's time to just pause and look at the our UIs in light of the power modern
    machines.

    >>

    Most likely they would not notice for a few days and have to go back through
    somesort of 'autosave history' to undo their changes. You expect me to write
    code to keep this history for hundreds of possible different forms?
    <<

    No. Design is something you do before you write any code. Trying to graft
    this one design change on to an existing product is probably not profitable.

    >>

    This is really going to make them much happier than having to push yes or no
    to a messagebox.
    <<

    How happy are they when they accidently press No instead of Yes? I have
    done it several times and it's never made me happy. Hey, but may be I'm
    being self-referential and that other users would be over the moon.

    --
    Anthony Jones
    Nuesoft Ltd



  10. #25
    Anthony Jones Guest

    Re: Bad programming practice? Advice needed ...

    >go search through all those reams of data to find what they want.

    What is it that you expect them to be searching for?

    --
    Anthony Jones
    Nuesoft Ltd



  11. #26
    Anthony Jones Guest

    Re: Bad programming practice? Advice needed ...

    Of course if you show the yes/no/cancel the user always chooses the right
    button. Their Yes always mean Yes and their No, No.

    Still if they do accidentally choose incorrectly then that's just tough on
    them. They were give their chance and they blew it. I'm mean, hey, why
    should the computer have to sort out the mess they have made. The computer
    thinks 'who do you think I am your slave?!'. Umm.... actually yes you
    are.

    --
    Anthony Jones
    Nuesoft Ltd



  12. #27
    Anthony Jones Guest

    Re: Bad programming practice? Advice needed ...

    >You're advocating _changing_ the user's data _without_ their permission

    Absolutely not! The user made the changes.
    --
    Anthony Jones
    Nuesoft Ltd



  13. #28
    dnagel Guest

    Re: Bad programming practice? Advice needed ...

    Even Miscrosoft has issues when dealing with this aspect of writing
    software.

    Look at Access. If you make a change to a value in a table and move off the
    line you're on or even to a diferent field, then that change is committed.
    They
    offer little in the way of undo ...

    Accidentally hit a key and close the table view or close Access all
    together,
    and your change is permanent without even knowing you did anything.

    Then look at notepad. Hit a key and click the X and it says, Hey, Wanna
    Save
    this?

    Now, Which behavior can be more damaging to your sanity?

    Some people LOVE the fact that Access just does what you tell it to, and
    some people curse them to the ends of the earth for it. But in order to
    solve the problem it's my estimation that one would have to design for
    both capabilities, and then offer preferences to the user as to how the
    app will behave.

    > I didn't say it wasn't. In fact we have known for many years that there

    is
    > a trade of between ease of use and development effort. I was pointing out
    > what may be currently considered 'good programming practise' isn't
    > necessarily good design.


    Trade off indeed... In order to write code that people like to use and will
    continue to use, you must write more code than just the data access layer
    and the business rules. The UI is an all too-important, all too-overlooked,
    and all too-oversimplified aspect of most applications.

    D.



    "Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote in message
    news:3c9608b5@10.1.10.29...
    > >>

    > Not just me, pretty much every user is used to a form asking them if they
    > would like to save changes.
    > <<
    >
    > Only because they have been conditioned by existing software. A person

    new
    > to using computers and completely ignorant of the difference between RAM

    and
    > Disk would not expect this dialog.
    >
    > > It really is the standard behaviour.

    >
    > Doesn't make it right or good. It is behaviour which serves the

    limitations
    > of the past.
    >
    > >>

    > I can guarantee that if I changed this behaviour I would get more
    > complaints than I would gain happy customers.
    > <<
    >
    > In that case don't do it. :-)
    >
    > >Providing some mechanism to reverse their changes would be complicated.

    >
    > I didn't say it wasn't. In fact we have known for many years that there

    is
    > a trade of between ease of use and development effort. I was pointing out
    > what may be currently considered 'good programming practise' isn't
    > necessarily good design.
    >
    > It's time to just pause and look at the our UIs in light of the power

    modern
    > machines.
    >
    > >>

    > Most likely they would not notice for a few days and have to go back

    through
    > somesort of 'autosave history' to undo their changes. You expect me to

    write
    > code to keep this history for hundreds of possible different forms?
    > <<
    >
    > No. Design is something you do before you write any code. Trying to

    graft
    > this one design change on to an existing product is probably not

    profitable.
    >
    > >>

    > This is really going to make them much happier than having to push yes or

    no
    > to a messagebox.
    > <<
    >
    > How happy are they when they accidently press No instead of Yes? I have
    > done it several times and it's never made me happy. Hey, but may be I'm
    > being self-referential and that other users would be over the moon.
    >
    > --
    > Anthony Jones
    > Nuesoft Ltd
    >
    >




  14. #29
    Mark Alexander Bertenshaw Guest

    Re: Bad programming practice? Advice needed ...


    "Jeff Pipes" <JeffP622@msn.com> wrote in message
    news:3c95f829$1@10.1.10.29...
    >
    > "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    > >
    > >Not really. Instead of committing the data to permanent storage, put the
    > >"invalid" storage on the local machine. That way, you haven't really

    changed
    > >anything.

    >
    > Depends what data you're saving. If it's a simple one record screen,

    mabye.
    > But what about situations where you're talking about thousands and

    thousands
    > of rows of data in multiple tables? Also, you're probably talking about a
    > database redesign in many situations. And even then, when the user goes

    back
    > to edit their data, you have to figure out if they want to edit their

    'official'
    > version of their data or the 'unsaved' version of their data. And how do
    > you know which version the user wants? You're going to have to ask them,
    > so you're still back to prompting them!
    >
    > -Jeff


    Jeff -

    It's nothing to do with prompting them! It is to do with allowing the user
    to save partial or invalid data without this impacting on the rest of the
    application. And what's all this talk of thousands and thousands of rows of
    data? The user isn't going to input thousands of rows of invalid data.
    Instead, the user can have the ability, for instance, to go easy on a screen
    or two. It is quite possible that the user might have already spent time
    typing in a lot of data, only to realise there is some data missing. Whilst
    that user is waiting for the data, why shouldn't s/he be able to save that
    on which he has been spending 10 minutes?

    Here's two examples in my daily work of this principle working and not
    working:

    * Working: Outlook 2000.
    I can write an email, address it, but not send it. Instead, I can save it,
    and it goes into the Drafts folder. Later on, I can come back to my draft
    email, alter it, and send it.

    * Not working: MKS Track Integrity:
    Whilst I am working on a bug, I fill in a fairly large form in stages every
    ten minutes or so, but I can't save the data since then the record would go
    to Fix Applied, which would be invalid at that time. Therefore, I have to
    hope my machine doesn't crash until I have finished the bug.

    Note that this _does_ involve more programming. But in the final
    assessment, who are you programming for: yourself, or the user?

    And Jeff, I really wish you would read the post before commenting on it. I
    specifically said that this data would not go in the final storage (database
    or whatever), instead this would be saved to somewhere else (I was thinking
    along the lines of saving on the local machine as opposed to a remote
    database, but don't worry about specifics, I am deliberately generalising).

    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Chordiant Software, Inc.
    Brentford
    UK



  15. #30
    Mark Alexander Bertenshaw Guest

    Re: Bad programming practice? Advice needed ...


    "Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote in message
    news:3c9608b5@10.1.10.29...
    >
    > It's time to just pause and look at the our UIs in light of the power

    modern
    > machines.


    Absolutely right. It is amazing how little has changed in the last 10 years
    as regards usability, although those UIs sure look nice! Funny though, some
    people were thinking along the right lines ages ago. I wonder if anyone
    remembers "Geoworks" - a strange little windowing system that sat on top of
    DOS. Incredibly fast (worked on a 386SX40 absolutely fine). I played with
    this before I started playing with Windows, and many of its features were
    superior to Windows at the time. But the best one was that you could open
    several instances of the word processor, an instance of the calculator, and
    a couple of paint applications, close Geoworks, reopen it, and you'd find
    that the _entire_ desktop environment was saved, right down to caret
    positions and clipboard! I _dream_ of this ability in Windows - I work with
    about 20 application instances at any one time, and rebooting is a major
    pain. Sadly only the windows shell exhibits this behaviour. But one day
    .... one day ...

    > --
    > Anthony Jones
    > Nuesoft Ltd


    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Chordiant Software, Inc.
    Brentford
    UK



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center