PRISM Documentation: The 'Missing' Table of Contents

For some reason (several actually!) PRISM is largely being ignored by many Silverlight developers. In my talk on PRISM (which I'm repeating at the next meeting of the Silverlight User Group this coming Tuesday - more information here) I talk about the documentation, and the fact that it seems to prejudice people against PRISM, when in fact it's an excellent resource. I talk about the fact there are two ways of looking at it.

The 'glass half empty' crowd see how much documentation there is (assuming they can even find it - it's pretty much hidden in a totally inappropriate chm file format by default) and panics that there just isn't enough time to read and understand all this stuff when their Silverlight application needed writing yesterday, and dismiss PRISM as a result.

The 'glass half full' view usually discover the pdf version and realise they're getting a really good full-colour 300+ pdf electronic book with lots of useful advice and guidance for free. For more information on how to get the pdf version see the excellent Downloading and Building PRISM Guide from the folks at Sparkling Client.

One disappointment of the pdf version is that, unlike the traditional e-book, when printed out it doesn't contain a good table of contents. This makes treating it like a book, and finding a specific 'How to', or getting even a basic idea of what's covered in the 'book', is a bit of a nightmare.

I use the documentation a lot, so to avoid wasting time thumbing through my dog-eared copy when I want to look-up something specific, I've put together the 'missing' table of contents as a pdf, which you can download by clicking on the image below. I've taken the liberty of changing some of the "Composite Application Library' headings to instead read 'PRISM' as I think PRISM is pretty schizophrenic with regards to its identity (and think 'Composite Application Library' is too much of a meaningless mouthful). Let me know if I've missed anything!

.

My SketchFlow Comments: Christian Schorman of the Blend Team Responds

On Friday I posted a quick report on my impressions of the Silverlight Firestarter event, which included my expressing surprise at what appeared to be a fundamental shift in the way SketchFlow was being promoted.

Christian Schormann from the Blend team sent a detailed response to those comments, which I am happy to reproduce below. Unfortunately it is not obvious from this blog that you can easily comment to a blog entry by clicking on the "0 comments" (hidden) hyperlink at the end of a given blog entry (blame Google for the UX, me for the fact I haven't customised things from the basic templates they provide!), which is why I received the email rather than a comment directly on the blog itself.

In any event I think it makes more sense to post this response as a separate blog entry, rather than as a somewhat hidden comment to the original blog entry

"Hi Ian,

I wanted to respond to a few questions regarding SketchFlow you brought up on your blog. I am part of the Expression Blend team, where I am responsible for product design and strategy.

You write:

"One thing that did alarm me somewhat, was the seeming step-back by Microsoft from the whole 'Sketch your application and then make it real - don't throw all that hard work prototyping away' story. Suddenly the story was that we should be re-using assets used in SketchFlow applications and not turning 'sketch' controls into 'real' controls as documented in the Blend 'Help' feature. Given that most of these assets are produced in Adobe Photoshop and other tools outside of Blend it kind of begged the question 'So the real advantage of SketchFlow over Balsamiq is...what exactly?'."

Let me comment on the last point first.

Balsamiq creates static mockups of UI. It does so very fast and with minimal learning effort.

SketchFlow is meant to make it more cost effective to create, explore, evolve and communicate deep dynamic prototypes. In SketchFlow, designers can model high-level flow and composition (from a product design perspective) of a user experience. They can use animation to illustrate their design intent. They can model and experiment with states and state transitions. Using sample data and behaviors, they can create compelling prototypes of serious interactivity. With the SketchFlow player and feedback tools, other stakeholders in the process can evaluate prototypes effectively. SketchFlow thus has a very different goal than Balsamiq. SketchFlow certainly can be used to simply create static mockups, but it is much more special for prototyping dynamic interactivity.

We believe that both mockups and dynamic prototypes have their place in the design process – they are complementary. They are often not created by the same people, and they are usually artifacts of different stages in the design process.

Regarding prototype re-use, I don’t think our story has ever changed. We believe that the whole point of a prototyping process is to quickly generate and explore a multitude of ideas. Often, it is a good idea to not over-invest in such explorative prototypes, and to avoid getting attached to any given prototype: the longer one stays with a given idea, the harder it is to discard it when it fails. Introducing architectural or production constraints into the prototyping process too early risks reducing the productivity and effectiveness of prototyping. Also see Bill Buxton’s book on Sketching User Experiences for more on this argument.

Our general advice therefore is that in strict idea generation / verification scenarios, it is often better to not plan on re-using a prototype as the blue pause for an application. This is not an advice based on technical criteria or limitations of tool or platform, just a recommendation from a design process perspective.

However, we also recognize that SketchFlow is used in scenarios that are more RAD-style development than prototyping. Also, there are applications where the structure of a prototype naturally is similar enough for re-use in production. Because we know that there are certainly valuable cases for re-using prototypes as part of a production-oriented scenario, we enable conversion of prototypes into navigation applications. The process is currently not automatic, but it is feasible and documented in the manual.

In summary, our message is that if you want to prototype efficiently, we recommend that you focus on the design problem at hand, rather than trying to build architecture (or even think about architectural concerns) as part of the prototyping process. However, this decision is of course entirely up to you.

Should you, at the end of the design process, decide that either the prototype as a whole or individual assets are useful in production, we enable this re-use. It is a decision in the hands of a designer, based on the goals and complexity factors of the prototyping work actually undertaken. The tool enables re-use of projects and assets, but we believe it is not always a wise choice to expect to do so.

You also comment that most assets are created in Photoshop et al. There is of course no doubt about the prominence of Photoshop et al, but in many cases these assets undergo significant pre-processing . Visuals often need to be packaged into control templates, equipped with transitions, animations and behaviors, before they can be used efficiently. And there are many assets (for example UserControls or resource dictionaries) that are even more entirely “native”. In this sense we see a lot of asset re-use that would not easily be possible with pure artwork.

Finally, you write regarding a conversion problem with the metrics of the SketchControls. I will look into this – I have not heard about this so far. In practice, we have not heard that from many users, but then again, many SketchFlow users do not spend much time getting their layout to be very precise – SketchStyles are generally meant (and used) in the first place to convey the notion that the visual design (and the exact layout, as part of it) is just a sketch, and precision of layout is somewhat antithetical to this. That said, I still agree that the metrics should match, so I will look into the issue.

Christian Schorman"

Silverlight Firestarter and a few other bits and pieces

This is going to be a very hasty blog post because it's being written in my lunch hour. Why? Because I desperately need a break from trying to convert a complex Silverlight 'storyboard' application to use a separately developed .NET RIA Services prototype application whilst also introducing the use of PRISM modules and regions usng MVVM inside the Silverlight 3 navigation framework using .NET RIA Services!

And there in that opening paragraph you perhaps have a clue as to why folks aren't rushing to jump on board the 'Silverlight in the Enterprise' bandwagon, and didn't seem to be rushing into this 'Silverlight Firestarter' event the way you'd expect given the very high profile speaker list (at least if the lack of much real activity on the pre-advertised Twitter #slfs stream was anything to go by).

Microsoft's 'silo' approach to Silverlight architectural guidance/marketing/development really doesn't help and I haven't even added MEF into the mix yet. This, and the whole Microsoft 'La! La! La! Can't hear you!' approach whenever someone mentions the 'Blend' or 'Sketchflow' words and how all this 'architectural' stuff is intended to fit together will no doubt be the subject of a future rant - sorry I mean 'blog entry' ;-)

So (see how I'm trying to embrace the whole Microsoft employee thing there!) Silverlight Firestarter was Microsoft's annual day-long event featuring all the big Silverlight rock stars (Scott Guthrie, Tim Heuer, Brad Abrams, Adam Kinney) and held at Microsoft HQ in Redmond. This year it was streamed live to us mere mortals outside Redmond between around 5pm and 1am this morning.

After an initial experience that looked like this was going to be another over-hyped seethelight.com fiasco all over again (no international users could access the live stream because someone had hard-coded an assumption that we were all running Windows in US date format mode into the Silverlight streaming application!) - things went very smoothly and the quality of the video and audio of the speakers, if not the blurry, pretty indecipherable code walkthroughs and laptop screen captures, were excellent :-) As was the support on the #slfs Twitter stream. The folks behind this event have every right to pat themselves on the back for an excellent inaugral event and I'm sure future events will be even better!

If you were wanting a whole day of 'overview' material of the various Silverlight bits and pieces including Blend and .NET RIA Services the speakers all did great jobs and the download videos, planned to be available in a week's time here are 'must see's and will be a great way of getting 'the big picture' around a lot of this new stuff.

The event was, in many ways, much like the excellent WPF Training course recently held at Heathrow: Touted as an 'introductory' course, the event was swamped (these words are all relative!) with those of us who regard ourselves as well beyond the introductory level these things are aimed at, attracted by the high-profile speakers in the hope that some as-yet-unrevealed gems will emerge from the paucity of information that's available to help us with our 'real world' problems, or at least give us an opportunity to get long-simmering issues and questions answered. As a result, if the associated Twitter stream is any indication, the event was really very much a case of 'preaching to the converted' rather than one bringing new folks on board, which is nobody's fault, but somewhat disappointing if, as some of us believe, Silverlight is going to take over the world at some point!

On the plus side, the Twitter stream was pretty lively (with comments, if not number of different people) and fun. On the downside the event itself was, for the most part, pretty much the same old canned 'not real world' demo's most of us have seen several times now, albeit slickly presented and delivered.

New information was almost non-existent, despite promises that it would be casually added in (the old 'Oh! I ran out of time!' excuse is getting so lame now :-P) and the Q&A session was, for me, a huge disappointment because instead of addressing the (admittedly more complex) issues some of us were trying to raise we got stuff like 'How do I become a Silverlight MVP?', 'How do I get to talk on the main stage at MIX?' or 'Ask the MVP lead who her favourite Silverlight MVP is'? (no! really!). Honestly I expect this sort of 'Me! Me! Me!' nonsense at mainstream fan events like Comic Con, but not at a technical developer event. We have truly entered a world where 'the cult of celebrity' is taking over everything - even our everyday developer work lives :-(

So, for the record, here are the main bullet point items I 'learnt' during the long 8 hour event:

• Scott Guthrie (VP, .NET Development Division) claimed Microsoft are "on track to having Silverlight installed on 50% of all machines within the next couple of months". Others are already treating this remark with some cynicism and demanding to know the source of the data Microsoft keeps touting, as for me ... well everyone knows how cynical I am! I'd like to believe it's really true, but...


• Brad Abrams promoted (and Karl Schifflet gave us an excellent overview of) New XAML PowerTools for Visual Studio 2008 with Silverlight and RIA Services support which will be made available this Sunday. Karl heads up the “Cider” (XAML Visual Designer) team.
  


• The Silverlight Toolkit (containing open source Silverlight controls) now has a shiny demo site for all controls complete with "View XAML" and "View code" functionality.


• .NET RIA Services RTM ship date is still "early next year" but Microsoft are not prepared to commit to any firmer date than that at this stage.
  

One thing that did alarm me somewhat, was the seeming step-back by Microsoft from the whole 'Sketch your application and then make it real - don't throw all that hard work prototyping away' story. Suddenly the story was that we should be re-using assets used in SketchFlow applications and not turning 'sketch' controls into 'real' controls as documented in the Blend 'Help' feature. Given that most of these assets are produced in Adobe Photoshop and other tools outside of Blend it kind of begged the question 'So the real advantage of SketchFlow over Balsamiq is...what exactly?'.

In truth for Enterprise apps I don't see reusing SketchFlow as an option anyway (no MVVM, PRISM, .NET RIA and all that other stuff that's really likely to be needed) but it seemed odd for Microsoft to so publicly step away from what had been the initial message, and one that is very easy to sell and promote as unique. Since I tweeted about this I've had a response to the effect that this was just a sensible bit of guidance based around concentrating on the real benefits of wireframe prototyping ("We enable conversion but caution that having reuse in mind might cause you to lose the quick & dirty mindset"), but even so...

Interestingly one of the questions asked on the Twitter stream that didn't get asked (for very obvious reasons - there goes my cynicism again!) was why the 'sketch' styles were different from 'real' styles to the extent that if you DID do the conversion of a Sketchflow application from using 'sketch' styles to 'real' ones your hard-fought work in layout would get totally screwed! Eeek! Who knew?! I suspect Microsoft aren't being totally honest with us in this rush to over-sell SketchFlow as the panacea to all designer problems (which gets them to actually use Blend instead of ruddy 'Always used it. Not budging!' DreamWeaver). I need to find time to investigate how serious a problem this reported 'change of layout' problem is!

Outside of the event itself, several other bits of interesting news occurred. Most exciting was the news that John Papa has joined Microsoft. Almost single-handedly John's blog has been trying to make sense of how the hell anybody's supposed to build a Silverlight application that uses MVVM and PRISM and works with Blend too - so his move to Microsoft will hopefully help resolve the paucity of any real official information around this whole problematic area.

And just after the event First Floor Software announced they had documentation for their 'must have' Silverlight Spy 3 tool. You can download it here and it will be automatically included in an updated release of the installation msi coming soon. To put it bluntly, if you don't have this tool then I don't think you have the right to refer to yourself as a Silverlight developer :-P

Apologies for the lack of links to people and blogs in this post: lunchtime has been slightly longer than intended and I need to get back to my PRISM/SL3 Navigation/.NET RIA Services integration exercise!