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
[email protected]
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
_______________________________________________
Patchwork mailing list
[email protected]
https://lists.ozlabs.org/listinfo/patchwork
