Skip to end of metadata
Go to start of metadata

Context

During FOSDEM 2012 at Brussels, several of the community members had a spontaneous meet-up where we discussed key UI enhancements that would improve the usability of Jenkins. The goal of the conversation was to come up with a small enough and concrete enough list so as to enable actual progress.

Foldable actions list

The standard layout of Jenkins UI is to have the "action list" on the left, followed by several "widgets" (such as the executor list and the queue), and the main section on the right.

This enhancement is to allow the action list and widgets to "fold to the left", enabling the user to use a bigger screen real estate for the main section when needed.

An example of a similar UI that I know of exists in IntelliJ IDEA, the screenshot attached below.

Manfred (IRC:mdreher) volunteered to come up with the screen mockup.

Enhanced breadcrumb (implemented)

This enhancement is to to enhance the breadcrumb on the top of the page so that they can display the drop-down menu, which will reveal the action list associated with the said object.

This was expected to considerably reduce the number of mouse clicks and page loads necessary to achieve the typical UI flow (such as scheduling a new build after seeing the console output of the last failed build.)

As a part of this change, we expect to make the breadcrumb stick at the top of the page (much like the save button sticks at the bottom of the page), which will provide easy access.

Again an example of this can be seen in the IntelliJ IDEA:

Move icon sets into a plugin

This enhancement creates a new library plugin whose sole purpose is to maintain a set of icons that plugins can use. Currently, these icons are bundled in the war file, and this occasionally forced plugins to require a newer version fo the core just to pick up new icons.

Moving this into a plugin is expected to eliminate this problem.

Performance improvement of the configuration page (done)

Performance is a feature, and a numbe of people reported that Jenkins takes too much time generating a page. This slowness is most typically felt in the configuration page.

We should identify what's causing the slowness and try to resolve this.

Improve inline HTML to show the plugin the feature came from. (completed)

In larger deployments of Jenkins with a lot of plugins, it's not obvious which plugin a given feature is coming from. This prevents the administrator from identifying a plugin that can be disabled, etc.

This change should be made in the core so that the inline help HTML will automatically include this information in a consistent location (I'm thinking at the bottom right of the inline help page.)

Improve navigation in configuration pages (implemented)

In larger deployments of Jenkins with a lot of plugins or big configuration, the page is often long and requires a lot of scrolling.

This enhancement adds a drop-down menu on the top right of the configuration page, at the same row as the breadcrumb (therefore it'll stick to the page top — see above), this drop-down menu will provide quick navigation to the different sections of the configuration page via a href="#id".

This is achieved by making the <section> tag emit information about the outline.

Save/Apply button (completed)

In the configuration page, add the "Apply" button that achieves the same effect as the "Save" button but without going back to the top page. Combined with the sticky save button behavior, this makes the repeated adjustment of the job configuration easier and faster.

(During the meeting we also talked about adding the "Cancel" button that leaves the configuration page without saving the new configuration. While save/apply/cancel combo does appear in various UIs, such as Windows property dialog, but I'm not really sure if this is a common thing in the web UI.)

Pop-up instead of separate confirmation page

In several places (such as when deleting a job), Jenkins sends the user to a page to confirm the intent of the action. This enhancement turns this UI pattern into an in-page confirmation dialog, eliminating the page transition (and thereby speeding up the user experience.)

  • No labels