> Am 21.04.2015 um 22:09 schrieb Gus Reiber <[email protected]>: > > Hey Daniel, > Awesome feedback. You have pointed out a few things that I have totally > missed and a few things that I have just not shown well with my wireframes. > So, let me see if I can work my way through your feedback: > Item selection page issues: > No descriptive text: I very much agree that is important, but I am thinking > that text could move to a hover. Maybe not though, but I should have shown > the hover in my pics here. > Default category: All the uncategorized items would get pushed under the > "Plugins" category, though that name may or may not be right. It would be > important that new categories make their way back into the community on a > regular basis so plugin authors could self-select the category they want > their new item to be associated with. This would all need to be documented, > but for now... > Not realistic category distribution: This is definitely the tricky bit, > because it would have to be done well to be helpful. For what its worth, the > categorization I am showing is based on the plugins CloudBees actually uses > internally. That isn't a great sample size, but it isn't cherry picking, > either. You are absolutely right, the categories need to proven out in a > handful of real-life scenarios. I think it would be a great improvement if 80% of the uses cases would be easy to achieve. So it looks very promising to have such a minimalistic view with just the icons. Maybe there needs to be some kind of ‚Advanced‘ section where one can edit all details.
> Build step icons: > Again, you are right that this only works if it really works. We would offer > three (imperfect) pieces to help it work: > We at CloudBees (with the permission of the plugin author) would take the > work of backfilling icons for commonly used plugins > We would offer a set of images that are pictorial abstractions for common job > related functions that plugin authors could pick from > We offer a default icon or icons That would be a great help, I think most developers would love to use icons from a predefined icon set that matches the rest of the graphics/style. > This view as config: > So while I have jiggled some of the names around a little bit and some of the > category membership around a little as well, in general, this form form > should map with logical equivalence to the existing form. The main thing that > is changing is the underlying DOM structure and the CSS and JS that glues > visuals and effects on the top. To the extent the current create form works > as a config page, this version should work just as well. > Collapsing makes the page look empty: in general, I think that is a good > thing. Each time I look at the Jenkins config screen, I see a giant list of > options, most of which I don't care about for my particular job. Ideally, we > would make the GUI smart enough to open all and only those sections that have > values set in them when the user is using the form in config mode. > Read only view: We have also talked a bit internally here about showing a > read-only initial state to the config form. The read-only view would make it > a lot easier to see what the current settings are because it wouldn't need to > be burdened with all the GUI goop of editing the settings and the other goop > of settings not being used. You would then choose to edit that view and all > the config options would then be presented. > Help Buttons: > Shame on me, yes, I just left them out. I do think our current help text > metaphors are pretty good, but could use a little bit of refinement to make > them look a little nicer, but in general, I mean to only be adding context, > not removing it. > Hide/not hide first section: > I think hiding helps, even for the first section, but I am often wrong. > Scrolling behaviors: > So just as an FYI, what I have shown here are actually screenshots of > semi-functional HTML. Smooth screen scrolling has not yet emerged as a > problem in the prototypes, but it may be that my dataset is insufficient to > really stress my proposed GUI gestures. But, not having scrolling problems > would be an essential aspect of anything we would want to try to pass-off as > an improvement. > Simple builds: > My hope here is that by silencing the noise of job configuration steps not in > play, but cleanly naming and differentiating those categories, the simple job > gets a lot simpler as the create/config process takes on more of a guided > wizard type experience. Again, though, the simple build case is indeed a > critical use case, so we would need to prove that experience was in fact > better, not worse. > Anyway, hopefully my answers help you know where I do or do not understand > your feedback, because it is definitely my goal incorporate as much of it as > possible. I want to keep the bar of improvement as high as possible. > > On Tue, Apr 21, 2015 at 12:20 AM, Daniel Beck <[email protected] > <mailto:[email protected]>> wrote: > On 20.04.2015, at 23:41, Gus Reiber <[email protected] > <mailto:[email protected]>> wrote: > > > As it stands today, most folks first interaction with Jenkins is a fairly > > dry list of radio buttons, asking him/her to select which type of item to > > create. Not only is the radio list fairly dry in appearance, as users add > > plugins it does little help the user scan the page to find the particular > > item type he/she is looking for > > I don't see how this is an improvement in any way for that "first > interaction". There should be descriptions what each item is. Imagine the > first interaction with Jenkins replaced by a single tile ("Jobs and > Workflows") with 1-4 entries (depending on which bundled plugins are enabled) > with no further explanation what each item is. Seems to be a huge step > backwards. > > Also, what's the default for any plugin not supporting this? An > 'Unknown'/'Unclassified' section? Or default to 'Jobs and workflows'? > > How does this view look with 15-20 entries in the 'jobs' category and 1-2 in > others? You're presenting the 'best case' distribution of items, but that's > not what it will really look like. > > > Because of this importance, and iterative sub-process nature, I am pulling > > the list of step operations out of its current pull-down list and giving > > each a bit of visual meat. Beyond being decorative, this is meant to help > > the user scan quickly for the process step he/she wants and in a sense, > > wake the user up with a little reminder that this is likely to be where the > > important choices need to be made. > > Could you explain how you'd get there from here? Because today there are no > icons, and hundreds of plugins would need to be updated to add these to the > builders and publishers they contribute (not to mention any trademark messes > related to those icons). How does that design look like with all non-bundled > builders having no icon, or the same generic icon? > > > "Notifications" would be another boring control set, so I am not going to > > bother showing it, but hopefully you get the idea. > > Actually, I'd be interested in how you determine into which set each > Publisher goes. Are 'Post-build actions' those that don't inherit from > Notifier? I have some concerns about how Jenkins determines execution order, > as this grouping would worsen today's problem that the UI does not properly > show the order in which post-build steps are actually executed. > > > This wireframe adds the concept of collapsible region categories, and in > > this "Overview" step, weeds out some of the non universal input settings > > that are currently in the first segment of the item creation/editing > > > Assuming this will be implemented for all config forms to keep things > consistent, could you show the Edit View form in this new design as well? My > first hunch is that it'll look really empty. > > What's also completely missing in these designs is the help button next to > each item. Are there plans to change these as well, or did you just leave > them out? > > I wonder about the title 'Create Freestyle Build'. For one thing, the > terminology is wrong (it's a job or project, not a build), and the only form > that today appears before the corresponding item has been created is the > initial slave creation form. > > Why are you collapsing the first section at all? Shouldn't name and > description excluded from the collapsing sections? Will the form hide the > information what users are editing by default, relying on e.g. bread crumbs? > > IIRC Tom's first attempt (last year or so?) at collapsible sections suffered > from navigation issues (as in the viewport moving around) due to all the > scrolling going on when collapsing/expanding sections. How are you planning > to deal with that? > > How are you going to address the problem that users will no longer be able to > see at a glance the handful of options/build steps they have in simple > projects? 'Expand all'/'Collapse all' buttons? Indicator how many > steps/enabled options are in each section on the title line? > > -- > 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/6BdWZt35dTQ/unsubscribe > <https://groups.google.com/d/topic/jenkinsci-dev/6BdWZt35dTQ/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:jenkinsci-dev%[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/F82F165A-6935-4DC8-BBD5-5F81575D5EB2%40beckweb.net > > <https://groups.google.com/d/msgid/jenkinsci-dev/F82F165A-6935-4DC8-BBD5-5F81575D5EB2%40beckweb.net>. > For more options, visit https://groups.google.com/d/optout > <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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXy1OTc657jL__6qu15rtjeW8HpLhD7Lhvf0tVr8FoiAdw%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXy1OTc657jL__6qu15rtjeW8HpLhD7Lhvf0tVr8FoiAdw%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/99193027-A235-4B63-B2E5-19A5555DBEF4%40gmail.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP using GPGMail
