User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:18.104.22.168) Gecko/2009042316 Firefox/3.0.10 Build Identifier: When I'm picking an extension that hat been in the queue for a longer time, it's often because it's admin flagged. Because I'm not an admin, there is noting I can do with that extension. Hiding this kind of extensions would prevent me from clicking on the same queue items (which I can't work on) every couple of days. Reproducible: Always
We should just hide these for people that aren't admins or senior editors.
Would it be more useful to add "flagged" (any/yes/no) to the queue filter form? While it would require a couple of extra clicks to set the filter, it would provide greater flexibility and potentially save some confusion with an editor not finding what a developer insists is pending.
Would it be possible to add another column to the right of "Platforms," something like: +--Flags-----+ | [ ] Admin | | | +------------+ And have it default to off? We've got the automated testing suite coming down the line which will be setting other flags like "Security review." This would also give us the option of filtering on the "Additional Information" column - not sure if we would want to right now.
A flags group would be doable as well as a default initial filter. Any checkboxes would have to be tri-state to accommodate the empty filter. Personally I think select or radio inputs are less confusing.
Could do something like: +--[ ]-Filter Flags--+ | [ ] Admin | | | +--------------------+ And just have the whole box greyed out and disabled unless the top checkbox was checked. I don't know if that would be less confusing though. Maybe chowse has some design input!
(Foreword: I'm assuming this refers to the Editor's Queue: https://preview.addons.mozilla.org/en-US/editors/queue ... I'm still learning the admin/editor workflow.) My two cents: For the filter UI, I'd lean toward drop-downs (<select>s). Tri-state checkboxes are uncommon and unintuitive. The two-checkbox approach won't work if there's more than flag to filter against (e.g. I might want to filter against one flag but not the others). Radio buttons would be a good choice, but there isn't the screen real estate to accomodate them. For each flag, your choice comes down to 1) not caring if the flag is set or not, 2) only wanting things with the flag set, or 3) not wanting things with the flag set. Your options should be presented accordingly, with 1 being the default. I'll attach a sketch of how you might present this. Another approach might not to add filtering, but add indicators to the list itself. For example, if there was a visual cue to indicate that an item is admin-flagged, an editor could know to skip it without having to inspect the item. I'll attached an example where a column containing icons could be used to achieve this. This would involve little change to the UI and should be easy to learn after a few encounters (and perhaps a title attribute on the icon). You could also add some smart highlighting. For example, if the logged-in editor is not an admin, admin-flagged items could be faded to accentuate the fact they can't be reviewed. HTH.
Flag indicators would be useful with or without enhanced filtering. Correct me if I'm wrong, but the only way for an editor to tell if something may be flagged is to scroll to the bottom of /editors/review/1234 and look for a recent "Admin Review" entry. Flag indicators near the top of this page (in addition to the queue listings) would make things clear.
chowse, these are great ideas. My only concern is there is a potential for 15 flags per row and that would take a lot of space, both to display them (or, more likely, the space where they are not), and the filter boxes. I don't have another solution though (maybe less flags...). If you come online sometime we can talk about better ways to show flags.
We discussed this on IRC. We'll stick with Chris's designs in this bug.
May extend this one a bit? I share your concers about having to much flags per row. But it would be useful too, if we could see if there is more information requested for an add-on from a reviewer. But I don't know if there is even a special state for reviews, I mean. So if an editor requested more information, this should be shown somehow in the table, and as soon as the add-on author answered, this flag should be removed again. More general, editor need to see on the first sight, on which review they can work. As someone said before, often you start reading nomination message, description etc and start reviewing and at the end you see that another editor already worked on it and requested more information or marked it for admin review or something else.
Please ignore the typing errors, sorry for that. I wanted to add that there are still other methods to "flag" or "mark" a review. I could image a greyed font color, or a special background color (look at http://www.mantisbt.org/demo/view_all_bug_page.php which is overloaded of course, but just to give you an idea, please look at the lower table only). Or something like bold/italic font style, or maybe even a small icon before the add-ons name on the first column of the table.
An additional flag for feedback requested is a good idea. I'm hesitant to start combining different ways to show an add-on is flagged in case they are confusing, although greying out an add-on that is admin-review flagged seems reasonable. Chowse can comment more on which are practical in this case. So far I'm seeing flags for: - admin review - feedback requested - security review needed (from the automated tool) - malformed review needed (from the automated tool) any others we should have in mind at this point?
Created attachment 385320 [details] [diff] [review] Admin Flag Filter This patch adds an admin flag filter and a flags column to display flag icons. It also adds a flags section to /editors/review/. Additional flags should be easy to add once they are actually in the schema. Filter form real estate is the biggest challenge at this point.
Thanks Scott. I'll review it as soon as I can and we can land early in 5.0.8.
Comment on attachment 385320 [details] [diff] [review] Admin Flag Filter Nice. I can see our table real estate is at a premium already. Maybe we should collapse the "Additional Information" column into icons too. And not give every app it's own column. Anyway, playing with space is a different bug that we'll hit when we get to it. Thanks.
Fixed in r30064
Looks good on https://preview.addons.mozilla.org/en-US/editors/queue/nominated and https://preview.addons.mozilla.org/en-US/editors/queue/pending; looking at the patch and Scott's comment 16, only Admin flags are displayed, right? (Just asking since comment 15 brought up the other types.)
Thanks; verified. I did find the filter value of " " to include both flagged and regular items to be a little non-intuitive, but that's a separate bug.