Created attachment 143100 [details] Positions are now reversed This makes the workflow slightly awkward, since you typically first change a resolution status, and then click the save changes button. Because the save changes button ins on the left, you first need to move the cursor over to the right, make a change, then move the cursor back over to the left to save it. I would recommend reversing the positions and bringing back the old locations for these UI controls, which was more ergonomic as it requires less cursor travel back and forth. As a further improvement, the Save Changes button could also be moved closer to the Resolution Status combobox to further reduce cursor travel.
Created attachment 143102 [details] Alternative new comment layout (In reply to Nate Graham from comment #0) > As a further improvement, the Save Changes button could also be moved closer > to the Resolution Status combobox to further reduce cursor travel. Check attachment.
That would be fine. For consistency's sake, the "Add Comment" button should then be moved over to the right as well. Or everything could just be kept left-aligned. :)
Created attachment 143105 [details] Alternative new comment layout 2 How about now?
Could the "Save Changes" button be moved to the right of the other controls? That would preserve a left-to-right flow. Then the "Mark as duplicate" button could go below onto another row, as it was before.
(In reply to Nate Graham from comment #4) > Could the "Save Changes" button be moved to the right of the other controls? Since "Save Changes" is a primary button, don't you think it would look ugly if it is under the textbox somewhere in the middle and not aligned to either the right or left edge of the table? > That would preserve a left-to-right flow. I understand this is better from a UX perspective but worse from a UI perspective (in my opinion). The thing I suggested first (https://bugsfiles.kde.org/attachment.cgi?id=143102) works in terms of left-to-right flow, so maybe we can implement that? > Then the "Mark as duplicate" button could go below onto another row, as it was before. This can be done.
I'm a firm believer in the idea good design can keep UX and UI from being in conflict, but when this is unavoidable, UX has to win. In this case I think we can have both, with a design like this: ``` +----------------------------------------------------------------+ | Comments go here | | | | | | | | | +----------------------------------------------------------------+ Status [ CONFIRMED v ] [Save Changes] [Mark as duplicate] ``` (paste it into a text editor, because the new design mangles text that looks better in a monospaced font, which is another issue. :) )
(In reply to Nate Graham from comment #6) > In this case I think we can have both, with a design like this: I see what you mean. Expect an MR very soon :) > (paste it into a text editor, because the new design mangles text that looks > better in a monospaced font, which is another issue. :) ) Unfortunately, as you know, Bugzilla doesn't have markdown or any formatting support. The only formatting it supports is for quoting text. I find it kind of annoying to read conversational text in monospace. But I wanted to keep both options as I knew that some people might find the opposite annoying. So, you do have the other option. Just go to your user preferences and select the "Classic" theme. It will change the comments text to monospace and keep everything else exactly the same. Additionally, if you believe that this should be the site default, i.e. everyone (including logged out users) should see comments as monospace unless they manually alter their preference, please tell Ben to change the site default to the "Classic" theme.
I'm torn. I agree that variable width text is nicer for reading in general. But being able to use monospaced text for impromptu ASCII art is nice, as well as making crash backtraces in bug reports a lot more readable. For the former, we can probably abuse the fact that quoted text is still monospace. But we can't easily do that for inline crash backtraces. It's really inconvenient that you can't just make text monospace by putting it in a ``` block.
(In reply to Nate Graham from comment #8) > For the former, we can probably abuse the fact that quoted text is still monospace. I intentionally kept the quoted text to be monospace, so that we could abuse it as makeshift monospace formatting :) > It's really inconvenient that you can't just make text monospace by putting it in a ``` block. It is indeed :( We are dealing with prehistoric software here. This thing is written in perl :(
(In reply to D. Debnath from comment #9) > (In reply to Nate Graham from comment #8) > > For the former, we can probably abuse the fact that quoted text is still monospace. > > I intentionally kept the quoted text to be monospace, so that we could abuse > it as makeshift monospace formatting :) Good thinking. Let's stay with that for a while and see if it's enough.
Git commit a2802ff5cabd44ec34c4bcd52df2137e71f20867 by D. Debnath. Committed on 04/11/2021 at 20:33. Pushed by bcooksley into branch 'kde-5.0'. Reverse "Resolution Status" and "Save Changes" buttons M +28 -13 skins/standard/additions/show_bug.css https://invent.kde.org/websites/bugs-kde-org/commit/a2802ff5cabd44ec34c4bcd52df2137e71f20867
Much better, thanks!