Am 19.06.2014 um 18:32 schrieb Gus Reiber <gusrei...@gmail.com>: > 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? > >
I think it would improve the usability if we add some „shortcuts" What I’m using frequently (global): - Manage Jenkins->Configure System (the rest of the "Manage Jenkins" items I’m not using very often). - Create a new job During the process of creating a job I’m always in the loop 1) Open Job configuration 2) Run Job 3) If the Job failed: Look at the console log, what is the reason for the failure and go to 1) After step 1 it would be helpful if we would have not only „Save" and „Apply" but also a „Save and Run" button. In step 3 it is quite cumbersome to navigate to the console log. This should be more intuitive. New users often ask me where they can see why the job failed. (Maybe the ball indicating that a build failed or is unstable should provide a link to the reason) While viewing the console it would be good to have an option to navigate to 1) with one click. (Kohsuke mentioned that we could add a link to the console text but up to now you need to scroll back to the top of the page to find the Back to project link and then you can configure the project).
signature.asc
Description: Message signed with OpenPGP using GPGMail
