Just as a note: in my description I did not interject that a user had defined a bug. I was talking from UI design only, from a users perspective. I find the the UI seems to suffer. I must say though that since 2003 the UI had significantly improved.
David E Jones sent the following on 10/28/2007 12:17 PM: > > For customers, yes, I think it's VERY important to make that distinction > too. If you have a support contract or they want fixed bids it's > critical. Even if not it is very valuable for planning and setting > expectations, basically just good client communication. > > -David > > > On Oct 28, 2007, at 11:28 AM, Jonathon -- Improov wrote: > >> Well, my message (or response) was very tied to the real world. My >> clients don't care what my design patterns or thoughts are. If >> something doesn't work according to their needs or wants, it's a bug. >> >> I was trying to use the "gray areas" in my message to point out that a >> "design bug" (BJ's term?) may or may not be a bug in human >> perspective, depending on real world conditions (availability of >> resources, for eg). >> >> Of course, in IT speak and in a computer's perspective, a function >> that does not work as designed is buggy. But try telling that to a >> customer. "It's not a bug, it's a feature, so would you please?". :P >> >> Jonathon >> >> David E Jones wrote: >>> Was this message intended to evoke a response? Well, here it is. >>> The way I'm used to defining things what you describe is more of an >>> "issue". An "issue" is anything that represents a difference between >>> what a user (any user...) needs or wants and what the system offers. >>> A bug is a totally different animal. When looking at bugs it doesn't >>> matter at ALL what a user needs or wants, the only thing that matters >>> is what the current system is designed to offer. If there is >>> something that the system is designed to offer, or in other words >>> that is already implemented in the system, but that is not >>> functioning as intended, then THAT is a bug. Fixing a bug is changing >>> something (usually small, isolated changes) that exists, not adding >>> anything new. >>> I may be biased on this one, but I don't really see this as all that >>> complex. The point for any word is to have a useful definition that >>> makes distinctions of value in real life. Defining a "bug" as >>> anything a user doesn't like basically makes a release branch with >>> "bug" fixes only useless, as it might as well be the trunk. That is a >>> pretty good litmus test for this definition, IMO. >>> -David >>> On Oct 28, 2007, at 12:32 AM, Jonathon -- Improov wrote: >>>> If some function doesn't work according to user needs, then it is a >>>> bug. Period. >>>> >>>> Now the gray areas. >>>> >>>> If that same function still serves the user's needs if used in some >>>> other ways (albeit not exactly according to user's mouse-clicking >>>> habits), it depends. >>>> >>>> If I'm given time and resources to fix the issue, then it is a bug. >>>> If I don't have time and resources to fix it, then it is... erm... >>>> not a bug. :P >>>> >>>> Jonathon >>>> >>>> BJ Freeman wrote: >>>>> Most bugs arise from mistakes and errors made by people in either a >>>>> program's source code or its design >>>>> we all accept that if the code breaks it is a bug. >>>>> For applications that have UI, it is also a failure if the person >>>>> using >>>>> the application is not given the input necessary to put correct >>>>> data and >>>>> then gets an error message say they should. This to me is a design >>>>> bug. >>>>> So I put to you. >>>>> is it important to include how a user might use the application >>>>> inappropriately if there is not the correct information for the user >>>>> interact without getting error messages. >>>>> if so is this considered a bug. >>>> >> >
