119

The Public Platform team would like to announce another release in a series of planned work for the Review queues. This release focuses on refreshing the queue user interface in preparation for further improvements to the user experience. Starting today, we will roll out these changes in three phases across the network.

Roll-out plan

We have planned for these UI changes to ship in three distinct phases affecting specific queues across the network. We will update this post as each phase is rolled out.

What Where When
Phase 1 • Home page (/review)
• Close and reopen votes queue
• Stats/History view
• Steward badge
Meta Stack Exchange
Meta Stack Overflow
Shipped!
January 28, 2021
Phase 2 Changes from Phase 1
• Suggested edits queue
• Low quality posts queue
• First posts queue
• Late answers queue
SuperUser
Ask Ubuntu
Shipped!
February 16, 2021
Phase 3 Changes from Phase 1 + 2
• Triage queue (SO only)
• Help and improvement queue (SO only)
All network sites Shipped!
February 23, 2021

UI changes to all queues

updated close votes queue

All review queues will be adopting a new user interface that focuses on providing reviewers with context to make deliberate, thoughtful decisions on review tasks. We shared an initial design proposal in our product discovery phase and made sure to include that feedback into the final design.

Responsive/Mobile-friendly design

new mobile view of close votes queue

We utilized Stacks to update the visual design in the review queues. As part of this update, we were also able to make the queues responsive and utilize mobile-friendly UI components.

Changes

  • Actions menu - We’ve removed the action buttons for a menu-style component. Selecting an action now requires a bit of pause and mitigates robo-reviewer behaviors we've seen in the past. Instructions are now always visible and associated with each action.

  • More context - Users can now toggle between the review task and the necessary context (original question, answers, and comments) on the task page to assist in making educated decisions on a task. No need to open new browser tabs!

  • Vote controls and follow feature - We heard from you that being able to vote directly on all tasks as well as the option to follow posts and receive updates on changes would help in the reviewing process. These features will be available in all queues.

  • Filter button - We’re highlighting this feature (where it’s available) with a button and replacing the easily missed text-link.

  • Review count - We’ve removed the badge progress bar in lieu of keeping track of how many tasks you can complete in a queue (don’t worry, the badge bar isn’t gone).

Review home page

updated review queues home page

The review homepage has received a Stacks update as well, setting it up for forthcoming plans to create better onboarding for new reviewers. This page now provides a bit more information to new reviewers.

Changes

  • Only the queues available/earned by the user are clickable

  • Includes additional text about necessary reputation to earn access to new queues

  • Available queues are prioritized to the top and then sorted by the number of tasks in each queue

Additional updates

updated history page

updated stats page

All aspects of the Review queues are receiving some much needed design attention. Here a few more changes you can expect to see:

  • There is more incentive to continue reviewing. The Steward badge can now be earned multiple times for every 1,000 reviews in each queue. If you have already completed 2,000 or more reviews, we will backfill any additional Steward badges that you have already earned. You can expect to see them accrue over the next few days.

  • History view - Added and rearranged a few UI components so that users can better navigate and utilize the page

  • Stats view - Updated badge progress bar

Feedback

Please leave any feedback or bug reports related to this release below this post. We will be reviewing responses on this post for one month following Phase 3 (March 23, 2021). After March 23rd, please ask a new question to report any new issues.

32
  • 26
    You have Dark Mode on ... Meta Stack Exchange? I knew about Meta.SO from Catija's screenshots in the stacks-editor announcement ... – Glorfindel Jan 28 at 17:41
  • 2
    @Glorfindel You sure that's not SO? – Ollie Jan 28 at 17:42
  • 7
    What's behind the decision to show the "questions list" view of the post title, its asker, and ask date instead of the normal question view? Likewise, why are you injecting the meta information about the review item in between the title and the post body? Both of those decisions are confusing to me. – TylerH Jan 28 at 23:24
  • 15
    Look at the dates and names in those screenshots, @Ollie / Glor - this is likely a local or dev-tier build running against a dump from the MSE database. Any theme can be selected in that context - dark-mode Physics, for instance. Which just leaves the question of why Lisa is NOT using dark-mode Physics?! 😏 – Shog9 Jan 29 at 1:46
  • 4
    Thanks for adding responsive design. I use the site (math.se) exclusively on mobile device and it was a real pain handling reviews . – Paramanand Singh Jan 29 at 2:21
  • 5
    I think it would've been better if Phase 1 included an opt-in on Stack Overflow. Only ~900 users have access to the Close and reopen votes queues on Meta.SE and Mata.SO's queues are almost always empty :( – 41686d6564 Jan 29 at 9:31
  • 5
    The giant gap between the title and body of the question is jarring and confusing. The body follows from the title, so putting the reason for flagging between the two like you did is like putting it between the first and second paragraph of the question. Except this is worse in some sense, as the title is now part of an entirely different thing and doesn't appear to be the title of what appears below at all any more. That thing also duplicates the score and answer count. – Bernhard Barker Jan 29 at 21:11
  • 3
    @StephenRauch Probably because the user profile image is not relevant info to have for reviewing posts, and screen real estate is limited as it is – TylerH Jan 29 at 22:16
  • 5
    Wow, you can update the Review Queues but still cannot deliver site designs? Some sites have been waiting nearly five years to get their look feel updated as promised. You implemented a generic site design which was supposed to standardize and make easier the rollout of the designs. That was a few years ago now, too. So, just curious? You have time for this but not for site designs? – Pᴀᴜʟsᴛᴇʀ2 Jan 30 at 13:49
  • 5
    @Pᴀᴜʟsᴛᴇʀ2 I understand your frustration and I know that it's difficult to be waiting for so long. But we can't make site designs at this point. We have major needs for improving very basic elements of our sites so that they function well and so that people understand how to use them. This change improves the review experience network-wide, site designs benefit a single site and are purely cosmetic. On smaller sites, the improvements to review may not be as important but these are still valuable changes. – Catija Jan 30 at 14:56
  • 3
    @Trilarion it's not that they aren't important... but it's like trying to paint a house while the foundation is failing. Paint serves a purpose in protecting wood siding and making the house look approachable but I don't think anyone would argue that painting a house that has identical paint to the ones in the neighborhood but has foundation issues is the right choice - do you? – Catija Jan 31 at 16:17
  • 5
    @Pᴀᴜʟsᴛᴇʀ2 They probably cannot deliver site designs because they are working on review queue updates (among other things). The review queues have been needing an overhaul for more than 5 years anyway. Sites can wait to have a new background image. – TylerH Feb 1 at 16:10
  • 4
    Does the new version include the ability to flag low-quality spam, or do we still need to open a new window for that? – Mark Feb 3 at 21:30
  • 5
    @Braiam, yes, there is: the system can automatically decide that a post is low-quality, or someone could flag it as "very low quality" instead of "spam". – Mark Feb 16 at 21:54
  • 2
    Hi @Lisa, now that I have had some time to play around with this on Stack Overflow (where 99.999% of my reviewing takes place), I have some thoughts on layout changes. With this rolled out and already having 75 answers over 3 pages, would you recommend I post that suggestion as an answer under this question, or as a new question here on MSE? – TylerH Feb 24 at 16:06

112 Answers 112

4

Bit of an obscure curiosity, but couldn't resist asking...

I noticed that when there are multiple potential duplicates others have chosen in the close queue, those are now shown with letters ("Duplicate A", "Duplicate B", etc.) instead of with numbers as they were before ("Duplicate 1", "Duplicate 2", etc.)

However, I'm curious to know something: what if there are more than 26 potential duplicates others have chosen (which is possible through recommend closure flags)? How will the duplicates be lettered beyond the letter Z? Will they appear with a proper letter (e.g. "AA", "AB", etc.)?

enter image description here

4
  • 1
    So, I'm not exactly sure why the design is like this but I implemented it so I can tell you what'll happen. The first thing to consider is that it's hard to get more duplicates than the number of close votes available (3 or 5). I guess you could with recommend close flags, but I'd have a tough time envisioning that. You wouldn't be able to get more than 5 on the reopen queue because we don't let moderators add more than 5 originals to a reason. So, I have "Duplicate A" -> "Duplicate E" in a switch statement. – Brian Nickel Feb 22 at 17:09
  • If there are more than 5, we just switch to numbers for all of them. "Duplicate 1", "Duplicate 2", ... – Brian Nickel Feb 22 at 17:10
  • @BrianNickel Why not just use numbers to begin with…? This is just asking for bug reports in the future, where “sometimes it’s letters and sometimes it’s numbers”. – Sebastian Simon Feb 22 at 17:12
  • 1
    I didn't create the design but I think that defaulting to letters makes sense - this is a number-rich row and putting "Duplicate 1" next to "Answers (1)" invites more confusion. Labeling them by letter instead of by number makes them clearly readable as labels instead of tallies. – kristinalustig Mar 1 at 18:46
4

On my iPhone 11 with iOS 14, if you scroll all the way down to the footer and then choose 'Close', the close dialog hides under the 'review action widget' and there's no way for you to reach the 'Close' button you need to complete the review.

enter image description here

1
  • This will be fixed in the next build. Legacy popups have a default z-index of 2000, which is pretty low in our new design system. I've given these two popups a z-index of 9000 to bring them in line with other ones. – Brian Nickel Feb 22 at 16:10
4

Dialog for leaving a comment when reviewing to delete an answer in the low quality queue is not responsive

When I review an item in the low quality queue as "Delete" or "Recommend Deletion", the dialog box to select a comment is not responsive, and requires horizontal scrolling to view completely:

Non-responsive comment dialog which requires scrolling on a mobile device

I'm able to scroll to the right to find the button to submit the review, but I'm unable to scroll to the left to see the full content of each comment option.

Can this dialog please be made responsive, just like the close reason dialog?

1
  • This will be fixed in the next build. I just completely missed that this dialog existed. – Brian Nickel Feb 22 at 17:55
4

There is no string to translate for “This edit clearly improves the post.” I can’t found it in traducir.win

Screenshot from Stack Overflow in Russian:

ruso

8
4

When reviewing first posts (and in other review queues) - New Contributor has been lost

The information that a user is a new contributor has been lost on the main first post review page. Previously, the question was shown with the avatar in the usual place with New Contributor "tag" shown below it. Now, with the avatar being much smaller and at the top (above the question), the New Contributor tag has been lost.

Points to note:

  • Admittedly, if it is the First Post review queue, then the user most probably is a New Contributor.
  • However, as we were emphatically told a year or two ago (when the New Contributor indicator was introduced) to be more gentle/forgiving in our edits/comments/etc. towards common newbie posting mistakes, then that info should still be prominent... or does that advice no longer stand?
  • Yes, you could right click the question title and open the question to see this information, but why add more clicks/work to see information that was once so immediately clear?
1
  • 1
    Also if you start adding a comment then the usual new contributor message is shown - which is arguably one of the more important situations where you need to be reminded to Be Nice. But I agree that it is inconvenient that you cannot see this when you start reviewing the post. – Marijn Feb 24 at 11:36
4

When a review queue is empty, clicking on the "return to ..." invariably returns to the active question queue. If I had been looking at the "unanswered" queue, that setting is lost. (Active on TeX - LaTeX.)

addendum:

On connecting to the site (https://tex.stackexchange.com/) I typically look around a bit before going to check the review queues. I'm working on a Dell laptop running Ubuntu Linux, and connect via Firefox. I haven't (as far as I'm aware) reset anything other than the size of the browser window, but that shouldn't make any difference.

The main window has a list of options in a column on the left; from the top: Home, Questions, Tags, Users, Unanswered. Then the middle column with the question area, and a right-hand column with various notices and links. Above the actual questions is a list of option boxes: Active, Bountied, ... The Active queue is in effect when I first connect; I sometimes select Unanswered (from the list on the left) to see what's there.

But when I click on the icon to see the review queues, the page geometry changes. The option list on the left has disappeared. (It was there until the last design change for the review queues.) I used to return to the main page by clicking on Questions, but that's no longer possible. I believe that if I had been looking at Unanswered, that's what it would return to, but I can't prove that. Now, when a queue has been cleared, this possibility is offered:

Want to get back to the questions? Return to TeX - LaTeX Stack Exchange.

where the text following "Return to" is a link. Clicking on that link always returns to the Active queue, regardless of which queue option was in effect before loading the review queue page.

7
  • 1
    Thanks for the report! I'm digging into bugs right now - could you please provide a bit more information about what's happening here? I'm afraid that I don't fully understand the issue based on your description. – kristinalustig Mar 1 at 18:28
  • @kristinalustig -- I've described a typical session. I hope that's what you were asking for. – barbara beeton Mar 1 at 20:45
  • 1
    The post is confusing and some screenshots would help. “The option list on the left has disappeared” — if you mean the left navigation, this is by design; you can still access the menu using the hamburger icon. You keep talking about “active question queue” and “The Active queue”. If you mean question lists, those aren’t queues (review queues are “queues”). – Sebastian Simon Mar 1 at 23:11
  • 1
    And these aren’t called “option boxes”, they’re just navigation items. I was confused by the usage of the word “connecting”; perhaps “accessing” is a better choice. The “Return to …” link indeed links to the homepage, i.e. https://tex.stackexchange.com/, but look at the small site logo in the breadcrumb navigation (referred to in this answer, the one preceding “› Review queues”. It takes you to https://tex.stackexchange.com/questions. These are different pages with different question lists. – Sebastian Simon Mar 1 at 23:12
  • The filter that you used last (“Active”, “Unanswered”, etc.) is probably remembered on /questions, not on /; there is no setting being lost. So is this post a feature-request to change the “Return to …” link to /questions? By the way, tabs can also be used on the Questions (i.e. /questions) page, which have similar filters, as an alternative to the left navigation. I suspect they behave similarly in the context of this report. – Sebastian Simon Mar 1 at 23:12
  • Thanks for adding more information there. I understand now what is happening - that's not a change that's within the scope of this project, but if you want to open up broader discussion about how we handle those sorts of links and remembering tabs, you could spin off a separate meta post to gather thoughts from the community? – kristinalustig Mar 2 at 15:56
  • @kristinalustig -- Thanks for looking into this. I have learned from another comment that the "hamburger" icon will restore the "left navigation" (I'm not entirely familiar with this jargon), and that provides the facility I'm looking for. As for finding the "hamburger" icon, the contrast on my laptop screen is not optimum, and that icon tends to disappear into the background; I'll have to work on the screen tuning. – barbara beeton Mar 2 at 19:07
4

Another issue with narrow screens (this time it's personal browser specific).

When shown a Low quality posts review task (and possibly other review task types) where the title for the post under review is long, there is no wrapping of the title text.

For instance, this review task is for an answer to the question PHP Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp\htdocs\vendor\symfony\process\Pipes\WindowsPipes.php on line 140.

On Chrome 88.0.4324.190 and Edge 85.0.564.67 (both on Windows 10), and Chrome 88.0.4324.181 on Android 10, the question title causes horizontal scroll but the answer body is fine:

On Firefox 85.0.2 on Windows 10, the title is wrapped - so there is no horizontal scroll bar:

Presumably wrapping (and therefore no scroll bar) is the desired behaviour.

1
  • 2
    Thanks for the bug report - I made this fix; it will go out in the next build, likely a bit later today. – kristinalustig Mar 3 at 17:06
4

In the Close Votes review queue, for community-specific close reasons the number of close votes is shown (left). This is nice, but can we have the same for the general close reasons (Needs details or clarity etc.), just as the regular flag dialog (right)?

enter image description here

3
4

I got a question in the Low Quality Posts which has a bounty in the grace period. My decision on that review was to close the question, but after choosing the close option I got a banner on the top of the page that said: “Unable to close a question with an active bounty”.

enter image description here

Sorry for the screenshot from a non-English site, but I only have that one.

My suggestion is that something needs to be improved on the review pages. For instance, remove the bountied question from the review entirely, or grey out options that are not actually available for the item under review.

4

Some completed review tasks (this is definitely the case for the Low quality posts queue) do not show the action that I chose until the review task is complete (i.e. the reviewers of the item reach a consensus).

For instance, I reviewed this review task but I don't see what action I took (and it doesn't show that I have reviewed it at all) on the review page itself:

but in my history (and the review-generated comment that I posted on the answer being reviewed) clearly show that I have reviewed it:

Completed Low quality posts review items correctly show the action I took, e.g.


This does not seem to be the behaviour in other queues, e.g. Close votes or Suggested edits:


This appears to be due to me having reached the daily limit of reviews in this queue although I think I've seen this happen when I still have available reviews for the day. For the same review task:

Before reaching the daily limit:

After reaching the daily limit:

1
  • 4
    This will be fixed in the next build. I had moved the permission check higher in the code and thought I had accounted for all the cases that had preceded it. I missed this one. – Brian Nickel Mar 8 at 17:59
4

This is the responsive view of the review stats when used on a mobile device. I encircled (yes freehand) all instances where usernames are randomly clipped to the next row due to a fixed width. In this case it happens to exactly half of the usernames. While some users have really long names, a name like Glorfindel with its 10 characters isn't one of those. It would be good to see them on just one line. In the case there is a higher number of reviewed items (for example more then 1K) the name gets clipped to:

Glorfin
del

Which IMHO is even more awkward.

I appreciate the effort the designers made to use as much screen real-estate as possible in potential, by putting the daily and all time lists next to each other. But the screens might simply be too narrow in these cases, and it would look better if they are stacked upon each other.

Screenshot of the review stats page (Thanks to Wai Ha Lee for combining the images into one) (click to enlarge)

0
4

Same user listed twice on audit review:

same user listed twice

1
  • 2
    That's because they did review it twice, somehow. Maybe the event got bound twice or there's something unexpected in the code? This is an extremely rare event, having happened 5 times in total on ruSO and 5 times last year on SO. Since it looks fairly benign and very uncommon, I'm inclined to do nothing for now. – Brian Nickel Mar 9 at 18:45
4

No source string (in transifex/traducir) to translate for:

The edit does not improve the quality of the post. Changes to the content are unnecessary or make the post more confusing.

enter image description here

Link to review

2
  • 1
    Already reported: meta.stackexchange.com/questions/361714/… – Ollie Mar 5 at 20:19
  • 1
    This has made it into Traducir as 258396b5baf8f6192c74f66e93229a7b. It's fairly unlikely that a string will not get marked for translation, this bug mostly speaks to our rough translation pipeline. – Brian Nickel Mar 9 at 19:18
4

The author's name is no longer highlighted if they reviewed a suggested edit to one of their own posts

In the old UI for the suggested edits queue, if the author reviewed a suggested edit to one of their own posts, their name would appear in a blue highlight to make it clearer to others that the author reviewed the edit, especially if no one else reviewed or if their review contradicts the others (e.g. if they overrode an edit's outcome).

However, in the new UI, the author's name is no longer highlighted as it used to be:

OP's name no longer highlighted

I understand that the prior blue highlight (which matched the background for the author on user cards on questions as well as on comments they made) isn't feasible here as it's the same color as the background, so it will just mix in and not be visible.

However, please re-add in an indication (e.g. in text) that the author reviewed a suggested edit, as there used to be before.

4

Feature request: Display the author of the answer when reviewing a suggested edit on an answer.

While reviewing a suggested edit I realized that I had to navigate to the answer to see who had authored it. There are a couple of "suggested edit" situations where it is important to know who asked the question, who wrote the answer, and who is proposing the edit.

The most common situation on ELL is that we have a migrated question from a new user who then creates a new account with the same name as the account that asked the migrated question and they are really confused about how things work. They can't edit their question and they can't comment on answers to their question, so they try suggested edits and writing comments as answers. If it's apparent in the review queues that this is what's going on, we can help them get on track more quickly.

The second situation is when someone is attempting to incorporate information from comments made by the author of a post—it is important to know that the comment was made by the author and not someone else when judging whether it is appropriate for it to be incorporated into the answer.

I apologize if I missed an existing answer that already covers this; I searched all the answers for "suggested edit" but I was just skimming so I may have missed one.

3

In the First Posts review queue, when I go to edit the tags on a question, the How to Edit list pops up. This is normal behavior, but once I click in the input field, or start typing a tag, the list disappears instead of switching to the How to Tag help list. Is this normal, or a bug?

Tested with this task.

1
  • 1
    This is existing behavior that got carried over into the new design. I'll review and see if we can bring the other instructions over. – Brian Nickel Feb 16 at 22:52
3

When reviewing this item in the Close Votes Queue, I switched to the "Answers" tab on the Review Task, and tried submitting a close vote in the new Actions menu. But, like in the old queue, the button didn’t bring up the close dialog. Clicking “Edit” and submitting that on both the “Duplicate” and “Answers” tabs still brings you to the edit page of the actual review task, so the lost QuestionID appears to apply only to the close action.

Nothing happens when clicking on "Submit" when "Close" selected, on Answers and Duplicate tabs

This had previously been reported with the old review UI, but the new UI also introduces the "Answers" tab, and the bug has also been introduced there. (Also, making sure that that bug isn't forgotten since the screenshots show the old UI.)

2
  • This has been fixed in a roundabout way, with a design change that hides the review UI when off the question tab. What's happening is that the close dialog is hosted inside a div inside the post menu, so clicking "Close" would attempt to show it inside an element that's already invisible. – Brian Nickel Feb 17 at 0:06
  • 2
    @BrianNickel This used to work correctly in the old review UI a long time ago. However, it stopped working with it fairly recently, and that same issue got carried forward to the new UI. Why not fix it for the new UI? Does the nature of the new UI mean that you can't go back to how it used to work properly with the old UI? – Sonic the Curiouser Hedgehog Feb 17 at 22:43
3

Will this bug be fixed?

In the close vote review queue, when you switch to look at a duplicate question, the close button is broken

(I haven't been able to test it because the queue here on MSE is always empty.)

5
  • 1
    Yes, it's broken in the new queue. I haven't dared to test the Reopen action, though ;) Yet. – Ollie Feb 3 at 19:20
  • 2
    I mentioned on this duplicate that we're now hiding the actions when you're not looking at the question itself. So it's fixed but in a different way. – Brian Nickel Feb 17 at 17:00
  • 3
    I'm not sure this should be tagged status-completed? Fixing a bug by removing the functionality altogether is not really a fix, that's like "I have a flat tire on my car and I fixed it by removing the wheel so now my car doesn't have a flat tire anymore". A real fix would be to make sure the Close button works when a duplicate is in view. The reply by Adam Lear on the old bug report (2 days after the above comment) seems to suggest that this is planned, so maybe change the status here as well? – Marijn Feb 25 at 16:39
  • 1
    @BrianNickel I saw this still broken in one of the MSE queues yesterday, have to switch back from the duplicate to the first tab to get the button to press. – Rob Feb 25 at 22:33
  • 1
    @BrianNickel Status not completed. - Example: Choices Shown, No Choices - Dupe A or No Choices - Dupe B. – Rob Feb 26 at 18:11
3

Found a couple of problems in the Late Answers queue on AU. This review, for example: First, when I click the edit button on an answer, it shows this:

Answer, not question. The view count is also largely irrelevant, as the number is never shown for an answer; it was also answered, not asked, on that day. Perhaps we could remove those?

1
  • 1
    The Suggested Edits queue has this problem too if you choose Improve Edit. – Glorfindel Feb 16 at 22:01
3

I'm not sure if the new review queues support migration, or if this is just a coincidence. I just reviewed this Super User question and the dialog showed four people voted to migrate it to Stack Overflow. I did as well, but the question is still there, and it has peculiar 'locked'/'unlocked' events in its timeline.

enter image description here

4
  • 2
    Something weird happened but I can't find any logs for it. There weren't any exceptions reported by either the closure route or the private migration API. The timeline makes it clear that it attempted something and that it failed, but beyond that it's a mystery. I was able to migrate successfully on my local instance, so I'm going to say this is probably unrelated to the review queues. – Brian Nickel Feb 18 at 23:49
  • 4
    I think this is because the migration was blocked, as the author was banned or rate-limited from posting on Stack Overflow. See meta.stackoverflow.com/questions/261324/… – Sonic the Curiouser Hedgehog Feb 19 at 0:16
  • 1
    @Sonic that could very well be the case (especially if the author has any deleted posts on SO). An event in the timeline 'migration failed because of a question block' would really help to clarify things, but I understand if the company wants to keep that information private. – Glorfindel Feb 19 at 7:21
  • 1
    @Glorfindel Yeah, I'd make the timeline event a lot clearer for blocked migrations in general rather than what it is now. But it is easy to check for the other reasons that can block a migration, and if none of those apply, it's that case. – Sonic the Curiouser Hedgehog Feb 19 at 7:58
3

It feels a bit stupid to have to select 'I'm Done' or 'No Action Needed' in the First Posts / Late Answers review queues. There's always only one option enabled; can it be selected by default please? Or is this a deliberate choice to prevent robo-reviewing? In that case, I'll probably write a userscript to do it ...

4
  • 1
    Keep in mind that the whole point of the "No Action Needed" button back when it was implemented was to stop robo-reviewers from simply upvoting everything instead: it was one click while upvoting and clicking "I'm Done" was two. Initially, I was thinking that one could make "No Action Needed" require the usual two clicks, but make "I'm Done" only require one, but that would remove that difference. – Sonic the Curiouser Hedgehog Feb 16 at 22:14
  • 1
    Fair enough, if it's a deliberate choice then I won't press the matter (but I'll still write that userscript). – Glorfindel Feb 16 at 22:19
  • 1
    I totally agree with the sentiment of this answer, well said. Although I would have omitted "a bit". – Greenonline Feb 17 at 7:27
  • 1
    The UX here is definitely a challenge, the two possible outcomes dependent on other actions definitely pushes the limits of this design pattern. I'll bring this up to design, but in the mean time I've made it so performing an action selects "I'm Done". In that way, both scenarios require two clicks. (e.g., upvote + submit versus "No action needed + submit). I'm going to mark this as complete and use meta.stackexchange.com/a/361030/235711 for tracking. – Brian Nickel Feb 22 at 16:05
3

It's not possible to flag questions for closure in the Low Quality Posts review queue on sites where you have between 2k and 3k reputation. When I select 'Recommend close' and click 'Submit', no close dialog appears:

enter image description here

There's no network call performed after clicking submit (that's probably the problem); I don't see any JavaScript errors in the console. On sites where I do have the necessary 3k reputation to vote to close, the close dialog shows as normal.

3
  • 1
    This is already reported meta.stackexchange.com/a/361336/344828 and in a couple other places - should have a fix out soon. Thanks! – kristinalustig Feb 24 at 20:06
  • That's a different queue (but probably the same bug, but I have no way to tell :)) and since this one is reputation-dependent, I thought it was worthwhile to mention. – Glorfindel Feb 24 at 20:28
  • 2
    Hah, yes, I think it's the same bug, and also reputation-dependent. Basically, the recommend close action tries to reference a link via javascript that doesn't exist if you don't have close permissions. – kristinalustig Feb 24 at 20:31
3

When more than 3 tags entered in filter box the popup notification from the top of the page contains an extra border around the text:

enter image description here

3
  • 1
    That’s a notification inside a notification! – Sebastian Simon Mar 1 at 6:50
  • 1
    @SebastianSimon and we need to go deeper! Good example here. – αλεχολυτ Mar 1 at 6:51
  • 2
    I fixed this! We had a notice inside a notice. I un-Inception-ed it, the fix will be out a bit later today. Thanks for the report. – kristinalustig Mar 3 at 17:12
3

Follow-up on this bug report: the "action detection logic" in the First Posts queue does not react to retracting a flag.

  1. Open a First Posts review queue item
  2. Flag the post – this will select the "I'm Done" option and enable the "Submit" button
  3. Retract the flag
  4. This should reset the state (deselect the "I'm Done" option and disable the "Submit" button), but it doesn't; I'm still able to complete the item as "I'm Done".
2
  • Potential exploit. – bad_coder Mar 3 at 17:54
  • After looking at this more thoroughly, this is an edge case that would require extensive backend changes, so we're going to status-decline this particular issue for now. Thanks for the report! – kristinalustig Mar 4 at 17:56
3

When doing edits to the already proposed edit or reject+edit in review queue on narrow display I face problem that I can't get to the beggining of the interface, I can get only to the end. Screen attached - not able to move further to the left.

the problem image

1
  • 2
    This will be fixed in the next build. I've learned in the past 2 months how wildly aggressive <pre> tags are about displaying at full width. I had even applied code here that resolved the issue at a couple responsive breakpoints, but we changed flex direction on narrow devices and the min-width: 0% approach stopped working. Adding max-width: 100% was the other piece of the puzzle. – Brian Nickel Mar 8 at 17:57
2

I'm not sure if this is intentional, and what will happen on February 16th, but the order of the 'I'm Done' and 'No Action Needed' buttons has been reversed:

Is this a or a deliberate choice? Right now, it messes up my muscle memory a bit :)

1
  • 2
    This change accidentally bled through. "I'm done" is above "Not action needed" in the new design and the reversed order carried over here. Given that it's been this way for a week and that it only has one week left, I'm inclined to leave things as they are. – Brian Nickel Feb 16 at 20:49
2

(this could be a side-effect of this other bug report about questions being faded out when not logged in)

When not logged in, clicking on the "show [x] more comments" at the bottom of questions (e.g. in the this review on Meta Stack Overflow) does nothing:

2
  • 1
    The console says TypeError: null is not an object (evaluating 't.state.reviewTaskId'). – Sebastian Simon Feb 3 at 10:16
  • 2
    This was related to the faded review bug. A JavaScript error occurred early on in the code and everything after it failed. – Brian Nickel Feb 17 at 16:40
2

When not logged in, the questions in Close Votes review tasks are greyed/faded out, e.g.


This isn't how it currently is, e.g.


Could this be fixed/reverted please? I can't think of a reason why this would be a deliberate choice, but in case it it I've added the tag.

2
  • 2
    That section literally has style="opacity: 0.30000000000000004;" on it — no semantic class name, no explanation. – Sebastian Simon Feb 3 at 9:54
  • 2
    During loading, we use jQuery's fade function to dim the view, which is a carryover from the original code. There was a JavaScript error that prevented us from unfading for logged out users. – Brian Nickel Feb 17 at 16:42
2

When reviewing first posts (in the case of an answer):

Radio Buttons There are two issues with the buttons:

  1. Pointless clicks
  2. Standard radio button UX is not followed

Pointless clicks

Pointless clicks are required. Once an edit has been done, there is only one radio button available ("I'm done" - the other is greyed out), which must be clicked before being able to click "submit".

Utterly pointless! If only one option is available (in a radio button group) then it should be automatically selected. Otherwise a checkbox should be used1.

Radio button UX

When first opening, the "I'm Done" is disabled... so surely that should mean that "No action is needed", as it is the only enabled option, should be selected by default?

But no, if you action something (i.e. make a change to the post, vote, etc.) then "No action is needed" becomes disabled, yet "I'm done" (which magically becomes enabled) is not selected by default.

This is not how radio buttons work. The radio buttons are extremely confusing in their logic, and leave the user dithering over which one to click, only to find that one, or other, is disabled anyway (without the only enabled button being automatically selected).

In addition, the "No action required" radio button is superfluous to requirements, as if the user could click Submit, without doing anything (which they used to be able to do so), then it is implicit that no action is required.

In summary, there is no need for the radio buttons and they should not exist:

  • "No action required" is implicit when the user clicks the Submit button after having done nothing, and;
  • "I'm done" is the only choice (if an action has been taken).
  • At no time are both buttons enabled, thereby negating their reason for existence.

"Question"/"Other Answers"

WRT to the "Question"/"Other Answers" tabs, it was already possible to view the question of the first post answer under review, by simply scrolling down. Now you have to click another button. The other answers weren't visible though, so the ability to now view them might be an improvement, I guess.

Conclusion

UI/UX improvements are meant to make things easier, and not require even more effort and induce RSI. As a result, reviews now take longer to perform, which impacts on people's time and reduces workflow efficiency. These additional clicks quickly add up, especially when doing multiple reviews, across multiple sites. If people were being paid (by the hour) to do reviews then they might not mind so much about the time each review takes, but as this is an unpaid voluntary task, it's not a good idea to put reviewers off, as this will lead to more full queues, and people will not then be able to suggest edits, or what-have-you.


1 However, that would mean that the UI element would have to change, from two radio buttons (before anything was done), to a single checkbox (after some change has occurred), and obviously changing UI elements, in the middle of a workflow, is extremely bad practice.

1
  • 1
    I did write a user script to make it so that clicking a review action will immediately submit the review. This restores the behavior of the old review UI. – Sonic the Curiouser Hedgehog Mar 22 at 6:39
2

If a question has already been closed since you opened the review, selecting "Close" and clicking "Submit" has no visible effect. In the current version, you get an error message informing you that the question is already closed.

Behind the scenes, there's a 500 error on a request to GET https://[site]/flags/questions/[post-id]/close/popup.

1
  • 1
    This fix is building out. We were sending error messages to a non-existent view. – Brian Nickel Feb 18 at 17:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .