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