Microsoft Development Blog

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

I recently got tapped to put together some really cool stuff using one of the great but nearly un-explored features of Internet Explorer 8 , Web Slices. We put together a series of slices for General Motors highlighting their Chevy, Buick, Cadillac and GMC brands car shows in Chicago with the expectation of adding other shows as they occur. This IE 8 feature allows you to create a button in the IE 8 tool bar linked to content or live information and has the ability to indicate when new content is available like a feed. I created the slice content using Silverlight 3.0 .

Cadillac Web Slice

  Setting up the slice to use all it’s feature can be a little tricky since the documentation available is , well, awfully inadequate. One of the first issues I ran into was that its impossible to call any of the navigate functions of the DOM. All navigation has to be done by using an htm <a> element (in HTML) or a <LinkButton> (in Silverlight) . You cannot target a specific tab or window (it will always open a new tab or window) but can navigate within the slice. Now, there are a number of ways to create a slice. The docs cover the basics here IE Activities And Web Slices.

I am going to cover the recommended practice of using all three elements; the installer, updater and content. First the relationship between the elements. The installer set up the web slice in the IE tool bar. This can be accomplished by using HTML attributes or script that can be embedded into any page.

HTML Attributes:

<div class=”hslice” id=”buick-webslice” style=”top: 40px; position: absolute; left: 40px;”>
     <span class=”entry-title”>Buick Web Slice</span><br />
     <a rel=”feedurl” href=”update.htm” style=”display: none;”></a>
     <img src=”images\buickslice.jpg” />
</div>

This causes IE 8 to render a special border around the content and an install icon for installing the slice.

Script:

<a style=”cursor:pointer;” onclick=’window.external.AddToFavoritesBar(”http://www.buick-auto-shows.com/info/Update.htm#buick-webslice”,”Buick Auto Shows”, “slice”);’>Download the Buick-Auto-Shows.com Web Slice</a>

Note the ‘id’ attribute in the HTML and the bookmark ref in the url in the javascript version. Now the installer piece points to the update piece that I have placed on a page called update.htm. Here is the contents of Update.htm.

<div class=”hslice” id=”buick-webslice”>
        <div class=”entry-title”>Buick Auto Shows</div>
        <div class=”entry-content”>
            <span id=”placeholder”>2/16/2010 12:00:00 PM</span>
        </div>
        <a rel=”entry-content” href=”Slice.htm” style=”display: none” />
        <a href=”http://buick-auto-shows.com/info/ie8-webslice.html” rel=”Bookmark” style=”display: none” target=”_blank” />
        <span class=”ttl” style=”display: none”>15</span>
    </div>

This is what the browser will use to determine if the slice has new content available. It has an ‘entry-content’ section that the borwser will cache and check to see if it has changed. I used a date but it can be any thing, a version number, a random string or sequence that changes when you want to signal the slice that new content is available. It also has a <a> element referencing the the actual slice content with the attribute rel=”entry-content” and an <a> element with a rel=”bookmark” attribute that is the link that will be used as the link for the slice in the toolbar. I pointed it at the install page of the slice. The final part is the <span> element that holds the ‘ttl’ (Time to Live) value for the slice. These vales can be equal 15min, 30min,1hr,4hr,1day,1week or never. The one above is set to 15 min.

The content that the update peice points to is hosted in what I named slice.htm. Its a page that is formated to be hosted in the default size of the slice window. I used Silverlight 3.0 as the actual content. You can find all of this here at these links:

Slice Install Pages:

http://gmc-auto-shows.com/info/ie8-webslice.html
http://chevy-auto-shows.com/info/ie8-webslice.html
http://cadillac-auto-shows.com/info/ie8-webslice.html
http://buick-auto-shows.com/info/ie8-webslice.html

Slice Update Pages

http://gmc-auto-shows.com/info/update.htm
http://chevy-auto-shows.com/info/update.htm
http://cadillac-auto-shows.com/info/update.htm
http://buick-auto-shows.com/info/update.htm

Slice Content Pages

http://gmc-auto-shows.com/info/slice.htm
http://chevy-auto-shows.com/info/slice.htm
http://cadillac-auto-shows.com/info/slice.htm
http://buick-auto-shows.com/info/slice.htm

Main Landing Pages

http://gmc-auto-shows.com
http://chevy-auto-shows.com
http://cadillac-auto-shows.com
http://buick-auto-shows.com

 

 

 

This post is a continuation of a previous post here.

One of the first artifacts we work with is the User Story.  A User Story describes a feature or part of a feature and its usage and can be broken down into three basic parts: the story text, story notes, and conversations and testing/acceptance criteria.  The story also has a value or score that represents its size or level of effort in relative comparison to the other stories in the project. A story with a score of 2 would be twice the size or effort as a story with a score of 1.  

Example:

A good story meets 6 criteria:

1.       Independent

2.       Negotiable

3.       Valuable to users or customers

4.       Estimatable

5.       Small

6.       Testable

Scoring for stories is usually done with values in a numerical pattern such as 1,2,3,5,8,13,20,40,80. This pattern represents orders of magnitude that simplify the process. Using a sequence like this makes the scores more meaningful. Each value is an order of magnitude different from the preceding value.  We are not as concerned whether a story is a 7 or 8, or an 8 or 9 because the difference is insignificant and the discussion around trying to choose between them does not add value to the process. Larger stories (Epics) will have a much greater degree of imprecision to them so even attempting to determine whether it is a 72 or 77 is in fact implying far more precision than can be achieved.

 This scoring/estimating should be done by all the members of the delivery team if possible and include the product owner (the product owner will not participate in the estimate but provide elaboration during the process).  As each story is discussed, each member should write down their estimate without showing anyone else (usually on index cards).  Now, all estimates are going to be revealed at once. It’s important to not make any individual uncomfortable with providing their estimate.  The lowest and highest estimators are asked why they chose their values.  The low estimator could be thinking of a way of implementing the story that’s much simpler; or in fact that person could be overlooking implementation details.  The high estimator may be thinking of hidden risks, dependencies, or of things that were overlooked. This increases the accuracy of the estimates, allows the team to participate, helps to develop a unified vision of the project , and creates a sense of ownership of the plan.  

There are some things that don’t fit well within a story but are very important to the success of the project. One of these is constraints. Constraints that are specific to a story can be listed in the acceptance criteria section, but sometimes constraints are more applicable to the system as a whole or are simply not compatible with any story.  I usually include a constraints list with the stories. Some typical constraints are:

·         Service communications must be RESTful.

·         Must be compatible with SQL Server 2000.

·         Must adhere to the principals of dependency inversion.

  Next Up……Planning velocity

One of the tough things about agile, as with much of management of anything in general, is many people just don’t get it. Many agile projects ‘fail’ simply because of the misconception or misunderstanding of what agile is. Agile is not a process, as much as it is a collection of disciplines. These disciplines center on open communications, honesty and realistic expectations. Many managers/administrators latch on to the processes, labels and artifacts, incorporate them into their ‘methodology’ and call it agile, bypassing all the disciplines that really make agile work. Agile starts and ends with communications, honesty and realistic expectations. Those are tough words to live by, especially in the consulting arena. Over the next few weeks, I would like to discuss these disciplines, the processes and artifacts that represent them, even some of the tools, like Micosoft Team Foundtion Server and some custom tools I am creating, targeting the estimating and requirements aspects of the project lifecycle.

It’s funny. As I sat down to write my first blog entry, I was reminded of the first time I picked up a paint brush. I had an idea of what I wanted to do, but where to start?

I remember in the beginning when most computer software and systems had only the most basic human interfaces.  Much of it was computer to hardware and the processes associated with software creation were very much an engineering effort. As their usage proliferated and human/computer interaction gradually increased, the paradigm shifted. Unfortunately much of the processes didn’t keep pace. Even now , so many years later (and I’m talking man years if estimated in how we track a single project , simplified is like a team of 12 for 1 year = 12 years) a mind boggling number starts to form.

Human interaction required far more variables than original engineering methodology allowed for. At pace with increasing human interaction we also have interactions with other systems of widely varying technology and purpose that need integration. This shift caused the effort of software creation to simply deal with more variables than traditional engineering methodologies would allow.  The inevitable changes in scope and design were treated as unwanted products of the equation and a wide variety of processes were implemented to try to control or limit such things.

Project after project failed, and projects continue to fail to this day, all because of that one simple lie we call ‘The Plan’. After all these incalculable man years of experience ‘we’ still can’t quite come to grips with the simple fact that ‘The Plan’ is far far less accurate than we think.  Quite simply this is the result of the sheer volume of variables in human interactivity, how quickly technology changes (usually increasing the potential ways we and systems can interact with each other) and the application and uses of technology growth.  Add to that HOW software is created, by individual human minds , an intellectual process that’s not only technical but potentially extremely creative, as is evidenced by so many of the best products out there.

Decade after decade this blind faith in these old processes have failed us over and over yet people still cling to them and tell themselves that, ‘Maybe if I add more process and try harder I can get better at it! I can make this work! After all, this is how it’s done, right?’. Well, no. A significant part of what we do lies outside the realm of traditional ‘engineering’. It’s why I am far more passionate about software development today than the day I started so many years ago, and am excited about the future even more so.  It’s because I am not alone in this realization. I have worked with and am working with people that understand this and embrace this. I work with products, technology and patterns that have learned how to be agile and durable at the same time. I look back and remember with pride the things I have created and look forward to the things I will create. I am here to share this passion, knowledge and technology with any and all who will listen.

William Wallace