patch list action bar design changes

[Raxel Gutierrez]

Thanks for the feedback! As I mentioned before, I implemented the
changes (screenshot in previous email). I'm not very experienced with
sending a patch series and have to touch up a lot. With the help of
Jonathan and Emily, I should hopefully send the changes this Friday.

> I think this depends on how you intend to make these changes. If it's done via a
> form submit (i.e. not using AJAX), then I think a confirm step is necessary.
> Without this, it becomes difficult to update multiple attributes on multiple
> patches since you will have to select the same N patches M times (i.e. for each
> attribute you'd like to update). If you can do the update asynchronously via
> AJAX (with a standard form submit for those navigating the web without JS), then
> doing it immediately is fine since we don't lose information like the currently
> selected patches.

The multi-patch list action bar continues to function the same way in
the backend as the forms, just now with the UI changes. However, the
dropdowns for one-off, inline changes (row values for the State and
Delegate columns) make asynchronous calls via AJAX. So, I believe your
thoughts align with the implementation.

> Yes, though I would like to ask how you envision the 'delegate to' button
> working. Ideally, I'd like the ability to delegate a patch to any user in the
> project, however, when we tried this in the past we had to remove it because the
> amount of users could be huge, resulting in ridiculously large <select>
> elements. An AJAX'y dropdown that is pre-populated with maintainers of the
> project but that contains a search dialog to find other users would be awesome.
> I have attached an example from the GitHub UX demonstrating what I mean (from
> https://github.com/getpatchwork/patchwork). I have tried to do this myself more
> than once but my JS skills (or lack thereof) have let me down each time.

I like the example a lot! I think that's a good idea to change the
'delegate to' dropdown UI to that in a future patch. I believe my
HTML/CSS & JS skills are adequate enough to make the tool possible
with enough time :)

On a similar note, Jonathan suggested refactoring the UI of the bundle
create/add/remove tool into a single tool similar to Gmail's label
tool (screenshot attached for reference).

> This is the only component I'm not a fan of. For most projects, the amount of
> users that can actually make changes on patches (i.e. patchwork "maintainers")
> is a tiny fraction of total users. For all users that are not maintainers, these
> are controls which they'll never be able to actually use and therefore are
> things that just waste space. In my opinion, this form should be hidden for
> those users that can't do anything. I would expect that creating a bundle is the
> only one they'll care about.

I think this is something that can be further discussed.
Unfortunately, I don't think there's a consensus/research on what UI
makes the most sense.

> As an aside, I have a fairly sweeping series that reworks the Patchwork UX
> significantly sitting on my local machine. I've reworked a lot of the
> login/logout logic and replaced Bootstrap 3 with Bulma. However, it's incomplete
> which is why I haven't pushed it (funnily enough, I got stuck trying to get a
> patch detail page that I was happy with). Would this be helpful for you? I can
> push it as an RFC series over the weekend if so.

Yes, definitely! It would be helpful to see what you've worked on. I
think being about to look through it would be nice to reference and
know what for my own work.

As for the individual patch detail page, I'm going to be starting
another thread about a mockup I have concerning this page.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2021-07-14 10.41.25 PM.png
Type: image/png
Size: 45399 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20210714/d5b80f38/attachment-0001.png>