Archive for the 'Laurent Bugnion' Category

October 10, 2012

Laurent Bugnion Featured in MSDN Magazine for Windows 8

IdentitMSDN Magazine featuring an article by Laurent BugnionyMine’s own Laurent Bugnion, our European Senior Director and a Microsoft MVP, has just been published in the Microsoft journal for developers October issue of MSDN Magazine.  Here’s a snippet of his article, click here for the full piece and download the code sample he included:

 

Using the MVVM Pattern in Windows 8   | by Laurent Bugnion

Any programmer with previous experience in any of the XAML-based frameworks has probably at least heard of the Model-View-ViewModel (MVVM) pattern. Some have been using it extensively in all of their Windows Presentation Foundation (WPF), Silverlight or Windows Phone applications. Others have avoided it, either because they misunderstand what the pattern does, exactly, or because they don’t want to add what they see as a new level of complexity to their application…”   Read more

 

Laurent Bugnion, IdenittyMine, Microsoft MVP

October 7, 2011

My Windows 8 Has Split Personalities

I had dinner the other night with my good friend Josh Smith, and of course we started talking about Windows 8. Something he said was pretty much spot on: He said that Windows 8 feels as if it has split personalities. There are the WinRT “Metro-style” apps and there is the “classic” Desktop, which looks and feels like Windows  7++ (optimized for touch, and actually a real delight to use with my fat greasy fingers).

Side note: I really dislike more and more the name “Metro-style” for the WinRT apps. Metro is a design language, and nothing prevents me from creating a beautiful Metro application in Win32 if I want (though it would be a lot of work), or (more realistically) in Silverlight. I was not sure about “immersive apps” but “metro style apps” is much worse. Please change it Microsoft.

Two devices

So it really feels like you have two very different devices in one. The Desktop mode feels like it is a totally standard PC, and is typically used with a keyboard and a mouse, though it has been extremely touch optimized (in the contrary of Windows 7 which runs on my Touchsmart TX2 with 4 points of touch, where it is hard to target those small buttons. On Windows 8, it feels as if the computer knows in advance what you are trying to achieve. Pretty amazing, and to see more about this topic, check this touch session and this other one too.)

On the other hand, the Metro-style apps feel much more like a phone app, and in fact they follow a similar development and application model (I will blog more about that soon).

Why split personalities?

One important concept you learn when you are interested in user experience is that if possible you should avoid to switch the user’s context. When the user is doing work in one environment, changing to another environment is feeling like a disruption, or even like an aggression. And unfortunately, we have this in the Windows 8 OS with the Start menu: When I am in Desktop mode and I press the Start button (top left corner on the picture above, because I moved my taskbar to the side), Windows 8 switches to the “green Start menu” shown in the second picture. That switch is not nice at all.

Now I understand that Microsoft wants to show off the Start menu because it is new and shiny, but I would really prefer if, when I do work in the Desktop mode with my keyboard and mouse, I want to stay in that mode until I decide otherwise. On the other hand, if I am in tablet mode, no keyboard/mouse, then it is fine to stay in a touch only, Metro style mode until, again, I decide otherwise.

So how can Microsoft solve it?

In fact it is pretty easy to solve, and I really hope that they do it before RTM: Implement a simple Start menu in Desktop mode, similar to what we have in Windows 7 (though it doesn’t have to be as complex in my opinion). Just give me a menu that open when I click the Start button, with a Search that acts similar to the Windows 7 one, a list of pinned application shortcuts, and maybe access to all the installed applications through folders.

This would avoid the annoying context switch,  and allow me to pretty much forget that it’s not a “classic Windows device”. On the other hand, when I take it out of the dock and out in the wild, this becomes a touch-intensive device, a whole other class of hardware.

This becomes even more attractive now that it seems that ARM based devices (low energy, low power devices similar to an iPad) will also run the Desktop mode (Note: Take this information with a grain of salt right now, because we only heard about it yesterday and I am not 100% sure what will actually happen). Anyway, every time that there is a context switch, a kitten dies, so please Microsoft, change it and save the kittens.

What about the web browser?

The web browser is another of these weird split personality things. The Metro IE is a very poor version of the web browser, with no plugins and no extensions. It feels very limited. On the other hand, there is a full version of IE on the device, in the Desktop mode, which runs Silverlight and Flash, is extensible etc. From the Metro IE, you can switch to the Desktop IE by showing the application bar, opening the File menu and selecting Use Desktop View. This is however not very discoverable (not even mentioning that the UI needs a lot of polish Winking smile

Needless to say, this is not a good experience. How can you explain to “normal users” that there are two versions of IE, and one had Silverlight/Flash, while the other does not? It barely makes sense. I really hope that this gets changed, and that we get either the full experience (including ActiveX plugins), or at least a better experience to suggest switching to the Desktop IE when an object tag is found on the page.

Note: We start seeing hints that ActiveX plugins will run in the less powerful ARM based devices. I don’t have information suggesting that it is true or not, but it is interesting to see the videos.

Cheers,

Laurent

Attributions: Kitten picture

September 28, 2011

My thoughts about Build, Windows 8, WinRT, XAML and Silverlight

Last week, Microsoft held their long awaited Build Windows (or simply “Build”) conference in Anaheim CA. About 5000 people packed the convention center to discover the latest version of the Windows operation system: Windows 8.

This is a very major iteration (much more than the Windows Vista –> Windows 7 transition) (and also, it is an early preview so it is quite unfinished ;) As such, we will definitely need a bit more time to play with it before we can express a truly informed opinion. Of course that didn’t stop tech journalists and dumbasses all over the world to (again) express complex thoughts such as “Microsoft is abandoning Flash/Silverlight in Windows 8″ or to ride again the “Silverlight is dead” roller coaster.

Side note: Did I just call you a dumbass? Well if you are on this blog, reading, the answer is most probably NO. I want to be very clear: This comment was not targeted at Scott Barnes either (though, why would he think it was? mmm food for thoughts there) ;) The dumbasses are the haters, the people who keep taking any occasion to spread FUD because they do not know it, understand it, or simply because it has the name Microsoft on it. So no, I did not call YOU a dumbass. Apologies for not making that super clear from the start. After all, you read my blog, that makes you my best friend (or something ;)


Of course, as usual (it is starting to get annoying, right?), these opinions are far from the truth and attempt to put a negative spin on everything Microsoft does. I won’t even speculate why that is, but based on track records, it is safe to say that this kind of prediction is not very accurate or rational (remember when we were told that we would not be able to use anything else than HTML to build Windows 8 apps? Yeah those were the days ;)

So what is the reality now? Here is what we know:

(disclaimer: this is based on what I understand after many discussions with experts. However, I am not a Windows 8 expert, I just played with it for 5 days now. If anything here is incorrect, it is my own fault and not the experts’)

Desktop vs Metro style

  • Windows 8 has two modes, one named “Desktop” and one named “Metro style”. These names are temporary and may very well change before release. The “Metro style” applications are also referred to as “immersive apps”.
  • Silverlight and WPF will continue to run as is on Windows 8 in Desktop mode. You can think of the Desktop mode as Windows 7++, an improved version especially optimized for touch operation. Honestly using the Desktop mode with the fingers is an amazing pleasure now, while it was a pain in Windows 7.
  • All applications (as far as I tested) that run in Windows 7 also run on Windows 8 Desktop mode. I installed Silverlight and Flash already on mine, OneNote, Live Writer, Live Messenger, Skype and more. No issues at all so far (apart from an occasional instability because “it’s an early preview” (TM)).
  • Metro style applications (aka “immersive apps”) are a new class of apps altogether. They are in fact much more similar to a Windows Phone 7 app than to a classic Windows application. They are optimized for Touch and can also be actuated with keyboard and mouse, though the experience is better with the fingers.
  • Metro style apps are sandboxed for security. Again, this is very similar to the Windows Phone 7 model.
  • Metro style apps can be developed with 3 possible stacks: XAML/C++, XAML/C# or HTML/CSS/JavaScript. They rely on a set of API named “WinRT” which is exposed in a very consistent manner for the three stacks.

This last point is important. It means that there is no reason to choose one or the other stack based on WinRT features that you want to address. Because of the chosen architecture, the features will automatically be available to the three stacks. In some cases however, some features will be hidden on purpose from one stack or the other, because they might simply not make sense.

The Windows 8 programming model: The blue side is largely unchanged (.NET 4.5, Silverlight 5, Win 32) and everything runs as usual. The green side is new (see the next section).

Programming stacks for WinRT

  • Amongst the three stacks, there will be some differences due to the languages. For instance, JavaScript and C# don’t address asynchronous programming in a similar manner (by the way Windows 8 is sporting C# 5, so you have the great “await” and “async” keywords that are making asynchronous programming much more similar to synchronous coding). Similarly, JavaScript is more dynamic than C#, but C# is easier to code and to debug, etc.
  • All three stacks talk to unmanaged code (the WinRT libraries). For C++, this is a direct unmanaged call. For C# and JavaScript, there is a thin managed layer to “map” the calls into WinRT. However, the managed layer is much thinner than before. It is simply because most of the previous .NET libraries are now WinRT libraries, and these are unmanaged.
  • For the C# developer however, you will not notice that the WInRT are unmanaged (except in some rare occasions) because the API is managed.
  • This means that the performance gain in C++ is not going to be as significant as versus “classic .NET”. There will be however a small performance gain in using XAML/C++.

Portability of Metro style apps

  • HTML/CSS/JavaScript applications coded for WinRT are not cross platform. They are something new. They use WinRT specific APIs, both in HTML/CSS (for instance the new Grid layout, which is not supported by other browsers at this time), or of course any calls against the WinRT APIs. This is NOT web programming. This is a standalone Windows 8 app that happens to be coded in a programming language that can also be used on the web. Two very different beasts, though of course knowledge and skills can be leveraged.
  • XAML/C# apps are not Silverlight or WPF. They are something new. They use WinRT specific APIs (sounds familiar?). Mostly, these APIs were already available in Silverlight, however there was a rather large “spring cleaning” operation, and a lot of APIs were moved in different namespaces, and sometimes renamed. A good example of this is the System.Threading.Dispatcher class which is now a Windows.UI.Core.CoreDispatcher. The original dispatcher’s CheckAccess() method is now a property named HasThreadAccess.

In both these points, notice how similar the experience is for the developer: Much is familiar, some things are new (most significantly new/renamed APIs), skills are portable but there is a learning curve.

How to choose?

In Jason Zander’s (and others’) own words, to choose the stack of choice to create a new Metro style app, you should consider the skills you have. If you are a web programmer with a solid experience in JavaScript, it’s obvious that you want to leverage your knowledge of the language. You will have a learning curve though, to learn the new proprietary APIs. If on the other hand you are a Silverlight/WPF developer, or even a .NET developer with no prior XAML experience, it will be easier and more faster for you to climb on the C#/XAML stack. Finally, if you are a C++ enthusiast, the C++/XAML stack is for you. And if like me you love to learn new things, then you can try one or both of the other stacks to build new apps.

Because of the Win8 architecture, any new feature added to WinRT will (almost) automatically be available to all three programming stacks (in fact it requires a little bit of work to decide what should be exposed or not, because some APIs just don’t make sense with a given programming language, but in regards to the investment needed to implement the feature, this is not significant.

What about existing applications?

It means that your (our) investments in any technology you were using until now are safe for a number of years. You had a Silverlight application, or are currently working on one? You should continue. WPF? Same thing. Not only these frameworks are fully supported and extended (Silverlight 5 release candidate was announced a few days before Build started), but they also work as is, without any changes on Windows 8.

And C#?

I had the immense privilege to be invited to a side session with Anders Heljsberg, the father of C#. It was a great session, and you can feel Anders’ happiness and enthusiasm. WinRT currently supports C#5, including all the new features such as the async and await keywords, and more. When asked if he was thinking of a version 6, Anders laughed and told us that he had a history of being quite stable at his job (13 years at Borland, 10+ years at Microsoft) and that he was foreseeing C# 6, 7, 8. C# is actively developed, and Anders is an accessible architect, who will listen to requests for new features. Changing a language is obviously not a fast process (nor should it be!) but his team is working on exciting stuff, and we are his customers!

Thoughts about porting applications from Silverlight/WPF to WinRT

This one is a tough one, mostly because I did not have time to experiment enough. If you have an existing application implemented in Silverlight or WPF, and you want to make it a WinRT application, how should you proceed, and is that easy?

Based  on what I saw and what others reported, it is not a trivial process, even if in most cases the major work is to find out what was renamed and what was moved (see the “spring cleaning” mention above). If you want/have to do that work, I would consider the following:

  • Why do you want to do this? Do you really want to make your existing application (which by the way runs perfectly fine on the Windows 8 Desktop) a WinRT app? Who are you trying to touch. Shouldn’t you rather be developing a new app, something like a companion to the existing application?
  • If you answer “yes” to the “do you really want to” question, then I really hope that you followed best practices and layered and componentized your application carefully (I also hope you wrote unit tests, because you’re going to need those to verify that the ported code runs fine).
  • Porting the code will take some effort. Do not underestimate the effort. I tend to believe that Microsoft was (purposely?) over-optimistic in telling us that this is an easy process. At least now that the documentation is in a very early stage, looking for the renamed objects is a tedious process.
  • By the way, I started porting MVVM Light to WinRT and I hope that (if my compulsion to blog about Windows 8 lets me) I might have something to share soon.

Tip: I was told (and didn’t test yet) that ILDASM can decompile the WinRT assemblies and let you peek for your objects/methods/properties. This is because even though the WinRT framework is unmanaged, a thin layer of meta data is built in to allow managed code access. Pretty clever (and handy) if you ask me. I (again) didn’t try but I suspect that dotPeek and other similar tools may work too. Let me know in the comments if you try it!

Wrapping up

There are a few not-very-well organized thoughts on Windows 8, WinRT, XAML and more, put together after 5 days of immersion and tons of discussions with Microsoft employees as well as third party experts. I hope you’ll forgive me if it sounds a bit chaotic, it is simply that a new framework of that amplitude will need a few weeks (months?) to be fully assimilated and digested. I hope that this helps painting a clearer picture however.

If there is one thing only you should take from this post, it is the following: Don’t panic. Yes we will have some work to fully climb on this new exciting platform. But much MUCH of what we know is going to apply almost 1:1 to the new stack. Also, Microsoft is really investing in user experience, Blend, XAML, C# and all that. If there is only one session of Build that you must see, it is Jensen Harris fantastic Big Picture session about the Windows 8 UX.


 

I for one am pretty excited about Windows 8 and WinRT. First it confirms what I have been thinking since I started playing with the Avalon bits: XAML is a great way to build a wonderful user experience, Blend is central to that experience and C# is awesome. I am also excited to see new ways to develop applications for WinRT, because diversity is good. The Samsung slate is an awesome device, and there was a great sense of excitement in Anaheim this week. Of course I am known for being an optimistic, but I don’t think it’s just me feeling that excitement. Windows 8 is going to be pretty awesome.

 

September 27, 2011

Running unit tests in Visual Studio 2011 and Windows 8 (WinRT)

This is a quick tip, because it confused me at first. But thanks to the always excellent Tim Heuer and Peter Provost (from the Visual Studio team), here is the answer:

Usual disclaimer: This is for XAML/C#. I am not sure how this works for the other programming stacks.

Creating unit tests for your WinRT application/library

  • Start Visual Studio 2011.
  • Create a new project.
  • From the Add New Project dialog, select Unit Test Library (In the Visual C#/Windows Metro Style category). Give a name to the project and press OK.
  • Either open the unit test class that was created, or create a new class. No need to select a fancy template, just create a new empty class.
  • Decorate the class with a [TestClass] attribute.
  • Create a public method with no parameters, and decorate it with a [TestMethod] attribute.
  • Right click on the unit test project and select Add Reference from the context menu.
  • In the Reference Manager, select Solution and then the project you want to write tests for. Then press Add and then Close.

You can now write your tests, using the usual Assert syntax. Here is a simple example.

01.[TestClass]
02.public class UnitTest1
03.{
04.    [TestMethod]       
05.    public void TestAlwaysPass()
06.    {
07.        const string expected = "Any text";
08.        var myClass = new ClassLibrary1.Class1(expected);
09.
10.        Assert.AreEqual(expected, myClass.Parameter);
11.    }
12.
13.    [TestMethod]
14.    public void TestAlwaysFail()
15.    {
16.        const string expected = "Any text";
17.        var myClass = new ClassLibrary1.Class1(expected);
18.
19.        const string notExpected = "Another text";
20.        Assert.AreEqual(notExpected, myClass.Parameter);
21.    }
22.}

Running the unit tests

To run the unit tests you just wrote, follow the steps:

  • Select the menu View / Other Windows / Unit Test Explorer.

Build your application. You should now see the unit tests you wrote in the explorer window.

Press Run All to run all the unit tests.

Hopefully this quick tip will be helpful!

Cheers

Laurent

May 27, 2011

Mango Update – Silverlight Box Scrolling

We’ve been lucky enough to have access to phones with early versions of Mango installed for a little while now. We will continue to report on key improvements and impressions of the update. This post will present some of our findings regarding Silverlight Box Scrolling.

One  major improvements in performance in Mango for Windows Phone 7 is the Silverlight ListBox scrolling. This was often mentioned as a major pain point in many applications (John Zolezzi can attest how many hours were spent improving the scrolling in the Twitter application.)

Mango is solving the Silverlight ListBox Scrolling issue in a few ways:

  • Pictures are now decoded on a background thread (this had to be implemented manually in previous versions.)
  • User input is now executed on a background thread, which means that if an animation is running while a user interacts with the phone, the animation will not skip frames.

There are also other improvements to make the scroll action better. A side by side comparison using our Twitter application can be seen here.

The nice thing is that we do not need to do anything to get those improvements, they will be available to all pre-mango applications automatically.