Awesome. Thanks for the feedback Daniel. So you are totally right about the backwardness of my examination of the the left action menu. The thing is that I am investigating at two levels, how does the code work and thus what is feasible, and then what is actually desirable. What I am showing in my screenshot is just an affirmation that splitting out the left actions menu is reasonably easy to accomplish and converting it into a bootstrap navigation bar is also fairly straight forward.
To the question of does it make sense, your responses are super helpful. If I am summarizing your responses correctly, you are basically saying that you are sceptical that it make sense, as the UX model Jenkins follows is that the user navigates into a context, and then the actions present themselves in the left menu based on their relationship to that context, and that makes sense and is good. My thought that it might make sense is based on a general feeling about UIs, that they should in general not hide or remove fundamental tools when the app state changes. That's not to say this is an iron rule, but in general, the less buttons jump around as an app shifts state, the easier it is to find and remember what buttons do what. For picking out actions of fundamental importance, it is definitely true that this set (if it even exists in Jenkins) will likely change based on user role and plugin set. None-the-less, in my own use, some actions, like going straight to the console-out of the most recent build within a job, are so fundamental and repeated that making that button big and not require any drill-down that they are maybe worthy of special designation. ...but again, that is really an ask. Can Jenkins benefit from the general principle that bigger buttons and few clicks for most common actions is good? If so, does anyone have their own list of actions that they do a lot but find tedious, or remember them being difficult to discover when they were first starting out? On Wed, Jun 18, 2014 at 7:00 PM, Daniel Beck <m...@beckweb.net> wrote: > > On 19.06.2014, at 01:45, Gus Reiber <gusrei...@gmail.com> 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). > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-dev/zDaX4yiWLLw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > jenkinsci-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
