Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday August 23 2016, @07:27PM   Printer-friendly
from the push,-pull,-swipe,-turn-and-Pong dept.

Late for work in Manhattan, you push the crosswalk button and curse silently at the slowness of the signal change. You finally get a green light, cross the street, arrive at the office, get in the elevator and hit the close door (>|<) button to speed things along. Getting out on your target floor, you find that hurrying has you a bit hot under the collar, so you reach for the thermostat to turn up the air conditioning.

Each of these seemingly disconnected everyday buttons you pressed may have something in common: it is quite possible that none of them did a thing to influence the world around you. Any perceived impact may simply have been imaginary, a placebo effect giving you the illusion of control.

In the early 2000s, New York City transportation officials finally admitted what many had suspected: the majority of crosswalk buttons in the city are completely disconnected from the traffic light system. Thousands of these initially worked to request a signal change but most no longer do anything, even if their signage suggests otherwise.

[...] Today, a combination of carefully orchestrated automation and higher traffic has made most of these buttons obsolete. Citywide, there are around 100 crosswalk buttons that still work in NYC but close to 1,000 more that do nothing at all. So why not take them down? Removing the remaining nonfunctional buttons would cost the city millions, a potential waste of already limited funds for civic infrastructure.

More examples are quoted in linked article, and some suggestions how tech can make our lives more pleasant while waiting - Pong anyone?.

http://99percentinvisible.org/article/user-illusion-everyday-placebo-buttons-create-semblance-control/

-- submitted from IRC


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Insightful) by Anonymous Coward on Tuesday August 23 2016, @07:39PM

    by Anonymous Coward on Tuesday August 23 2016, @07:39PM (#392253)

    The progress bar that steady moves till near the end and then it inevitably gets stuck for a long-ass time before final (if you're lucky) completion. Whoever came with that, thou be a jackass.

    Starting Score:    0  points
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  

    Total Score:   1  
  • (Score: 0) by Anonymous Coward on Tuesday August 23 2016, @07:41PM

    by Anonymous Coward on Tuesday August 23 2016, @07:41PM (#392255)

    That. My fav is a download. Going full blast until about 98% then 0 bytes for 20 mins. Whattttt is it dooooing....

    • (Score: 0) by Anonymous Coward on Tuesday August 23 2016, @08:51PM

      by Anonymous Coward on Tuesday August 23 2016, @08:51PM (#392292)

      Pause and resume. Go back to full speed.

    • (Score: 3, Funny) by PartTimeZombie on Tuesday August 23 2016, @09:04PM

      by PartTimeZombie (4827) on Tuesday August 23 2016, @09:04PM (#392300)

      Yay!
      An XKCD [xkcd.com]

  • (Score: 0) by Anonymous Coward on Tuesday August 23 2016, @07:47PM

    by Anonymous Coward on Tuesday August 23 2016, @07:47PM (#392256)

    I remember in the old days, seeing a few that were poorly coded enough that they clipped through the other edge of the box containing them and kept going.

    I think it had something to do with making the progress bar a function of time elapsed, but not actually remembering to stop it at any point.

    • (Score: 0) by Anonymous Coward on Tuesday August 23 2016, @08:35PM

      by Anonymous Coward on Tuesday August 23 2016, @08:35PM (#392284)

      I wrote one of those once with two different methods that allowed overflowing progress bars. It also calculated the amount of progress as a function of a stored benchmark of how long a certain process took and did the math for a rough guess on time, which meant progress equaled elapsed time divided by the quantity of fudge factor multiplied by estimated time. Also, to keep people from thinking it stopped, I had an override to add one pixel after a huge amount of time (5 minutes, I think, and this was back when 1 pixel was considered huge). Both of those together could make the progress bar go way over in the wrong conditions.

    • (Score: 0) by Anonymous Coward on Tuesday August 23 2016, @09:07PM

      by Anonymous Coward on Tuesday August 23 2016, @09:07PM (#392304)

      poorly coded

      In my day we called it "programming" and not "coding" because coding was something you did when you were encoding data into a coded representation, and programming was something you did when you were writing programming instructions. Get off my lawn, dumb kid coder.

      • (Score: 0) by Anonymous Coward on Tuesday August 23 2016, @10:01PM

        by Anonymous Coward on Tuesday August 23 2016, @10:01PM (#392334)

        software developer

      • (Score: 2) by tibman on Tuesday August 23 2016, @10:03PM

        by tibman (134) Subscriber Badge on Tuesday August 23 2016, @10:03PM (#392335)

        Programming results in computer code. Not that big a deal to say something was poorly coded instead of poorly programmed. In ten years the gripe will probably be "In my day we called it 'engineering' and not 'programming' because programming was something you did when you were writing something without any architecture or standards." Something like that anyways : P

        --
        SN won't survive on lurkers alone. Write comments.
        • (Score: 0) by Anonymous Coward on Tuesday August 23 2016, @10:17PM

          by Anonymous Coward on Tuesday August 23 2016, @10:17PM (#392344)

          No you have history backwards. First it was applied mathematics, then it was computer engineering, then it was programming, then it was software development, then it was coding, and soon it will be brown-people-squeezing-out-a-shit. Actually I think we might already be at the shit stage.

      • (Score: 2) by dyingtolive on Tuesday August 23 2016, @11:23PM

        by dyingtolive (952) on Tuesday August 23 2016, @11:23PM (#392364)

        Guy who wrote the crappy progress bars, is that you?

        :D

        --
        Don't blame me, I voted for moose wang!
  • (Score: 2) by tangomargarine on Tuesday August 23 2016, @09:31PM

    by tangomargarine (667) on Tuesday August 23 2016, @09:31PM (#392317)

    Hey, if you're so smart, you write a better one.

    As frustrating as they may be, sometimes it's not *possible* to give an accurate prediction. And are you sure it was time elapsed, not % progress?

    --
    "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
    • (Score: 3, Insightful) by AthanasiusKircher on Tuesday August 23 2016, @09:51PM

      by AthanasiusKircher (5291) on Tuesday August 23 2016, @09:51PM (#392331) Journal

      As frustrating as they may be, sometimes it's not *possible* to give an accurate prediction.

      In which case, why bother to have one anyway?

      And are you sure it was time elapsed, not % progress?

      Regardless, progress bars, IMHO, should be reserved for situations where there's actually some sort of rough correlation between "progress" and "time." By placing a bar that fills up while moving in a particular direction, you are creating a sense of dimensionality that should correlate to SOMETHING. If it doesn't correlate (at least roughly) to time, then what does "progress" even mean?

      Now, you might say, "Well, it could be correlated to the number of files copied. You need to copy 100 files, but the last 3 files are a thousand times as big as the rest." Well, then are you really measuring "progress" in a meaningful sense? Most people don't care how many files are copied -- they want to know when something is going to be done.

      And if copying the files won't reasonably correlate with time, then maybe you should just get rid of the progress bar completely and just have a file counter displayed. Then you avoid the implicit association of dimensionality of progress (generally expected to correlate with time) that a "progress bar" indicates. If you have a bunch of different tasks, just put a checklist and indicate when each completes. Even better, put a little note on that checklist to steps that could take a lot longer than others, so users are prepared for it.

      I personally hate "progress bars." Unless you're doing some sort of linear task where the rate of completion is roughly constant in 99% of scenarios, I'd prefer they not be there at all.