But we designed it to work...



  • We have a couple of BAs who freely admit that they a) are completely non-technical, b) don't know how to write technical specs and c) don't know how to think through technical problems for edge cases, etc. That doesn't stop them from forcing us to build the application the way they "design" it, and they have the backing of someone who can enforce it.

    Ok, so there's a lot of re-doing of things as edge cases come up and we need to force them to thnk through at least that part of things. No biggie, we get paid by the hour.

    However, this time, they designed themselves into a corner. We warned them not to do it. We told them it would come back to bite them in the ass....

    We are replacing a legacy C++ application with one written in Java. Whoever wrote the C++ application didn't know about drag-to-select rows on a table so they implemented "select row" by placing a checkbox on every row. You check the boxes on the rows you want, and the button callback to do something scanned the list for the checkbox field and if set, did whatever.

    In Java, the JTable is the spreadsheet widget. I told them to just let us implement select-row the same way you do it in Excel; click and drag. No, they MUST have the checkbox also as some users can't live without it. Their solution? We can now select rows by a) clicking the left most cell (similar to Excel), b) clicking and dragging, c) checking the box in each row. Instead of do-x buttons, we now have "do-x row select", "do-x drag-select" and "do-x checkbox" buttons - for EVERY action. And you can't tell them that it's stupid because they don't want to hear it.

    Ok, some background on the JTable for the unfamiliar. You can set the table to initiate the cell-editor to activate on 1 click or 2 clicks. Using one click is useful if you don't want to click to activate the editor and then click again to actually change data. Using two clicks is useful if you want to be able to click and drag to highlight cells without triggering the editor.

    Our users don't want to be need to double click on the checkbox to set it so we had to set the start-editing click count to 1. This is a table-wide attribute. I warned them this was getting worse.

    Finally, they ask us to put a combo box in one of the columns. Try to click-drag starting in a cell with a combo box that activates on a single click. They said "no problem, fix the combo box so you can click-drag". But that means you need to double click the checkbox to set it. Oh no, we don't want that. So now they have us customizing the JTable so that we can have a different click-to-edit count on an individual column basis.

    When we told them it would be extra work over what they had figured, they said "There can't be all this extra work, we designed this application to work, so it should work". We laughed in their faces and told them to grow up and make a choice.

     



  • @snoofle said:

    We laughed in their faces and told them to grow up and make a choice.
     

    You actually did this, right?



  • @snoofle said:

    That doesn't stop them from forcing us to build the application the way they "design" it

    I hate that. Only design an interface if you know what you're doing, otherwise just describe functionality in abstract terms and let me figure out the specifics. I've been on the other team too (analyst/business user) and I try to let them do their job so I can do mine.

    Of course when they're about to screw up I see it as my obligation to show them the error of their ways, but that's different. I actually know what I'm talking about.



  • @dhromed said:

    @snoofle said:

    We laughed in their faces and told them to grow up and make a choice.
     

    You actually did this, right?

    Yes we did!



  • @snoofle said:

    @dhromed said:

    @snoofle said:

    We laughed in their faces and told them to grow up and make a choice.
     

    You actually did this, right?

    Yes we did!

    +1 karma



  • @b-redeker said:

    @snoofle said:

    That doesn't stop them from forcing us to build the application the way they "design" it

    I hate that. Only design an interface if you know what you're doing, otherwise just describe functionality in abstract terms and let me figure out the specifics. I've been on the other team too (analyst/business user) and I try to let them do their job so I can do mine.

    Of course when they're about to screw up I see it as my obligation to show them the error of their ways, but that's different. I actually know what I'm talking about.

    To be fair, the majority of developers are fucking awful at designing interfaces. Of course that doesn't mean these guys are any good at it, either... just saying.

    Edit: and of course the real WTF here is using Java for a GUI app. It's pretty much impossible to make a good UI in Java, so all you can do is "least shitty" anyway.



  • @blakeyrat said:

    Edit: and of course the real WTF here is using Java for a GUI app. It's pretty much impossible to make a good UI in Java, so all you can do is "least shitty" anyway.

    "least shitty" is the industry standard.



  • @blakeyrat said:

    To be fair, the majority of developers are fucking awful at designing interfaces.

    Oh, guilty as charged, your honor. But at least I know that.

    I now work with a guy who is very good at designing them, just doesn't know all the latest tricks and tools. So when he designs something that I think can be done more easily with standard components (which is basically what snoofle says), I show him, he says ok that works too if you bold that one and do that on doubleclick and we're good. Works great.

    Similarly, we have a business user who thinks up functionality, I explain "actually the way to do that is ...", he listens (really) and everybody's happy.



  • @snoofle said:

    @dhromed said:

    @snoofle said:

    We laughed in their faces and told them to grow up and make a choice.
     

    You actually did this, right?

    Yes we did!

     

     

    I applaud you sir. Please let us know if they did in fact grow up and made a logical (or at least workable) choice.



  • @b-redeker said:

    @blakeyrat said:

    To be fair, the majority of developers are fucking awful at designing interfaces.

    Oh, guilty as charged, your honor. But at least I know that.

    I now work with a guy who is very good at designing them, just doesn't know all the latest tricks and tools. So when he designs something that I think can be done more easily with standard components (which is basically what snoofle says), I show him, he says ok that works too if you bold that one and do that on doubleclick and we're good. Works great.

    Similarly, we have a business user who thinks up functionality, I explain "actually the way to do that is ...", he listens (really) and everybody's happy.

    I just had a potential employer ask me for screenshots of UIs I've worked on.  Is that normal?  I can't say anyone has ever asked me for screenshots before.  Everything I've worked on was designed by someone with talent.  I just make the pictures do something other than look pretty.

     



  • @b-redeker said:

    @blakeyrat said:

    To be fair, the majority of developers are fucking awful at designing interfaces.

    Oh, guilty as charged, your honor. But at least I know that.

    QFT. I'm good at making things work, it's just that, when I have to make it look pretty/usable, it invariably ends up looking like the output of an incontinent, colorblind monkey.



  • @toth said:

    @b-redeker said:

    @blakeyrat said:

    To be fair, the majority of developers are fucking awful at designing interfaces.

    Oh, guilty as charged, your honor. But at least I know that.

    QFT. I'm good at making things work, it's just that, when I have to make it look pretty/usable, it invariably ends up looking like the output of an incontinent, colorblind monkey.

    If you're refering to the UI a monkey would design, why would his incontinence matter?

    If you're refering to the "output" of a monkey, why would his colorblindness matter?

    Unless, of course, he's designing the UI with the matter he "outputs."



  • @toth said:

    when I have to make it look pretty/usable

    Without trying to leap down your throat too much, if you think "pretty" and "usable" relate to each other in any way, that's a huge problem. Those are two completely different continuums, ugly things can be usable, and pretty things can (and usually are) unusable.



  • @blakeyrat said:

    @toth said:
    when I have to make it look pretty/usable

    Without trying to leap down your throat too much, if you think "pretty" and "usable" relate to each other in any way, that's a huge problem. Those are two completely different continuums, ugly things can be usable, and pretty things can (and usually are) unusable.

    Yes, I know. Perhaps I should have said "pretty and/or usable".



  • @HighlyPaidContractor said:

    Unless, of course, he's designing the UI with the matter he "outputs."

    Guilty as charged your honor. I just fling controls unto the panel and see where it sticks.



  • @toth said:

    @blakeyrat said:
    @toth said:
    when I have to make it look pretty/usable
    Without trying to leap down your throat too much, if you think "pretty" and "usable" relate to each other in any way, that's a huge problem. Those are two completely different continuums, ugly things can be usable, and pretty things can (and usually are) unusable.
    Yes, I know. Perhaps I should have said "pretty and/or usable".

    I've had to work on a few projects that were pretty, but the function was handled entirely by the engineer behind the curtain in the corner.  You might imagine usability and responsiveness were a little lacking.  "Form before function" was the company motto.

    "Pretty" is closely tied to "doable," however.  Ugly things can be usable after a few beers.



  • @HighlyPaidContractor said:

    .

    "Pretty" is closely tied to "doable," however.  Ugly things can be usable after a few beers.

    Depends on how desperate are you, what is your tolerance index, etc, ugly things can be doable after a few winks, no beer involved whatsoever



  • @DeepThought said:

    I applaud you sir. Please let us know if they did in fact grow up and made a logical (or at least workable) choice.

    First they were going to think on it for a couple of days because it wasn't due in production for 10 days. I pointed out that it was due in QA in 1 day and that the time to think about it was before the work began and that it was time for a decision, or it stayed the way it was and the users would live with it. They couldn't decide so I sent out an email to all concerned stating the diametrically opposed requirements, the two choices of how it could work, and that the BAs couldn't make a decision.

    It took 30 seconds to get an answer.

    If we don't push back, then we failed to "make it work".

    I then took the user to a local bar and bought us lunch. In an hour, I got him to understand all the problems that had been created, and he said that they (users) would be willing to give on most of the problem-causing idocy we were forced to implement.

    The folks around here are sooooo afraid of conflict or confronting anyone that they just take whatever crap is thrown at them and everyone is miserable.

    Don't get me wrong, we're here to give them solutions to their business problems. But you can say NO to a user by phrasing it approriately: "You want to add x, y and z? Sure, it'll postpone the release by n days; do you want to wait or should we push it to the next release?" Invariably, the answer is to push it, but THEY made the decision, not me.

    I have a *spine*.

     



  • @snoofle said:

    @DeepThought said:

    I applaud you sir. Please let us know if they did in fact grow up and made a logical (or at least workable) choice.

    First they were going to think on it for a couple of days because it wasn't due in production for 10 days. I pointed out that it was due in QA in 1 day and that the time to think about it was before the work began and that it was time for a decision, or it stayed the way it was and the users would live with it. They couldn't decide so I sent out an email to all concerned stating the diametrically opposed requirements, the two choices of how it could work, and that the BAs couldn't make a decision.

    It took 30 seconds to get an answer.

    If we don't push back, then we failed to "make it work".

    I then took the user to a local bar and bought us lunch. In an hour, I got him to understand all the problems that had been created, and he said that they (users) would be willing to give on most of the problem-causing idocy we were forced to implement.

    The folks around here are sooooo afraid of conflict or confronting anyone that they just take whatever crap is thrown at them and everyone is miserable.

    Don't get me wrong, we're here to give them solutions to their business problems. But you can say NO to a user by phrasing it approriately: "You want to add x, y and z? Sure, it'll postpone the release by n days; do you want to wait or should we push it to the next release?" Invariably, the answer is to push it, but THEY made the decision, not me.

    I have a *spine*.

    If possible, I always try to make friends with the end-user.  You get much more useful input, and produce a better product in the end.  The more levels of abstraction between you and the user, the more static on the line.  It's like a game of telephone.

    If the end result isn't exactly what the BAs requested, it's usually drowned out by the overwhelming praise from the users and their managers.



  • @HighlyPaidContractor said:

    If possible, I always try to make friends with the end-user.  You get much more useful input, and produce a better product in the end. 

    I sincerely believe that user involvement is the main key in running an efficient and effective project. Also, typically the user you want for this is the user that can't be missed.



  • @b-redeker said:

    @HighlyPaidContractor said:

    If possible, I always try to make friends with the end-user.  You get much more useful input, and produce a better product in the end. 

    I sincerely believe that user involvement is the main key in running an efficient and effective project.

    I always enjoy it when I find out something I've always done is in a book somewhere.

    (Wait until I tell you about the times I invented arrays, function calls, and recursion.)

    @b-redeker said:

    Also, typically the user you want for this is the user that can't be missed.

    Also the user who doesn't have the time to work with you because the existing system is so terrible and inefficient. Unless that's what you meant.  I'm not sure I've ever seen "can't be missed" used in that context.

    Unfortunately, I'm usually in a position where I can't even log onto the network without express written consent.  There's nothing like waiting 2 weeks to get the go ahead to update my email signature so I can email my project manager, so she can email the client-side manager, so he can ask my question to the user.  I get a lot of "billable research" done.



  • @b-redeker said:

    Similarly, we have a business user who thinks up functionality, I explain "actually the way to do that is ...", he listens (really) and everybody's happy.


    Isn't that the norm? Taht is business users that say, "I want a button right here that does this!"

    Getting them to separate what they want done vs how it's done is impossible. I step them through it every time hoping they'll catch on.. but it hasn't worked yet.

    I'm surprised your example listens. That's a rarity. I'm used to the american speaking to a foreigner approach, "WHAAAAT.. I .. WAAAANT ... IZZZ ... AAAAA... BUTT TONNN (waves hands) ... HERRRRE (points to location)... THAAAAAT ... DOOOOES ... THIIIIS!! (more hand waving)"

    Yup, just say the same thing louder and slower. That will really get your point across.



  • @snoofle said:

    Ok, some background on the JTable for the unfamiliar. You can set the table to initiate the cell-editor to activate on 1 click or 2 clicks. Using one click is useful if you don't want to click to activate the editor and then click again to actually change data. Using two clicks is useful if you want to be able to click and drag to highlight cells without triggering the editor.

    Pleze sedn me the codez for integrating JTable in an ASP.NET application. . . .
    Or links to a good tutorial website.



  • @snoofle said:

    I then took the user to a local bar and bought us lunch. In an hour, I got him to understand all the problems that had been created, and he said that they (users) would be willing to give on most of the problem-causing idocy we were forced to implement.

     

    I think there is a very important lesson hidden in this paragraph.



  • @ShatteredArm said:

    @snoofle said:

    I then took the user to a local bar and bought us lunch. In an hour, I got him to understand all the problems that had been created, and he said that they (users) would be willing to give on most of the problem-causing idocy we were forced to implement.

     

    I think there is a very important lesson hidden in this paragraph.

    All problems can be solved with beer?



  • @HighlyPaidContractor said:

    I always enjoy it when I find out something I've always done is in a book somewhere.

    (Wait until I tell you about the times I invented arrays, function calls, and recursion.)

     

    Way back when i was in school, specifically 5th-8th grades, i was teaching myself BASIC through books and practice. I had gotten to the point where i was had created my own version of a function call, however it wasn't reentrant. Either the version of BASIC i was using didn't support parameters with gosub, or i didn't know how to use them, hence the re-entrancy problem. I had spent quite a while trying to solve this problem, before i picked up a C primer in highschool and realizing that i was trying to solve a solved problem. I never touched basic again, never even used VB until recently to write some example automation scripts.

    A similar thing happened in C, where i unknowingly was going down the path toward classes. Luckilly i bought a C++ book before I spent a large amount of time trying to solve it.



  • @b-redeker said:

    @snoofle said:

    That doesn't stop them from forcing us to build the application the way they "design" it

    I hate that. Only design an interface if you know what you're doing, otherwise just describe functionality in abstract terms and let me figure out the specifics. I've been on the other team too (analyst/business user) and I try to let them do their job so I can do mine.

    Of course when they're about to screw up I see it as my obligation to show them the error of their ways, but that's different. I actually know what I'm talking about.

    Our BAs do it too.  Only, ours screw it up differently.  Instead of jumping in over their heads and designing a horrible user interface, they defer the design to the users.  Yes, instead of actually looking around for someone that knows design, they simply ask the users what they want it to look like, faithfully record it, and make it a requirement.  If the users happen to design an interface with mutally exclusive requirements, then so be it.

    On the other side of the coin, I have the overly passive operations department.  When it comes to non-functional requirements, they never ask for anything they actually need.  One time, I changed the logging of an application so that it wasn't a nightmare to integrate with our "enterprise monitoring system", they came back with "You can do that?".  I only found out that the change needed to be made by accident, no one would have ever mentioned it if I hadn't bumped into it.



  • @blakeyrat said:

    @ShatteredArm said:

    @snoofle said:

    I then took the user to a local bar and bought us lunch. In an hour, I got him to understand all the problems that had been created, and he said that they (users) would be willing to give on most of the problem-causing idocy we were forced to implement.

     

    I think there is a very important lesson hidden in this paragraph.

    All problems can be solved with beer?

     

    Okay, two very important lessons.



  •  TBH, some users prefer checkboxes over drag-to-select, but in that case, drag-to-select simply should not be there.



  • @Jaime said:

    On the other side of the coin, I have the overly passive operations department.  When it comes to non-functional requirements, they never ask for anything they actually need.
    I'm maintaining (read fixing) a godawful app for a client that's a bit like that. I was trying to use it here and noticed that it had a "Delete User" button that crashed the entire thing. It just didn't work. So I call them:

    "Say, I noticed this button here doesn't work. How exactly have you been deleting records all this time?"

    "Oh, what we do is we track down all the user-related stuff we've put in and then delete that in reverse order. Afterwards we can delete the user."

    "wat"

     

    It's a good thing they're this passive because if I was running that company and had paid for an app like that, there would have been trouble...



  • @ammoQ said:

     TBH, some users prefer checkboxes over drag-to-select, but in that case, drag-to-select simply should not be there.

     

    Windows Explorer Vista+ contains both and it works like a charm.



  • @b-redeker said:

    @HighlyPaidContractor said:

    If possible, I always try to make friends with the end-user.  You get much more useful input, and produce a better product in the end. 

    I sincerely believe that user involvement is the main key in running an efficient and effective project. Also, typically the user you want for this is the user that can't be missed.

     

    QFT

    I've come up with a very good way to design interfaces lately, and I'd like to share.

    Roughly 90% of my interface has been quickly scribbled in Balsamiq Mockups, and distributed to the users for input.  They make their coments either in text or by editing the pictures in Paint (or whatever) with the same roughness as Mockups produces, so everyone understands all the way that these are just ideas and drafts, nothing definitive.
    I then sit down with all the edited versions, and the feedback, and use that to make another mockup, which is then distributed for the same process over again.
    This is done a couple of times, or as long as we have time for.  The three times this has been done so far it has been a HUGE success!

    Users feel involved in the application they're using every day ("Oooh, I got my suggestion for bigger spacing between the tabs in!") and those that don't care or don't have time can simply ignore the involvement request when it comes.

    That takes care of the interface.
    The "business needs" are (thankfully) pretty well defined, but still sort of abstract.  I'm especially free when it comes to what kind of reports and stuff the system will produce, as they've come to trust my innovations in the past.  Legacy compatibility, however, is an absolute, so I've got about a gazillion lines of legacy reporting code in my current project.
    One of the users came up with a "Legacy mode" checkbox, along with a rather detailed explaination of how it'd be neat if it worked with/without that checked, so a bright head solved that for me before I even had time to mutter to myself about it.

    In the end, this very tight cooperation between programmers and users is very fruitful here, and in the end we have an application we all love.



  • @Chewbacca said:

    @b-redeker said:

    @HighlyPaidContractor said:

    If possible, I always try to make friends with the end-user.  You get much more useful input, and produce a better product in the end. 

    I sincerely believe that user involvement is the main key in running an efficient and effective project. Also, typically the user you want for this is the user that can't be missed.

     

    QFT

    I've come up with a very good way to design interfaces lately, and I'd like to share.

    Roughly 90% of my interface has been quickly scribbled in Balsamiq Mockups, and distributed to the users for input.  They make their coments either in text or by editing the pictures in Paint (or whatever) with the same roughness as Mockups produces, so everyone understands all the way that these are just ideas and drafts, nothing definitive.
    I then sit down with all the edited versions, and the feedback, and use that to make another mockup, which is then distributed for the same process over again.
    This is done a couple of times, or as long as we have time for.  The three times this has been done so far it has been a HUGE success!

    Users feel involved in the application they're using every day ("Oooh, I got my suggestion for bigger spacing between the tabs in!") and those that don't care or don't have time can simply ignore the involvement request when it comes.

    That takes care of the interface.
    The "business needs" are (thankfully) pretty well defined, but still sort of abstract.  I'm especially free when it comes to what kind of reports and stuff the system will produce, as they've come to trust my innovations in the past.  Legacy compatibility, however, is an absolute, so I've got about a gazillion lines of legacy reporting code in my current project.
    One of the users came up with a "Legacy mode" checkbox, along with a rather detailed explaination of how it'd be neat if it worked with/without that checked, so a bright head solved that for me before I even had time to mutter to myself about it.

    In the end, this very tight cooperation between programmers and users is very fruitful here, and in the end we have an application we all love.

    ARGH!! And I was just told last week that gui mock-ups only slow down the programming / brd process.



  • @Medezark said:

    ARGH!! And I was just told last week that gui mock-ups only slow down the programming / brd process.
     

    It works very well here, but it might not work everywhere.  Have they tried?  SRSLY, give that program a twirl and see what it does.  I love it.



  • @Chewbacca said:

    @Medezark said:

    ARGH!! And I was just told last week that gui mock-ups only slow down the programming / brd process.
     

    It works very well here, but it might not work everywhere.  Have they tried?  SRSLY, give that program a twirl and see what it does.  I love it.

    It also depends on your IDE/ORM tools/etc. If you have a programming environment that will allow you to quickly add/remove fields so you have in fact a functional prototype, that's even better. If not, GUI mockups (and these could even be post-its on a flipover) work great. Better still if you use them to test actual use cases.


  • :belt_onion:

    @b-redeker said:

    @Chewbacca said:
    @Medezark said:
    ARGH!! And I was just told last week that gui mock-ups only slow down the programming / brd process.
     

    It works very well here, but it might not work everywhere.  Have they tried?  SRSLY, give that program a twirl and see what it does.  I love it.

    It also depends on your IDE/ORM tools/etc. If you have a programming environment that will allow you to quickly add/remove fields so you have in fact a functional prototype, that's even better. If not, GUI mockups (and these could even be post-its on a flipover) work great. Better still if you use them to test actual use cases.

    I work with the Microsoft stack and we use Sketchflow for mocking GUI's.

    I have used it now for the first time on a project and it was a real help. The users finally started understanding their own requirements (and their implications) when they saw them implemented in the UI. Thanks to the mocks the business users realized that their requirements did not fullfill their actual needs, so we are now starting up a new "Phase 2" project.



  • @bjolling said:

    @b-redeker said:

    @Chewbacca said:
    @Medezark said:
    ARGH!! And I was just told last week that gui mock-ups only slow down the programming / brd process.
     

    It works very well here, but it might not work everywhere.  Have they tried?  SRSLY, give that program a twirl and see what it does.  I love it.

    It also depends on your IDE/ORM tools/etc. If you have a programming environment that will allow you to quickly add/remove fields so you have in fact a functional prototype, that's even better. If not, GUI mockups (and these could even be post-its on a flipover) work great. Better still if you use them to test actual use cases.

    I work with the Microsoft stack and we use Sketchflow for mocking GUI's.

    I have used it now for the first time on a project and it was a real help. The users finally started understanding their own requirements (and their implications) when they saw them implemented in the UI. Thanks to the mocks the business users realized that their requirements did not fullfill their actual needs, so we are now starting up a new "Phase 2" project.

    Yay! WTF-free UI discussion!



  • @blakeyrat said:

    Yay! WTF-free UI discussion!
    I use vi to mock-up my UIs.  Because my UIs are just command lines.



  • @bjolling said:

    we use Sketchflow for mocking GUI's.

    I have used it now for the first time on a project and it was a real help.

    +1. I like it.


Log in to reply