It will help reduce support calls...



  • a typical example of a defect report I get on an almost daily basis:

    "the client is complaing that when entering new customer details in their CRM module, that when entering the email address, the system is appears to freeze for a couple of seconds, and then is presented with a list of potential duplicate customer records (based on the data entered)

     

    there are 2 problems with this:

    1) The system should not be freezing when performing such a simple task

    2) The potential duplicates have no relationship to the details being entered, and as such the list of duplicates should not be shown

    ===================

    replication details:

    log onto clients system, select CRM/New customer

    enter new details, at the box for email type 'no@email.com' system will freeze for a couple fo seconds."

    Typically I would reject this with the following note attached:

    "when entering the email address, if there is no email address to enter, the user should leave this field blank, rather than type 'no@email.com'. As it is valid to check for other records with the same email address to prevent the user re-entering an existing customer's details. If they leave it blank, it will both record the fact that no email address was entered, and prevent the display of ~60,000 other customers in a grid with 'no@email.com' entered as their email address"

     

    All well and good... the message has got through.

    Then, we go through our annual company-wide objective reviews. One of the objectives virtually every member of staff gets is:

    "make all efforts whenever/wherever possible to reduce support calls"

     

    Over the next few days I experience de-ja vu every few minutes when I see a new defect report coming in that reads:

    "the client is complaing that when entering new customer details in their CRM module, that when entering the email address, the system is appears to freeze for a couple of seconds, and then is presented with a list of potential duplicate customer records (based on the data entered)

    ...snip...

    ...I feel that FIXING THIS would help reduce the number of support calls"



  • Your users are clearly stupid. I recommend that you take this to management with a proposal for "extra training", and then every time you get one of these reports, the person who sent it is required to attend an extremely boring 1-hour seminar that explains how to use the application correctly.

    Also, configure the system to reject no@email.com on the grounds that it is an invalid address (the email.com domain is squatted). That should shake them up a bit.



  • I would hardcode the 60.000+ records into the application, so you don't have to retrieve them. This will fix the "freezing" problem.



  • Better yet, why not fix the source of the problem

     It sounds like email is a required field when creating a customer record, and somebody has gotten around that by using no@email.com for customers that don't have an email.  In fact, it's probably a policy among all users at that location... thus that's why they transfer it over when running reports.

     
    Just make email a non required field. They can leave it blank for the customers who don't provide one, and thus won't enter it in when searching.
     



  • it isn't a required field... right back when the application was new, we are talking ~1990 so it was definately not mandatory 

    before I started here it was made a required field, but not validated... so pretty soon it was filled with ".", "none", "askjfhaskj","yeeeeah right" and so the evolution continued before some bright spark decided that it was no longer required, but input was validated. (as being a correctly constructed email address)

    So now, if they don't enter anything, that's fine. If they do enter something, it's validated.

    it has to be an inherited working practice from the time that it was a mandatory field, then when it was validated... rather than blanking it out - they got "smart" to get around the "dumbass" application.

     

    I could change it to reject 'no@email.com' but then I suspect that they might "work around" this defect by entering "iamafxxxxxgretard@ndthatswhyihaveadataentryjobatknobbers.com"



  • I don't know, the OP says he tells them to leave it blank, and (implied) they do for a while.  Then it starts up again.  I would bet that it's not the application requiring an email address, but perhaps it's some management directive.  Marketing maybe?  I wouldn't put it past some manager to say "we MUST have full contact information for all our customers, so we'll ding you each time you enter customer records with missing data".



  •  my guess as to why this continues to be a problem is that they see the paragraph of text in the response, and assume that it's a very wordy version of "it's fixed" without ever reading it.  try being terse: "stop entering fake email addresses.  just leave the field blank if they don't have one."  next step after that is to actually call them on the phone.   

     

    @asuffield said:

    Your users are clearly stupid. I recommend that you take this to management with a proposal for "extra training", and then every time you get one of these reports, the person who sent it is required to attend an extremely boring 1-hour seminar that explains how to use the application correctly.

    Also, configure the system to reject no@email.com on the grounds that it is an invalid address (the email.com domain is squatted). That should shake them up a bit.

     in general, this is a decent enough approach.  making the training boring, however, won't solve anything; they're not likely to pay attention and actually learn anything then.  better would be to get some dancing girls involved, or maybe a clown



  • This is an example of failing to meet user's expectations.  For whatever reason, whether a holdover from a previous package or some other conditioning, your users expect no@email.com to be treated as a NULL value.  Adapt to that- one extra if statement with a comment for the reason it exists isn't so hard to write



  • @joh6nn said:

     call them on the phone.   

     

    has that man gone completely insane!?

     

    I'll go for the terse option first, failing that, I will filter out that specific email address and add a configuration suite where they can go and enter all of the email addresses that they consider to be valid, and another one where they can enter all the email addresses they consider to be allowed as "filler"

     

    that ought to cover all the bases...



  • @joh6nn said:

     my guess as to why this continues to be a problem is that they see the paragraph of text in the response, and assume that it's a very wordy version of "it's fixed" without ever reading it.

    ...

    @asuffield said:

    Your users are clearly stupid. I recommend that you take this to management with a proposal for "extra training", and then every time you get one of these reports, the person who sent it is required to attend an extremely boring 1-hour seminar that explains how to use the application correctly.

     in general, this is a decent enough approach.  making the training boring, however, won't solve anything; they're not likely to pay attention and actually learn anything then.

    You seem to have missed the point. Sending them to an hour of boring training, just to hammer home one sentence, is a way to get the message across that you don't appreciate being sent "bug" reports that are user errors. The only thing they are supposed to take away from this hour is the two following points:

    • leave the field blank
    • stop sending me bug reports about this 


  • I'd say there's a bad interaction design on your part.  If there's a legit option to have an account with no email address, you should put a checkbox saying "no email" next to the email input.

    If an email address is required, then it stands to reason that a [i]valid[/i] email address is required.  Send a confirmation email to no@email.com and scrap the account when the confirmation gets bounced.  You'll have to make it very clear to the users that the address has to be valid though, or you'll get a number of support calls about accounts for no@email.com magically not working like they used to.



  • Actually this should be resolved one fo two ways:

    Let the user enter no@email.com and if that is entered do not parse it or treat it as an email so you don't make a search.  You can still save this info as it is what the user entered, just treat it differently.

    If that fails or requires far to much QA to get through, then create a SQL batch job that runs every night that changes records with no@email.com to blank.  This way you won't have the 60k+ records coming back, just the ones created that day. 



  • While all of your suggestions for code changes are valid, the OP never said that he was a developer for this product, so the best he can do is suggest to someone that these changes be implemented. 

    I don't know how requirements get generated and passed around in his system, but in my system, only the end users (we have about 10) can generate requirements to change anything. 



  • "in my system, only the end users (we have about 10) can generate requirements to change anything."

     That's fine, as long as you're allowed to meet with users every now and then to 'suggest' requirements :)
     



  • @bobday said:

    it isn't a required field... right back when the application was new, we are talking ~1990 so it was definately not mandatory 

    before I started here it was made a required field, but not validated... so pretty soon it was filled with ".", "none", "askjfhaskj","yeeeeah right" and so the evolution continued before some bright spark decided that it was no longer required, but input was validated. (as being a correctly constructed email address)

    So now, if they don't enter anything, that's fine. If they do enter something, it's validated.

    it has to be an inherited working practice from the time that it was a mandatory field, then when it was validated... rather than blanking it out - they got "smart" to get around the "dumbass" application.

     

    I could change it to reject 'no@email.com' but then I suspect that they might "work around" this defect by entering "iamafxxxxxgretard@ndthatswhyihaveadataentryjobatknobbers.com"

     

    You're right, they will get around that with other crap.

    But the question is why will your system accept 60,000 accounts with the same email address? emails are reasonably unique,

    Find your "duplicates" on more than just email, I would say.

    OR

    Count them first, display a message that "60,000 accounts were found with 'no@email.com', Would you like to see the list" kinda of a prompt. That way, they can dodge the wait.

     

    Of course, that me playing "nice dev". In my mind, I'm saying "If they are stupid enough to put in a bogus email when they don't need to enter any, they deserve to wait". Of course, that's little consolation for your poor DB server.

     


     



  • old code:

    if (email != null) {
        lookupDuplicates(email);
    }

     

    new code:

    if (email != null && email != "no@email.com") {
        loopupDuplicates(email);
    }

     

     

    I know it's a dirty hack, but I feel that this would be the cheapest way to solve your problem.
     



  • Amendment:

    if (email == "no@email.com") {
    MessageBox.Show("It's ok to leave the email field blank."); 
    }
    if (email != null) {
        loopupDuplicates(email);
    }

    When you stop getting no@email.com, take the code back out. 



  • Sounds like the users don't realise that something significant is happening in the background after the email is entered.

    It could probably be solved with a simple spinner/throbber style widget, and possibly a "checking email address" message, just to show that the app is actually doing something rather than just freezing.

    Although this

    "2) The potential duplicates have no relationship to the details
    being entered, and as such the list of duplicates should not be shown"

     shows that you're going to be fighting a strong front of belligerent mouth-breathers.
     



  • So fix it and quite whining. 

    Why, oh why are you trying to display 60,000 results in a grid?

    Thankfully google don't display "<font size="-1">about 2,160,000" results all in one go when I do a search or they might not have quite as many users (or a 0.09 second response time)</font><font size="-1">.</font>

    Unfortunately for your users it seems as if they are stuck with you and will have to keep raising defects until someone with a brain decides to design your software sensibly.

    T. 



  • @asuffield said:

    Your users are clearly stupid. I recommend that [ ... ]

     

       Hey, you typo'd!

     

    @asuffield said:

    Your users are clearly users. I recommend that [ ... ]

     

      There, I fixored it for you! 



  • Does the interface indicate in any way whatsoever that the field is not required?

    A) No. Users are utterly forgiven and a ticket must be submitted to subtly modify the form to improve communication.

    B) Yes. Users are utter twats and must be gloveslapped repeatedly.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.