Posts Tagged ‘FogBugz’

Search Axis Auto-Complete: Helping you find what you’re looking for (even faster)

July 23rd, 2014 by Aaron Maenpaa

In April, I talked about how we’re trying to make our axis search more discoverable, and ultimately, more widely used. Our first step was to introduce the search guide, which brought our axis documentation directly into FogBugz where it’s more relevant and contextual. The next step (which I hinted at), was to more actively help you create axis queries via auto-complete:

Auto-complete in action

… wait, what? What are axis queries?

In addition to supporting run-of-the-mill “full-text” search (e.g., “bob widget bug”), FogBugz also supports axis queries which let you filter cases based on criteria that apply to specific case fields. You probably know that you can specify exact values for fields in a filter, but it can be slow to click around for a one-time need to find a case. Instead of choosing between specific but slow and fast but vague, try an axis query. Compared to full-text search, axes can greatly reduce the number of matching results you need to scan over (or worse yet click and view). If you know a case was about a crash and there was an email in the case mentioning “I tried reinstalling”, you could simply search for those words, but if you know that “crash” was in the case title, using the title axis could make finding the case much faster:

On my FogBugz installation, that’s 239 cases down to 4! If you also know the case is in your “Support” project and had a tag “regression”, add project:Support tag:regression to your query. Avoiding scanning over a long result list just saved enough time to watch at least 29 cat gifs, and that’s just scratching the surface! So far, axis auto-complete has been really well received in our internal testing. On the second day of our Summer 2014 internship, I observed one of our interns doing an axis search using the new auto-complete feature… which is something I would have never expected even a few months ago. Axis search has gone from a largely hidden power-user feature to a productivity booster that’s discoverable enough for brand new users to find it.

… so what does this auto-complete…uh…complete?

When you start typing any axis name, you will see a list of potential matches. Typing a value for an axis will auto-complete possibilities (for example, your list of project names after the project: axis). Auto-complete also knows how you can sort your cases, suggesting sortable column options when you start to type them after “orderBy:” Finally, it lists past queries from your search history in case you’re just trying to make the same search you made the other day.

assigned

Axes: Including assignedTo, editedBy, opened and many more.

me

Objects: Including the names of people, projects, milestones in FogBugz, as well as special names like me, today, tomorrow.

auto-complete historical searches

Historical searches: Helping you run your favorite searches again.

Our favorite searches:

With all this talk about axis searches, it seems like we should share some of the searches we run frequently to help get you started:

 Michael: “What was that case again?”

 Justin: “Cases I’ve assigned out.”

 Adam: “I put this on everything.”

 Aaron: “Who’s doing what?”

Documentation is available on our help portal for auto-complete, the search guide and our complete list of axes. Like the look of it, but don’t have FogBugz? You can try FogBugz for free today!

Sign Up For the FogBugz Beta (Closed)!

March 26th, 2013 by Aaron Maenpaa

Update: The beta is now closed. A big “Thank You!” to everyone who signed up.

 

Want to see what’s coming in the next version of FogBugz? Now you can! The FogBugz team has been hard at work on a project we’ve code-named “Ocelot” for the past several months. We’ve rebuilt the core pages of FogBugz to use a completely new architecture that’s significantly faster. Like, seriously fast. And now we’re ready to start sharing it with you!

 

What’s shiny and new?

The new version of FogBugz is a single page app when it comes to the list page and the case page. What’s that mean exactly?

  • a super fast list page for listing and filtering your cases
  • a wicked fast case page for viewing and editing individual cases
  • blazing fast search for finding the cases you’re interested in
  • and blink-of-an-eye fast transitions between these pages

We’ve been dogfooding the new UI internally for a couple of months now and it has really improved our own experience of using FogBugz. We hope you’ll like it!

Riding the Ocelot

 

A Word of Caution

This is a beta, so there will be bugs. If you find one, please contact our customer service team and let them know. Furthermore, since we’re trying to get this into your hands as soon as is humanly possible, there are some caveats to the beta:

  • The beta is for FogBugz On Demand accounts only.
  • The beta UI has only been tested in Firefox and Chrome. Support for IE10 and Safari are on our TODO list and they should mostly work, but they might not and you will probably run into cosmetic issues.
  • Customizations from the BugMonkey Plugin will not apply to the beta UI.
  • With a few exceptions, existing plugins will not interact with the beta UI.
  • A number of features have not yet been implemented including:
    • Custom fields
    • Quick case add on the list page
    • Graceful handling of concurrent case editing
    • Similar speed improvements and single-page-appification to Wikis, Discussion Groups, Reporting, Admin pages, etc.
    • The Working On menu
    • Searching Wiki Pages and Discussion Groups from the main search box
  • With the exception of some specific text used in outgoing emails, the beta UI is not localized

 

Share your Feedback

We’re looking for feedback on: How the application feels, your general impressions, any missing features that impact your day-to-day workflow, and of course any bugs you find. Once you’ve started using the beta, please contact our customer service team and let them know what you think!

Once your account is enabled for the FogBugz Beta, you can enable and disable the beta UI on a per user basis from a link in the top right corner. If you later decide that you’d like your entire account taken off of the Beta, just let us know and we’ll be happy to take care of that for you.

Sign Up!








At Long Last: The Case Merge Plugin!

August 30th, 2012 by Quentin Schroeder

We have a variety of methods for tracking what features our users are looking for, and by every measurement available, the ability to Merge Cases was at the top of the list! In fact, this has been a top feature request for quite some time.

We’ve had our eyes on this feature for a while now and even drafted a feature specification for it, but while we were drafting ideas, a user from the FogBugz Developer Community contacted us with a fully functional plugin that solved the problem! So, without further ado, may I present the Case Event Merge Plugin, written and generously shared by the developers at Quarantainenet:

“The FogBugz Case Event Merge plugin adds the functionality to display the case events of a duplicate case in the original case…. We have tried to overcome the design problem of merging by not merging at all: we just display the events of one case in the history of the other, keeping the workflow of cases intact.”

Here’s a quick video that goes over how it works:

The Case Event Merge Plugin is available for both FogBugz On Demand and customers running FogBugz on their own server. Follow the installation instructions to get started, and check out the full documentation to see what the authors have to say about it. Read on for a bit of history on the development of this plugin.

 

Why was this feature so hard to add?

After Quarantainenet knocked the ball out of the park with this plugin, it is easy to look at it and wonder why Fog Creek didn’t deliver it earlier. The answer lies in the details, or to be more accurate, the lack of details.

The solution that Quarantainenet devised is simple because it does not manipulate the existing rows in the database. In the feature specification draft that we were working on at FogCreek for merging cases, we were looking at it from the opposite perspective and dealing with the repercussions of trying to move the bug events from one case to the other within the database. In this scenario we had a lot of corner cases and questions that weren’t trivial to deal with.

For example:

  • Once a case is merged to another, does the system delete it?
  • What happens with new incoming emails that have the case number for the now-closed duplicate case?
  • Do we try to merge the attributes of the two cases together?
  • How do you seamlessly transition the conversation to the new case and discourage updates to the old one?

Each of these questions has valid possible solutions that we considered, but would lock the users into a specific workflow, which was something we were trying to avoid. The ability to merge cases had to make life easier for users who kept getting emails with the Case keyword stripped from it, or those infamous CC chains that seem to spawn an endless number of new cases. The solutions we were batting around made life easier in about eight out of ten scenarios, but made life a lot more confusing in those last two cases. The net gain was teetering on the edge of positive, which meant producing it just wasn’t worthwhile.

 

A Fresh Approach

The genius of the Case Event Merge Plugin is that the only data it requires is a marker for the duplicate cases whose events we want to display in the other case. The real work comes when FogBugz goes to render a case view page; the plugin interacts with the rendering process and creates a bunch of “pseudo bug events” from the duplicate cases. (The Kiln plugin uses the same pseudo bug event mechanism to show changesets inline with the rest of the case). These events are read from the database just as they would be if the user went to view the closed duplicate case. What this means is that the Plugin can crash, fail, be deleted, mucked with and otherwise abused and your original data is left completely intact.

Because Quarantainenet was never thinking about manipulating the existing Bug and BugEvent tables, their solution exclusively utilizes the rendering of the case view. This means that all of the core FogBugz code gets to keep chugging happily along, completely oblivious to the fact that these two cases are anything but “Resolved as Duplicates”! It’s simple, elegant, and it just works.

This plugin is already being used heavily at Fog Creek and we know many of our customers are excited about its release as well. Several years after the feature request first appeared, we’re glad that we can finally mark it as Resolved (Implemented).

Better BugzScout Error Reporting

January 30th, 2012 by Jude Allred

Prelude and a pain point.

One of the many ways to spawn cases in FogBugz is via a mechanism we call BugzScout. BugzScout is a simple interface for collecting crash reports from your software in the wild. For example, you might add an exception handler to your product which hooks into BugzScout so that when your customers encounter errors, you receive a case in FogBugz with details about the problem. Unlike the FogBugz XML API, which can also be used to serve this use case, BugzScout doesn’t require that you embed any type of FogBugz security token in your deployed application, and BugzScout will automatically collate all of the bug reports into cases based on titles of the reports.

We use BugzScout extensively throughout our own infrastructure — when FogBugz accounts misbehave, if an unparseable email gets stuck in an account’s mail queue, if an account’s full-text search index gets corrupted, etc., we receive cases in our FogBugz environment detailing the problem and often including key diagnostic information such as stack traces and assorted report-specific meta-data.

BugzScout has been around for a while, long enough to get a little crufty, and we’ve felt some BugzScout pain as we’ve scaled up. Pain can lead to cases:

We generally agreed with these suggestions, and we’ve definitely known the frustration of some small process misbehaving and sending literally thousands of BugzScout reports our way.

Better.

The first thing we came up with was what we all thought would be a completely amazing BugzScout-esque product which could solve the BugzScout use case perfectly. But we didn’t build that… its scope was slightly larger than the part-of-a-week we wanted to spend on it. Plus, building a new product wouldn’t have solved our immediate problems fast enough. Our driving force behind the improvements became the following insight:

Sometimes you get a human-readable number of BugzScout reports. In these cases, you absolutely want the full error text from each occurrence, and it’s reasonable to route the event through all of the standard notification hooks. If someone doesn’t want to hear more about this error, they can direct BugzScout to stop reporting via editing the case.

Other times, you get so many reports that no human will read them. The case is spammed with stack traces and error notifications. After some point, additional stack traces are of no use — you’re not going to read through them anyway, they just make the case cumbersome. At this scale, you need BugzScout to do a few things:

  1. Shut up and let me fix it. You’ve already gotten a bunch of emails about the problem- one additional email per occurrence is of no use to anyone, but can legitimately hinder your efforts to actually deal with the problem.
  2. Help me know I’ve fixed it. It’s always been possible to determine if more reports are coming in by either watching the occurrence count of the BugzScout case or by monitoring when the case was last modified by BugzScout. Unfortunately, if you wanted to accomplish #1 by setting BugzScout to ‘Stop Reporting’, you’d also stop getting updated timestamps from when new reports came in.

We decided that reconciling #1 and #2 would be a great improvement for BugzScout and would be well within the scope of a few days of development. We felt confident that this type of change would solve our pain point, but before we went any further we wanted to make sure we weren’t operating in a no-fact zone. We reached out to our SaaS platform and gathered some anonymous data on how people were using BugzScout. The data confirmed our guess: Our use cases are valid and a significant amount of people are using BugzScout-based error reporting.

We settled on:

  • BugzScout will now automatically place itself into “Stop Reporting” mode after 50 occurrences of a report.
  • Last Occurrence is a new case field which is stored alongside all BugzScout cases and is fully searchable, filterable, etc. Last Occurrence is the timestamp of the most recent BugzScout report, regardless of whether that report was recorded as a case event.

Resulting in:

  • Human-readable amounts of BugzScout reports should be unaffected.
  • Human-unreadable amounts BugzScout reports will automatically cut off after 50. This means that the bloody tide of email will be curbed; BugzScout cases are limited to having a workable number of events in them.
  • If it comes time to collect more reports, you can do this by editing the case and instructing Scout to ‘Continue Reporting’.
  • Last Occurrence is a new and useful filterable value.

Shipped.

We’ve been dogfooding the new BugzScout in our FogBugz environment for the last month and have been quite happy with the improvements. We’ve found that the automatic shutoff of case event generation after 50 reports has allowed us to function much better when dealing with issues at scale.

Here’s an example of how our team likes to monitor the incoming BugzScout reports using the new Last Occurrence column:

This isn’t the only way we triage our BugzScout reports, but this simple filter lets us quickly spot any issues that are happening right now and know if they’ve happened with enough frequency to warrant immediate attention.

These changes went live to FogBugz On Demand two days ago, so we hope that you’ve found them useful. Licensed FogBugz customers will get these changes in our next licensed release.


Looking for more?

Visit the Archives or subscribe via RSS.