Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43316

When developer selects text it should pause karaoke

    Details

    • Similar Issues:
    • Sprint:
      Blue Ocean 1.1, Blue Ocean 1.1, Blue Ocean 1.2-beta1, Blue Ocean 1.4 - beta 3, Blue Ocean 1.4 - beta 2, Blue Ocean 1.6 - beta 2, Blue Ocean - 1.6 - beta 4

      Description

      Steps to reproduce

      1. I am viewing the running Pipeline defined in the example below
      2. Step 1 of stage 1 is executing. I select its text with my mouse to copy and paste or interact with the log in some way (selecting, clicking, etc - I am focused on this log as its streaming)
      3. Step 1 of stage 1 finishes and Step 1 of Stage 2 starts executing
      4. My focus is ripped away from Step 1 of Stage 1 to Step 1 of Stage 2.

      What should happen
      When I open step 1 of stage 1, karaoke should not move my focus to Step 1 of Stage 2.

      Example

      pipeline {
          agent any
          stages {
              stage('1') {
                  steps {
                      sh 'ping -c 10 localhost'
                  }
              }
              stage('2') {
                  steps {
                      sh 'ping -c 50 localhost'
                  }
              }
          }
      }
      

        Attachments

          Issue Links

            Activity

            Hide
            cliffmeyers Cliff Meyers added a comment -

            Piggy-backing on this, it would be cool if pressing the "HOME" key (which scrolls browser to the top) also disabled karaoke.

            I wonder if it would be easier to code the logic so that a mouse event or keyboard event stops karaoke, except in the following cases:

            • User pressed "END" key (to scroll to bottom)
            • User scrolled log console to very bottom

            Maybe also on a mouse click that isn't an interactive element. It's hard to say which approach is the right way, but it feels like most of the time when the user begins interacting that it's safe to assume we should stop scrolling. I could be wrong, but thought it was worth discussing.

            Show
            cliffmeyers Cliff Meyers added a comment - Piggy-backing on this, it would be cool if pressing the "HOME" key (which scrolls browser to the top) also disabled karaoke. I wonder if it would be easier to code the logic so that a mouse event or keyboard event stops karaoke, except in the following cases: User pressed "END" key (to scroll to bottom) User scrolled log console to very bottom Maybe also on a mouse click that isn't an interactive element. It's hard to say which approach is the right way, but it feels like most of the time when the user begins interacting that it's safe to assume we should stop scrolling. I could be wrong, but thought it was worth discussing.
            Hide
            cliffmeyers Cliff Meyers added a comment -

            Pausing this until clarification is provided on JENKINS-44342

            Show
            cliffmeyers Cliff Meyers added a comment - Pausing this until clarification is provided on JENKINS-44342
            Hide
            dragoonis Paul Dragoonis added a comment - - edited

            Cliff Meyers

            keystrokes and mouse movement on the page in general is OK i would say and shouldn't affect karaoke because they've not expressed intent to pause and see something. HOME and END are just panning around the screen and they haven't engaged with the pipeline (stages/steps) itself yet.

            Based on my experience and the experiences of client's developers using BO. I sit behind them and watch them use it as well as hear regular feedback from them.

            What I would say is a user's desire to stop this would be:

            1. clicking on a stage icon
              • this should pause karaoke and show the steps below
            2. clicking on a step row 
              • when you click on a step to expand it if new steps start kicking in, it shouldn't jump your page anchor around but instead append the step to the end of the steps list. The extra added step should be collapsed and shouldn't affect the current step you've chosen to expand
            Show
            dragoonis Paul Dragoonis added a comment - - edited Cliff Meyers keystrokes and mouse movement on the page in general is OK i would say and shouldn't affect karaoke because they've not expressed intent to pause and see something. HOME and END are just panning around the screen and they haven't engaged with the pipeline (stages/steps) itself yet. Based on my experience and the experiences of client's developers using BO. I sit behind them and watch them use it as well as hear regular feedback from them. What I would say is a user's desire to stop this would be: clicking on a stage icon this should pause karaoke and show the steps below clicking on a step row  when you click on a step to expand it if new steps start kicking in, it shouldn't jump your page anchor around but instead append the step to the end of the steps list. The extra added step should be collapsed and shouldn't affect the current step you've chosen to expand
            Hide
            stevenfoster Steven Foster added a comment -

            For me, pressing home means I'm done looking at the logs right now and want to see something in the pipeline view. So I would +1 the suggestion to pause karaoke when pressing home.

            Show
            stevenfoster Steven Foster added a comment - For me, pressing home means I'm done looking at the logs right now and want to see something in the pipeline view. So I would +1 the suggestion to pause karaoke when pressing home.
            Hide
            dragoonis Paul Dragoonis added a comment -

            Guys - you're making this way over complicated.

            When you click on a stage or step (to expand its contents) it will pause. When it's paused there's a `position:fixed` in the top right saying "Karaoke: paused" and you can click on it to unpause.

            Simples. 

            ..

            All these implicit rules over complicate things and make for a poor DX .. having an explicit button always visible to unpause it at the dev's discretion is explicit and a good DX.

             

            Show
            dragoonis Paul Dragoonis added a comment - Guys - you're making this way over complicated. When you click on a stage or step (to expand its contents) it will pause. When it's paused there's a `position:fixed` in the top right saying "Karaoke: paused" and you can click on it to unpause. Simples.  .. All these implicit rules over complicate things and make for a poor DX .. having an explicit button always visible to unpause it at the dev's discretion is explicit and a good DX.  
            Hide
            sophistifunk Josh McDonald added a comment -

            .... which will immediately be mistaken by 25% of users to think it means their build has been paused.

             

            It's not always as easy as we think

            Show
            sophistifunk Josh McDonald added a comment - .... which will immediately be mistaken by 25% of users to think it means their build has been paused.   It's not always as easy as we think
            Hide
            dragoonis Paul Dragoonis added a comment -

            Yes, so that's why we use language that isn't ambiguous. So we don't use "paused, aborted, running, failed".

             

            I propose we do "Karaoke: <Switch_Slider>" just like this: http://gfazioli.github.io/react-switch-button/#demo

             

            If we use the on/off terminology it's non conflicting and  the UI element removes any need for language.

             

             

            Show
            dragoonis Paul Dragoonis added a comment - Yes, so that's why we use language that isn't ambiguous. So we don't use "paused, aborted, running, failed".   I propose we do "Karaoke: <Switch_Slider>" just like this: http://gfazioli.github.io/react-switch-button/#demo   If we use the on/off terminology it's non conflicting and  the UI element removes any need for language.    
            Hide
            cliffmeyers Cliff Meyers added a comment -

            Being able to use SPACE, PGUP, PGDOWN, END and HOME is important because it is default browser behavior for scrolling pages. In the current impl, that behavior is broken because of some complex nested overflow and scroll policy. The user needs to click into the scrollable area to ensure focus is correct so those keyboard events are handled. That's the first problem that ought to be fixed: if I'm on the results page, pressing HOME should scroll to the top of active log. The other keys should work too.

            If we properly support those keys, then we need to think about how karaoke should or shouldn't continue to operate. My proposal was, simply, "if the user is moving around in the logs, don't automatically scroll the UI." The exception being that if they jump to the bottom of the logs, it probably makes sense to continue to show them what's currently happening.

            It may sound "overcomplicated" but really it's just a proposal to align with end user intent. Giving them a button to toggle karaoke is just another step for the user - one that requires they use a mouse. Not all developers like mice: just ask the thousands (millions) of developers that use vim or emacs as they primary editor.

            Show
            cliffmeyers Cliff Meyers added a comment - Being able to use SPACE, PGUP, PGDOWN, END and HOME is important because it is default browser behavior for scrolling pages . In the current impl, that behavior is broken because of some complex nested overflow and scroll policy. The user needs to click into the scrollable area to ensure focus is correct so those keyboard events are handled. That's the first problem that ought to be fixed: if I'm on the results page, pressing HOME should scroll to the top of active log. The other keys should work too. If we properly support those keys, then we need to think about how karaoke should or shouldn't continue to operate. My proposal was, simply, "if the user is moving around in the logs, don't automatically scroll the UI." The exception being that if they jump to the bottom of the logs, it probably makes sense to continue to show them what's currently happening. It may sound "overcomplicated" but really it's just a proposal to align with end user intent. Giving them a button to toggle karaoke is just another step for the user - one that requires they use a mouse. Not all developers like mice: just ask the thousands (millions) of developers that use vim or emacs as they primary editor.

              People

              • Assignee:
                sophistifunk Josh McDonald
                Reporter:
                jamesdumay James Dumay
              • Votes:
                2 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated: