DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 14 of 14

Thread: Auto Save or Not?

  1. #1
    Andrew Merisanu Guest

    Auto Save or Not?

    Hello,

    I'm looking for input regarding the way changes made by a user on an edit
    screen should be saved.
    The traditional way is to have a save and cancel button which the user
    clicks when they are done making changes. I feel this approach is somewhat
    insulting as it assumes that the user is usually making a mistake by
    changing the data. I would like to have the changes saved automatically when
    they move to another record or screen, and have only a cancel button which
    the user can click to cancel any changes they made. The fields that are
    changed will have a different color or be bolded (I haven't decided which).

    My coworkers feel this would be a bad approach.

    What do you think? Any ideas or feed back would be greatly appreciated as
    this is a very important design decision.

    TIA

    Andrew Merisanu
    Development Manager
    Courier Complete Inc.



  2. #2
    Bruno Paris Guest

    Re: Auto Save or Not?

    Hi, Andrew
    I am not UI expert, but I can describe what I use.

    >changes saved automatically when they move to another record ...


    Yes. Save when another record is selected in a List (listbox,
    listview, treeview), or even when selection changes.

    But leave both Save & Cancel buttons. Why?
    Because user can press Enter (Save button has Default=True)
    - record is saved, and focus goes to List
    Without Save, user would have to click in the list to move to next
    record, or press Tab more than once to reach List.


    >changes saved automatically when they move to another ... screen


    If move is done by pressing x button on the titlebar (or Alt+F4),
    it always means cancel.

    If move is done by menu/toolbar selection, or by pressing Close,
    Back or Forward buttons, it depends on global variable
    g.ConfirmChanges

    That variable is Off by default, meaning app doesn't ask "Save
    Changes?" question. This can be a bit surprising for users at
    start, so there is also a sound effect when record is saved.


    >The fields that are changed will have a different color or be

    bolded (I haven't decided which).

    For changes, I change Forecolor to dark blue or to system
    Highlight color, for errors Forecolor is red.
    (except for Memo and Binary fields, which don't have that
    'feature')


    Bruno




  3. #3
    Christopher Thomas McGinlay Guest

    Re: Auto Save or Not?

    Hi,

    Perhaps your co-workers are anxious to maintain the integrity of your
    data source. How about using a transaction file to record proposed
    changes during a user's session, where you then batch process all the
    changes onto your master file later?

    I hope I'm on 'your wavelength' here; the only way to be *pretty *****
    sure that a user's changes are what they want is to use double entry
    verification.

    Personally, for a DB, 'no save' instant updates either to a master or
    transaction file is what I have seen most often.

    If your data source is to be accessed by multiple users and it is
    important that it be up-to-date, then perhaps you can't afford the lag
    of a transaction file. Could also have a nasty situation where, for
    example, user Bob deletes record #12, whilst user Florence amends a
    field of record #12 - how to resolve this conflict in two transaction files?

    The last financial institution I worked for had a multi-user shares
    database, using transaction files and double entry verification.
    Further, if Bob entered a batch of data, then Florence would have to
    re-enter the same batch before it would be added even to the transaction
    file (Bob could not verify data which he had entered)
    HTH

    Chris

    Andrew Merisanu wrote:

    > Hello,
    >
    > I'm looking for input regarding the way changes made by a user on an edit
    > screen should be saved.
    > The traditional way is to have a save and cancel button which the user
    > clicks when they are done making changes. I feel this approach is somewhat
    > insulting as it assumes that the user is usually making a mistake by
    > changing the data. I would like to have the changes saved automatically when
    > they move to another record or screen, and have only a cancel button which
    > the user can click to cancel any changes they made. The fields that are
    > changed will have a different color or be bolded (I haven't decided which).
    >
    > My coworkers feel this would be a bad approach.
    >
    > What do you think? Any ideas or feed back would be greatly appreciated as
    > this is a very important design decision.
    >
    > TIA
    >
    > Andrew Merisanu
    > Development Manager
    > Courier Complete Inc.



    --
    Ascent Software Limited Registered in Scotland: SC201671
    www.ascent.zetnet.co.uk Bank Of Scotland Buildings
    Lerwick, Shetland, ZE1 0EB


  4. #4
    Willy Van den Driessche Guest

    Re: Auto Save or Not?

    I'm all for autosave, as long as your provide an "undo" with it.
    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html



  5. #5
    Andrew Merisanu Guest

    Re: Auto Save or Not?

    Thank you all for your feedback.
    It has given me some things to consider as well as encouragment in knowing
    I'm not a complete idiot for even proposing it.

    Thanks,

    Andrew



  6. #6
    Brad Siemens Guest

    Re: Auto Save or Not?

    My approach is to offer the users both. If they want the record saved on
    transition or if they want the changes discarded a simple option setting
    should take care of it. A heads up on the edit form should indicate (In no
    un-certain terms) what mode the form is in.

    IMNSHO

    Brad

    "Andrew Merisanu" <andrewm@couriercomplete.com> wrote in message
    news:3c371bb9@147.208.176.211...
    > Hello,
    >
    > I'm looking for input regarding the way changes made by a user on an edit
    > screen should be saved.
    > The traditional way is to have a save and cancel button which the user
    > clicks when they are done making changes. I feel this approach is somewhat
    > insulting as it assumes that the user is usually making a mistake by
    > changing the data. I would like to have the changes saved automatically

    when
    > they move to another record or screen, and have only a cancel button which
    > the user can click to cancel any changes they made. The fields that are
    > changed will have a different color or be bolded (I haven't decided

    which).
    >
    > My coworkers feel this would be a bad approach.
    >
    > What do you think? Any ideas or feed back would be greatly appreciated as
    > this is a very important design decision.
    >
    > TIA
    >
    > Andrew Merisanu
    > Development Manager
    > Courier Complete Inc.
    >
    >




  7. #7
    Thomas Eyde Guest

    Re: Auto Save or Not?

    Did you ask a typical user of his/her opinion?

    /Thomas



  8. #8
    Andrew Merisanu Guest

    Re: Auto Save or Not?

    Hi Thomas,

    Our product is sold to many different companies. Although it's a vertical
    market, the users range from computer savy to computer illiterate. So asking
    the users is really not a usefull approach in this case.

    Thanks,

    Andrew

    "Thomas Eyde" <thomas.eyde@online.no> wrote in message
    news:3c3899f1$1@147.208.176.211...
    > Did you ask a typical user of his/her opinion?
    >
    > /Thomas
    >
    >




  9. #9
    Andrew Merisanu Guest

    Re: Auto Save or Not?

    Hi Brad,

    We have been considering such an approach, but we are concerned that these
    options will confuse the users. They tend to share workstations and they
    don't always log off the previous user so they may be expecting the screen
    to behave a certain way and it may not. The other issue is that most of our
    users seem to have problems reading messages and instructions unless they
    are in a big flashing message box.

    We have had our current version out for 2 years and over that time we have
    had many cases of users doing foolish things because they didn't read the
    messages. Our goal in developing our new version, apart from some features,
    is to make the product as usable as possible. (Our current version has many
    usabilty issues)

    We will consider your suggestion further though.

    Thanks,

    Andrew

    "Brad Siemens" <ebspc@sympatico.ca> wrote in message
    news:3c3891f6@147.208.176.211...
    > My approach is to offer the users both. If they want the record saved on
    > transition or if they want the changes discarded a simple option setting
    > should take care of it. A heads up on the edit form should indicate (In

    no
    > un-certain terms) what mode the form is in.
    >
    > IMNSHO
    >
    > Brad
    >
    > "Andrew Merisanu" <andrewm@couriercomplete.com> wrote in message
    > news:3c371bb9@147.208.176.211...
    > > Hello,
    > >
    > > I'm looking for input regarding the way changes made by a user on an

    edit
    > > screen should be saved.
    > > The traditional way is to have a save and cancel button which the user
    > > clicks when they are done making changes. I feel this approach is

    somewhat
    > > insulting as it assumes that the user is usually making a mistake by
    > > changing the data. I would like to have the changes saved automatically

    > when
    > > they move to another record or screen, and have only a cancel button

    which
    > > the user can click to cancel any changes they made. The fields that are
    > > changed will have a different color or be bolded (I haven't decided

    > which).
    > >
    > > My coworkers feel this would be a bad approach.
    > >
    > > What do you think? Any ideas or feed back would be greatly appreciated

    as
    > > this is a very important design decision.
    > >
    > > TIA
    > >
    > > Andrew Merisanu
    > > Development Manager
    > > Courier Complete Inc.
    > >
    > >

    >
    >




  10. #10
    Brad Siemens Guest

    Re: Auto Save or Not?

    I went to your site and talked Mike into letting me use the terminal Server
    Demo... ( I think I freaked him out. The password was cancelled sometime
    about 6:00 pm. <g>).

    I did a mock up of the order form (forgive the presumption but I am bored
    stiff waiting for the corporate wanks to make some decisions) If you are
    interested let me know and I will send you a screenshot or post it
    somewhere.

    Tell Mike I'm not trying to steal your stuff!

    Brad
    ebspc@sympatico.ca

    "Andrew Merisanu" <andrewm@couriercomplete.com> wrote in message
    news:3c38f52e@147.208.176.211...
    > Hi Brad,
    >
    > We have been considering such an approach, but we are concerned that these
    > options will confuse the users. They tend to share workstations and they
    > don't always log off the previous user so they may be expecting the

    screen
    > to behave a certain way and it may not. The other issue is that most of

    our
    > users seem to have problems reading messages and instructions unless they
    > are in a big flashing message box.
    >
    > We have had our current version out for 2 years and over that time we have
    > had many cases of users doing foolish things because they didn't read the
    > messages. Our goal in developing our new version, apart from some

    features,
    > is to make the product as usable as possible. (Our current version has

    many
    > usabilty issues)
    >
    > We will consider your suggestion further though.
    >
    > Thanks,
    >
    > Andrew
    >
    > "Brad Siemens" <ebspc@sympatico.ca> wrote in message
    > news:3c3891f6@147.208.176.211...
    > > My approach is to offer the users both. If they want the record saved

    on
    > > transition or if they want the changes discarded a simple option setting
    > > should take care of it. A heads up on the edit form should indicate (In

    > no
    > > un-certain terms) what mode the form is in.
    > >
    > > IMNSHO
    > >
    > > Brad
    > >
    > > "Andrew Merisanu" <andrewm@couriercomplete.com> wrote in message
    > > news:3c371bb9@147.208.176.211...
    > > > Hello,
    > > >
    > > > I'm looking for input regarding the way changes made by a user on an

    > edit
    > > > screen should be saved.
    > > > The traditional way is to have a save and cancel button which the user
    > > > clicks when they are done making changes. I feel this approach is

    > somewhat
    > > > insulting as it assumes that the user is usually making a mistake by
    > > > changing the data. I would like to have the changes saved

    automatically
    > > when
    > > > they move to another record or screen, and have only a cancel button

    > which
    > > > the user can click to cancel any changes they made. The fields that

    are
    > > > changed will have a different color or be bolded (I haven't decided

    > > which).
    > > >
    > > > My coworkers feel this would be a bad approach.
    > > >
    > > > What do you think? Any ideas or feed back would be greatly appreciated

    > as
    > > > this is a very important design decision.
    > > >
    > > > TIA
    > > >
    > > > Andrew Merisanu
    > > > Development Manager
    > > > Courier Complete Inc.
    > > >
    > > >

    > >
    > >

    >
    >




  11. #11
    Russell Jones Guest

    Re: Auto Save or Not?

    I disagree. You should create products so they're most usable by the
    computer savvy people, and then add checks to prevent the less familiar
    users from making mistakes. If you write to the lowest common denominator,
    only the beginners will be satisfied with the program. But you should ask
    them anyway, or better--observe them first, write down what they *do* and
    then ask the experienced users what they'd like to change.

    There are two reasons to keep the Save button on screen. First, it doesn't
    hurt you in any way to let users save the data whenever they want--as long
    as you're performing data validation on the fields. Second, providing a Save
    button lets users save an intermediate record state, which is often very
    convenient. For example, they may have the data for all but one field--and
    they need to look at another record to find the information. If you don't
    provide a Save button, they will lose the already entered data during the
    search and have to reenter it. That's not a good feature. If necessary,
    implement a flag that lets you know the record is in an unfinished state, or
    save it in an "unfinished" table, but *always* let users save the data.

    You should only activate the Save button when a user modifies some field in
    the record. You do this by cleaning up the entry (e.g. trimming strings) and
    then comparing the entered data to the initial data for the record. Only
    enable the Save button if the data changed. After a user presses Save,
    disable it again until more data changes occur.

    Next, you should provide a Cancel button that ignores any changes made since
    the last Save action.

    With the Save and Cancel buttons in place, you can now decide whether to
    automatically save the data when the user changes records. My advice is:
    Yes, you should automatically save the data whenever it's valid. There are
    only two possibilities when the user has modified the data:

    1. The user is leaving the record accidentally--the user meant to save, but
    forgot to press the button
    2. The user is leaving the record on purpose, and doesn't want to change the
    data.

    Of the two, I believe the first is far more common--and you've covered the
    second case with the Cancel button. Data validation prevents you from
    automatically saving data in an invalid state.

    You can change the behavior relatively easily by making it an option. If the
    user selects the automatic save, display the Cancel button. If the user
    *doesn't* select the automatic save, only display the Cancel button if
    there's no other way to leave the record (e.g. when there's only one
    record).

    Finally, for everyone, you can handle this situation nicely by asking people
    which behavior they'd prefer (and gently teaching them the user interface
    features at the same time). For example, the first two times a user leaves a
    modified record without Saving, you can prompt them--ask if they want to
    save automatically. Track the answers and set the current option
    accordingly. For people sharing terminals, put the autosave option on-screen
    where they can change it with a single click.



    "Andrew Merisanu" <andrewm@couriercomplete.com> wrote in message
    news:3c38f380$1@147.208.176.211...
    > Hi Thomas,
    >
    > Our product is sold to many different companies. Although it's a vertical
    > market, the users range from computer savy to computer illiterate. So

    asking
    > the users is really not a usefull approach in this case.
    >
    > Thanks,
    >
    > Andrew
    >
    > "Thomas Eyde" <thomas.eyde@online.no> wrote in message
    > news:3c3899f1$1@147.208.176.211...
    > > Did you ask a typical user of his/her opinion?
    > >
    > > /Thomas
    > >
    > >

    >
    >




  12. #12
    David Bayley Guest

    Re: Auto Save or Not?

    Russell Jones <arj1@northstate.net> wrote in message
    news:3c4488df@147.208.176.211...

    > I disagree. You should create products so they're most usable by the
    > computer savvy people, and then add checks to prevent the less familiar
    > users from making mistakes. If you write to the lowest common denominator,
    > only the beginners will be satisfied with the program. But you should ask
    > them anyway, or better--observe them first, write down what they *do* and
    > then ask the experienced users what they'd like to change.


    Generally speaking, I think it is better to design the UI for the non-savvy
    users first, and then provide options for the savvy to go into "advanced
    mode". That way you satisfy *all* users. I agree that passive observation
    is an invaluable design aid.

    > <snip: provide both Save and Cancel buttons/>


    Agreed.

    > You should only activate the Save button when a user modifies some field

    in
    > the record. You do this by cleaning up the entry (e.g. trimming strings)

    and
    > then comparing the entered data to the initial data for the record. Only
    > enable the Save button if the data changed. After a user presses Save,
    > disable it again until more data changes occur.


    I used to agree with this, but am having second thoughts. The trouble is,
    when a form contains some complex validation rules, it is difficult to
    inform the user why the Save button is disabled. A common technique, is to
    color required field labels in red or some other such visual cue, but that
    alone isn't very informative. By keeping the Save button enabled, when the
    user clicks it you can popup a message box with a clear explanation (in
    English!), of why the form cannot be saved.

    The danger of a disabled Save button is that the non-savvy user gets
    frustrated and randomly starts changing fields just to get the bloody Save
    button enabled. By all means add the visual cues as well, so that the savvy
    user will be able to avoid annoying message boxes.

    Still not sure about this though. In Wizard like forms the disabled Next
    button works better, but in more complex data-entry forms I think the Save
    button is best left enabled.

    > With the Save and Cancel buttons in place, you can now decide whether to
    > automatically save the data when the user changes records. My advice is:
    > Yes, you should automatically save the data whenever it's valid.
    >
    > <snip/>
    >
    > Finally, for everyone, you can handle this situation nicely by asking

    people
    > which behavior they'd prefer (and gently teaching them the user interface
    > features at the same time). For example, the first two times a user leaves

    a
    > modified record without Saving, you can prompt them--ask if they want to
    > save automatically. Track the answers and set the current option
    > accordingly. For people sharing terminals, put the autosave option

    on-screen
    > where they can change it with a single click.


    Yes, although rather than changing behaviour "auto-magically", I prefer to
    popup a message box asking "Save Changes?", with a checkbox underneath
    labelled "Don't ask me this newbie question again". This comes back to
    designing first for the non-savvy, but providing options for the savvy.

    --
    David.




  13. #13
    Andrew Merisanu Guest

    Re: Auto Save or Not?

    David, Russell,

    Thank you both for your input and taking the time to think about and answer
    my post.

    You both make a great deal of sense and we will probably implement your
    suggestions.
    I like the idea of a message with a checkbox, I have implemeted this sort of
    idea before and it worked well. I guess the challenge is that our app has no
    modal forms at all, and I want to take advantage of that to the greatest
    extent possible. However, it seems like there is no getting away from the
    "Save" button.

    As for asking or observing the users, the problem is that I don't know the
    users, I only have access to the users that are using our current version
    and I already spent a lot of time observing and speaking with them. Their
    input and behaviour though, are of limited value because they are locked
    into the way things are in the current version and they are not really
    capable of envisioning a different design.

    Thanks again,

    Andrew

    "David Bayley" <dbayley@spamless.aebacus.com> wrote in message
    news:3c4702e3@147.208.176.211...
    > Russell Jones <arj1@northstate.net> wrote in message
    > news:3c4488df@147.208.176.211...
    >
    > > I disagree. You should create products so they're most usable by the
    > > computer savvy people, and then add checks to prevent the less familiar
    > > users from making mistakes. If you write to the lowest common

    denominator,
    > > only the beginners will be satisfied with the program. But you should

    ask
    > > them anyway, or better--observe them first, write down what they *do*

    and
    > > then ask the experienced users what they'd like to change.

    >
    > Generally speaking, I think it is better to design the UI for the

    non-savvy
    > users first, and then provide options for the savvy to go into "advanced
    > mode". That way you satisfy *all* users. I agree that passive

    observation
    > is an invaluable design aid.
    >
    > > <snip: provide both Save and Cancel buttons/>

    >
    > Agreed.
    >
    > > You should only activate the Save button when a user modifies some field

    > in
    > > the record. You do this by cleaning up the entry (e.g. trimming strings)

    > and
    > > then comparing the entered data to the initial data for the record. Only
    > > enable the Save button if the data changed. After a user presses Save,
    > > disable it again until more data changes occur.

    >
    > I used to agree with this, but am having second thoughts. The trouble is,
    > when a form contains some complex validation rules, it is difficult to
    > inform the user why the Save button is disabled. A common technique, is

    to
    > color required field labels in red or some other such visual cue, but that
    > alone isn't very informative. By keeping the Save button enabled, when

    the
    > user clicks it you can popup a message box with a clear explanation (in
    > English!), of why the form cannot be saved.
    >
    > The danger of a disabled Save button is that the non-savvy user gets
    > frustrated and randomly starts changing fields just to get the bloody Save
    > button enabled. By all means add the visual cues as well, so that the

    savvy
    > user will be able to avoid annoying message boxes.
    >
    > Still not sure about this though. In Wizard like forms the disabled Next
    > button works better, but in more complex data-entry forms I think the Save
    > button is best left enabled.
    >
    > > With the Save and Cancel buttons in place, you can now decide whether to
    > > automatically save the data when the user changes records. My advice is:
    > > Yes, you should automatically save the data whenever it's valid.
    > >
    > > <snip/>
    > >
    > > Finally, for everyone, you can handle this situation nicely by asking

    > people
    > > which behavior they'd prefer (and gently teaching them the user

    interface
    > > features at the same time). For example, the first two times a user

    leaves
    > a
    > > modified record without Saving, you can prompt them--ask if they want to
    > > save automatically. Track the answers and set the current option
    > > accordingly. For people sharing terminals, put the autosave option

    > on-screen
    > > where they can change it with a single click.

    >
    > Yes, although rather than changing behaviour "auto-magically", I prefer to
    > popup a message box asking "Save Changes?", with a checkbox underneath
    > labelled "Don't ask me this newbie question again". This comes back to
    > designing first for the non-savvy, but providing options for the savvy.
    >
    > --
    > David.
    >
    >
    >




  14. #14
    Caroline Guest

    Re: Auto Save or Not?


    I agree with Russell and Thomas and think custom apps should be designed for
    the users. For commercial apps, we still have standards to use as guidelines
    ... even MS Word, Excel and other off-the-shelf products require the users
    to save their changes. I also prefer the save/cancel buttons because it
    gives users some semblance of control over the data entry process. My approach
    to enabling the save button, however, is the opposite of Russell's suggestion.
    I disable it when the user saves and enable it again when they start editing.
    The save action is deliberate and users are less confused moving from one
    form to another wondering if the data's been edited, or saved or not. I still
    include an update button on some forms (a relic from my DOS programming days)
    and have found that this avoids a lot of update concurrency problems ...
    a user can keep a record on the screen all day, but when they hit 'update'
    the record is refreshed. When they save, the code loops through the recordset
    and the table is updated only if any of the fields have changed. Users don't
    even know that nothing happened unless there's a concurrency error and that's
    rare since my code only updates the changed fields, not the entire recordset.
    This method has made security and user access easier to code too ... if
    users have read-only capabilities, the update button and controls are disabled
    and there's no question as to what they can or can't do just by looking at
    the screen. I know this is a rather old-fashioned way of designing a UI and
    it will certainly evolve as my client's needs change, but right now they
    are moving from a DOS application and are most comfortable with that interface.


    Caroline
    "Russell Jones" <arj1@northstate.net> wrote:
    >I disagree. You should create products so they're most usable by the
    >computer savvy people, and then add checks to prevent the less familiar
    >users from making mistakes. If you write to the lowest common denominator,
    >only the beginners will be satisfied with the program. But you should ask
    >them anyway, or better--observe them first, write down what they *do* and
    >then ask the experienced users what they'd like to change.
    >
    >There are two reasons to keep the Save button on screen. First, it doesn't
    >hurt you in any way to let users save the data whenever they want--as long
    >as you're performing data validation on the fields. Second, providing a

    Save
    >button lets users save an intermediate record state, which is often very
    >convenient. For example, they may have the data for all but one field--and
    >they need to look at another record to find the information. If you don't
    >provide a Save button, they will lose the already entered data during the
    >search and have to reenter it. That's not a good feature. If necessary,
    >implement a flag that lets you know the record is in an unfinished state,

    or
    >save it in an "unfinished" table, but *always* let users save the data.
    >
    >You should only activate the Save button when a user modifies some field

    in
    >the record. You do this by cleaning up the entry (e.g. trimming strings)

    and
    >then comparing the entered data to the initial data for the record. Only
    >enable the Save button if the data changed. After a user presses Save,
    >disable it again until more data changes occur.
    >
    >Next, you should provide a Cancel button that ignores any changes made since
    >the last Save action.
    >
    >With the Save and Cancel buttons in place, you can now decide whether to
    >automatically save the data when the user changes records. My advice is:
    >Yes, you should automatically save the data whenever it's valid. There are
    >only two possibilities when the user has modified the data:
    >
    >1. The user is leaving the record accidentally--the user meant to save,

    but
    >forgot to press the button
    >2. The user is leaving the record on purpose, and doesn't want to change

    the
    >data.
    >
    >Of the two, I believe the first is far more common--and you've covered the
    >second case with the Cancel button. Data validation prevents you from
    >automatically saving data in an invalid state.
    >
    >You can change the behavior relatively easily by making it an option. If

    the
    >user selects the automatic save, display the Cancel button. If the user
    >*doesn't* select the automatic save, only display the Cancel button if
    >there's no other way to leave the record (e.g. when there's only one
    >record).
    >
    >Finally, for everyone, you can handle this situation nicely by asking people
    >which behavior they'd prefer (and gently teaching them the user interface
    >features at the same time). For example, the first two times a user leaves

    a
    >modified record without Saving, you can prompt them--ask if they want to
    >save automatically. Track the answers and set the current option
    >accordingly. For people sharing terminals, put the autosave option on-screen
    >where they can change it with a single click.
    >
    >
    >
    >"Andrew Merisanu" <andrewm@couriercomplete.com> wrote in message
    >news:3c38f380$1@147.208.176.211...
    >> Hi Thomas,
    >>
    >> Our product is sold to many different companies. Although it's a vertical
    >> market, the users range from computer savy to computer illiterate. So

    >asking
    >> the users is really not a usefull approach in this case.
    >>
    >> Thanks,
    >>
    >> Andrew
    >>
    >> "Thomas Eyde" <thomas.eyde@online.no> wrote in message
    >> news:3c3899f1$1@147.208.176.211...
    >> > Did you ask a typical user of his/her opinion?
    >> >
    >> > /Thomas
    >> >
    >> >

    >>
    >>

    >
    >



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