The build numbers on the build page should do lazy loading and have a "more" button

[jama22]

This story came about as a result of debugging the View Build History SLI being slow.

The root cause of the slow-ness was that the build page (example here: https://ci.concourse.ci/teams/main/pipelines/monitoring-stats/jobs/view-build-history/builds/103221) is loading the historical records of 100,000+ build records with their colour status. Loading that many elements onto a screen makes the build page painfully slow, so we probably shouldn't do that.

Proposal:

1. Only load the first 100 builds onto the screen
2. Always show a < and > navigation arrow to let people scroll through the builds
3. we load 100 builds at a time once they go past the last 100 builds

cc/ @Lindsayauchin

ic_chevron.zip

[Lindsayauchin]

ic_chevron.zip

[jmelchio]

After discussing with @jama-pivotal and @Lindsayauchin, there are some UI changes to make.

1. The next/previous buttons will replace the current list of builds, instead of append. This alleviates the needs to have logic to remember what to load, caching, etc.
2. If a build number is provided, the builds will show the 100 builds including that build. It will no longer only show the most recent builds.

[jmelchio]

After futzing around with this for a bit it's become clear that it's a bit of a challenge to make this into something coherent from a UI point of view. IMO the challenge with the buttons is that they indicate that the screen navigates while in reality we simply want to use them to fetch the next chunk of build history after the initial fetch of 100.
The code does have a 'scrollToCurrentBuildInHistory' function but that function has the problem that it always is one build off regardless of what direction you scroll in. This is not a good user experience and probably the reason it's not employed currently.
We also have to keep the possibility in mind of people using the location bar to target a specific build which is a challenge when fetching non-continuous blocks of 100 builds because the server side was not built to accommodate this.

As a result I came up with a different approach that I think solves the problem we're trying to address (not fetching a boatload of builds when that is not required) while providing a coherent UI experience and complying with current behavior.

1. Initial fetch of the page will load a maximum of 100 builds in the history.
2. The UI will show the number of builds fetched with a '+' button next to it to get the next batch of 100.
3. If a user uses the navigation bar to go to a specific build the application will fetch in batches of 100 until the indicated build has been fetched into history.
4. Navigation is unchanged from current behavior
   • 'h' and 'l' keys can change build but do not bring tab bar in position if you scroll off the screen
   • when using the location bar to target a build the tab bar will show latest builds regardless of build position
   • scrolling works as before over the available items in history

@jama-pivotal and @Lindsayauchin please provide feedback when you get a chance.

[jwntrs]

I like this idea, however why not make it load automatically? We could just put an autoload cell in the last position? That way if a user scrolls to the end of the list the last cell shows a loading spinner until it loads the next batch.

[jmelchio]

I like that as well, not sure how to do the autoload cell but if someone can pair with me on that or point me in the direction we can do that.

[topherbullock]

After discussing with @Lindsayauchin and @jmelchio we've come up with some incremental steps to implement this:
On first load (of the most recent build):

• load up to 100 other builds and display them
• If there are more than 100 builds, we show ... and link to the job page which shows a paginated vertical list of builds

When they navigate to a build past the initial range (eg. build 150 of 300 ) :

• Load 100 builds after (or maybe before and after ?) the one they navigated to.
• Display ... on either end of the list if there's more to load
• Display a button on the build list to jump to the most recent build (|<)
• ???
• profit

[Lindsayauchin]

build_pg_icons.zip

[vito]

When I click the controls in the build history it takes me to the...first? last? build loaded. Seems kind of confusing as there's no indicator as to which build it's going to take me - it looks like it'd just be a UI control to expand or navigate the history, without changing my page.

[topherbullock]

@vito yeah, I think an improvement to the ... button would be to load the next 'page' and not change what build you're on.

[jama22]

I think we gave a best effort to implement this, but as @jmelchio and @vito mentioned there's some weird stuff going on UX wise. The original intent of this story was to reduce the load times of the build page, and even in our initial tests it doesn't seem to move the needle on our Build History SLI on wings. Combine that with our upcoming redesign of build history...I'm thinking we should just stash this change and leave the build pagination for a problem for the new build history page.

[jama22]

Looks like its reverted, closing

[osis]

Poking this back to life. It's been awhile and still affecting scenarios like...

https://ci.concourse-ci.org/teams/examples/pipelines/time-triggered/jobs/job/builds/444843

[stale]

Beep boop! This issue has been idle for long enough that it's time to check in and see if it's still important.

If it is, what is blocking it? Would anyone be interested in submitting a PR or continuing the discussion to help move things forward?

If no activity is observed within the next week, this issue will be exterminated closed, in accordance with our stale issue process.

[jama22]

bump

[vito]

Going to add this to our Build Lifecycle project as an end goal. The project name is kind of confusing now but it's effectively for designing a new build page and UX.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.