On 19/06/2014 03:00, Daniel Beck wrote:
On 19.06.2014, at 01:45, Gus Reiber <[email protected]> wrote:
As a possible remedy to that bit of awkwardness, I am looking at pulling some
of the 'action' link list items out and displaying them in a global toolbar
sort of context. Jenkins Management, in particular seems like it really should
be clearly separated as a global set of actions, and not bound to any
particular build or custom view.
At the moment, I am merely doing a proof of concept examination of how the link
list gets generated, but I would love to get community feedback as to whether
or not it does make sense to separate out a portion of the Jenkins actions,
splitting the contextual from the global and the high-use/high-value actions
from necessary but tangential or highly specialized actions.
Attached is a screenshot.
(the top menu shown here isn't really the right set of global options, but
instead just a strawman to see if I can grab the action buttons and put them
into a bootstrap nav-bar, which I can)
Isn't this backwards, if you don't know yet which items need to be shown more
prominently?
All globally relevant entries' availability depends on your
situation/configuration:
* Project Relationship and Check File Fingerprint (only shown if there are
fingerprints recorded),
* My Views (only if you're a logged in user, i.e. requires enabled security and
being logged in),
* Manage Jenkins (only if you have Administer permission).
Everything else that exists by default in the sidepanel for top-level views is
context specific:
* New Item: specific to ItemGroup (and even view!)
* People: specific to View
* Build History: specific to View
* Edit View (not on the 'All' view): specific to View
* Credentials (bundled plugin): One globally, one per folder
While you could add some entries from 'Manage Jenkins', they basically all
require admin permissions.
Jenkins Management, in particular seems like it really should be clearly
separated as a global set of actions
That's basically what's "Manage Jenkins" is for. Everything that's
management-related in the sidepanel is added by plugins. Often, these make sense, e.g. in
the case of Credentials, I imagine the reason being consistency with different credential
stores (e.g. the Jenkins-wide credential store accessed similar to a per-folder
credential store, just on a different object).
While your response heavily emphasizes the negatives as you see them, I
think there's some very useful info in there that Gus can take and work
with in a positive way.
I think your comments were primarily targeted at his experiments with
the navigation, right? Or maybe it was both the navigation and the
restyling of the tables?
On navigation, I'd say Gus is like me in that he doesn't yet totally
understand the logic behind navigation within Jenkins, other than the
fact that it's not very intuitive. I think he's trying to throw out a
conversation starter that can eventually lead to something working
better after a number of iterations. Or, maybe we'll discover that
it's not practical to try restructuring it.
So if it's generally acknowledged that navigation in Jenkins causes
issues/confusion/frustration for users, then what can we do about it? I
thought what Gus did at least looked like there was potential in it that
was worth exploring in a positive way. For me, it + your comments has
me wondering how can we better separate navigation so that the different
types of nav items (contextual, global etc etc) are presented in a more
useful/understandable way.
I wonder would it make sense to take a step back and draw a map of the
current navigation and how it changes depending on where you are in
Jenkins? Armed with that, then maybe we can make some proposals?
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
