It’s been an interesting year, but quite a morbid one as well apparently: a lot of technologies, frameworks & principles have been declared dead, if you want to believe everything you read. Silverlight? Dead. Flash/Flex? Dead. Java? Dead by standstill and fighting. ASP .NET Webforms? Dead. .NET, even? Dead – WinRT to the rescue. And apparently Biztalk has been dead for years.

Well have you ever!

Today it came to my attention that it doesn’t stop there:

• The Web? Dead, according to Forrester.
• Apps? Dead as well!
• Or wait, no – apparently, apps are the future.

Conclusion? Well, apparently, the internet is full of crap. Of course, none of what I mentioned above is dead. If anything, we’ve never had a demand as high as this year for Silverlight & Flex, and mobile Apps in general (note: at the company I work for, we mainly build business app – your opinions may vary ;-)). Some of the stuff that’s been declared dead (HTML5) hasn’t even matured yet: demand is only going to go up, not down, the next few years.

In other words: when you’re reading yet another article on the imminent dead of a certain technology, take it with a grain of salt. If something is declared “dead”, the author probably means he or she thinks (or hopes) it will be “dead” in 3 to 5 years or so. Take a look at predictions that were made 5 years ago, and you immediately know the value (or lack of value) of these predictions.

Dead? Not really.  

As some of you might know, this blog isn’t the only place where I publish content: I regularly write articles that get published on other sites (and which I obviously can’t just duplicate on this blog, although I try to think about posting the links in an update), and some content is published as books or e-books as well.

As it was becoming increasingly difficult to keep an overview of what got posted where, I decided to add 2 pages to this blog: one outlining the content that’s published as a book or e-book, another one with a listing of articles, podcasts, … on other sites. 

I added these as an easy reference for myself (from time to time, I need to get organized ;-)), but as they might prove useful for you as well: a quick blog post. 

Enjoy! :-)

Windows 8 is here!

Well, it's been announced :-)  The last few days, a lot of new information has been released about Windows 8, specifically aimed at the new Metro-style apps.  Windows 8 will essentially feature 2 modes: the regular desktop, and the touch-optimized Metro style.  I'm not going to go into much detail about this: I'm guessing people who end up reading this post already know a thing or two about Windows 8.  But: I've been getting a lot of questions on this topic, so I decided to try and answer a few, and share my 2 cents.

Some things we've been hearing: Windows 8 changes everything.  HTML5 + javascript is the way to go.  XAML is a first class citizen.   OH MY GOD IE10 Metro doesn't support plug-ins: Silverlight is dead.  Silverlight is alive and well.  Et cetera, you know the drill.

Time to take a step back.  Does this really change everything?  Is the change that big?  Well: I don't think so. 

What is Metro?  What about the regular desktop?

If you look at Windows 8, it actually falls apart in 2 vastly different experiences.  We've got the regular desktop, which is much like Windows 7.  Everything we know about Windows 7 still applies to Windows 8: all the applications we've built, including WPF, Silverlight, in-browser apps built with ASP .NET MVC, ... Winforms, even, still run on Windows 8. Aka: the .NET we know and love.  This is the way applications will be built for a long, long time: just as we do it now.

And then there's the big new thing: Metro-style apps.  This is what all the fuzz is about.

One way to look at this, and this is the way I like to look at it, is: in fact, Metro style Windows = iOS or Android, the Microsoft way.  It's made for tablets/slates, it's made to be touch-optimized.  It's aimed, mainly, at consumers, or at apps that don't require a lot of input.  And every app you build for it will be built using the new development paradigm: WinRT, in combination with HTML/js or XAML/C# (I know, VB .NET etc is also possible - but let's just assume the majority uses C#), and they will be distributed through the Windows App store. 

WinRT (regardless of how you talk to it - through JavaScript or C#) allows us to talk to device-specific functionality through C# or js (although it does still run in its own sandbox).  That's "The Cool Thing".  But in essence, writing Metro-style apps is a lot like writing apps for Android or iOS: you've got the power to use most of the capabilities of the device, the distribution mechanism is more or less the same, and the apps are OS-specific. 

But at the same time: Metro style apps do not run on anything but Windows 8 - Metro style (nope, not even the regular desktop).  Metro apps do not run in a browser, do not run on other devices, do not run ...  well, you catch my drift.  Even though you code these apps using syntax that is much like the XAML/JavaScript you're used to, they are not redistributable through other channels.

So what have we got here?  A new type of apps, with lots of capabilities, built in a new way that's a lot like what we're used to, but not quite the same.

What about IE10?

A nice example of this is IE10: there will be 2 versions of this: a regular IE10 for the desktop, and a Metro Style IE10.  This is actually just a Metro Style app: that version will not run on anything else but the Metro Style desktop.  By the way, this also means that other browsers like Chrome, Firefox, ... do not run in Metro Style mode - unless Google & Mozilla create Metro-versions of their browsers, and Microsoft allows it.  Just like none of your existing apps run in Metro Style mode (you might start to see why I like to think of this as "MS's iOS" :-)).

Now, of course: web applications do work, as you're just browsing to them using IE10, Metro Style.  But don't be mistaken: these are the web apps we're used to, and they are confined to the browser sandbox, just as we're used to.  They do not have access to any of the WinRT-stuff.  It's, well, just a browser.

And what's more: it's a browser that does not support plugins.  None.

Well, that sucks.  Shouldn't these plugins be supported?

No plugins.  That means: no Flash.  No Silverlight.  But also: no Adobe Reader, and none of the other plugins a lot of LOB applications rely on. 

There's been a lot of concern about this: does this mean Silverlight is dead?  Or Flash?  Isn't this a very bad decision? 

No: it's a good decision.

It's like wanting to have support for Flash or Silverlight, in-browser, on your smarthphone or iPad.  It can be done, technically (there's a Flash for Android), but it will offer sub-par user experience, almost by definition.  Steve Jobs was right on this one: if you create a Flash app (or Silverlight app for that matter) that runs in the browser, it's supposed to be manipulated with keyboard & mouse.  Using an app designed for those input types on a touch-based device is not - and I mean: never - a good user experience.  Let alone the different amount of screen estate, orientation, ...  any designer will tell you a specific form factor with a specific input type requires an application design catered to those specifics. 

From an end-user POV, not supporting plugins in Metro is a good thing.  And for those who are concerned about Flash or Silverlight: this is, and stays, fully supported in regular Windows 8.  Remember: Metro apps are touch-centric apps, for slates and tablets.

Touch centric?  Metro?  Isn't this supposed to work with mouse & keyboard as well?

Yes, it works.  But this is one of the things where I'm quite opposed to what Microsoft is trying to sell us with its Metro paradigm: the idea that Metro works just as good with mouse & keyboard. 

With Metro, we're looking at a UI and UX tailored to touch devices.  As any - and I mean any - UX specialist will tell you (and as I've stated above): a different input methodology requires a different UI approach to ensure good UX.  Even Microsoft themselves tell us that: just read their Metro design guidelines for WP7: it's based upon the notion that a touch-centric UI is vastly different from one in which you manipulate your apps with mouse and keyboard.  So, Metro with mouse and keyboard?  It's not because it can be done that it should be done.

My gut feeling?  The typical LOB/Enterprise applications that require mouse/keyboard input will not be Metro applications - they will look, feel, and be developed just as we do today, web-based or desktop-based, and will be run through the regular desktop in Windows 8.

Conclusion?

With Windows 8, we get a new type of application: the Metro style app: touch-centric, Win 8 only apps, using a new WinRT stack, which can be developed using XAML/C# or HTML/JavaScript (keeping in mind that those apps will not just run in a browser, or in Silverlight).  This Metro style version of Windows is, in my opinion, quite similar to what we've got with iOS/Android-based devices.  The thing Windows 8 has going for it is the ability to switch between Metro & regular mode, but we've got to keep in mind that these are 2 very, very different environments, from a user POV AND from a development POV.

But for the most part, and for the majority of applications that are built today by companies as the one I work for, there's not that much that changes: we typically buildLOB / Enterprise apps, not very suited for the touch-based, small application, consumer-like approach Metro is tailored to.

The best advice I can give anyone who’s building applications today: build a decent, standards-based service layer, and tailor the frontend to the devices it has to run on, be it a regular web app, a Silverlight OOB app, an iPad or iPhone app, or a new WinRT Metro Style app.  The “build once, run everywhere”-dream should be put to rest.  The best user experience is, and stays, a native experience.

Quick post: the slides and demo-code from my Silverlight, MMVM & RIA Services – an Architectural Story are available for download from my SkyDrive.

Thanks for joining the session, the nice comments and interesting questions afterwards :-) I enjoyed delivering it, hope you enjoyed listening to me, and if you’ve got any questions, drop me a line.

I've just seen the MIX11 keynote, and followed my first session at MIX (HTML5 for Silverlight Devs :-)). Everyone who's here or who's following online will already have noticed there's a heavy focus on HTML5 this year - you can feel it in the Day 1 keynote (in tomorrow’s keynote, we’ll get some Silverlight 5 / Windows Phone 7 stuff), you can grasp it from the amount of sessions about HTML5. We're getting demo's showing off some CSS features, graphic features, video features, animations, …

Hold on. Let me rephrase that: we're getting demo's of how these features work great in IE9 & IE10 (get the preview now), and don't run all that great in, say, Chrome.

The problem? I build business apps, and for these apps, I'm not buying it. It's too early. It's immature. There's not enough browser support.

Interestingly enough, Dean started his keynote by stating that what people want are native apps on their devices. I tend to agree with him on this one - but that means that, for your mobile devices, you will want to write a native app in whatever tech it is that's supported on that device - you'll have to write iPhone apps, WP7 apps, Android apps , … in their native development languages. I agree, but that makes me wonder: why all that talk about "write your app in HTML (5) so it works on each device," when in essence it will offer you a sub-par experience, a fallback experience really?

If you want to offer the best experience to your consumers, you will have to write a native app for each device. But this post isn't about that - I'll write another one with my thoughts on building apps for multiple devices & multiple form factors in the near future.

I've seen some pretty cool stuff today. Jumplists from Facebook (needs IE9 & Windows 7). A FourSquare playground built in HTML5 (needs IE9 & Windows 7). CSS gradients. Auto resizing grids (runs great in… IE10). Are you catching my drift here?

We've got Canvas. We've got SVG. We've got native sound. We've got the video tag. But it won't work across browsers. It won't work in older browsers. It won't work natively at all for most of the people & devices out there.

As said, I've seen pretty cool stuff, but I've mainly seen UI features – UI features that are already available in plugin-based technologies.  What's more: I've seen that native cross-browser support for these features is nothing more but a distant dream; and even if the features are supported, they seem to run fast in a certain browser, but run like crap in any other one.

Do you really want this for your apps?

Now, of course you can write your sites to gradually decrease as far as UI capabilities are concerned, or you can use something like Modernizr to "fake" HTML5 features using JavaScript / ECMA Script 5 (input elements are a nice example of why you’d want to use this), or at least to check if a certain feature is supported by the users’ browser.

But again, I'm not building sites, I'm building business apps.

So let's step away from the great, pretty, flashy, gradient-y HTML5 features. The real power of HTML5 are, in my opinion, its state/dev-related features; and these are either available or not: you can't use something like Modernizr to magically enable them on older browsers. 'm talking Local Storage, Session Storage, File API, WebSQL API, WebSockets, Offline Apps, … the stuff we've got in plugin-based approaches but are missing from HTML. This is the stuff that makes HTML5 great.

Problem is: I can't use these features. Not all of them are implemented at the moment, not even in the latest preview builds of most browsers. There's not enough browser support for this, my users probably won't have the correct version of the correct browsers, and there's no way to gradually adapt my app for older browsers when using these features: they either fully support them natively, or they don't.

So what are we left with, from a business app point of view? Flashy semi-supported, semi-fast or slow (depending on your browser) features, poor cross-browser support & not enough market penetration to start using the interesting features. And I'm not even talking about tooling support for these features. I need support for these features across browsers, and I need a substantial amount of users having a modern browser which supports them.

Are you really going to build a business application today, using HTML5?  I won't.

Don't get me wrong: I like where the new HTML spec is going. You'll probably see me blogging about the latest cool HTML5-based business application we're building at my job… in about three years or so. But not now.

So, what should you use to build your business apps today? In my opinion: use a plugin-based approach (Silverlight, for example) if you need it to run on the web (or on the desktop, cross-platform even).

What if that’s not an option?  Use ASP .NET MVC + jQuery if you need your app to be HTML-based, pairing it with something like Modernizr to enable you to use some of the UI-related HTML5 features.

Need it to run on mobile devices or devices with another form factor?  Build them natively in the technology the device supports (but as said, more on that in another post).

But don't get caught up in the HTML5 hype. There’s cool stuff underway.  It will get there, but it's not there yet. Not now. Not today. Not in the near future.

I’m happy to announce I’m going to do a session at the Norwegian Developer Conference in Oslo, June 8 – 10.  The session will be an in-depth session on architecting Silverlight solutions with WCF RIA Services and MVVM, and I’m quite excited about it; sessions like this are much more fun to prepare & deliver than high-level sessions, in my opinion..  If you’ve got things you absolutely want to know about these techs/frameworks, don’t hesitate to drop me a line – I’ll try to fit them into the session :)

In case you don’t know NDC, here’s some info straight from their site:

NDC 2010 was an unqualified success, with more than 1,300 participants and a range of Partners from leading IT companies. We are now about to repeat the success by organising NDC2011

  

   

Leaders in the field

Again in 2011, participants will be able to learn from the leaders in the field.

The conference promoters are ProgramUtvikling AS. Their vision is to provide developers with the very latest in practical expertise in technology and project performance. Norwegian developers are already well–respected for their abilities, and the aim of the conference is to stimulate the environment in Norway even further, so that Norwegian developers can maintain and enhance their sound position. The way this is being done is by establishing an international conferencing environment in Oslo and focusing on seminars of the highest quality.

     

 

Norway’s largest agile program development conference

NDC is Norway’s largest conference dedicated to .NET and Agile development. Along with ProgramUtvikling, Microsoft Norge AS is also supporting the conference and doing its bit to make the event a real boost for developers in the industry.

 

 

Access to new technology

Over many years, Microsoft has been focused on giving developers access to the latest technology – as demonstrated at NDC 2008, 2009 and 2010. For 2011, it has been decided that, as before, the conference should feature seven different specialist tracks, each including a series of relevant talks.

Hope to see you there?

In October last year, I participated in the beta exams for Silverlight MCTS certification.  Last week, I was notified that I had passed the exam, so – quite excitedly – I tweeted about this.  Not soon thereafter I got a few questions from people asking me what to expect of the exam, and how to prepare for it.  Therefore, I decided to dedicate a blog post to it.

So, what can you expect of this exam, 70-506, Silverlight 4 Development?  If you’ve taken any other MS Certification exam, you already know what you’re going to get: a bunch of multiple choice questions, spanning about every aspect of Silverlight development.  Questions can be more theoretic, but often consist of a proposed problem, and 4 code examples you have to choose the right one from.  I got the feeling the questions were much more aimed at real-life problems compared to other certification exams I took in the past.  I vividly remember a .NET Fundamentals exam (.NET 2.0) containing questions like “What is the correct syntax for xxx”, with possible answers consisting of useless (due to IntelliSense) wrongly spelled class names. 

No such silliness here: for almost all code-related questions, I could easily imagine a real-life situation where I would pose myself that exact question. 

You should, however, have a vast knowledge of all the core concepts: DataBinding, INotifyPropertyChanged, Converters, DataContext, Validation, … as there were questions about all of these.  That said: this is something every serious Silverlight developer should know about.

Next: how should you prepare for this exam?  At the moment, there isn’t a book you can buy/download (might want to read mine though ;-)) specifically aimed at the exams.  But: if you’re working with Silverlight day to day, you should be able to pass the exam without any problems.  I’ve been working with it for more than 2 years now, and I didn’t prepare for the exam at all, yet there were very few questions I wasn’t able to answer with certainty – so I guess my main advice would be: don’t worry, you can do it! ;-)

However: if you haven’t been developing SL projects for a while, you should prepare – and even if you have, brushing up on your knowledge is always a good idea.  Luckily, there are resources to be found around the web:

• Mark Monster has an exam preparation guide on his blog
• Gill Cleeren has started a guide on Silverlight Show

Look at these links, and you should be more than prepared for the exam.  Good luck!