Scanning for Annoyance

I know, I’m too harsh sometimes. But please tell me, this can’t be true, can it?

Am I the only one who does not like the “my plug-in rules your workspace” attitude? Why do some developers always think that their functionality has to be exposed to everybody? Isn’t it too much to accept an opt-in model?

In the end, it’s about user experience and I doubt that such issues will contribute positively to it. How can we avoid those conflicts in the future? Would more communication (read blogging) when designing features help so that people could comment and give their feedback early in the cycle?

4 thoughts on “Scanning for Annoyance

  1. > Would more communication (read blogging) when designing features help so that
    > people could comment and give their feedback early in the cycle?

    The Phoenix team seems to have taken that approach (blogging, requests for feedback) before implementing new features and design, and although the process is time consuming, I think it works well. The end solution, although not everyone’s ideal, typically ends up being a far superior solution than the one we originally had planned.

  2. In my experience, I’ve given up blogging as a mechanism to try and give feedback; the cycles are too slow to have any real impact. In fact, I rarely find it useful to raise enhancement bugs any more; there’s generally no desire to fix usability issues in any application, including Eclipse.

    The JDT indexer and Mylyn’s random backup are a couple of other examples of plugins eating both CPU and Disk IO to the point where I disabled the latter by removing all the plugins as the only means to get it to stop.

  3. Gunnar: I agree completely. Developers have to design assuming that they are sharing a workspace with other plugins, and play nicely. True, it’s impossible to know what other projects will be concurrently installed, but it’s a safe bet that it won’t be just you… so stealing 100% of system resources is a bit rude, even if it’s only once in a while. Allowing users to disable annoyances and making them NOT the default behaviour goes a long way to making them choices rather than annoyances.

    Alex: As to mechanisms for feedback, the best IMHO is always Bugzilla. I’m of the opinion that it’s often good to open new bugs on the same topic and force devs to mark them dupes — provided that the dupe bugs provide something valuable, like better / more recent steps to reproduce, screenshots, or console logs.

    When enough dupes have been logged, sometimes the team will acknowledge that as enough people are complaining, one of the dupes should be elevated to a higher priority. There’s also the voting mechanism but it seems that doesn’t have the developer-annoyance-factor or developer-visibility-factor that dupes do. Of course it ultimately depends on the responsiveness of the team.

    This has worked for me most recently with PDT, to name one shining example. However, some teams just keep assigning bugs to further and further targets or ignore them completely. In those cases… well, there’s not much you can do beyond actually submitting a patch or joining a Bug Day, I guess.

  4. I was frustrated to find out about a validate action that was added to EMF resources and showed up in our editors. It confused users because we already have a validate action in our editors that does the right thing and the one contributed by WTP doesn’t do anything useful or meaningful for our resources. In EMF we’ve avoided creating perspectives or anything else that pushes us into people’s faces. We want to blend in and be invisible when we’re not needed. When we did provide interesting, though not so useful, actions (such as the ability to open any XML file in EMF’s reflective editor) we removed them as soon as we got the first complaint about it.

    I think it’s good to raise awareness as you’ve done. I don’t agree with Alex’s assertion that there is generally no desire to fix usability issues. I’m sure many groups, like my own, are simply frustrated and limited by lack of resource and are not happy to have that characterized as lack of desire.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.