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.
-
*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
- *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]> wrote:
> On 20.04.2015, at 23:41, Gus Reiber <[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.
> To unsubscribe from this group and all its topics, send an email to
> [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
> .
> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXy1OTc657jL__6qu15rtjeW8HpLhD7Lhvf0tVr8FoiAdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
