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

When developer selects text it should pause karaoke

    • 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

      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'
                  }
              }
          }
      }
      

          [JENKINS-43316] When developer selects text it should pause karaoke

          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.

          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.

          Cliff Meyers added a comment -

          Pausing this until clarification is provided on JENKINS-44342

          Cliff Meyers added a comment - Pausing this until clarification is provided on JENKINS-44342

          Paul Dragoonis added a comment - - edited

          cliffmeyers

          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

          Paul Dragoonis added a comment - - edited cliffmeyers 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

          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.

          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.

          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.

           

          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.  

          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

          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

          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.

           

           

          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.    

          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.

          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.

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

              Created:
              Updated: