Why Windows UI Matters: Part 2

This post comes into 2 parts:

1. Typography
2. Colors and Tiles (this one)

Following my first post about Typography in Windows 8, I would like in this post to talk more about colors and the tile concept in Windows Phone and Windows 8.x.

If you create a new account on your Windows 8.x, you will get the following start screen (on a 27")

First remark, it looks empty. We know the problem for a long time: this was designed for smaller form factors - Windows Phone but unfortunately we got it as-is on desktop.

Second remark, we also start to get a glimpse of the color problem with the Metro/Tile concept: It looks flashy.

Why Windows UI Matters: Part 1

This post comes into 2 parts:

1. Typography (this one)
2. Colors and Tiles

You have probably seen some leaks of screenshots of the next Windows and while this could be - or not - the technical preview that is going to be released later this month for enterprise preview, I have been a bit shocked by the poorness of the UI visuals. Lots of commentators are saying that Microsoft is usually tweaking the OS UI few months before releasing to the public, fine, but I hope this technical preview will unveil a better sneak peak of next Windows UI. If it does not, that's really an unfortunate move, because all these images are already generating misunderstanding.

We are lots around waiting and watching for the next Windows. We are not just waiting for the desktop to come back, we are waiting for something that will make us happy and excited! I'm not a UI designer, I'm just a developer using Windows, but I love good visuals and I'm concerned by the OS UI that accompanies me all along more than 12 hours per day!

I won't comment more on the next Windows OS, but I would like to take the opportunity to share some of the unpleasant things I'm feeling about for the past years with the Windows Metro UI era.

Packages vNext: Power-up our .NET Builds

In the sequel of my previous post "Managing multiple platforms in Visual Studio", having done lots of cross-platform development in .NET in the recent years both at work or for SharpDX (with platform specific assemblies, PCL, assemblies using native compiled code... etc) while trying to trick and abuse nuget and msbuild as much as possible, I have realized that in order to provide a smooth integration of "build packages", this require to be more tightly integrated at the core of a build system.

Unfortunately, we only have today a patchwork of this integration, still quite incomplete and far from what it could be, and this is hurting a lot our development process. We really need something brand new here: we have lots of inputs, usecases, and while it is of course not possible to cover every aspects of all build workflows, It is certainly possible to address most of the common issues we are facing today. Let's try to figure out where this could lead!

Micro-benchmarking .NET Native and RyuJit

[Disclaimer] As both RyuJIT and  .NET Native are improving a lot between their updates/previews, results of benchmarks in this post may no longer be relevant. Benchmarks were ran with the following versions:

• RyuJIT CTP4 
• .NET Native developer preview 2 

While .NET JIT is performing quite well on Windows, it is still behind a fully optimized C++ program, though an efficient compiled program is not only about code generation but also memory management and data locality, the .NET Team has recently introduced two new technologies that might help for the code gen part: The introduction of  .NET Native, an offline .NET compiler (similar to ngen, but using the backend optimizer that is used by the C++ compiler) and the next generation of .NET JIT called "RyuJit". In this post I would like to present the results of some micro-benchmarks that are roughly evaluating some performance benefits of these two new technologies.

First of all, you may have already read about a few benchmarks results available around about RyuJit and .NET Native, here is a non-exhaustive list I have found (if you have more pointers, let me know!):

• A first look at RyuJIT CTP3 and SIMD (SSE2) support for .NET by Frank Niemeyer
• Lies, damn lies and benchmarks by Kevin Frei
• .NET Native Performance by Sasha Goldstein

Managing multiple platforms in Visual Studio

Who has not struggled to correctly manage multiple platform configurations in Visual Studio without ending to edit a solution file or tweak some msbuild files by hand? Recently, I decided to cleanup the antique SharpDX.sln in SharpDX that was starting to be a bit fat and not easy to manage. The build is not extremely bizarre there, but as it needs to cover the combinations of NetPlatform x OSPlatform x DirectXVersion x Debug/Release with around 40 projects (without the samples), it is an interesting case of study. It turns out that modifying the solution to make a clean multi-platform build was impossible without hacking msbuild in order to circumvent unfortunate designs found in Microsoft msbuild files (and later to found at work in Xamarin build files as well). In this post, we will go through the gotchas found, and we will see also why Visual Studio should really improve the configuration manager if they want to improve our developers experience.