Feedback on recent Patchwork update

Sat Apr 2 08:20:45 AEDT 2016

On 03/29/16 12:22, Finucane, Stephen wrote:
> David Miller recently posted a comprehensive review [1] of the latest
> version of Patchwork available on 'ozlabs.org' [2], and it's been a bit
> of an eye opener*. This instance of Patchwork has gone from v0.9.0 to
> v1.1.0, and the major version increase is mostly a reflection on the
> scale of a UI changes that Patchwork has undergone. It seems to be
> these UI changes, rather than the other non-visible changes in v1.1.0
> [3], that have irked power users like David and (presumably) others.
> Something needs to be done about this.
[snip]
>> 2) Don't change the layout of the patch list pages with new fonts,
>> new spacing, etc. when part of the usage is clicking a lot of check
>> boxes. Now all of the boxes are spaced apart differently thus
>> throwing off all the muscle memory heavy users of patchwork have been
>> accumulating over the past decade of patchwork usage.

  It shouldn't be too hard to maintain the old layout/style in parallel with the 
new one for a while, would it? That gives users some time to discover what works 
and doesn't work in the new layout/style. Of course, chances are that power 
users just keep on using the old layout instead of posting their feedback on G+ :-)

>> Nobody who uses this stuff a lot cares if the fonts or CSS layout
>> layout is pretty, we just want to get as much work done as fast as we
>> possibly can.  And any new layout like this works against that goal.

  I also disagree with this one, for me the more readable layout is a usage 
improvement. I don't look at the patchwork interface that often, however.

>> If you want to be able to change the page layout willy nilly like
>> this, give me a way to drag select large numbers of patches side by
>> side with a click and drag gesture or something like that.
>
> I think the recently merged "shift-select" patch will help [4]. To
> summarise, this lets you use the shift key to select a range of
> patches and is, to me, a clear usability boost. As for the general
> spacing, let's see if we can compress this further without reducing
> readability. This could also be a user configuration option, a la
> Gmail's cozy/compact UI setting.
>
>> 3) Comments are now after the PATCH. This is nuts. That's the first
>> thing I want to see after the commit message! I want to see if people
>> have reservations or major feedback about the patch before I even
>> see the patch itself.
>>
>> Do people understand this? The comments and feedback are more
>> important than the patch itself. For example, if the kbuild robot
>> says ANYTHING about a patch, I'm marking it as needing changes. I
>> don't need or want to invest the time reading the patch at all when
>> this happens.  But now I have to spend time scrolling past it, this
>> is bad.
>
> Jeremy has resolved this, and the ozlabs instance is now updated
> to reflect this. We could also add an counter on the patch list page
> to state how many comments a patch has, if this would help?

  The counter would really help me: it makes it easy to identify patches that 
have not received any feedback yet. It could be added the the A/R/T column.

  Regards,
  Arnout

>> 4) The list of all projects used to fit on one single page on my
>> screen, now it's pages and pages of scrolling. Don't change the
>> layout if it fits less information on the screen. I'm happy to
>> squint at a crappy 4 point font if it allows me to take in more
>> information on the screen at once and scroll around less.
>
> Agreed on this point. In addition, the page looks awful on mobile
> (yes, some folks do use this on mobile). We can either make the
> boxes smaller (6 per row, reduced height), or go back to a row
> format but more in the style of the "Popular respositories"
> window found on a GitHub profile page [5].
>
>> If none of the above makes sense to anyone, try real hard to imagine
>> what processing 500 patches in a single day might be like. It
>> happens to me periodically.  More often an average day is 100 or so,
>> and even at that rate the things happening above are deal breakers.
>> Together they could make it take twice as much time or more to
>> process incoming changes each day.
>
> Totally understood. As I said, we're dealing with a lot of different
> users with very different use cases. What matters for some users
> doesn't necessarily matter for others. We're just trying to find a
> balance.
>
> [4] https://lists.ozlabs.org/pipermail/patchwork/2016-March/002458.html
> [5] https://github.com/stephenfin
> _______________________________________________
> Patchwork mailing list
> Patchwork at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork
>

-- 
Arnout Vandecappelle      arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF