• Len (unregistered) in reply to Simon
    Simon:
    Jens:
    Wow. That's a heavy WTF.

    I mean, deployment by "the coder compiles and puts in in the live system without any user instruction, information or interaction at all" shows a level of ineptitude that borders the imbecilic. Kolby really is a big mismatch between role and capabilities.

    That's what this WTF is about, right?

    That'd be my take, certainly. Sure, the original is kind of crappy, but you don't do a major UI rewrite, and put it into production without any kind of feedback from the people who actually have to use it.

    Came to post exactly this

  • (cs) in reply to Ol' Bob
    Ol' Bob:
    I Forget:
    The real WTF are those weird third world foreigners who think there is such a thing as 15 O'clock. :)

    Yeah - the military at least calls it "Fifteen-hundred hours". MUCH clearer! :-)

    Joke from about a hundred years ago:

    Q: "What time is it when the clock strikes thirteen?" A: "Time to get a new clock."

    21st-century version:

    Q: "What time is it when the clock strikes thirteen?" A: "Thirteen o'clock. Duh."

    (I like the old one better.)

    Nihilist version:

    Q: "What time is it when the clock strikes thirteen?" A: "Four-thirty, time for Wapner. Def'nitely time for Wapner."

  • You are allowed to have both pie and cake. (unregistered)

    It has been decreed that users may have both pie and cake, and they may order their dessert in any way that gets the order and the money to the cook,

    Programmer Fascists Must Die!

  • Friedrice The Great (unregistered) in reply to I Forget
    I Forget:
    The real WTF are those weird third world foreigners who think there is such a thing as 15 O'clock. :)
    There isn't. There is 15:00 hours. What is this "o'clock" thing you speak of? And I'm a first world American, thank you.
  • Friedrice The Great (unregistered) in reply to Mithrandir
    Mithrandir:
    I'll give Kolby the benefit of the doubt, and guess he hasn't had enough experience dealing with strongly task-focused UI's intended for users with little computer training.

    If he had, then he'd have realized that when you see a user interface that looks completely f**ing stupid, there's probably a reason. It may be a f**ing stupid reason like "the previous developer was even less experienced than you" or "the users were bitten by a rabid keyboard as a child and have all developed a phobia of typing", but there is a reason, and until you know what that reason is, you can't hope to improve the user experience.

    This is what happens when you allow programmers to design the user experience.

  • Bill C. (unregistered) in reply to Ol' Bob
    Ol' Bob:
    But the whole thing about using sliders to set dates - classic!
    After the slider passes quality assurance, you want to spend at least 12 minutes setting the date.
  • jo (unregistered)

    At the4 risk of starting WW VII.....

    A lot of WTF's these days seem to be that the user wants stupid things, rather than a techo DID stupid things (which I thought was more the pointof this site).

    Although in cases like this the users seem to be being very silly in not wanting a quicker process, as IT geeks we always have to remember that what the client wants is ultimately what signs our pay check. Sometimes we're lucky because the client wants something like "Provide a function that lets me do this quickly" which makes us happy, because that's what we think IT is a bout. Sometimes, though, we deal with clients who want things done a certain way and are not so interested in efficiency. While we can (tactfully, of course) suggest that there may be more efficient ways to do things (and even delicately put it to them that in our opinion the idea of using computers instead of pencils is because it makes things quicker) we also have to remember that the clients also have their own motivations (which are not necessarily about speed). If playing with sliders is seen by a client as more convenient than typing things in efficient, writing on a piece of paper or playing with any time control we can come up with - who are we to argue?

    Sometimes (in an ideal world most times) requirements are about optimizing a process. Sometimes, however, requirements are about aesthetics and what people are comfotable with. We are currently trying to replace an aging system where (in our opinion) a lot of the GUI is counter-intuitively designed leading to confusion, however one of the requirements from our customer is that "we know how things are that way, so any new GUI should (as much as possible) be the same - widgets in the same places, same mnemonics (which in some cases include using ones that in other apps you'd be accustomed to doing other stuff) and same tab orders". Whether justified or not, they have a concern that there'd be a massive training cost to changing the way things are done (from a user visibility perspective).

    Customers are often dumb (that's why they're not in IT) but they also have very non-IT requirements (ie things other than speed/efficiency). As a Systems/Business Analyst (or even architect) you might have some responsibility to recommend that they do things differently in the interest of efficiency - as a humble code monkey, however, you just do exactly what they ask of you....

  • Chris (unregistered) in reply to jay
    jay:
    Following on the idea of a no-keyboard GUI:

    So okay, you set up set of radio buttons for the hour, and another set for the minutes.

    A row of 12 radio buttons and then another for am/pm would be busy but not unmanageable. Even if they use 24-hour time and so want 24 buttons, two rows of 12 doesn't seem too bad.

    If they have to be able to schedule down to the minute, and thus need 60 buttons for the minute, that would be ugly. But if they always schedule 0, 15, 30, or 45, that wouldn't be bad at all. Even if any multiple of 5 is legal, that makes 12 buttons for the minute. Ooh, that gives a nice symmetry with 12 or 24 buttons for the hour.

    Such a screen wouldn't be my first choice, but if the user insists on keyboardless entry, it's not totally horrifying.

    As someone or other said, a dropdown is also possible.

    MEH two circles of radioboxes - one inside the other. 12 equally spaced on the inside for hours, 60 equally spaced on the outside for minutes. And lines drawn from the centre to visually display what they chose. We could even put 12 on top and start from 1 to the right.....

  • (cs)

    "I don’t know what you did to our scheduler, but it needs to be fixed right away. The Quality Control managers want the text boxes back so they don’t have to click and drag so much!"

  • Chuck (unregistered) in reply to jay

    Oh god how do I bookmark a comment

  • jonesy (unregistered) in reply to Chris
    Chris:
    jay:
    Following on the idea of a no-keyboard GUI:

    So okay, you set up set of radio buttons for the hour, and another set for the minutes.

    A row of 12 radio buttons and then another for am/pm would be busy but not unmanageable. Even if they use 24-hour time and so want 24 buttons, two rows of 12 doesn't seem too bad.

    If they have to be able to schedule down to the minute, and thus need 60 buttons for the minute, that would be ugly. But if they always schedule 0, 15, 30, or 45, that wouldn't be bad at all. Even if any multiple of 5 is legal, that makes 12 buttons for the minute. Ooh, that gives a nice symmetry with 12 or 24 buttons for the hour.

    Such a screen wouldn't be my first choice, but if the user insists on keyboardless entry, it's not totally horrifying.

    As someone or other said, a dropdown is also possible.

    MEH two circles of radioboxes - one inside the other. 12 equally spaced on the inside for hours, 60 equally spaced on the outside for minutes. And lines drawn from the centre to visually display what they chose. We could even put 12 on top and start from 1 to the right.....
    What MEH? Manchester Emergency Hospital from yesterday?

  • Chuck (unregistered)

    So the real wtf is that they hired 6 developers instead of 1 designer and 1 developer.

  • A Money mouse (unregistered) in reply to Ol' Bob

    I honestly wish the "Software Curmudgeon's Phrasebook" was a real thing. I would buy that instantly.

    Anyway, can't you use a rolling selector or an up-down selector? Obviously the interface would have to be tweaked, but that's the idea. That's something you can use completely without a keyboard.

    CAPTCHA: aliquam. That wham, bam, aliquam coding style is always good for business, especially when you're an independent contractor.

  • Suggester of Helpfuls (unregistered)

    Next they'll ask for every text entry box to be replaced with a slider representing the keyboard keys, and a back/next to move the edit point.

    O.o

  • Kyle (unregistered) in reply to Ol' Bob

    Agreed, but it's much easier to pick up "one five zero zero", or "one five" for short, over a radio.

  • (cs)

    That's the most retarded UI I've seen in a while (even if not the ugliest; the colors are at least all standard). Click a checkbox to say “I'm editing this one” then move the sliders to adjust the time, and then rinse and repeat for the other 27 fields? Absolutely nuts. The only way it could have been more stupid would be if there was a single slider for picking times throughout the day.

    And someone wanted to do it that way?

  • iMalc (unregistered)

    Okay so it's not a coding problem, it's a requirements problem. Get the BAs, the customer representatives, and the QAs into the same room and don't allow them to leave until they've sorted their erm 'stuff' out.

    Likely end result: Separate sliders for the first digit of the minutes and one the second digit of the minutes. Plus instantly updated tool-tips, or numbered graduations.

  • ThomasX (unregistered) in reply to Simon
    Simon :
    That'd be my take, certainly. Sure, the original is kind of crappy, but you don't do a major UI rewrite, and put it into production without any kind of feedback from the people who actually have to use it.

    This reminds me of Visual Studio 2012...

  • Simon (unregistered) in reply to jay
    jay:
    Years ago I saw a poster labeled "System Development Lifecycle". It went something like this:
    1. Write the programs
    2. Deploy to production
    3. Test
    4. Get requirements from users
    5. Growing panic
    6. Search for the guilty
    7. Punishment of the innocent
    8. Bonuses and promotions for the non-participants

    Not too far out, but normally you at least have some user requirements before step 1. They're just not the ones the users actually require...

  • faoileag (unregistered) in reply to Simon
    Simon:
    jay:
    Years ago I saw a poster labeled "System Development Lifecycle". It went something like this:
    1. Write the programs
    2. Deploy to production
    3. Test
    4. Get requirements from users
    5. Growing panic
    6. Search for the guilty
    7. Punishment of the innocent
    8. Bonuses and promotions for the non-participants

    Not too far out, but normally you at least have some user requirements before step 1. They're just not the ones the users actually require...

    Or are supplied to the developers who write the programs. Having requirements is one thing; communicating them another :-)

  • smurf (unregistered) in reply to CodeMonkey

    How about a button grid for hours and minutes. She could have selected the time with only two clicks and no keyboard interaction.

    Yep, the WTF is the untested user interface. I'd put a mockup of a new inteface in front of her and ask her if she likes it before implementing?

  • chris (unregistered) in reply to Chris
    Chris:
    jay:
    Following on the idea of a no-keyboard GUI:

    So okay, you set up set of radio buttons for the hour, and another set for the minutes.

    A row of 12 radio buttons and then another for am/pm would be busy but not unmanageable. Even if they use 24-hour time and so want 24 buttons, two rows of 12 doesn't seem too bad.

    If they have to be able to schedule down to the minute, and thus need 60 buttons for the minute, that would be ugly. But if they always schedule 0, 15, 30, or 45, that wouldn't be bad at all. Even if any multiple of 5 is legal, that makes 12 buttons for the minute. Ooh, that gives a nice symmetry with 12 or 24 buttons for the hour.

    Such a screen wouldn't be my first choice, but if the user insists on keyboardless entry, it's not totally horrifying.

    As someone or other said, a dropdown is also possible.

    MEH two circles of radioboxes - one inside the other. 12 equally spaced on the inside for hours, 60 equally spaced on the outside for minutes. And lines drawn from the centre to visually display what they chose. We could even put 12 on top and start from 1 to the right.....
    There must be a few circular slider/drag controls out in open source by now (think music software: pitch wheels, etc). Why not just arrange two or three of those concentrically on the screen, then as a bonus, dragging the "seconds" slider gives you accurate control over the "minutes" slider, just like on a real wall-clock.

  • (cs)

    I'd go for the 'button grids' option myself.

    Two clicks, and you can set an exact time.

    Or even have 3 synchronised entry methods - button grid, slider and text boxes

    --

    Although, this is rather worrying: "The manager slid the bottom knob a pixel at a time until the minute value landed at 15:00."

    Maybe the manager needed a clout around the head. Setting the minute value to '15:00' is impossible. But, assuming the author means 'until the minute value landed at 00', surely that's one of the the simplest settings you could have. Drag left until you can't drag any further. If it takes more than 1 second, then you have problem that's far outside the realms of the UI design.

  • Neil (unregistered)

    TRWTF is not setting the page increment to something reasonable (i.e. near sqrt(N)). And no, N is not a reasonable page increment, especially on instant-apply controls. You know who you are.

  • Paul M (unregistered) in reply to da Doctah

    Q: "What time is it when the clock strikes thirteen?" A: "Nineteen Eighty-Four"

    If you don't geddit, you need to read the book.

  • Valued Service (unregistered)

    Or, don't commit to the database until you hit the big BOLD SAVE BUTTON.

    Geez.

  • jay (unregistered) in reply to Suggester of Helpfuls
    Suggester of Helpfuls:
    Next they'll ask for every text entry box to be replaced with a slider representing the keyboard keys, and a back/next to move the edit point.

    O.o

    Hey, now that you mention it, that sounds like a really great idea ...

    Every now and then I tell make an obviously ridiculous suggestion to users to make a point. And sometimes I have to kick myself because they decide that, yes, that's exactly what they want.

  • jay (unregistered) in reply to pscs
    pscs:
    I'd go for the 'button grids' option myself.

    Two clicks, and you can set an exact time.

    Or even have 3 synchronised entry methods - button grid, slider and text boxes

    --

    Although, this is rather worrying: "The manager slid the bottom knob a pixel at a time until the minute value landed at 15:00."

    Maybe the manager needed a clout around the head. Setting the minute value to '15:00' is impossible. But, assuming the author means 'until the minute value landed at 00', surely that's one of the the simplest settings you could have. Drag left until you can't drag any further. If it takes more than 1 second, then you have problem that's far outside the realms of the UI design.

    In fairness: The original premise of the story was that the interface was too slow. Maybe the slider just wouldn't drag that fast. You position the mouse over it and drag left ... and the slider lags behind.

  • jay (unregistered)

    Speaking on the whole issue of changing the interface without consulting the users:

    G.K. Chesterton once wrote -- and this is not an exact quote, just a paraphrase, I'm too lazy to look it up for a casual forum post -- that you should never allow someone to change or abolish a rule unless he can clearly explain why the rule was established in the first place. Like, if someone tells you that this rule was originally put in place in 1940 because shipments then were received by train and that created thus and thus a situation which no longer applies now that we get shipments by truck, so we really should change the rule, then, assuming he convinces you that he knows what he's talking about, he can be trusted to change the rule. But if you ask him why this rule was originally made, and his only answer is "because those people were idiots!", don't let him near the rulebook. Even if their reasons were stupid, they must have had some reason for what they did that made sense to them at the time. Know what it is before you go tearing things up.

    I think the same applies to software design, especially a user interface.

    (Even though I am an American, I can acknowledge the existence of British writers. :-)

  • Decius (unregistered) in reply to Kyle
    Kyle:
    Agreed, but it's much easier to pick up "one five zero zero", or "one five" for short, over a radio.

    Or even better, "one fife zero zero" or "Fifteen hundred") if using proper radiotelephony.

  • Norman Diamond (unregistered) in reply to jay
    jay:
    In fairness: The original premise of the story was that the interface was too slow. Maybe the slider just wouldn't drag that fast. You position the mouse over it and drag left ... and the slider lags behind.
    "Wanna drag?"

    "Yeah."

    "Yeah?"

    "Yeah."

    Vroom vroom vroom.

    Vroom vroom vroom.

    And then a race condition as each slider reluctantly drags along behind the other one.

  • SteGriff (unregistered)

    Make the sliders fill the width of the form... at least until you can get authorized to replace them.

  • Anonymous (unregistered)

    Jesus. Fucking. Christ. Are you guys kidding? Judging from the OP it sounds like he identified the problem. A terrible UI. Fine grained sliders are really hard to get right, and general mice are really inaccurate when you need fine grained control. And regardless, sliders are a terrible UI for entering time. The OP solved the problem appropriately.

    I'm assuming that he did show the users the interface and that after he was gone the lusers complained to management simply because they don't like change. It takes way more energy to drag a slider to the correct position than it does to type the correct time. It astonishes me how even so called software developers and engineers think mice (or now, "touch") are superior forms of input.

    Mice are actually pretty terrible input devices. It requires way more effort to use a mouse than it does the keyboard. As usual with things of this nature, the mouse has a shallower learning curve than the keyboard, but is ultimately inferior.

    The story cuts off, but I assume that Kolby went on to explain to the caller that the sliders were responsible for the bottleneck in the process and that's why he made the change.

  • IN-HOUSE-CHAMP (unregistered) in reply to FragFrog

    They must be on some kind of virtualized desktop. Virtualization will screw up your UI faster than you can spell "Patrick P. Gelsinger"

    FragFrog:
    Wait, it takes her three minutes to move a slider? I mean, sure, it's not the most efficient interface, but getting it at the general location and nudging it a few pixels to adjust should take no more then twenty, thirty seconds at most?

Leave a comment on “Manual Time Entry”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article