To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=100936
------- Additional comments from niarb...@openoffice.org Sun Dec 27 12:17:18 +0000 2009 ------- I would like to add another feather of "seriously annoyed user"-weight to this issue. I forget the exact details, but I suffered the "number recognition" curse as well. Personally, I find it ridiculous that Calc doesn't even TELL the user what's happening. I would recommend that rather than turning it off completely, that instead a notification pop up the first time number recognition is used by the program each session. Obviously, there are plenty of alternatives, but leaving it simply turned on is likely to piss tons of people off, and might cause a business or government entity evaluating the software to simply drop it if they discover that the software is doing things they don't expect it to do. I believe that some sort of compromise is possible between user experience and feature-richness. I understand someone will undoubtedly have worked hard to make the number recognition feature available, and I have no doubt that there are people that find it useful. At the same time, it was nearly a show-stopper for me when I had a project due soon for a class. If the bug (and I WILL call it that; were a programmer using an IDE that behaved in this way, changing intentionally-entered information without asking or notifying the programmer of what was going on or where to turn the annoying behavior off, the programmer would curse loudly and repeatedly and declare "the feature" to be a bug) can nearly devastate a simple student's experience with the software, then it would undoubtedly set any other large-scale users, such as a business or government entity or university, into a serious tizzy. Large scale users might become large-scale donors. Large-scale donors are your friend. "Features" that might chase away large-scale donors should be modified such that they do not have such a potential. This doesn't mean the feature should go away, or even that the feature should be turned off by default. It simply means that the user experience should be enriched with information telling the user why it is that their information is being changed, and how to stop it from happening. Beyond this, I have an opinion on how to handle such complaints in the future. Remember that as someone handling bugs for a large-scale product with many simple end-users, you are often the first person related to the project that users with an issue will communicate with. If you come across as though you're saying, "We're right, and we don't care about your problems, go away," or, "If you don't know every little detail about the software, you're too stupid to be using it," then you'll chase users away and pollute the community in general. I understand that no one here actually said anything of that nature, but some might construe certain posts as such. I also understand that it may sound like I'm telling you how to do your job. To some extent, I suppose I am, but please understand that I'm trying to be polite about it. I understand that you're busy, and have lots of bugs to triage and little time, and things that you'd like to do with your life other than deal with whiny users. However, it greatly enhances the user's experience when you show some level of sympathy to their plight, such as noting that you've experienced such frustrations with other software before and are willing to help the user fix the issue short-term (in this instance, finding the checkbox to turn the behavior/feature off), and are also willing to work with the user to look into long-term solutions and are willing, at least a little, to investigate whether or not anything in the project itself needs to be changed. In this case, when the user suggested that the feature be turned off by default, it would be far more diplomatic to say "Disabling the feature by default is an unacceptable solution. Would you be willing to work with us to help find an alternative acceptable to users?" Also, immediately closing a bug makes it look like the entire team, or at least the specific responders, don't care about user frustrations at all. Remember, one of the purposes of Open-Source Software, as an idea, is to make GOOD SOFTWARE. Good software doesn't just have good features that do cool things, it has good features that do cool things when the user wants, how the user wants. Good software doesn't just have the best algorithms, it has the best user experience. Also, if this isn't the proper place to report such an issue, for example if user-experience issues are supposed to go to some other bug-tracker or suggestion box, then don't just tell the bug-reporting user to go elsewhere (that sounds like you're telling them to four-letter-word off, by the way), tell them exactly where they need to go (a link helps!) and give advice about the procedure they need to follow. Anyway, sorry for the long post. I used to work retail, and based on what I've seen having to handle customer service issues, the kind of behavior displayed here would shortly result in cardboard signs with phrases like "Will work for food" printed on them... --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
