User WTF



  • This has probably been covered time and time again, but as of right now
    I'm so damn angry I just have to vent my anger somewhere. This thread
    seemed perfectly fine.



    I HATE USERS. I'm a java developer, working in a project for a
    subsiduary to a major car manufacturer. We're creating an application
    for project management.



    Back in school I have attendend allt the User oriented soft coarses
    that teach us that we're square and the users are round, and that where
    we like to have values of "1, 2, and 3", the users want significance
    such as "Apple, diamond, roses are red." And I believed it. And I DO
    want to be a good developer, so I've gladly attended and listened to
    the users time and time again.



    In my current project I can't help to create a crappy application. Not
    because I wan't to, because I'm stressed, but simply because the
    F*CKING USERS ARE MAKING ME!!! They demand for it....



    Example:

    In their old application (which is part application, part paperwork),
    they fill in some field with number. The number represent values such
    as "Department" or "Material type" and such. We thought we'd help them
    by creating dropdown selectboxes for them to pick from. And today when
    the application review was held I got that page back with the comment.
    "Please change it to the numbers". FSCK ME!



    Another time... We had a field that was clearly boolean, called
    "Delivery". I was asked to change my suggested checkbox from a checkbox
    to an options selec with the fields "L" and blank! When I suggested
    that that would be both costly and completely against all logic and
    usability I was ignored. Amazingly what I have to do is this:

    a, read the boolan from the DB

    b, convert it to either blank or "L"

    c, create the options selectbox

    d, let the user choose

    e, convert the fscking "L" or blank BACK to a boolean

    f, store it in the DB



    It's not me! It's the users. They're making me into a bad coder... And
    the sad truth is this: Someone will look at this application, realize
    that it's crap, and BLAME THE DEVELOPERS.



    .... please... help.... me..... sniff



    PS. Cussing due to frustration and language barrier



  • @pd0 said:



    PS. Cussing due to frustration and language barrier




    Language barrier should never be a reason for cursing. Frustration is a different story, however [:D]



    People are creatures of habit, so they tend to resist change. They
    already know that 165 is the "Inventory Management" department, and can
    quickly key that in... Did you ever think of creating a look-up table
    that would bring back something like "165 - Inventory Management" when
    they key in the numbers into a combo box? With a combo box (as opposed
    to a drop-down listbox) such things can be quite simple.



    The point is: it can be difficult to institute change. Yes -- they are
    stubborn, and that understandably frustrates you... but, you have to
    look for what's best for the people using the software, even if what
    you're doing seems more intuitive.



  • Just do what I do and make it the way the users want it (as long as that's possible), but put lots of scathing comments into the code about how retarded it is to do X in such a manner, but that the users wanted you to do X that way so you had to.  The users get what they want, you get a little stress relief, and future developers will know you're not a no-talent ass-clown.



  • @UncleMidriff said:

    Just do what I do and make it the way the users want it (as long as that's possible), but put lots of scathing comments into the code about how retarded it is to do X in such a manner, but that the users wanted you to do X that way so you had to.  The users get what they want, you get a little stress relief, and future developers will know you're not a no-talent ass-clown.

    Completely Agree.  Well said.  CYA Bigtime!!  (CYA = Cover Your ASS)  Comment, Comment and Comment your code especially when you are doing someting really weird that could end up being posted here... Just kidding on the posted here part! [:D]



  • I once heard someone say that software development would improve greatly if we could simply get rid of the users.

    It's a shame, but on many occaisions I've had to implement concepts that were beyond retarded simply because the user is incompetent and very demanding. I'll share my story with you (don't worry it's fairly short):

    I was involved in a project that was tasked to make a web-based production system. The piece I was working on was where one person had to enter data via checkboxes, drop-down lists, and plain text boxes. There were easily 40+ items to be filled in, and the users DEMANDED that it all fit on one screen. I tried explaining the limitations of the screen resolution they were using (most were at 800x600) and that it just wasn't possible to do that unless I made everything at an unreadable 6pt font.

    I showed them a prototype and they utterly hated it. One guy proceeded to draw the layout on a piece of paper and asked why I couldn't make it look like that. The solution I came up with was to divide the form into 5 sections, and group the appropriate items together. Then have a minimize/maximize icon they could click to expand the area they want. Basically this would just hide or show that section, but I thought it was a cool bit of Javascript.

    The users hated that too. However, they agreed it was better than the 6pt font idea, so they've been using it for the past two years with relatively few complaints.

    Then someone figured it was a good idea to to verify the data before the user submits the form. This was a horrendous headache because they couldn't agree on one set of rules, so it took twice as long as it should have to get it implemented. Then they wanted a way to bypass that quality check step, thereby negating all the work I had done to put the checks in there in the first place. My favorite is where they had a list of values in a drop-down list, and they wanted to prevent the user from submitting the form is one particular value was selected, as that value was not allowed. I suggested that I just remove it from the list. Nope, that value MUST stay in the list, and the user MUST NOT be allowed to select it.

    Sorry man, this is the path you have chosen. May God have mercy on your soul.



  • I think the complaint about users wanting numbers instead of a listbox is a developer WTF.  It comes from the developer never experiencing data entry and hence never realizing where the slowdown is.  If you were trying to rate the efficiency of a function you would use a profiler; if you are trying to rate the efficiency of an interface, use someone who actually uses it.

    Looking at the above example, I can see exactly what has the users in an uproar:  the forced switch between keyboard and mouse.  They are entering information in fields and suddenly see a listbox they have to pull down (as mentioned already, you can make those numbers the beginning text of each item but listbox behavior can be inconsistent from system to system and program to program and users might expect that they have to pull it down anyway).

    I first ran into this in a job early in my career.  The users had an old DOS FoxPro database--horribly written, btw--that they used to enter form data.  It was all done by keyboard, and it was fast.  The developers changed it into a Windows VB app with buttons and listboxes and tabs and what have you, and the users HATED it -- it was slower, they couldn't key through fields the way they were used to doing, some UI elements had no keyboard shortcuts, in short they had to retrain themselves just to get back to square zero.  The system underneath may have been a thing of beauty, but users don't really give a damn about your elegant program structure, or the kludges necessary to make their jobs easier.

    The users hated the program and the developers tried to argue them into liking it.  Why the disconnect?  Because the developer never talked to the users -- really talked to them.  (Call this top-down programming:  I the programmer give you the user what I think you need, and if you don't like it you're wrong.)  Talking to users (yes, some of them are kind of dumb) is not as straightforward as it sounds; users are often busy, they don't speak your language, they don't understand the implications of what you tell them all the time.  But a good developer does it and wrangles the needed information to make his program a well-received success.  A bad developer never really understands how the program is used in real life and blames the user for not liking the end product.  I've done it myself.

    Users aren't stupid, they just have different work to complete than you do.



  • @ Mike R:

    Yes, I've tried to argue that prefixing the value with the number was a
    good idea. But they didn't want it. Apparently the dropdown became too
    wide. :-(



    @ Nancyboy:

    Thank you. That perspective is actually refreshing. I guess that when
    developers teach us about users we hardly get the right nuance. I'll
    try to be imaginative to my solutions when it comes to user input.



  • *bows in appreciation*

    No that is so true! Just because something isn't logical for a coder, doesn't make it stupid or useless! :p

    I always try to get some kind of user input before getting started on a project, though I have noticed that you cannot possibly expect them to tell you all that is needed to design a system...But they can tell you how a program would work more efficient for them, and that is where you, the software developer should listen keenly! And if you do need to bring changes, do it slowly...If the users don't like the program, or are in any other way annoyed by it, you haven't done the best job now have you? *ignores the users that will bitch about anything, just because they're like that*

     

     

     

     



  • The trouble with transition from command-line to DOS/CURSES to GUI
    seems to be fairly common (I can sympathise with the poor users; I
    prefer command-line apps myself in most cases, and most inhouse
    developed GUIs have spectacularly bad interfaces). Oddly, people seem
    quite happy, usually to shift from those to web-based thingies.



  • It's all very okay to ask users what they want, unless you are making what I had to make for some microbiologists.

    Each one wanted different fields to be mandatory. End result: no fields are mandatory.

    Each one wanted different data in the drop-down boxes and lists. End result: You can select from the dropdown list, or type in your own data. Which was why there was a dropdown list in the first place, because the data needed to be uniform throughout the community.

    Everything needed to fit on one page. And you had to be able to split it into 2 halves too. Luckily we were able to talk them out of having just one page.

    For reasons of evidence, logs had to be created when certain diagnoses were made, with all the evidence of why that diagnosis was made in them. Then all of a sudden they needed to add more evidence at the same time as creating the diagnosis, so there's no real need to log anymore, but we still do it.

    Everyone had different methods of working, like first screen A then B, or first screen B then A.

    The list goes on and on. If only there was such a thing as uniformity among users.

    Drak



  • @NancyBoy said:

    Users aren't stupid, they just have different work to complete than you do.





    Naaaw, they are stupid. :)



        dZ.



  • @Binsky said:

    bows in appreciation

    No that is so true! Just because something isn't logical for a coder, doesn't make it stupid or useless! :p

    I always try to get some kind of user input before getting started on a project, though I have noticed that you cannot possibly expect them to tell you all that is needed to design a system...But they can tell you how a program would work more efficient for them, and that is where you, the software developer should listen keenly! And if you do need to bring changes, do it slowly...If the users don't like the program, or are in any other way annoyed by it, you haven't done the best job now have you? *ignores the users that will bitch about anything, just because they're like that*


    The smart 0.1% of users will tell you that.

    The other 99.9% of users will tell you that it cannot possibly be done any way other than the way they do it currently. I've lost count of the number of times I've had to scrap an objectively better solution for an inferior solution merely because "that's they way they do it now"

    It's like people insisting that they won't accept any route from Paris to Berlin other than the route via Tokyo. It's long winded, it's insane, but "that's the way we've always done it, we don't want you damn programmers coming in here telling us how to do our job".



  • @Drak said:

    It's all very okay to ask users what they want, unless you are making what I had to make for some microbiologists.

    Each one wanted different fields to be mandatory. End result: no fields are mandatory.

    Each one wanted different data in the drop-down boxes and lists. End result: You can select from the dropdown list, or type in your own data. Which was why there was a dropdown list in the first place, because the data needed to be uniform throughout the community.

    Everything needed to fit on one page. And you had to be able to split it into 2 halves too. Luckily we were able to talk them out of having just one page.

    For reasons of evidence, logs had to be created when certain diagnoses were made, with all the evidence of why that diagnosis was made in them. Then all of a sudden they needed to add more evidence at the same time as creating the diagnosis, so there's no real need to log anymore, but we still do it.

    Everyone had different methods of working, like first screen A then B, or first screen B then A.

    The list goes on and on. If only there was such a thing as uniformity among users.

    Drak

     

    Sounds like what I was having to deal with recently.  The system I'm maintaining (Payback) doesn't even have that many users, but I'll be damned if every single one of them didn't have a different idea as to how everything had to be done.  Even a simple screen where the end user has to enter personal information such as name, address, etc. was too hard.  At first they told me that we had to have a place for the end user to enter a Mailing address and a Legal address.  Then one of them told me we just needed the first one.  Shortly after I made the change, I got an e-mail from another one of them telling me that we have to have both in there but that the end user should only be required to fill one out.  Keep in mind that this was after I had sat down with all of them to discuss this screen, at which point it was decided, by all, to require both address fields.

    Luckily, things have taken a change for the better.  They realized that changing the same thing back and forth 300 billion times was wasting their money, so they appointed a sort of point man to talk to me.  Now, I do nothing that he hasn't told me to do.  What a world of difference this has made!



  • @DZ-Jay said:

    @NancyBoy said:

    Users aren't stupid, they just have different work to complete than you do.



    Naaaw, they are stupid. :)

        dZ.

    Well, it's possible.  :-)  Actually, my worst experience developing was when the user with final approval was another IT person.  It was a web site and the guy knew nothing about web servers, web design, security, programming, GUIs, logic, or--it seemed--anything else, but still insisted on back seat developing every little detail of the implementation, with predictable results.  Talk about frustration.  Working with someone who has to be the alpha techie is not fun.



  • @NancyBoy said:

    @DZ-Jay said:
    @NancyBoy said:

    Users aren't stupid, they just have different work to complete than you do.



    Naaaw, they are stupid. :)

        dZ.

    Well, it's possible.  :-)  Actually, my worst experience developing was when the user with final approval was another IT person.  It was a web site and the guy knew nothing about web servers, web design, security, programming, GUIs, logic, or--it seemed--anything else, but still insisted on back seat developing every little detail of the implementation, with predictable results.  Talk about frustration.  Working with someone who has to be the alpha techie is not fun.

    Oh, and proof of his obtuseness:  He insisted that the login credentials for the administration page be stored in a plaintext file on the site, unencrypted, so he could edit it later.  Sob!



  • @pd0 said:



    Example:

    In their old application (which is part application, part paperwork),
    they fill in some field with number. The number represent values such
    as "Department" or "Material type" and such. We thought we'd help them
    by creating dropdown selectboxes for them to pick from. And today when
    the application review was held I got that page back with the comment.
    "Please change it to the numbers". FSCK ME!




    I hear you. But I can see that the dropdown selectboxes could make user entry cumbersome.

    Dropdown selectboxes may assist first time user. But when you use an
    application every day, inputing data must be easy. Dropdown selectboxes
    that donät allow for text input forces the user to use mouse. This is
    not good usability.

    You maby shulde go a midel way an make it possibel to write the code in
    the dropdown selectboxes, for those user who know it. Keeping the
    dropdown selectboxes helps to find the record.




  • User input is absolutely critical for a successful UI design, but that doesn’t me the users design the UI. Users *are* very smart, but only about their job. They aren’t UI designers and they certainly aren’t developers. When users complain about a UI, and insist it must be some other weird way, that doesn’t mean you necessarily should do it that way. The key question is why do they want it the weird way?<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    <o:p> </o:p>

    Once you drill down to that, often a third design alternative becomes apparent. NancyBoy and others give an example of how this may be with the dropdown list and points to the solution (and if that makes the dropdown too wide, consider abbreviating the value; also, I think some GUI toolkits allow the dropdown list to be wider than the text box portion –show number and value in the dropdown, but not the text box).<o:p></o:p>

    <o:p> </o:p>

    As for the “L vs. blank,” maybe they already have reports or records (which you cannot change) that use this coding. Maybe they’re even looking at a physical artifact that uses this convention while inputting it into the computer screen. “L vs. blank” would be faster, easier, and less prone to human error. If so, your solution is no WTF, but an intelligent implementation: the database is how the database should be, and the UI is how the UI should be. A WTF would be *always* forcing the UI to mirror the underlying database. The brake calipers of a car are outboard of the clutch. Does that mean the brake pedal should be outboard of the clutch pedal?<o:p></o:p>

    <o:p> </o:p>

    Also, I don’t know how you’re presenting the UI to the user, but it’s generally dangerous to throw a screenshot of a proposed window on the wall and ask users, “what do you think?” You have to get the users to *use* the UI to do the tasks they actually do at work. I’ve had users approve a feature when looking passively at the window, only to be demanding its removal about 20 minutes later when they actually tried to use the window. Also, you learn a lot from watching users work that you’d never learn from what they say.<o:p></o:p>

    <o:p> </o:p>

    <o:p>--RA</o:p>



  • @pd0 said:

    .... please... help.... me..... sniff






  • @Manni said:

    My favorite is where they had a list of values
    in a drop-down list, and they wanted to prevent the user from
    submitting the form is one particular value was selected, as that value
    was not allowed. I suggested that I just remove it from the list. Nope,
    that value MUST stay in the list, and the user MUST NOT be allowed
    to select it.





    I feel you for ya man.  I experienced the EXACT SAME SITUATION
    YESTERDAY.  We have this custom roguewave grid control. 
    What's spiffy about it is that you can embed a combobox into a grid
    cell.  Depending on certain situations, the combobox will remove
    items that are unselectable, which was a total PTA, since you can only
    indirectly edit the combobox.  Now the user wants me to put the
    missing items back in, but grey them out.  I tried explaining that
    this was extremely difficult (besides being completely pointless) to
    do.  So he said that I should just put an asterisk instead. 
    Okay... so the ones with the asterisk are available or
    unavailable?  And nothing happens if you pick the one with the
    asterisk even though you select it?  This is supposed to be easier
    and less confusing HOW?



    Also got a complaint about screen real estate. The original program was
    for windows 3.1 (that's still in use), and used about 20 cascading
    screens.  I manage to get the GUI down to a single screen. 
    Only prob is that the user ran at 800x600.  So we increase it to
    1024x768 after a large struggle and a monitor upgrade.  Okay, now
    the user is going crazy because he/she has to scroll to see the rest of
    the data.  People are never happy.  Also, the user wanted to
    display multiple data in multiple places.  Also the user wanted me
    to unhide columns that I had hidden to save screen real estate (even
    though the column data would not be used).



    Oh and the user wants me to replicate full excel functionality in my software.  Reinventing the wheel was never this fun!



  • @Charles Nadolski said:


    Oh and the user wants me to replicate full excel functionality in my software.  Reinventing the wheel was never this fun!

    Isn't this illegal to do with MS developer tools?  I remember something stating that you can not use their tools to develop a program that simulates one of theirs?  I could be wrong, I need to read that oh so fancy EULA again.[:)]



  • @cm5400 said:

    @Charles Nadolski said:


    Oh and the user wants me to replicate full excel functionality in my software.  Reinventing the wheel was never this fun!

    Isn't this illegal to do with MS developer tools?  I remember something stating that you can not use their tools to develop a program that simulates one of theirs?  I could be wrong, I need to read that oh so fancy EULA again.[:)]



    Actually, you can embed office automation tools into a visual studio application.  The pre-alpa version of our product allowed you to import and edit excel spreadsheets directly this way.  The catch it you have to have Excel installed on your machine for it to work.  Unfortunately, it would take a half-minute every single time you changed something in the spreadsheet :-/


  • Funny you should mention users. I'm a java developer as well and I'm currently on-site at a client to do a bit of troubleshooting.

    Unfortunately I have to disagree. You see, I work for a small software company, market leader in its field and very customer oriented. And working in a commercial environment as I am, I've started seeing things from a slightly different angle. Our company has wasted 5 developers since I joined 3 years ago. Wasted because they cracked under the pressure, or because they would not or could not get into the mindset of the customers.

    The users don't care whether your application uses typed collections. They couldn't give a flying if your indentation style is K&R or GNU. They are not interested in whether your application is RESTful or not. They want it to work smoothly, quickly and without errors. And if they want 'L' and blank, then 'L' and blank they will get, regardless of whether it makes sense or how much tranformation back and forth is required.

    When you make an error in your code that means that suddenly 150 staff are only getting minimum wage for two months, because of fuckups in your system, then your first requirement is to get the fix out as soon as possible, and if that means letting standards and good style come second, then that will just have to be the case. What makes a good developer is then going back later and changing the code without messing up the logic.



  • A good project project manager (point man) is a wonderful thing, but rare.


Log in to reply