Interface improvements for the issue view

One of our main goals with The Bug Genie is to make your life easier when tracking issues. To achieve this, we’re constantly looking for ways to improve. Closing in on the beta release for 3.3, we’re fine-tuning our final adjustments in the issue view, and wanted to share with you how this has been changed between the current release and the upcoming 3.3 release.

Read on for more details!


issueview_3.2 issue details page

Above is a screenshot from the current 3.2 release, showing the issue details for an old issue in the public issue tracker (issue #1621). Immediately, there’s a couple of things that stand out:

  • Whitespace-to-content ratio: There’s simply too much wasted space. There’s not much text on this page, but even so, you can only get to comment #5 on a fairly decent sized browser window.
  • Overview: Some important details – such as current status – are visually hard to distinguish from less important information, making it harder than necessary to get a good overview. You also need to click around to find attachments or comments


Update issue details page for 3.3

As you can immediately see from the screenshot of the 3.3 version, things have drastically improved.

  • Issue details are nicely grouped together in logical sections. Headers such as “People involved” and “Time tracking” gives you a good overview, quickly.
  • Comments are now part of the main issue stream, with a refined look. No more scrolling, and you can see more comments in less space.
  • Attachments (although no attachments here) are now shown to the left, as attachments are relatively important if they are present.

We hope you like what we’ve done so far. A few minor changes remain before the beta release will be made available for all you guys to test.

Until then, please leave your comments below!

10 thoughts on “Interface improvements for the issue view

  1. Great work Daniel! I’m very interested in seeing the RC and especially some of the changes made to scrum pages. The new layout is a very big improvement. Keep up the good work.

  2. Very compact, much more efficient, very thoughtful improvements! I like the full color treatment for the status flag. Can you also select the color of the text inside the flag to create enough contrast to make the text readable with all colors? Does the status flag text wrap to accommodate larger phrases like Ready for testing / QA? Thanks for the news! Looking forward to the Beta (if there is an easy installer 🙂 Cheers!

  3. Hi that is nice
    It Would be great if the Wiki will be improved, its to complicated to create new content. It would be easier if you can create ne content in Wiki in Kind of a cms Like ‘create new Site’ with a gui instead of Codes to create Headers, sites and the on

  4. While I love most of the improvements (if not all of them), the only thing I dislike is that all the line breaks are totally ignored. If I put a linebreak in here, I want the linebreak to appear in the output. Simple.

    I fixed that myself in 3.2 locally, but it seems it needs more fixes again in 3.3, as my previous fix isn’t working anymore.

    I really think there should be a “plain text” mode of writing, which has no codes at all breaking the issues. I mean, you can keep mediawiki and markdown for those who want, but please have a third syntax “plain text” which is purely plain text. What you see is what you get. That would be GREAT, and would stop me from making local fixes to stop the output be unexpected.

    Thank you!

    1. You’re not the first to be annoyed by linebreaks not behaving as intended, which is an unfortunate side effect of a decision that was made early in the 3.0 development cycle – using mediawiki syntax as the primary markup syntax everywhere. While this has its advantages, there are also downsides – such as the way the mediawiki syntax is single-line-break agnostic.

      In 3.3 we added support for github-flavored markdown syntax (which does preserve linebreaks), but the very latest commit also adds “Plain text” as a supported syntax. This will all be available in 3.3.

  5. From the screenshots, it still seems difficult to manage permissions for issues. It would be great if we could define who has access to an issue when creating it and to be able to easily manage the visibility for both the issues and comments made on an issue. Not everything is meant to be public when working on some commercial projects.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.