Creating compelling user interfaces for embedded devices

Let’s get started with a disclaimer, I’m a developer, I write code, that’s what I do, that’s what I’m good at – that means that my user interface design skills are somewhat lacking – I do a reasonable job of building forms based user interface for tools (CEFileWiz being an example) but that’s about as far as UI design/development goes for me. I’m a whizz at building operating system images, building COM objects, device drivers, native code web services etc… most of this you would consider to be plumbing, something that the user typically doesn’t (and shouldn’t) see.

When MFC (Microsoft Foundation Classes) shipped with support for CDialog and CFormView I was super happy, generating (some form of) application user interface became simple, I could drag controls from a toolbox onto a blank form and then “code behind” the controls. A very similar developer experience exists for C#/VB WinForms development in the managed world today.

If I needed to have a “fancy” user interface then that typically required some form of control subclassing and handling the paint message for the control by hand, this means that all of the user interface is really code driven, or to put it another way, the UI is “developer driven”. Changing the way the user interface looked required changes to code. From a Win32 C/C++ developers perspective all user interface elements are completely code driven. If you need some controls in the client area of your applications window then you need to create these by hand (CreateWindow), you need to place these by pixel coordinate, and subclass as appropriate to give the look and feel that makes sense for your device. In some cases controls may need to be animated, a drop down menu that scrolls open for example. Coding an animated drop down list would require creating a timer or thread and animating the control on each “tick” – that can be a lot of work, and even more work if the UI needs to change at some point in the future.

If we look at the desktop UI development experience (Windows Presentation Foundation for example) an application is really built by two groups of people, “Designers” and “Developers”. The designer/developer gets to focus on the work that they are good at and each are cleanly separated from each other – The designer only needs to care about the user interface look and feel and doesn’t care about the code behind the user experience. Animation, timelines, shading, fonts, images are all taken care of by the designer using tools like Microsoft Expression Blend. The developer then only focuses on writing the code behind the user experience and doesn’t need to care about what the UI looks like or even how the UI is implemented – the code in this case could be loading data sets to be displayed in the UI, or talking to web services, calling operating system APIs. Note that the developer doesn’t directly get involved in “how” the data is actually displayed to the user, but is involved in how the data is dealt with in the application. The developer is really focused on the plumbing, not on the UI. The link between designer/developer is XAML (eXtensible Application Markup Language) and Expression Blend (for UI) and Visual Studio (for the developer).

You could imagine that having a similar designer/developer story for building compelling user experiences for Windows Embedded CE devices would be awesome. This week, Kevin Dallas, General Manager for the Windows Embedded Business is showing a keynote demo at Computex, this demo shows the types of user experiences that could be build by decoupling the designer and developer experiences.

Since you are probably not at Computex we’ve recorded a video of the demo, and a brief interview with one of the Program Managers and Developers in the Windows Embedded CE Shell team that focus on applications and user experience.


User Interface Technologies for Windows Embedded CE

- Mike

Comments (8)
  1. Here's an interesting look at how User interfaces (or user experiences) come to fruition, and how

  2. Der derzeit wohl am häufigsten geäußerte Wunsch von Kunden, die Windows Embedded CE einsetzen, lautet:

  3. Der derzeit wohl am häufigsten geäußerte Wunsch von Kunden, die Windows Embedded CE einsetzen, lautet

  4. John says:

    Unfortuntately I can not view the video here at work, but I look forward to watching it at home. (If I am mis-informed then I guess you can safely ignore the following…)

    It is disappointing that this wound up being built on top of IE. The Silverlight runtime deserves to exist outside of the browser (the Moonlight people have this right), escpecially on embedded devices.

    It wasn’t until January of this year that the CE team finally shook out a bunch of issues with IE 6 on the device ("This update addresses a number of Internet Explorer issues.", This was literally *years* after CE started using IE 6.

    Here’s hoping there are no new problems introduced in the new browser version (as this would severely limit the usefulness of this technology). Restarting the browser because of memory usage, etc. is something people are willing to live with even on the desktop, but I doubt this is the case for a phone’s primary UI.

  5. mikehall says:


    You should watch the video 🙂

    – Mike

  6. John says:

    Very cool WPF-looking stuff, though not much explanation of the technology behind things apart from not being sandboxed (sounds promising).

    Looking forward to more info about what’s under the hood.

  7. Timothy says:

    What should we be keeping and eye out for when this eventually gets released?  WPF for Windows CE?  I’m really excited to try this out in a WinCE image.

Comments are closed.

Skip to main content