locked
Why does Microsoft not care about User Experience? RRS feed

  • Question

  • It seems that Microsoft, although they preach a lot about the importance of a great user experience, do not care about the user experience when it comes to their own software. I have found a rather significant defect in Blend, which caused me and my team hours of frustration before we discovered what was actually happening, but Microsoft has decided that it is not important enough and will not fix it. The following is the bug report that I posted:


    Description
    I have been experiencing an issue in Expression Blend with storyboards. Any time I create a "remove" storyboard trigger, it is visible under the trigger listing only until I restart Blend. Once I have saved it and restarted Blend, the trigger disappears from the trigger listing, but is still in the XAML code. So, the problem is not that I am losing the trigger altogether, it simply just disappears from the listing of triggers.
    Comments
    5 comments | post a comment to Microsoft

    Hi, thanks for the bug report, I've assigned it to dev to be fixed.

    Steve
     Posted by Microsoft on 10/15/2008 at 5:18 PM
    Thanks!
     Posted by RockwellDesign77 on 11/5/2008 at 10:43 AM
    Any updates of this fix?
     Posted by RockwellDesign77 on 2/2/2009 at 8:12 AM
    Just as an update, I noticed that this was not addressed in the Blend 3 preview
     Posted by RockwellDesign77 on 4/14/2009 at 10:22 AM
    Why have you decided not to fix this? It is surely a defect in the software. So you add a trigger which is temporarily visible in the GUI and is in the xaml, but then disappears from the GUI but still in xaml. This just helps to prove that Blend is neat, but very faulty and innefficeint.
     Posted by RockwellDesign77 on 4/29/2009 at 4:40 AM
    Product?
    Blend
    Product Version?
    Blend 2 (2.0.1523.0)
    Issue Type?
    Bug

    ANOTHER USER HAD THE SAME PROBLEM( the problem is stated in Japanese or Chinese, but pay attention to Microsoft's feedback :


    Description
    我 在使用Blend2.5 March 2008 Preview创建Triggers事件遇到这样的问题:在Blend中创建的动画Triggers事件,只有begin事件可以实时更新,例如我在设置 了stop、pause、resume、remove等相关动画事件,当你设置完成后,保存并关闭blend程序,之后在用blend打开刚才的项目文件 会发现在Triggers面板中,只剩下begin事件,其他的事件没有被显示出来,但是在XAML视图中又能看到这些事件代码,也不会影响程序运行。这 种情况我怀疑是没有完全更新这些事件展现到Triggers面板中,应该是个bug.希望能在下个版本中能够解决这个问题。
    Comments
    Hi, thank you very much for your bug report. We're investigating the problem.

    Regards,
    Steve White
     Posted by Microsoft on 4/30/2008 at 11:24 AM
    We're going to close this as we're not going to fix it this version. The actions are in the xaml, we're just not listing them. If it comes up enough we'll reconsider. Thanks!

    Steve
     Posted by Microsoft on 2/20/2009 at 6:28 PM
    Product?
    Blend
    Product Version?
    Blend 2.5 March Preview (2.1.1111.0)
    Issue Type?
    Bug


    Wednesday, April 29, 2009 11:46 AM

Answers

  • Thanks for your feedback! Let me assure we that look at each and every issue that you report via Connect in depth, and the number of issues that we have fixed that were reported via Connect for Blend 3 is pretty significant.

    That said, when it comes to fixing an issue, we have to make several tradeoffs. In this particular case, most of our investment in Blend 3 has been around the States pane and Behaviors because that is where we think we can take the entire control skinning / interactivity experience to another level., and most users will find maximum value for the buck (starting with Silverlight 3, and .Net 4.0 when WPF gets VSM). Since we did not invest much into improving the Triggers pane for Blend 3, we ran out of time to address this issue.

    Sorry for the inconvenience!

    -Unni
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, April 30, 2009 7:27 AM
  • Hi, it's a difficult call because this bug has been triaged as being below our current bug bar, partly due to the estimated likelihood of the issue to arise for any given user, yet clearly there will be _some_ affected users. Triage is a matter of making sure those bugs are fixed that have the greatest overall impact on users (based on likelihood, subjective impact on the user and objective impact on the user), rather than those that are thought to be less impactful overall. As I say, it's never pleasant to have to decide that a bug does not meet the bar. Deciding not to fix a bug for a given version still leaves the door open for it to be fixed in future of course.

    Thursday, April 30, 2009 7:28 AM

All replies

  • Thanks for your feedback! Let me assure we that look at each and every issue that you report via Connect in depth, and the number of issues that we have fixed that were reported via Connect for Blend 3 is pretty significant.

    That said, when it comes to fixing an issue, we have to make several tradeoffs. In this particular case, most of our investment in Blend 3 has been around the States pane and Behaviors because that is where we think we can take the entire control skinning / interactivity experience to another level., and most users will find maximum value for the buck (starting with Silverlight 3, and .Net 4.0 when WPF gets VSM). Since we did not invest much into improving the Triggers pane for Blend 3, we ran out of time to address this issue.

    Sorry for the inconvenience!

    -Unni
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, April 30, 2009 7:27 AM
  • Hi, it's a difficult call because this bug has been triaged as being below our current bug bar, partly due to the estimated likelihood of the issue to arise for any given user, yet clearly there will be _some_ affected users. Triage is a matter of making sure those bugs are fixed that have the greatest overall impact on users (based on likelihood, subjective impact on the user and objective impact on the user), rather than those that are thought to be less impactful overall. As I say, it's never pleasant to have to decide that a bug does not meet the bar. Deciding not to fix a bug for a given version still leaves the door open for it to be fixed in future of course.

    Thursday, April 30, 2009 7:28 AM
  • Thanks Unni and Steve for the response on this!
    Thursday, April 30, 2009 6:18 PM
  • Personally, I think the off-putting thing is just the language "Won't Fix" doesn't make it clear that it just isn't getting fixed this release. When you guys change status to "Won't Fix", it would be nice to include a message sayign something to the effect of "Did not make the schedule for this release, there is a workaround and the bug has been ported to the Blend 4 queue" etc.
    Monday, May 4, 2009 7:24 PM