Hi! I’m Luis Dieguez and I am a tester on the Expression Web team.
One of my tasks on the team is to monitor Watson data for our product. Watson is probably one of Microsoft’s most useful customer feedback technologies but it definitely takes the first spot as one that our customers hate the most. Why? Because Watson is a tool that appears only when Expression Web has crashed.
This dialog, my dear friends, is one of the main components of Watson.
In all seriousness, it seems inevitable that a software program will ship with bugs. Our testing team and Beta efforts target to minimize the number and severity of the bugs we ship with in order to make the program as stable as possible. However, the chance of not finding a critical crashing bug is always there and in this case, we want to know about it and fix it as soon as possible.
Watson allows us to comprehensively track what crashes and hangs are being hit by users of Expression Web in the real world (and during development of the program). Every time a user hits a crash, by providing the dialog above, we give our users the option to transfer the crash data to Microsoft automatically, providing us with all the system information we need in order to investigate the root cause for what could have caused the crash.
Basic Watson Flow
In a nutshell, this is what happens the instant the Watson dialog hits your screen:
· When a crash, hang or other tracked failure event occurs, the Watson program is activated and the dialog appears.
Bucketing permits us to prioritize the Debugging Effort and allows us to focus on the buckets that get the most hits. (Approximately 80% of failures in the real world are caused by 20% of the bugs.)
It is important to note that we only receive the data after you explicitly give your permission and the data is strictly used to improve the Expression Web program.
Watson is particularly useful in providing crashing trends in our product. Every time I look at the Watson database, if I notice that many users are hitting a particular bucket I need to escalate this immediately and trigger the investigation process. Once we know the cause of the crash and we can reproduce it locally, we implement and test the fix and depending on the severity of the bug, we will ship it in the form of a security patch, service pack or in the next release.
What can you do to help?
While Watson provides us with very good information on the system and the place in code where the crash might have occurred, one of the hardest challenges with Watson data is coming up with the right set of steps that trigger the crash. For example, Watson might tell us that we are trying to use a null pointer, but it doesn’t tell us where or how in code that pointer was nullified.
Moreover, if we cannot reproduce the crash locally, we can’t fix the bug. Here is where you can become a key element in helping us fix a bug.
When you encounter a crashing bug:
1. Always, always submit the Watson data. It is easy, just click the “Send information” button and the data will take a short time to submit.
2. Log a bug at connect.microsoft.com/expression with the steps you did to get the crash. Adding the file or set of files you reproduced the bug with also helps.
3. Make a comment on the bug with the Watson bucket that was created with your crash. This will help us match a set of repro steps with Watson buckets we don’t have repro steps for. To get the Watson bucket, just follow these steps:
· Right-Click on “My Computer”
· Click “Manage”
· Go To “System Tools | Event Viewer | Application”
· Sort by Type
· All Watson Events will have ID 1000 and 1001.
Event 1000 is fired when Watson first encounters a crash.
Event 1001 is fired when information (including the bucketID) comes back from the server.
If you were successful at reporting, double click on the most recent 1001 event and you will see the bucket ID:
Just add this bucket ID into the bug you log and that's it! We will then link your bug to our Watson buckets and we'll have a set of clear set of steps to reproduce the bug.
Cheers! See you next time.
In over 20 years of professional software development, I’ve never yet worked on a software project that had sufficient time and resources to do everything we wanted. One of the most painful tasks that project leads face is making tough choices about what features to add and remove, and what bugs to fix. Alas, Expression Web is no exception.
When you’re dealing with an application with so many features, it’s not really a surprise that there might be a few bugs. The real question is, given our limited resources and time, how do we decide which bugs to fix as we individually review each bug? Before I answer that, let me back up a step and review the various ways that bugs are found and submitted for triage.
All of these bugs are added to our bug database and they are considered, and occasionally reconsidered, in daily triage sessions. These triage sessions include one or more representatives from the development team, the test team, and the program management team. Discussions in our triage meetings can be fairly extensive, and occasionally heated, as we tend to be very passionate about the quality of our program, as well as the importance of meeting our deadlines.
So how do we actually decide which of these bugs to fix? We look at several factors:
An example of a really painful triage decision we had to make in Expression Web 2 was the issue of link fixup for PHP include files. A bug came in fairly late in our development process regarding including a PHP file in an HTML file, then renaming that PHP file. In other link fixup scenarios, the program recognizes that you have renamed a file that is referenced by other web pages and asks you if you want to automatically adjust the links to point to the renamed file. For included PHP files, this process was failing.
After careful investigation, we had the following answers for the various triage criteria:
Earlier in the development cycle, this bug is a no-brainer to fix. It’s a core scenario that is likely to affect many of our users, in an area where we’re investing significant resources. End users can work around this issue by using the Find and Replace feature, or manually updating their links, but that’s not as convenient and it’s contrary to our behavior with other types of included files. However, given the risk, the cost, and the time that the bug was reviewed, we ultimately decided that, painful though it was, we just could not take this fix for Expression Web 2. I’m pleased to say that the bug has already been reconsidered for, and fixed in, Expression Web 3, and that the fix will be available in our first preview release.
As you can imagine, seeing the list of criteria, not to mention seeing how subjective many of them are, our triage sessions are often contentious. At Microsoft, one of the core attributes we value and cultivate is passion and we definitely have a lot of passion around which bugs we want to fix and which we don’t. At the end of the day, though, the one thing that holds us together is that we also have a passion for doing the right thing for our end users. Sometimes, the right thing is to not fix the bug, as with the example I cited above. We just could not take the risk of destabilizing the program, potentially causing any number of other problems for our end users, painful though that decision was. Sometimes, though, and these are happier decisions, the right thing is to fix the bug, as was the case when we re-triaged the bug for Expression Web 3.
If you are ever wondering whether you should submit a bug report to the Expression Web team, the answer is an unqualified yes. We need this kind of feedback from you, our end users, in order to help us meet our goals for shipping a quality product. The detail you provide in your bug report could be the final clue that helps us track down the cause of the bug and yours could be the report that helps us fix a bug that thousands of our users could encounter. We need the feedback from you, both positive and negative, in order to help us assess whether we’re meeting your needs and our own goals. Without you, and your support, we cannot succeed. We are always grateful for any feedback you can provide and will always do whatever we can to meet your needs.
Paul Bartholomew Development Lead Expression Web
I used Expression Design to layout and create the elements for my wedding homepage (see my blog Composing a Wedding Page in Expression Design.) In this post I will describe how to use Expression Web to layout those elements on the page based on the composition image.
Using a Tracing Image is one way a web developer can be sure that the web page that they’re marking up will look like the page the designer intended.
To read the full post go mosey on over to my blog: Little-Endian.
Greg Smith, Expression Web Software Tester (I'm a PC)
I used Expression Design to layout and create the elements for my wedding homepage (see my blog Composing a Wedding Page in Expression Design) and then used Expression Web to position them on the page. In this post I will describe how to use Expression Web to add image swapping behavior to the page.
Selecting one of the images from the page and opening the Behaviors task pane via the Task Panes menu allows you to define a number of different kinds of behaviors for that image or element. Press the “Insert” button and select “Swap Image” from the menu.
You may recall that back in 2006 Target was sued because the Target website was not accessible to the blind. Target attempted to have the suit dismissed at one point, but just settled the lawsuit last week.
The settlement generated some good discussions here on the Expression Web team about what this means for web developers and their clients. The settlement inspired Steve Hebert (Expression Web developer) to blog about why he recently joined the Expression Web team. In his post, he touches upon the Accessibility and Compatibility tools in Expression Web:
Here are some additional perspectives on the Target settlement:
Site Point: http://www.sitepoint.com/blogs/2008/08/29/target-settles-accessibility-lawsuit-for-6-million/
the Web Standards Project: http://www.webstandards.org/2008/08/28/what-the-target-settlement-should-mean-to-you/
CNET News: http://news.cnet.com/8301-1023_3-10028109-93.html
WebAIM (Web Accessibility in Mind) http://webaim.org/blog/target-lawsuit-settled/
Opera Developer Network: http://my.opera.com/ODIN/blog/two-cheers-for-the-target-nfb-accessility-settlement
What do you think about the settlement of this lawsuit? Should retail websites be required to make their websites accessible? What features would you like us to develop for Expression Web to help you make your websites more accessible? Would you like more Help content that addresses website accessibility? Comment on this blog and let us know! Better yet, if you have any great ideas for Expression Web, submit a suggestion for the program here: https://connect.microsoft.com/expression . Or discuss this topic with others at the Forum for Microsoft Expression Web: http://forums.expression.microsoft.com/en-US/web/thread/5ce63b85-7199-46a1-9fb2-f605c13ec1f5
Hey everybody, I'm Greg Smith, a new tester on the Expression Web team.
In August of 2008 I was lucky enough to marry the woman of my dreams with a small wedding ceremony in Las Vegas. I really enjoy web design and while I am not a professional web designer, I get to play one at my new job as a software tester on the Expression Web team at Microsoft in Redmond. Because I wanted to learn more about the products in Expression Studio I chose to use them to build a website to commemorate our wedding and to share this event with the world.
The first step was to compose a homepage. Expression Design turned out to be the perfect tool for this because of its ability to create beautiful scalable vector art and how very easy it is to export web-ready bitmaps from it.
To read the rest of the post, go to my Blog: http://blogs.msdn.com/gsmith/archive/2008/09/03/designing-a-wedding-page-in-expression-design.aspx.