Living in the Tech Avalanche Generation

Just as I was about to embark on  a new project (codenamed PONGO), the IronPython team announced a CTP 2.0 drop of the IronPython tools for Visual Studio 2010 which is exciting on a number of different levels.

If IronRuby and IronPython eventually make it all the way to Visual Studio integration in the full sense (that is packaged as part of Visual Studio itself) that would be a mark of first class citizenry.

What about Expression Blend?

Personally I work in both Blend and Visual Studio and even though the Visual Studio designer is somewhat improved and it’s intellisense is far superior than that of Expression Blend, it still does not provide me with the same fidelity or fluency in the design experience as I get from Blend. This leaves me with a problem when it comes to building applications where IronPython is the choice language.

It would have been unrealistic (at this stage) to expect Blend to open IronPython projects created in Visual Studio and sure enough that is the not case. What might be useful is Blend having a “design XAML only mode”, enabling it to open XAML files individually, taking advantage of the design experience it has to offer. Still not ready to give up on using Blend with XAML files that were part of a Visual Studio IronPython project, I set out to find a way.

Symbolic Links

The first thing I tried out was to see if Symbolic and Hard linked files would make the difference? First up I tried a symbolic link using the MKLINK utility:

MKLINK [[/D] | [/H] | [/J]] Link Target

Before doing this I created two projects, the first one an IronPython Tools project generated in Visual Studio and the second one a C# project created in Blend.

It should be obvious from the naming which project is which. In the blend project I removed the default XAML file generated by Blend.

Next came the file linking, I used only the Link and Target command line options, creating a symbolic link using the same name as the .XAML file in my IronPython project.

MKLINK pongo.xaml d:\temp\PongoBlend\pongo.xaml

Having successfully created the soft linked symbolic file I tried to add it to the Blend project only to find that it would not open – which, to blunt I wasn’t expecting to work. I was a little more hopeful however when it came to the Hard Linked file which I setup as follows:

MKLINK \H pongo.xaml d:\temp\PongoBlend\pongo.xaml

This did in fact open correctly in Blend and worked for a brief moment, when I changed something in Blend – Visual Studio would prompt me that the file had been changed outside the editor, unfortunately my celebrations were short lived when I found that the files were not updating in both locations when one or the other was subject to an edit. After some investigation and testing it appears that once opening the file in both the IDE’s the links would somehow eventually become broken and so the symbolic linking idea was now officially a lost prospect.

Duelling Projects

Finally I decided to synchronize two separate .XAML files in each of the two different projects, so the challenge was to find the most unobtrusive way of working in both IDE’s and easily syncing the the .XAML files after edits had been made. Given that one of the IDE’s was running a dynamic language with a REPL built in, I thought it shouldn’t prove too difficult.

What I did was to add two .py source files into the project, each one with some code that would sync in one direction, either from Blend to Visual Studio and vice versa. Sure its  far from a perfect solution but it just might be a price I’m willing to pay in the short term to get the benefit of using Blend. In the long term I really do hope that as the dynamic languages gain support in Visual Studio we also get some integrated ways to work in both IDE’s.

Here’s the very same Pongo.xaml file (or copy of it to be precise) in Expression Blend, but before you get too excited, the “send to interactive console” context menu option seems to suffer some kind of inconsistent behaviour (on my machine any way), causing the File copy operation in my .py files to work on only some occasions.

Undeterred I decided to fall back to an even more disintegrated experience and opt for running the synchronizing .py files in IPY.exe itself. This is easily achieved by associating .py files to the IPY.exe in Visual Studio using the context menu’s “open with” option, which is a something existing Visual Studio users will be very familiar with.

Like I said its far from a perfect solution and to be frank it’s somewhat annoying however my frustration is another thing altogether if I’m faced with doing all my layout and design in Visual Studio – so I will live with it for the moment. Hopefully the IronPython team and or the Expression Blend Team can find a solution that flows changes through more seamlessly in the short term and the perhaps in the long term allow us to open IronPython and IronRuby projects in Blend.

By the way if your wondering about the codename of the project that drove this adventure (PONGO) – the answer is yes if you guessed that it’s something that revolves around IronPython and MongoDB and I will be blogging about that more in the coming weeks.

So is 2010 the year when WPF finally starts to make the big-time? Having spent some time now working with the new desktop framework, I find it unlikely that I will find a compelling enough reason to choose Windows Forms for a desktop UI technology choice again.

So what’s holding it (WPF) back? I have read and listened to a lot of stuff online suggesting it’s so complex that it’s turning people off the idea. So what about the issue of so called complexity? Of all the ‘W’ technology stacks to come out from Microsoft, I count WCF as the most complex and there certainly hasn’t been any overwhelming discussion about how that complexity has raised the barrier of entry, to the point where it’s slowed adoption. There seems to be an consistent message coming from the scribes, with constant reference to a new division of labour, shared by the trusty old developer and the so called ‘turtle necks’ (designers), a term that seems to be sticking and one I’m sure designers find amusing a pejorative one. And lets not forget the newest addition to the vernacular, the ‘Devigner’! There seems to be a lot of opinion and chatter that holds the opinion that UI design is no longer within our grasp as developers, unless we have enough right brain activity going on that we might be precluded from committing outrageous sins of the desktop.

So here’s my take – I have written a few UI’s now in XAML based technology (SL and WPF) and I do not count myself as a designer or devigner. Perhaps I have some artistic flair (yeah I’m an arty type) in a general sense, but when it comes to graphics, I am pure stick figures all the way. I have been known to classify myself in the past as the patron saint of the graphically challenged! And yet I have now developed a couple of XAML User Interfaces where the User’s and my peers considered them to be ‘attractive’, self describing, efficient, simple to use, etc. Oh, and I still managed to do this all with my trusty old supervising controller in tow.

So why didn’t I cower in corner somewhere at the prospect of building a XAML UI? Well it’s not in my nature for starters, but secondly I wasn’t prepared to believe the hype. Sure I did quite a bit of prototyping and experimentation but in the wash up, learning is doing and each time I do it I get better at it – sound familiar? By the way, I don’t think I was doing anything graphically amazing per`se, but some nice simple animations will go a long way even from the king of the stick men.

Here is what I advise: don’t be afraid of the technology. If you ever developed desktop applications in the past and considered yourself capable in designing a good user experience, then don’t buy into the scare mongering and be prepared to jump off the cliff.

I don’t doubt that there will be some small percentage of software teams that will bring on a dedicated designer(s) but I would hate to think that the small development teams out there will be put off venturing out into the brave new world. Yes there is a lot of complexity (particularly in WPF) and the learning curve is certainly not shallow by any means, but nothing good in life is easy.

Recently our team has been engaged in developing a highly scalable batch processing system, which to be fair didn’t require much beyond a fairly simple User Interface with few screens. Given our choice of WPF as the technology to build the presentation layer, we decided to extend our curiosity in SketchFlow and put it to the test in a real live project.

So, off we set and created our prototype and when completed, sent it on to the stakeholders to cast their critical eye upon it and provide feedback using the SketchFlow players tools for capturing feedback. I must admit that I wasn’t convinced that our users / stakeholders where going to be particularly enamoured by the experience but I am happy to say that I was wrong- so incredibly wrong. Whilst developing the prototype I found myself continually applying my own biases toward the tool and they were such that I was developing an opinion that SketchFlow’s feedback mechanism was a little too simple and perhaps even ‘clunky’ to provide them with an experience that they would consider productive or enjoyable. However, the feedback came through very swiftly and along with it an enormous endorsement of the process, tool and the whole experience.

These user / stakeholders are used to defining and or changing a proposed UI layout in well known visual design applications (unnamed) and feeding those design documents accompanied with text documents (for annotation) to the software team for consideration. These documents would bounce between parties until a finalised design had been settled upon.

This time, upon having been supplied feedback via SketchFlow, they are reporting a significant amount of saving in time dedicated to the process and they are attributing that time saving entirely to the ease of use and functionality of SketchFlow. Now it’s early days yet and I don’t want to get carried away until we get a few more iterations into the process, however I am feeling pretty excited when our users come back with such positive feedback in their experience of the whole development life cycle.

And there I was, ready to put the kybosh on the idea. I cant argue a case when the business stakeholders show you nothing but thumbs pointing in an upward direction.