Skip to end of metadata
Go to start of metadata

In the rough order of priorities,

No stale data in the page / dynamic content update (P1)

Much of the HTML pages served by Jenkins do not update by themselves in short of reloading. For example, the build status icon in the build page (such as this) do not change the color when the result is determined. Jobs listed in views do not update themselves when a new build happens.

The goal of this task is to identify those things that benefit from dynamic in-place update without page reloading, then fix them accordingly.

To make it easy for plugins to do the right thing, we also need to list up existing mechanisms that can be used for this purpose, such as JavaScript proxy, and we probably need to come up with new ones, such as Atmosphere integration.

Context menu hover behaviour (P1)

Many people reported that the automatically showing a context menu when the mouse hovers over a link is a bad idea. Kohsuke OTOH prefered not to provide an option to disable this.

The proposal that won the consensus is to add one more indirection by showing a small arrow on the right (except it should be showing 'v' instead of '>'), then activate the context menu upon clicking that.

Performance of the configuration page loading (P2)

People generally felt that the configuration page loading can get slow, and sometimes extremely slow (to the tunes of 10s of seconds)

  • Put more probes in the place to warn the users when they should be reporting this to us, and gather more data.
  • We need to find out if it's the generation of HTML that's slow, or if it's evaluation of JavaScript that's slow.

Separate read-only config page

Having a separate read only view of the configuration page would reduce the pain. This is because often people access the configuration page not to change it but to find out who it's configured. This is of course based on the assumption that the read-only view page can be shown a lot more quickly. Such a read-only configuration page can then possibly grow into editable configuration page if there are buttons that let people edit a specific section alone:

More UI controls for config page

Expanding the "/lib/form" tag library to support more UI controls can help improve the performance, as well as improving the usability. Some of the ideas discussed are:

Tab view (example)

We can split the configuration page into multiple sections and put each of them in a separate tab. Provided that invisible tabs are lazily loaded, we can reduce the amount of initial data loading for a page request.

Plugins can also use this control within their config.groovy to save space and reduce the amount of data-loading.

Grid control (example)

Provide a grid control, with the master/detail pattern, the modal dialog for editing, and/or in-place editing.

This would reduce the amount of AJAX form validation request and hopefully help the performance. And perhaps more importantly, it'll save a lot of screen real estate in a long repetitive job configuration.

Grid control with no copyleft license?

The example links to extJS, which is only available under a copyleft license. We need to find a control that has a liberal license.

Multi-column layout support (example)

Some plugins already do multi-column layout to pack more into the same space.

(This does not help the performance, but it'll be an usability improvement.)

Other children in the same container" menu in the breadcrumb (P2)

Improve the breadcrumb to provide a quicker access to sibling objects, as can be seen in Windows Explorer.

This sibling menu is activated by clicking the '>' between the ancestors, whereas the current context menu gets activated by clicking the ancestor itself.

Complete the Bootstrap integration work (P3)

There's a branch that fell behind the master branch where we attempted to replace the current table-driven layout to the one driven by Bootstrap. Complete this work and integrate this into the master.

This will give us some free UI eyecandy (such as animations), as well as some UI controls.

Extension point for widgets (P4) (done)

In large instances, displaying and updating the build queue and showing the executor status is neither useful nor efficient. So they prefer to be able to just disable them altogether, or replace them with other implementations.

This led to the conversation of making those widgets extensible, pluggable, then configurable by the admin. Some of this work has already been done, but we just need to finish up this work.

Build history tabular view (P4)

We want a full-width tabular view of the build history, with a similar degree of extensibility as in the project view. We want to support custom columns, and we want to support filtering (so that for example I can see those builds that contain my commits.)

  • No labels