Announcement

Collapse
No announcement yet.

"1/10 second" rule

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • "1/10 second" rule

    Just for not hijacking another thread, I thought I would ask just exactly what is the "1/10 second rule"?

    In my mind, its application specific, and faster than a human will react because they think something is "Locked-Up" because it takes longer than the user would think. So it keeps "Display" vs "Actual Work" on a happy balance

    Just to ask, if its something we come about with time? (I usually adhere to this rule myself, or display something to show not locked up), or is there an actual "Coined rule"???

    Only reason I ask, is cause an incident at the gas pump, and wonder "Why 9/10ths of a cent??" till I learned the meaning of milles sorta thing

    (amazing what you learn from the past)
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

  • #2
    Cliff
    I think it is also user specific, some classes of users will very quickly start clicking buttons because the think something is wrong, on the other hand I have programs for myself that will "white screen" for 5 to 10 minutes but then as the programs run for days and I know why its not a problem.
    The only reason I can think of for the selection of 1/10th second is that it is approximately the length of a time slice and so if the computer is very busy with many jobs then the actual period of the "white screen" could be somewhat longer.
    John

    Comment


    • #3
      If Mr. Petzold says its a rule, it's a rule.

      See recent thread from Mr. Doty.... users were clicking on a button a second (third? fourth?) time because the program did not react - or least they did not SEE a reaction - quickly enough for them to believe they actually clicked the button the first time. The extra 'clicks' got queued up and - as they should have - were processed again when the program finished whatever it was doing "on click" and was once again ready to process user-generated notifications.


      I think it is also user specific, some classes of users will very quickly start clicking buttons because the think something is wrong
      In my experience there is only ONE class of users who do this: All of them.


      MCM
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        I have often seen warnings "Do not click SUBMIT again or your credit card may be charged twice". Perhaps enough times of seeing that warning -- or dealing with the consequences of ignoring it -- will help start getting users accustomed to not decuple-click. Shutting down properly is now an accepted practice, though it once seemed strange.
        Erich Schulman (KT4VOL/KTN4CA)
        Go Big Orange

        Comment


        • #5
          I can't even guess the percentage split, but I'd say a good number of those who keep clicking, or hitting Return don't think the program didn't notice, but are merely impatient and taking it out on the thing they already have their fingers or mouse on.

          We have a big ongoing project at work to chage over from a CICS based environment to a web based one. Whatever else folks might think of IBM, they've done a pretty good job at making CICS (and COBOL and DB2) work well together, and work fast. The users were used to nearly instant response from CICS. They were not so happy with waiting 2-4 seconds for the web version of the same application, and ofen mentioned that on the satisfaction surveys. We ended up writing a pass-though step on the server that popped up a screen that said, more or less, "Processing. Thank you for your patience" depending on the function requested, and then went on with the real processing. This cut the slowness complaints by more than 2/3rds. (The other 1/3rd were mostly folks who we knew were determined to be unhappy with the New Thing.)

          Lesson learned: acknowledge the user command as quickly as possible, and let them know if they might have to wait more than a few seconds.

          Seems obvious enough, and yet a lot of good applications leave you hanging for a while.
          The boy just ain't right.

          Comment


          • #6
            Originally posted by Michael Mattias View Post
            If Mr. Petzold says its a rule, it's a rule.

            See recent thread from Mr. Doty.... users were clicking on a button a second (third? fourth?) time because the program did not react - or least they did not SEE a reaction - quickly enough for them to believe they actually clicked the button the first time. The extra 'clicks' got queued up and - as they should have - were processed again when the program finished whatever it was doing "on click" and was once again ready to process user-generated notifications. MCM
            You can't be serious, surely there aren't programmers who as a first action on the click of an important button don't disable the button.

            Comment


            • #7
              It is possible to double click on a disabled button and the clicks are queued.
              Solution was to execute some DOEVENTS and down the road put into a separate thread.
              On my test system FOR X = 1 to 4: DOEVENTS:NEXT fixed it.
              I thought this was impossible, but was able to duplicate it.
              Last edited by Mike Doty; 15 Oct 2008, 11:52 AM.
              The world is full of apathy, but who cares?

              Comment


              • #8
                Originally posted by Joseph Cote View Post
                We have a big ongoing project at work to chage over from a CICS based environment to a web based one.
                I wish your company luck.
                Just over 2 years ago a company I had consulted to many years earlier begged me to come back (first parting was a little less than friendly but as I respected the person who asked I did) to advise on a new package basically to run the company (they had run my previous recommedation happily for a number of years but outgrown it).
                They had just been bought by a major public company and the responsible director suggested looking at a well known Web Package which I did along with many other packages. My recommendation, an in house running package, the director disagreed (hey I got well paid so what) and put in the Web based.
                One year later they asked me back, wrote off a $250,000 cost of the web based package and paid me again (much less I have ethics) to confirm my original recommendation which they are now very happy with.
                Why not Web Based? Apart from the obvious of speed everything is displayed by a web browser. Which one? Which version? Very hard for a programmer to control where the window is displayed, its size (given different screen resolutions) controlling focus etc etc that are usual in normal windows programming are extremely difficult in applications that use web browsers.
                For very good reasons (for their future profits) MS, Google etc say this is the way of the future, it may be but my experience is not yet.

                Comment


                • #9
                  Originally posted by Mike Doty View Post
                  It is possible to double click on a disabled button and the clicks are queued.
                  Thanks Mike I didn't know that. Being an old fashioned "belt and braces man" I normally for important code put in a Static busy or in use flag as well so havn't seen it (didn't say that earlier, thought people would laugh)

                  Comment


                  • #10
                    Hence, on click...

                    - disable
                    - start thread function
                    - re-enable on completion of thread function

                    .... makes sense, after all?

                    However, I think the 'problem' here was with how "DDT" implements CONTROL DISABLE... if it requires a DIALOG DOEVENTS (posts WM_ENABLE), then that's why Mike's code did not effect the disable. If it does a SEND of WM_ENABLE the effect should be immediate. But CONTROL DISABLE is proprietary so we don't know how it's done.

                    FWIW, from SDK doc: EnableWindow() API sends WM_CANCELMODE followed by WM_ENABLE.

                    MCM
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      Originally posted by John Petty View Post
                      One year later they asked me back, wrote off a $250,000 cost of the web based package and paid me again (much less I have ethics) to confirm my original recommendation which they are now very happy with.
                      Why not Web Based? Apart from the obvious of speed everything is displayed by a web browser. Which one? Which version? Very hard for a programmer to control where the window is displayed, its size (given different screen resolutions) controlling focus etc etc that are usual in normal windows programming are extremely difficult in applications that use web browsers.
                      For very good reasons (for their future profits) MS, Google etc say this is the way of the future, it may be but my experience is not yet.
                      Since this is an entirely home-grown project, we're not dealing with anybody else's framework. And since the desktop is dictated by our IT standards folks, we know that *everybody* is running IE6 on XPPro/SP2 etc. It does work pretty well, and we're about 80-90% done with the conversion (after eight years...) so I'd say this one has worked out. The users get way more info per screen than the 80-by-24 CICS pages. Navigation is a lot easier for them. And we've automated a lot of things that had been done via mainframe batch before. (Example: a specific legal document would need to be created. old way was special letterhead on the mainframe printer. New way, web app creates a PDF file that can be printed on a local laserprinter and mailed off right away. Or a new thing we're trying, e-mailing the doc to the client right from the web app.)
                      Last edited by Joseph Cote; 15 Oct 2008, 03:58 PM.
                      The boy just ain't right.

                      Comment


                      • #12
                        WOW did I spurn a new one.

                        All in all the original question inadvertently answered the original question. "Why 1/10th of a second"???

                        Answer is: "Application Specific"

                        and why??
                        1. Faster than a human can normally "Double-Click"
                        2. If a "Double-Click" then code can account for it
                        3. Allow or Dis-Allow according to you specific needs
                        4. Users that can click faster than that...ummm REALLLLY need to step away from the


                        All in all, users are like kids on crack-phones...instant gratification, or something is wrong.

                        Display is EVERYTHING but strategically placed, shows the end user what they want (although slows things down unless strategically threaded), but the user will NEVER know (unless you can blink faster than that
                        Engineer's Motto: If it aint broke take it apart and fix it

                        "If at 1st you don't succeed... call it version 1.0"

                        "Half of Programming is coding"....."The other 90% is DEBUGGING"

                        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                        Comment


                        • #13
                          FOR X = 1 to 4: DOEVENTS:NEXT
                          That is like using a sledgehammer on the message queue.
                          SDK programming provides mechanisms to remove a specific message or range of messages from the queue.
                          For example, to remove all mouse messages, use code similar to the following:
                          Code:
                            WHILE PeekMessage(tmsg, hWnd, %WM_MOUSEFIRST, %WM_MOUSELAST, %PM_REMOVE)
                            WEND
                          Dominic Mitchell
                          Phoenix Visual Designer
                          http://www.phnxthunder.com

                          Comment


                          • #14
                            ... exactly what is the "1/10 second rule"? ... is there an actual "Coined rule"???
                            From "Programming Windows 95" by Charles Petzold, chapter 14

                            The first attempt by Microsoft ... to implement multitasking in a quasi-DOS/Windows enviroment was OS/2 and the Presentation Manager (PM)......

                            ..Thus PM programmers learned how to divide their programs into one message-queue thread that created all windows processed messages to them, and one or more non-message-queue threads that performed lengthy background tasks. PM programmers also learned about the "1/10 second rule." Basically, they were advised that a message-queue thread spend no more than 1/10 second processing any message. Anything that takes longer should be done in a different thread. If all programmers followed this rule, no PM program could hang the system for more than 1/10 second."

                            [ new section, "The Windows Advantage"]

                            ... I mentioned earlier the "1/10 second rule." Well, loading a large file into memory may take longer than 1/10 second. Does this mean that file-loading routines should be implemented in separate threads? Not Necessarily. When a user commands a program to open a file, he or she usually wants that operation carried out immediately. Putting the file-loading routines in a separate thread simply adds overhead. It's just not worth it, even if you want to boast to your friends you write multithreaded programs!

                            Three points..

                            1. Mr. Petzold nowhere discusses "who" came up with the 1/10 second figure or "when" they did so. (Not that I can find, anyway).

                            2. I am somewhat surprised he doesn't mention (not that I can find, anyway), the "white empty screen" phenomenon which occurs when a window procedure is busy processing a message and the window needs to be repainted for some other reason.

                            3. Regardless, your window procedure will only process one (1) queued message at a time. If you load a file in response to a button click (WM_COMMAND notification message), ain't no more queue messages (eg WM_PAINT, the 'redraw' message) gonna be handled until the processing of that WM_COMMAND message is completed.
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              PekkMessage vs DOEVENTS 4 times

                              'PeekMessage definitely works, thank you.
                              'The hammer DOEVENTS4 takes care of a blank control and flicker.
                              'Tried using DIALOG and CONTROL REDRAW instead of DOEVENTS4 and get flicker.
                              '------------------------------------------------------------------------------------------------------------------
                              'Added this remark at 9:54 AM
                              'DOEVENTS4 also allows scrolling the listview while it is being updated and moving the dialog around the screen. I like it.
                              '------------------------------------------------------------------------------------------------------------------

                              Code:
                              FUNCTION DisplayRecordSet(hDlg AS DWORD) AS DWORD
                                LOCAL row AS DWORD, col AS LONG, ColumnCount AS LONG
                               
                                LOCAL counter AS LONG  'not needed
                               
                                LOCAL x AS LONG
                                CONTROL DISABLE hDlg, %LISTVIEW
                                CONTROL KILL hDlg, %LISTVIEW
                                CONTROL ADD "SysListView32", hDlg, %LISTVIEW, "SysListView32_1", 0, 21, _
                                      466, 257, %WS_CHILD OR %WS_VISIBLE OR %LVS_REPORT, %WS_EX_CLIENTEDGE _
                                      OR %WS_EX_LEFT OR %WS_EX_RIGHTSCROLLBAR
                               
                                'ColumnCount = slGetColumnCount
                                ColumnCount = 8
                                IF ColumnCount THEN
                                      MOUSEPTR 11
                                  LISTVIEW SET STYLE hDlg, %LISTVIEW, %LVS_EX_GRIDLINES OR %LVS_EX_FULLROWSELECT
                                  FOR col = 1 TO ColumnCount   'Insert columns with column names
                                    'LISTVIEW INSERT COLUMN hDlg, %LISTVIEW,col,slGetColumnName(col),100,0
                                    LISTVIEW INSERT COLUMN hDlg, %LISTVIEW, col, "col" + STR$(col), 100,0
                                  NEXT
                                ELSE
                                  ? "No columns"
                                  EXIT FUNCTION
                                END IF
                               
                                row = 0
                                counter = 0 
                                DO WHILE row < 10000   'modified this later, had a SQLitening function here  9:34 AM, CST
                                  INCR row
                                  INCR counter
                                  'LISTVIEW INSERT ITEM hDlg, %LISTVIEW,row, 0 , slF(1) 'Insert row, 0=no image
                                  LISTVIEW INSERT ITEM hDlg, %LISTVIEW, row, 0, "col" + STR$(counter)
                                  FOR col = 2 TO ColumnCount                               'add text into columns
                                    'LISTVIEW SET TEXT hDlg, %LISTVIEW, row, col,slF(col)
                                    INCR counter
                                    LISTVIEW SET TEXT hDlg, %LISTVIEW, row, col, "col"+ STR$(counter)
                                  NEXT
                                  IF row =30 THEN
                                    CONTROL REDRAW hDlg, %LISTVIEW
                                  ELSEIF ROW MOD 1000 = 0  THEN          'refresh screen every so often
                                    Message hDlg, "Reading record" + STR$(row)
                                    DOEVENTS4
                                  END IF
                                LOOP
                                CONTROL SHOW STATE hdlg, %LISTVIEW, %SW_HIDE
                                FOR col = 1 TO ColumnCount   'fit columns
                                  LISTVIEW FIT CONTENT hDlg, %LISTVIEW, col
                                NEXT
                                CONTROL SHOW STATE hDlg, %LISTVIEW, %SW_SHOW
                                Message hDlg, "Total records" + STR$(row)
                                MOUSEPTR 1
                                FUNCTION = row
                                WHILE PeekMessage($NUL, hDlg, %WM_MOUSEFIRST, %WM_MOUSELAST, %PM_REMOVE):  WEND   'clear message queue
                                'DOEVENTS4
                              END FUNCTION
                              Last edited by Mike Doty; 16 Oct 2008, 09:56 AM.
                              The world is full of apathy, but who cares?

                              Comment


                              • #16
                                Inquiring minds want to know....

                                Why would you use all the new 'LISTVIEW do this' commands, except when you add the listview control to the screen, where you use "CONTROL ADD "SysListView32"..."

                                "CONTROL ADD LISTVIEW" would seem to be more consistent, wouldn't it?

                                MCM
                                Michael Mattias
                                Tal Systems (retired)
                                Port Washington WI USA
                                [email protected]
                                http://www.talsystems.com

                                Comment


                                • #17
                                  PBFORMS uses that name as a default.
                                  The world is full of apathy, but who cares?

                                  Comment


                                  • #18
                                    Just a little note , more or less related...

                                    I guess PowerBASIC Inc. is getting really serious about "we want you all to code DDT style."

                                    The dialog and image editors are no longer installed with PB/Win 9x. PB Support gave me some hokum response about 32 v 64 bit Windows with these 16-bit applications, but I have my own theory about why these tools were dropped frrm the release WITHOUT AN ENTRY IN THE 'WHAT'S NEW' section of the help file.


                                    MCM
                                    Michael Mattias
                                    Tal Systems (retired)
                                    Port Washington WI USA
                                    [email protected]
                                    http://www.talsystems.com

                                    Comment


                                    • #19
                                      DOEVENTS4 also allows scrolling the listview while it is being updated and moving the dialog around the screen. I like it.
                                      That is actually the poor man's multithreading tool, a holdover from 16-bit Windows.
                                      In 32-bit Windows MsgWaitForMultipleObjects is used to solve these problems.
                                      But you need access to the message loop to implement it.
                                      Dominic Mitchell
                                      Phoenix Visual Designer
                                      http://www.phnxthunder.com

                                      Comment


                                      • #20
                                        But you need access to the message loop to implement it
                                        Correct me if I'm wrong here, but I think the PB compilers support coding SDK-style, where you DO have such access.....
                                        Michael Mattias
                                        Tal Systems (retired)
                                        Port Washington WI USA
                                        [email protected]
                                        http://www.talsystems.com

                                        Comment

                                        Working...
                                        X