I wasn’t part of the bug reporter preview but having used it today, I’ve got to say that I am not a huge fan of the updated interface. It may be pretty, but for me it’s harder to use. I’d rather see icons and names at the start of the entry screen than scroll through three pages of iconless text (and their subtables) as I try to recognize the phrase that best matches my issue.
It’s funny because this design is a clearly cognitive mismatch between how I used to find the right items, which was just a matter of a single-screen scan, and trying to construct or detect the right verbal phrase that now matches the target issue. The new system is hitting the wrong part of my brain.
If you look at it, it’s laid out very nicely, with big clear areas to enter text and the “drop a screenshot” system is vastly improved over the old system. (Nice job there!) I like the font choices, can live with the sickly purple, and a lot of thought has gone into streamlining issue entry.
That said, the whitespace feels like there’s too much there, the left-to-right range of field width is too hard to scan to review the information you’ve entered, and as I mentioned before, the ‘What are you seeing an issue with?” tables are a little too much for me to process.
If I were to redesign it, I’d:
- Change the wording to be more business-like: “Classify this issue:”, not “How would you classify this issue?”. “Affected Product or Area”, not “What are you seeing an issue with?”. “Bug or Suggestion”, not “What kind of issue are you reporting” (with the bias being towards ‘bug’, since that’s the primary purpose of the tool.) “Reproducing the issue”, not “What steps can we take to reproduce this issue”, and so forth.
- In the prompt text, I’d eliminate weasel words. “Step-by-step instructions to reproduce this problem”, not “Please provide a step-by-step set of instructions to reproduce the problem (if possible).”
- I’d cut back massively on the vertical whitespace, allowing more of the report to be seen at once. There’s just too much floaty gray for my taste.
- I’d apply one of the “optimal line length” studies, which suggests anywhere between 50 and 75 characters per line for text (which is most of what this tool provides) and 80-160 characters for code entry. (I’d also consider a code-specific “related code” field.) The current width is about 98 characters if I counted correctly. It is very hard to track from the right back to the left while maintaining vertical positioning.
- I’d explicitly mention Markdown/Common Mark support for bullets and numbering, as well as other markup.
- I’d change the Suggestion/Bug toggle into either a radio control or a visual toggle with Bug, which should be to the left, pre-selected.
- I’d massively increase the size of the “Cancel/Save/Submit” buttons and move them from the bottom bar to the main field under attachments.
- Finally, I’d add a specific call out on completion. Thank the developer for taking time from their busy workday and express appreciation for participating in the radar process. Enroll them either in a rewards-for-radars program or a random giftcard giveaway for the month. It’s a small price to sweeten that “Radar or GTFO” message and it lowers frustration of typing into a big, faceless, low-feedback system.
Those are my thoughts. What are yours?
2 Comments
I agree specifically with the rewards part for people providing actionable bug information.
Warning: long pent-up rant ahead.
IMO, Apple have historically aimed at keeping bug-reporting closed and one-way. They have not wanted bug reporting to be used as a real, honest channel for developer feedback or suggestions. Usually, the only time Apple engineers want to talk to a developer is when the Apple engineer needs specific information from that user. (And yes, as a “user”.)
It’s clearly designed to impose as much trouble on the user as possible, to help prevent frivolous use, while limiting the amount of work that Apple engineers have to do, and limiting the amount of contact that Apple engineers have with the horrible developers.
Unless this has changed, and Apple have opened up the process to make it a two-way channel, with accountability and roadmaps for bug fixing and feature addition/improvement, then no thank you. Apple have been doing this to us for decades. And I’m not going to be used as an unpaid tester in a one-way process where I’m ignored if my technical problems don’t align with Apple’s current priorities.
There are individual engineers who don’t like this game, but overall, this is pretty much Apple policy towards developers; they see us as a necessary evil, antithetical to Apple’s top-down approach to everything. You see it in everything they do; the way they use WWDC to announce top-down announcements, the lack of a roadmap, the lack of genuine soliciting of feedback from developers (when was the last time Apple asked you for your thoughts on their APIs or tools?), the almost-total secrecy, etc.
Even major, much-needed improvements to Xcode are sprung on us once a year, instead of being incorporated in to frequent releases like a normal, reasonable tools provider. It’s the complete opposite of responsive, reactive development. It feels like developing for IBM in the ’80s.
Yet when Apple see a business case for opening up , they are only too willing to do so: see the Swift success open-source success story. It makes the total-secrecy model of the rest of Apple’s engineering look so developer-unfriendly and antiquated.
I’m not playing. If Apple want detailed bug reports from me, they can make them open, actionable, accountable.