There's another great article (in an excellent series) introducing WPF from the point-of-view of the Line Of Business developer. It makes a compelling case for WPF as a highly productive environment for data-based applications (one to which I wholeheartedly subscribe!).

This is a particularly interesting one, because it addresses the ListView - a much underestimated control. Anecdotally, we are told that a reason for LOB developers resisting WPF is the lack of an in-the-box grid control. Now, of course,  we have one - but that is no reason to reach for it as a knee-jerk response to the need for a bunch of data in a tabular form. In a great many cases ListView (or even ListBox or ItemsControl) is your friend.

Why might you want to choose one or other of these controls?

ItemsControl is great if you have no need to maintain selection state, and you have <1,000 items or so (depending on the number of visuals in your item). By default it uses StackPanel as its ItemsPanel, and so you get no virtualization of the visuals. However, you can choose to use a VirtualizingStackPanel instead. The only limitation there is that you have to handle your own data-virtualization for truly humungous data sets, to avoid bringing it all into memory.

As of 3.5SP1, using VirtualizingStackPanel as the underlying items panel, you can also get all the goodness of container recycling.

ListBox is just like ItemsControl (it is, of course, derived from it), and has exactly the same limitations and advantages - but also includes support for selection. It uses a VirtualizingStackPanel as its items panel by default, but you can (if you wish) dispense with virtualization and go for a basic StackPanel.

ListView layers on a bunch more "common-controls-alike" functionality - but you are still responsible for dealing with ultra-large data sets yourself.

These three are all pretty similar in the approach they take - each adds a little more functionality than the previous, building on the same plumbing.

DataGrid is a different beast entirely. Although it is still geared towards displaying broadly tabular data, it is engineered to enable a "drag-and-drop" RAD experience for displaying that data in small-to-very-large data sets, with good performance characteristics and minimum demand on the developer - while maintaining high levels of customization. The big wins come when you are dealing with a view model you don't control that is delivering you potentially very large amounts of data, and need a quick virtualization solution.

However, if you have the time, then rolling your own ViewModel that does the data virtualization can pay dividends in the long run.

I'm not arguing against using the DataGrid - it has its place in the toolbox. But don't hammer in a nail with a screwdriver, or drive in a screw with a hammer. And I'd always argue for using the simplest tool that can possibly work.

Rico has just posted an excellent blog about some of the architectural decisions he's taken for Visual Studio 2010 and beyond.

It is well worth a read, not least because the questions and decisions made apply well beyond VS, to the software all of us build. Have you got a memory consumption hot spot? Are your extensibility points appropriate to the ecosystem you live in today, rather than the one you designed for 2-3 (or more) years ago? Are you taking bets today that will see you through to the other side of the economic cycle? Will you be better positioned than your competition when business picks up again?

While lugging a regular laptop around PDC, I was wishing I had a smaller, lighter model to take in to a conference, use on a plane or train, or whatever. Something I could slip into my existing laptop bag without adding crippling weight, and that would be capable of running Vista with reasonable perf, on a decent-sized screen.

Eventually, I decided to get a MacBook Air (but with the standard HD, rather than the 64GB SSD), then partition it half-and-half for MacOS X and Vista. I'm only leaving MacOS on there because I don't have any other Macs to play with - so you could just repave the entire thing if you wanted.

One thing about the Air is that Apple doesn't support 64bit Vista on it. But while it doesn't support it, that doesn't mean that it doesn't work! There are a couple of things you have to do to make it work, though.

First - follow the standard BootCamp instructions to get Vista installed from the 64bit media.

However, when it comes to installing the drivers and so forth, insert the MacOS Disk 1. You can't run setup.exe because it checks the hardware and refuses to run. So, start a Command Prompt as Administrator. CD your way to the Boot Camp->Drivers->Apple folder and run BootCamp64.msi instead.

That will install almost all of the necessary drivers - apart from the video card. But don't worry, you can download that from here.

Again, this isn't supported, and Your Mileage May Vary, but all seems well - all of the magic Mac keys are supported, the multitouch pad etc.

Despite the challenging economic conditions, it is still worth considering a startup, if you've got the idea, the market and determination and ability to see it through.

There are a whole lot of pitfalls, though. That's the reason why most startups fail inside their first year, even with a healthy global economic outlook. One of the main reasons Ythos exists is to help entrepreneurs and their organizations identify those pitfalls and bring together the right business and technical skills to execute successfully, and come out the other side with a better, stronger business, well positioned to take advantage when the situation improves.

Guy Kawasaki has a couple of excellent blogs about the top 10 lies told by entrepreneurs and VCs. On the entrepreneurs' list, number 9 is particular apposite - "We have a proven management team." The reality is that we may all have been successful doing something in the past, but we're not fighting that battle this time around: the more support and advice you can get, from people who've been through the mill, the greater the chance of success.

To that end, Microsoft has created a new program - Microsoft® BizSpark™ - which is designed to help out in this way.

Here's what they have to say about it:

"Ignite your startup by enrolling in Microsoft® BizSpark™, a new global program designed to accelerate the success of early stage Startups.  BizSpark provides fast, easy access to current full-featured Microsoft development tools and production licenses of server products; professional technical support from Microsoft; and connections to a global community of business experts who can help guide you through the hurdles of growing your business. Microsoft BizSpark's requirements are minimal, and there are no upfront costs to enrollment. So get fired up and visit the Microsoft Startup Zone to learn more!"

Eligibility requirements for startups are minimal: If you're a privately held company building a software-based product or service (even using open source code), in business for fewer than three years, and with less than USD$1M in annual revenue, you're in! To actually join BizSpark, you must be sponsored by a BizSpark Network Partner.

We're really pleased to say that Microsoft have selected Ythos as a Network Partner for this program - you can read our press announcement here.

As part of our activities around BizSpark, we'll be publishing a whitepaper some time in the next few weeks about some practicalities of starting up and developing a new technology business. We want to develop this into a conversation with people who have an interest in the challenges facing technology SMEs over the next few years.

And if you've got a great startup idea, then don't hesitate to contact us - bizsparkenquiry@ythos.net.

Channel 9 have just posted a brief interview with Paul Dawson and myself, delving into the Tesco app in a little more detail.

And it even contains a data caching bug for your entertainment!

Having just completed a project pairing with a designer, I thought I'd post some of my observations on the developer/designer workflow in WPF. Following a long tradition, it's a top 10 list.

 (Breaking with tradition, I'm counting up...but hey...)

1) Build a view model

The view model is the point of communication between you and the designer about what your application actually does (from the user's perspective). You should both have an intimate understanding of those data structures, what they mean, and, more importantly, how they change.

2) Learn to read XAML together

Until the angle brackets make sense to you both, it will be very difficult to work together. Note that I'm not suggesting that you necessarily both need to be able to write XAML, but XAML is the shared expression of how your application appears to the user.

3) Developer: open your work in Blend

Your designer pal will almost certainly be using Blend. You need to make sure that the XAML structure, Controls, UserControls etc. that you create all open correctly in Blend. Unfortunately, this means that there will be some restrictions on what you can do with external resource dictionaries, and you need to preserve the mysterious Blend namespace extensions and attributes.

4) Think about the Events and context/state changes in the system

As a designer, you will want to perform all sorts of interesting transitions and animations in the system. The easiest way for designers to Trigger those transitions in Blend is via a RoutedEvent on some UI component (or the new Visual State Manager support, where you are talking about internal control state). Although a suitable DataTrigger from the view model can often do the trick, this is slightly harder to deal with in the design-time environment.

The other way the developer can make life easier for the designer is to break a state change into two halves. Before you actually change state, raise some StateChanging event. Only commit the change when they set some other piece of data, or call a method (possibly off a Storyboard.Completed event). This allows them to transition existing visuals away, update the data, and bring in new visuals.

5) Build a library of value converters

You can work much more effectively with your designer if you've got a standard set of value converters that you both know how to use. Good ones to get started include

StringFormat

(if you are not using 3.5SP1)

Proportional

(scaled by some absolute range to vary between 0.0-1.0)

 Divided

(divided by a constant factor)

Scaled

(multiplied by a constant factor)

BooleanToVisibility

(with properties mapping True and False to specific Visibility values),

OneMinus

(1 - x) and

Debug

(a pass through that allows you to set a breakpoint)

This is only really effective in conjunction with 6...

6) Learn to write binding expressions together

Although there is quite sophisticated data binding support in Blend (also coming soon in Cider), it will be much easier for you both if you learn to write binding expressions together in XAML. There are two aspects to this. First, it is empowering for the designer to be able to make sophisticated dependencies on the view model (and even the view), without requiring input from the developer. Second, it really helps if the developer understands what makes a view model easy to bind to. Binding syntax is gibberish to most developers, let alone designers - so, establish good examples and common patterns that you can use repeatedly.

7) Build UI at a component level

Identify early the UI components you want to build, and assemble them into the application. Just "drawing" the app (as is often the case with website design) leads to over-complicated, difficult to maintain XAML - and you often suffer from poor perf as a result. It also makes it cheaper to iterate the design (see 9). This can mean a completely separate step migrating visuals from a scamp in, say, Adobe Illustrator, to a build in Blend.

8) Learn the layout primitives together

The Blend design experience gives you a strong sense of an artboard or canvas on which items can be freely positioned, even though its basic layout primitive is actually the Grid. Get to a shared understanding of how the Grid works (a well understood concept to the designer, but perhaps not normally associated with the specific restrictions of the WPF implementation), and how you can break out of its clipping boundaries by use of the Canvas.

9) Learn how to iterate

It is much more productive to iterate with the designer. The developer is responsible for what the application does for the user, and the designer for how the user interacts with the application. Every time you transition from developer to designer, intents are blurred and structure created by one party is bent to the will of the other. Unless you make incremental steps on both sides, tidying everything up as you go, it can quickly become unmanageable for one or both parties.

One common problem is a view model that gradually becomes less and less suited to the interactions. A proliferation of value converters and requests for new events are symptoms of this issue.

Another is the "big ball o' angle-brackets" in the XAML file - a file comes back from the designer that is stuffed with paths, triggers and other gumph that make the structure impossible to see.

Sort these issues out early (e.g. by breaking XAML out into (user) controls or resources and identifying simpler primitives that can be used for the complex paths).

10) Acknowledge that the developer often has the easier job

For the vast majority of applications (in the UI tier at least) the developer actually has the easiest time of it. Most UI application structures are pretty simple, and building the view model, value converters etc. is not hard.

Designing high-quality visuals and user interactions is, on the other hand, extremely difficult. (If it was easy, then all our apps would look great and be a dream to use, and, frankly, they're not.) The developer/designer partnership works best if the UI developer, at least for part of the time, sees themselves as an enabler of the design vision for the application, and supports the designer in realizing that vision. In particular, you’ll find yourself having to build the complex and abstract animations that the designer will be describing to you. Conversely, the designer needs to be prepared to step up and take the lead when necessary, and see themselves as neither simply an artist, nor a "visuals factory", nor just creating a "skin" for some existing functionality.

The overall User Experience is a combination of good quality business analysis and customer representation, design vision (and innovation), and effective implementation. What I’ve outlined above really just talks to effective implementation. All three need attention, and a dash of design genius is necessary, but not sufficient. I'd like to sign off with the idea that great user experience is ultimately born of the single-minded determination to straighten out all of the kinks that appear when you give the product to a real user. When you get it right, this whole process is way more fun than we should be having, plus we’re developing business value for our clients!

You can find the value converters here:

Ythos.ValueConverters.zip (12.54 KB)

I've just got back from Microsoft's PDC 2008. Most of my time was spent preparing for the Tesco/Conchango Day 2 keynote demonstration that I have been working on for the last month or so. Conchango are a great company - really forward thinking in terms of their focus on User Experience, and a great understanding of how to realize business value for their clients. This was a very interesting opportunity to work outside our usual space in healthcare and pharma, albeit under a hectic schedule! No secrets of the sausage factory here, but it was also good to see this kind of event from backstage. I will say that the AV setup was astounding. I don't think I've ever seen so many blinking LEDs, outside of a TV studio.

The Tesco grocery system was a standard WPF application - we took the classic View, View Model approach, talking to a backend WCF service (not dissimilar to the approach outlined in our whitepaper last month). And because this was a real client app, we've also got a great offline story - caching in a local SQL database, and making use of peripherals attached to the system (e.g. the webcam). I think it showed how effectively you can aggregate other services (e.g. the calendaring, facebook messaging) into an application to deliver something that is more than the sum of the parts. Obviously, it isn't a finished product - exactly what services should be aggregated, and how they are surfaced is still be determined with customer testing, but I think it shows how far you can go with this kind of thing. We also had the challenge of the broad range of machines we were targetting - from Windows XP all the way through to Windows 7 (on which we ran the demo). Working out interactions that are good with touch, stylus AND mouse is surprisingly tricky, and a new skill we're going to have to learn as this kind of hardware becomes ubiquitous.

Even more interesting than the app itself (to me at least) was the development process. This was the first time I'd had the opportunity to pair with a designer (Xamlist? Blender?) during the sprint (in this case the very talented Felix Corke, Conchango's lead Blendmeister). I've always been an advocate of meshing development and design as closely as possible. Developers have a good understanding of the structural decomposition of the application, and the designer understands the best way to surface that structure, in terms of both static and dynamic interactions. However, if you just "throw the app over the wall" from one to the other, the structure can become blurred (interactive components are not drawings), or the interactions become clumsy (combobox is really a compromise, not a first-class design element). A shout out here to David and Rich, without whom it wouldn't have been possible to complete the development so effectively.

Anyway - the rest of PDC. Obviously, Microsoft's Windows Azure announcement is very significant for the industry as a whole. Developing from the kinds of cloud offerings currently provided by Amazon, we have a broadly horizontal platform and fabric that offers an almost impossibly simple provisioning and deployment model. If they have the business model and privacy/security SLAs to back it up, then it will offer compelling value - not necessarily to large enterprise customers who already have this kind of thing on- or near-premises, but to the vast majority of SMEs who represent millions of developers out there. It might even change some of the dynamics in the investment community. If you don't need billions of dollars of hardware investment to scale up, maybe entrepreneurs will retain a little more equity and control in their businesses? [But, "Azure" really shouldn't rhyme with "Badger"]

The Oslo family is also important - if more low-key (so low-key, it didn't even get a mention in a keynote; pace a sidebar in the Don'n'Chris show). I think everyone was a little surprised that there wasn't more meat on the bones at this stage. In a peculiar way I can feel the ghost of that vanished pillar of PDC 2003 - WinFS. Modelling our information in a way that can be queried and analyzed by tooling, and providing models of existing technologies (WF-XAML, WPF-XAML etc) is clearly a step forward in application design, but there's a lot still to be worked out, finished or polished (versioning being a key element). That's fair enough; as the team pointed out, these are very, very early bits.

Finally, Windows 7. Windows Vista R2, and all the better for that. I have no real criticisms of Windows 7. The new start bar is extremely productive, and - something close to my heart - the drive for proper support for High DPI (finally replacing a whole bunch of those applications and control panel applets that have steadfastly refused to behave at 120DPI+). They're also pushing a new High Color Model (wide gamut/high precision) that will benefit visualization apps in science and medicine.

And there will be another one next year - VS2010 and Windows 7 will likely have shipped by then; start speculating now on what that will all be about...

Gosh - what a lot of people have come to read this whitepaper on building a .NET 3.5 application. (The BradA effect, I reckon).

In his comments, Brad mentions that he doesn't agree with all the assertions made in the paper - I certainly wouldn't expect him to do so (my own views are constantly in flux as I learn more every day).

I'm posting this entry to encourage discussion and disagreement!