A couple of weekends ago, we had a design meeting on the WPF project I mentioned a week or two ago, which now glories in the codename Clock Tower 7 (don’t ask!).

Brian and Ian will have plenty to add, but here’s my perspective…

Coffee and extensibility

Once we’d decided which brand of coffee was going to fuel the day, thoughts turned to the extensibility model.

First question: do we need an extensibility model?

Well, that’s probably another blog post ; premature extensibility is like premature optimization – tempting, so very tempting. Suffice to say (for now) that we do want to allow ourselves - and 3^rd parties - to develop additional data providers for the application, and bind those at runtime.

Choices…so many choices…

We considered three basic options for the plug-in framework.

1) Roll our own

2) Managed AddIn Framework (MAF)

3) Managed Extensibility Framework (MEF)

We pretty quickly rejected “roll our own”. A plug-in framework is hard to get right, not least in terms of the programming model, security considerations and testability. So why shouldn’t we try to get the “Goldilocks” implementation – not too hot, not too cold, but just right for our app?

Well, groups inside Microsoft have had several goes at this with .NET, with varying degrees of success and compromise. On top of that there are innumerable 3^rd party efforts (try querying “.NET Plugin architecture” in your favourite search engine).

Adding to this menagerie just didn’t seem to be made of win.

Next under consideration was MAF. This was added in .NET 3.5, and provides very sophisticated plug in capabilities. It even has the option of full AppDomain isolation for security, stability, and the ability to unload code – almost the holy grail of plug-in models.

It even goes some way to supporting WPF add ins. However, it turns out that WPF is not happy at all in the presence of multiple AppDomains. It might seem to work, but it isn’t really supported. And while MAF is very powerful, and an in-the-box component of the .NET framework, it is also quite complex to use. Much of this complexity serves the goal of AppDomain isolation, and if we’re ditching that for WPF, then it is pain we could happily do without.

The third option is MEF. This is a new .NET library that enables in-AppDomain runtime extensibility, with a simple programming model that is itself extensible.

At the present time, MEF is not an in-the-box component of the .NET framework, but the published intention is that it will be, in the .NET 4.0 timeframe. At the moment we can download full source and binaries from the Codeplex site linked above. (They’ve just shipped “preview 5”.)

The major downside to MEF is that the programming model is still changing with each preview, so it is some way from being a totally stable target. That said, migration between versions has been pretty painless so far.

The other limitation of MEF is that we don’t have the potential isolation and unloading benefits of AppDomain separation. This was a serious consideration for us – not just from the security perspective, but also for crash isolation; we’d like to do as much as possible to prevent a 3^rd party plug in from bringing down our application. In managed code, this is much less likely to happen “by accident”, and we can catch most cases. Defending ourselves against a malicious plug-in is a topic for another day.

On balance, we think that the programming model and future-proofing makes MEF the compelling choice for our application.

So, the Windows 7 Release Candidate (build 7100) has shown up for MSDN Subscribers. (Keep looking here if you want the public RC – it will show up on 5th May).

I decided to go for a clean install, and then reinstall the apps and migrate my data across, rather than bodge an upgrade from the beta, and I’m glad I did.

OS install time was very quick (less than 30 minutes), and I’m back to fully functional in less than half a day. As usual, the VS2k8, TFS and SP1 was by far the slowest part of the process.

So far, everything seems fine, apart from a one-time MSN Home Page / IE8 crash that is new-for-this-build.

One of my colleagues is over in Chicago this week for the HIMSS 2009 meeting. We're taking the opportunity to give some briefings on our new software technology and agile process for clinical and pharamceutical applications developments - CloudBurst.

If you're intrigued, and in Chicago, then either call Gerry Skews on +44 79809 70326 or email himss-conference@ythos.net

Once the conference begins, we'll post the introductory slide deck we've used in Chicago , and there will be a business whitepaper next week.

On the technical front, I'll be producing a follow-up to this whitepaper which covers the evolution and simplification of our application architecture, and how we've updated our R&D processes to deal with a distributed development team, and closer partner involvement.

BTW - I've finally got a twitter account: @ythos, to turn passing thoughts into 140 characters.

As global economic conditions get chillier (already things look much worse than the early 90s), it is becoming increasingly difficult to find early stage venture funding. If you're in a job, are you really going to leap out into the dark (illuminated only by your BizSpark sparkler) and start up a new business?

Possibly, possibly not. What a lot of software folks can do is to start burning the midnight oil to create their new technology, so that there is something tangible to invest in.

If you go down that route, then you need to be very careful that you are not falling foul of your current contract of employment. At the very least, you need to make sure that you don't use any of your employer's resources (PCs, equipment, time, space, heat, oxygen) to do the job. And if they have first right of refusal on anything extra-curricular, make sure you get that waiver in writing. It doesn't matter how many verbal assurances you get, if you do anything even slightly successful you'll find that they were never said.

Which brings me to a sideline of my own. I was down in London last week, and caught up with some friends: Brian Randell, Ian Griffiths, and Felix Corke. Brian has cooked up a project which sounds very interesting - a data visualization problem in WPF. I'll leave it to Brian to explain the background, but it should be interesting, and result in something pretty useful (at least two of us already have something in mind for it when it is done).

One project that's kept us extremely busy for the last 3 weeks or so has been an Enterprise Search app with EMC / Microsoft FAST. I'm pleased to say that it has just been demonstrated in the Tuesday keynote at FASTForward.

As with the Tesco demo at PDC, the UX was the brainchild of the EMC Consulting guys and gals, who have done a fabulous job - sufficiently fabulous to win an award for best search UX at the show.

I just wanted to post a couple of thoughts about developing multi-touch interfaces, as embodied in the Microsoft Surface technology (and Windows 7, if you've got the necessary hardware).

Losing the mouse, and thinking about many people collaborating in the use of the same application changes the way you think about developing software. You have to find compact ways of displaying large amounts of information so that you can have multiple "centers of focus" for the different users; but equally, you need large target areas so that my fat fingers stand a chance of manipulating the information. Text has to take a back seat, and sound becomes an important part of the experience.

Given a blank sheet, there's plenty you can do, but should you do it? Will people realize that a two finger contact might be different from a single finger, for example? (Answer: no!)

The mouse is a proxy for your eyes: users tend to move it where they are looking, and you can deploy all sorts of clever hover effects when they do so, to enhance the information content. With touch, on the other hand, your eyes are your eyes (amazing!), and you don't make contact with an object until you are ready to action something; more like the "real world".

In fact, there's a lot more interaction with the physical world, and that brings up new questions: how could/should objects like your cellphone and business card interoperate with the virtual environment? How does security work in a public space like this?

We had three weeks of discovery and experiment, and although we're a long way from fully exploiting the possibilities of this platform, I think we're starting to find new and exciting ways of approaching old problems.

Quick tip if you are intending to install Virtual PC on Windows 7 (i.e. use Windows 7 to host other OSes, not install Win7 as a guest OS), and are upgrading from Vista.

1. Uninstall your existing Virtual PC instance

2. Run the upgrade from Vista to Win 7

3. (Re)install Virtual PC 2007 SP1

If you don't, then you can hit a problem with virtual networking / network sharing. (Although uninstalling and reinstalling VPC while in Win7 also seems to work)

The New Year has arrived, it is still unusually cold in Cambridge, and I've downloaded the Windows 7 Beta.

I decided to try an upgrade from a spare Vista x64 SP1 installation, with development tools (VS2k7, SQL2k8, Office2k7, TFS PowerTools, Resharper, Oslo bits, Flash CS4), and my usual utility set (MagicDisk, 7Zip, Feeddemon, BBC iPlayer, Live Messenger, Live Writer, Acrobat amongst others).

Only hiccup to start with was the long-standing "you have to remove PowerShell before you can upgrade" problem. It is hidden in the Windows Features bit of the Programs control panel applet, and needs its box unchecking. After that, it started the loooong process of backing up my programs and settings, the relatively quick installing of the Windows bits, and another looooong process of putting my programs and settings back.

On the plus side, it did actually work; everything is just fine at the other end of it, and my desktop is still recognizably my desktop.

Only a couple of minor gripes in the upgrade process - it would have been nice if it had defaulted to putting my Sidebar gadgets on the right of the screen in the order they were when they were forced to be docked there, rather than sort of splatting them in the top left of the screen. It could also have looked at what I had in the quick launch bar, and pinned them to the Task Bar for me.

As for the OS itself - well, it is a heck of a lot more polished and stable than the bits we got at PDC; in fact, this is one of the best Windows Betas I've ever seen (so far). It knocks Windows 2000 Beta 1, Windows XP Beta 1 and Windows Vista Beta 1 (redux) into a cocked hat for "feeling finished". I'm particularly pleased to see that Messenger supports the Jumplist feature already.

There's a slight disappointment in that Google Chrome is completely non-functional (even from the current Dev branch). Windows does warn you about it, though, with its standard "incompatible application" dialog.

The major disappointment is that they have gone ahead and tuned down UAC to the point where it is a waste of time. Job 1 is to go and crank it back up to 11, unless you are the kind of person who enjoys inflicting evil on us all. (And, BTW, for all those Mac Users who claim that their version of same technology is any less intrusive, I'd beg to differ...not only does it seem that I have to click a button, but I have to type my password in too. I can, of course, cut down on the amount of typing by just leaving it unlocked...but that's just as bad as turning the security off!)

Anyway, the Beta will be there for everyone to enjoy/hate/love any day now. Happy New Year.

We’re working with a couple of companies right now who are gearing up to shipping their products. They’re very different products in very different spaces, but there are a number of issues they have in common:

1. What exactly is it that we’re going to ship?

Technology businesses often get lost in the feature list. You don’t necessarily need to ship everything first time out of the door – especially that stuff you’ve only just crammed in at the last minute.

Make sure you know exactly what value everything brings to the end user, and be ruthless about cutting stuff that looks like bloat. You can always add it in later, but you’ll never be able to take it out again.

2. And how are people going to get it?

If your product runs in the browser, then you’ve got a relatively easy life. Because installers are hard. Really, really hard.

On the plus side, there are plenty of guidelines to follow (there’s good information here and here for the Microsoft stack). If you haven’t been planning for install (and upgrade) since the very beginning then it isn’t too late, but it is going to be more difficult.

The art of installation comes in three parts:

i. Prerequisite management (the hardest bit)

ii. Getting the bits onto the disk, and letting the right users access them

iii.  Updating the bits when you have a change

Make sure you’ve covered all of these in your installation process, right from the very first release – especially your update strategy. v1.1 will come frighteningly hard on the heels of v1.0.

Testing is then the key – you’re going to need a wide range of test environments (virtualized, naturally), just for installation. Every user that downloads your trial software and has a lousy installation experience is a lost customer; don’t skimp on install/uninstall testing.

3. When they’ve got it, are we sure they’re going to know what to do with it?

Have you invested in “getting started” and “how to” documentation? What about a walkthrough video? FAQs? A web forum? A web forum that you used during your soft-launch/beta testing to seed some user-generated content? Who’s looking after your web/email support? Do you need to run “getting started” webinars – like salesforce.com do?

None of that is very expensive, but it makes a massive difference to your users’ first experience of the product.  Oh – and make sure it is all available to people just trying it out, too.

4. And, is it likely to work?

You can’t test enough – but you can waste an awful lot of resource testing “known good” (or “known bad”). But, whatever your process, you can’t ship-test a moving target. This may sound stupid, but until you stop changing the code, you can’t ship. Stop. Stop now.

Right. You’ve stopped. Now – you need to work out when you’re going to stop fixing bugs. Not finding bugs. Fixing them.

Every bug you fix increases the chance of you creating another bug somewhere else. And testing will find bugs – especially beta testing. Have a process for investigating, prioritizing and then deciding whether to fix.

Don’t fix a bug at this stage because it is easy to fix; fix it because it will seriously impact on your customers. Remember you’re trying to stop doing anything else to the product. Including bug fixing.

I know this all seems pretty obvious, but I think we sometimes lose sight of the obvious when we’re in throes of shipping – especially shipping for the first time. Which brings me to…

5. You have to ship

You’re not going to make money/get investment/get sold without shipping. Companies have done so in the past, but that’s not going to happen in the current climate. Well, not often…

Turns out that writing a virtualizing panel (like VirtualizingStackPanel) is quite difficult. There are some good examples out on the web to give you a start (like here) but there turn out to be several further problems to overcome.

1) You have to deal with repositioning the scroll offset when the viewport and extent change relative size

That’s relatively straightforward – when you recalculate the viewport and the extent, you just need to scale by the relative changes: e.g.

_offset.X = (oldOffset.X / oldExtent.Width) * newExtent.Width;

2) You have to deal with focus handling, or ListBoxes (and other containers) won’t work properly

This is the most common problem with the existing examples.

By far the easiest way to do that is to realize one extra item off the beginning and the end of the visible area in each direction, and update your offsets accordingly. Don’t forget to check for the boundary conditions, where you’re already at the zeroth or (Count-1)th item in the collection.

3) Don’t forget that your panel can reach zero size, and may have infinite extent

Dealing with the infinities in the Measure() pass can be tricky. Don’t forget to check for them when it matters.

4) What about the case where you’re using it in a “non-virtualizing” manner

Sometimes, your VirtualizingPanel gets used in a non-Virtualizing context. You need logic to work out that there isn’t, in fact, an item container generator in play, and fall back on simple measuring of your InternalChildren. It should be possible to share your Arrange pass, though.

To help illustrate these points, I’ve hacked up an example virtualizing panel called EqualStackPanel. It behaves exactly like a stack panel, but fits the stack items to the available height/width of the container, depending on its Orientation. By default, it will try to fit all the items in the available space, but you can specify an alternative number of ItemsToDisplay, and it will fit exactly that many, and scroll to fit the remainder.

This isn’t production-hardened code, use at your own risk, your mileage may vary etc.