Will this “UI”/“theme” be in separate plugin? > On Apr 23, 2015, at 16:27, Ullrich Hafner <[email protected]> wrote: > >> >> Am 21.04.2015 um 22:09 schrieb Gus Reiber <[email protected] >> <mailto:[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 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:[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 > > <https://groups.google.com/d/msgid/jenkinsci-dev/99193027-A235-4B63-B2E5-19A5555DBEF4%40gmail.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/4CF8E9DB-8AEB-4F9B-8681-C4C54A310D89%40gmail.com. For more options, visit https://groups.google.com/d/optout.
