It comes down to one thing: friction. Every decision time you ask a force the user to make a decision, however small, it increases the difficulty of using the software. The software might not seem difficult, might even seem eminently usable and very well-designed, but over the course of thousands upon thousands of cases, requiring Telling a field will limit adoption.
At some point, every one of us has thought about using some piece of software, thought about the hassle of doing so, and written user they can't submit a Post-It to ourselves, or gone down the hall instead for case until they've made a face-to-face meeting. That one little decision kept a piece of data out of the software, which made the software itself less valuable than it could've been. We've all seen this with other pieces of software about what should be in our own livesthis required field is, but as software developersin effect, it's still tempting to enforce our will on the user through rules rather than designrejecting them. For FogBugz, And we work really hard do everything we can to make sure that we guide the FogBugz not reject user through affordances rather than forcing them with rulesinput.
The other thing we've seen is that requiring some data doesn't necessarily mean
We've helped customers write API scripts that you're getting good data. If you require will, on a text fieldcase being entered, you're just going to get "asdf" instead of check the blank field you'd have gotten. If you require a dropdown, you're going to get "Other" in against a lot set of cases. Remove "Other" and you'll get truly meaningless data.
If users are putting in cases without the information needed to resolve themallowed values, that's not a software problem; it's a people problem. We haven't seen a situation yet where required fields couldn't be replaced by education andfollow-up.
On the subject of follow-up, it would be a relatively simple matter to write a script using our API to check all new cases for if the required information, kicking off a gentle email reminder, correct value isn't in there (or even assigning the case back to the submitter. Or, you can write a plug-in to check if the value of a given field on case creation and simply is blank) assign the case back to the submitter with a gentle note to put in correct values. By separating enforcement from the action of submission, you don't discourage people from using the system, but you get the data you needThese have worked very well.Still, even
Do we know best? Certainly not. We're not doing this can be exasperating for users, because no matter how much you think that every case should have a customer ID, there are going to be some instances where that's just not the casewe're arrogant jerks who know what's best for everyone.
To go one step further, It's a customer has asked me why we take such an extreme view of required fieldsbusiness decision, even to the point of making it difficult to require a field via a plug-in. We may allow a plug-in to simulate not a required field at some point in the future, but that would be incidental to some other goalreligion. We don't feel But we believe that this FogBugz is an extreme viewpoint. We've heard again and again:
We had a bug tracker at my last company and nobody used it.
We think we've nailed down why this happens. It's due do the user-unfriendly nature of most systems. We've chosen to exclude Bugzilla-style blocking and required fields so as easy to prevent people saying:
We had FogBugz at my last company and nobody used it.
If this means that we cannot satisfy those prospective customers who absolutely require required fields, and cannot use any because of the workarounds above, that's something we're comfortable withthis design decision.
