Touch Can The Simple Touch Be Used as a Reliable Web Browser?

[afv011]

Originally Posted by anamardoll

Speaking as a technical writer, this.

Documenting a bug does not make it a feature. It IS good to document it so that the customer has a chance at realizing that the bad behavior is KNOWN bad behavior, but it is still a bug.

I think it very unlikely that the NC highlighting feature was implemented this way on purpose, with a specific use case in mind.

You are mistaken. When developing software, you are given a set of requirements, and the final goal is for the software to fulfill those requirements. If you do not like how a feature behaves, but that feature adheres to the requirements, then you do not have a bug. You would then submit a change request to have the requirements updated, so the feature can behave in a different way.

I'm not saying that this feature works as I would want it to work, I am just saying that it works as it was intended to work, hence it is not a bug.

[tomsem]

Originally Posted by afv011

You are mistaken. When developing software, you are given a set of requirements, and the final goal is for the software to fulfill those requirements. If you do not like how a feature behaves, but that feature adheres to the requirements, then you do not have a bug. You would then submit a change request to have the requirements updated, so the feature can behave in a different way.

I'm not saying that this feature works as I would want it to work, I am just saying that it works as it was intended to work, hence it is not a bug.

In a quality software organization, and especially those developing consumer software, requirements are not handed down from above, impervious to challenge and change. Better ideas are encouraged and early feedback sought out and incorporated. It's perhaps not surprising that B&N hasn't apparently achieved this level of maturity, they haven't been at this very long. But given the success and growth curve of their ebook division, I would expect this to change, and to do so sooner rather than later. Otherwise, they'll be toast.

In this specific case, given that it would probably have been just as easy to implement the feature in a way that nearly everyone would agree is more intuitive and useful, I have to think the feature was not specified in sufficient detail or delivered early enough in the cycle to allow for any course-correction. Documenting the behavior was the expedient thing to do. In terms of addressing it in the future, 'fixing' this will have to compete with all manner of other changes that they'd like to make, now would require a coordinated documentation fix as well, and it may not fare well. It 'works', after all (a more serious problem IMO is that you cannot extend a selection to previous or next page).

In all the software projects I've worked on, there are always a number of bugs that get deferred from one release to the next, even though everyone agrees they are in fact bugs. Often the risk and cost (including opportunity costs) of fixing bugs outweighs any benefit that might be achieved by fixing them.

[anamardoll]

Originally Posted by afv011

You are mistaken. When developing software, you are given a set of requirements, and the final goal is for the software to fulfill those requirements. If you do not like how a feature behaves, but that feature adheres to the requirements, then you do not have a bug. You would then submit a change request to have the requirements updated, so the feature can behave in a different way.

I'm not saying that this feature works as I would want it to work, I am just saying that it works as it was intended to work, hence it is not a bug.

YOU are mistaken. There are multiple kinds of bugs, with different levels of severity. The lowest severity is usually translated as "annoying to the user".

Annoying implementation and incomplete implementation of a feature are both considered bugs. As I said, I do this for a living.

[afv011]

Originally Posted by anamardoll

I do this for a living.

So do I, embedded real-time.

[anamardoll]

Then you should already know about bug severity and the differing levels. Unless your company is one that only considers "severity 1" bugs to be ACTUAL bugs and everything else is slapped "user error" and then pushed onto the market asap.