Fine-tuning Embedded Device Experiences
**Updated 3/26/09 with preface
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
An embedded device has to look like an embedded device! This means that the system and its user interface needs to be optimized according to the device purpose and should not behave like a PC. In some cases, the systems should not even give a hint about the platform they are running on. This does not only lead to a better usability experience, but also can be the first security barrier if systems are designed to operate in places where neither network nor physical access can be controlled very well. Gaming consoles, for example, are very often a target for fraud and designers try to set up many intrusion barriers to guard against this.
Tuning the boot sequence
A good place to start fine-tuning your device is with the boot sequence. It is quite easy to turn off the Windows boot logo by checking the “Do not display GUI boot screens” in the Other Settings area of the configuration’s “Settings” node.
This adds a /noguiboot option to the corresponding OS entry in the boot.ini and turns off the Windows XP boot logo, as well as the progress bar, and replaces them with a black screen.
To improve this not-so-thrilling experience, adding a custom boot logo is a great idea and can be accomplished quite simply by adding an additional /bootlogo switch to the same boot.ini entry.
Here is an example:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”Microsoft Windows Embedded Standard” /fastdetect /noexecute=AlwaysOff /noguiboot /bootlogo
The boot logo should be provided as a 4 Bit color depth bitmap placed in the Windows folder. It needs to be called “boot.bmp” and should have a size of 640 x 480 pixels.
Automatic logon
Especially if you think of using a custom shell, an automatic logon certainly provides the best user experience. This functionality is provided a component of the same name – Automatic Logon. It requires Username, Password and Domain values, and stores these settings in the registry.
Be aware that the password is not encrypted, when stored in the registry. Therefore, automatic logon can be considered a security risk and should never be used for administrative or power user accounts.
Avoiding unwanted welcome screens
If there are other, unwanted screens that display during the logon sequence, the Windows Logon component is the place to turn them off, by un-checking the related boxes in the components settings dialog.
Using a custom shell
If an OEM wants to provide a very good user experience, a custom shell is the way to do this. Any application can be a shell, but not any application is a good shell. There is a great article by Mike Hall in the MSDN library that explains how to implement a custom shell.
The golden rule regarding shells is to keep the UI simple enough to make it intuitively usable, but powerful enough to satisfy the most complex task of the application. This is not an easy mission, but it can be achieved by bringing simple and often-used pieces of functionality to the front, while putting the more complex and little- used functionality or “advanced” menu items at the back. Complex tasks should still be reachable, but should not clutter the UI and make simple tasks hard to understand. Additionally, it is a great approach to have different shells for different users, which provides every user just the UI needed.
Turn off status messages
After customizing the boot process, disabling welcome screens and adding a custom shell, there are only a few items left that remind an observant user that the embedded device is actually running a Windows Embedded Standard 2009 operating system.
The most prominent items left are status messages that appear during boot and while shutting down a system. They can be turned off using this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\DisableStatusMessages
Type: REG_DWORD
Value: 1
It is a good idea to disable the status messages only at the end of the development period. If disabled earlier, it may produce an uneasy feeling from a system developer’s perspective due to the lack of feedback.
Background colors
The final tasks are setting the right background colors to match the colors of the images. This enables smooth transitions between the different stages and should leave the system with only one last, unavoidable flicker of the screen, when the VGA boot mode hands over to the graphics adapter.
Alexander Wechsler
Wechsler Consulting