Nick's .NET Travels

Continually looking for the yellow brick road so I can catch me a wizard....

Occasionally Connected Application is NOT about Working Offline

For almost as long as I've been working with .NET I have been an advocate for building rich client applications (aka smart client applications) that work in an occasionally connected manner - think Outlook cached mode.  Recently there have been a couple of posts such as "You're not on a f^&king plane (and if you are, it doesn't matter)!" and "The Mile High Club: 37signals, [email protected]#k yeahs, and productivity stock-art" that talk about the current trend of people talking about providing caching/offline capabilities to their web applications.  IMHO they all miss the point.  Building web applications that will work offline is NOT the solution - you need to build rich client applications that are DESGINED to work offline.

Ok, so let me explain:  The basic premise of building occasionally connected applications is that you work on the assumption that the application WILL be offline.  To enable this you work with a local datastore (assuming a real world application that works with some sort of data) and you build an rich application that doesn't require any network access.  You then need to consider how the data is going to be synchronised to the local datastore (again, assuming a real world application where you want the data to be kept in a central repository).  This can be done using technologies such as Merge Replication, RDA, MS Sync Services but essentially this is a separate concern to building the application itself.

So, why is this better than just coding an application that will continue to work when I pull the network cable out?  Well it all comes down to usability - according to Microsoft we are in the Age of User Experience (which IMHO is rubbish, just because Microsoft has entered the design application market does NOT mean that we have only just started to think about usability - more on that later).  Usability of web applications has a fundamental problem in that it relies on request-response model back to the web server.  Even with the best implementation of Ajax you are still likely to experience delays, refreshes etc that lead to a poor user experience.  On the converse a rich client application "should" have smooth usability with no wait times between screens.  I know which one I would prefer!

Finally, back to my point about the Age of User Experience; Despite two iterations of the .NET Framework WinForms essentially hasn't changed since the old C/VB days.  A lot of companies have invested heavily on extending forms and controls to make their applications look good.  Of course there were always challenges making the application responsive - you could introduce multiple threads to load data, but then you ended up debugging locking issues etc. 

Now with the Windows Presentation Foundation we have a much rich (or so they keep claiming) framework with which to build applications.  I must admit the applications I have seen to date have all looked great, but they nearly all diverge from using standard menus or having a familiar look and feel - tell me how this is suppose to empower users?

Whilst WPF is a significant improvement when it comes to building rich client applications there is still a long way to go before "usable" and "applications" become synonymous!

Microsoft Whiteboard

Nick's .NET Travels

Continually looking for the yellow brick road so I can catch me a wizard....

Microsoft Whiteboard

I noticed the other day that Microsoft have added another app to the suite of apps that are available to Office 365 subscribers, Microsoft Whiteboard ( On downloading it from the Store I was immediately impressed with the overall look and feel of the app – very professional and clearly showcases what can be done with the Windows platform.

Having said this, here are my immediate frustrations:

Where are the apps for other platforms?

Namely iOS, Android, Web, MacOS – it’s very transparent that this is a push to promote how great the inking experience is on Windows but for this to be a viable solution for businesses it needs to be available anywhere

Why upload PNGs?

Being a developer I immediately ran the app through Fiddler and what shocked me was that PNGs are being uploaded. I haven’t delved into how the synchronisation process works when multiple people are collaborating but I can’t imagine any scenario where uploading PNG is efficient. If you look at what other shared drawing experiences do (eg there is no sharing of image, rather the line segments are sent back and forth.

Why isn’t this a Control

Again with my developer hat on, this shared whiteboard needs to be made available as an Office 365 control that developers can simply drop into their application in order to integrate a shared whiteboard experience. As more applications are built that tap into the Microsoft Graph and leverage the fact that users are connected with either an MSA or an Office 365 account, having rich component such as this would significantly cut development time and make it easier to build amazing applications.

Overall I’m impressed with Microsoft Whiteboard and hope that this is a sign of some of the great innovation that the Microsoft 365 platform will bring with it.

Comments are closed