About this Website

Community Technology Preview (CTP)

This release contains CTP versions of the following controls:

• MedicationsListView

As changes may be made between CTP and release versions, no official support or statement of quality can be offered for CTP controls prior to the development and distribution of release versions.

Contact Us

We welcome feedback on the Design Guidance, the controls and samples and all other aspects of this Website. Please use the feedback facilities on our CodePlex pages to let us know what you think.

Change Record – Guidance and Controls

The Change Record acts as a mechanism for tracking the availability of the Design Guidance documents, Controls and Samples for the current Release of the Microsoft Health Common User Interface.

Accessibility

This Website, the Design Guidance and the Toolkit controls and samples have been designed with consideration to usability and accessibility for users who utilize alternative methods of interacting with computer systems.

Testing was performed with Version 8.0 of the JAWS® for Windows screen reader. The tooltips for the Toolkit controls appear only on first focus and are not read by the screen reader.

The Design Guidance documents are provided in PDF format and consist of sequential pages starting with a title page and a table of contents.

The following Web pages use Silverlight 2 Beta 2 technology and, therefore, have limited accessibility functionality:

• Showcase – Testimonials
• Showcase – Demonstrators
• Roadmap – Schedule
• Microsoft Health CUI Control pages that include embedded Silverlight examples

Known Issues

• Browser Compatibility
  • This Website has been designed to work optimally on Internet Explorer and Firefox browsers running on Windows (with the current exception of Firefox 3). If Firefox 3 or other browsers, such as Safari, are used, certain elements of this Website may not display or operate correctly, such as the demonstrators and controls.
• CSS Styling
  • The ASP.NET versions of the controls have been designed to work with Cascading Style Sheets so the controls can easily fit in with ISV applications. Many styles for the controls are exposed, allowing developers to alter them without any constraints. If the controls are styled outside the parameters set by the Design Guidance, they can no longer be considered to conform to the Microsoft Health CUI Design Guidance.
• DateInputBox Can Throw an Exception When Used on Multiple Threads
  • If multiple threads are using DateInputBox, an 'An entry with the same key already exists' exception is sometimes thrown. This appears to be a threading issue with the ASP.NET AJAX Control Toolkit.
• Namespaces
  • We are currently changing our root namespace to Microsoft.Cui. Controls under the previous namespace will be updated as they are revisited in accordance with the roadmap.
• Some Controls Cannot Be Created Dynamically Using Client-Side Code
  • The DateInputBox, TimespanInputBox, MonthCalendar and TimeInputBox controls can be instantiated through JavaScript on the client PC. Implementing this functionality for other controls may be planned for a future release.
• Telephone Number Format in PatientBanner Guidance and Control Does Not Match Format in Design Guidance for Telephone Number Input and Display
  • The Design Guidance for Telephone Number Input and Display requires area codes to be enclosed in brackets, but the Design Guidance for Patient Banner and the PatientBanner control do not currently use this format. This will be resolved in a future release.
• ViewState Security Best Practice
  • You should avoid storing sensitive data in ViewState. If you need to manage sensitive data, maintain it on the server in, for example, a session state. If your ViewState does contain sensitive data, you should perform encryption. For further information, see How To: Configure MachineKey in ASP.NET 2.0.
• Web.config Configuration
  • There are different versions of the AJAX Control Toolkit JavaScript libraries for development and production. In development parameter validation is desirable to ensure that errors are detected in code. Deployed applications normally omit this checking; this is done by setting the flag <compilation debug="false" /> in the web.config file for an application. Failure to do this may result in performance problems in the client.
• Web.config Security Best Practice
  • You should set the customErrors mode tag of Web.config to "off" to prevent detailed errors returning to the client. Microsoft recommend you follow the best practice guidance given in the Exception Management section of Security Practices: ASP.NET 2.0 Security Practices at a Glance.