é	RCML			H
	Program management	Kiran Raj	created	6/30/99
	Development	Felix GTi Andrew	last updated	7/8/1999
	Test	Matt Desai
	Usability
	Design
	user assistance / documentation
	international / localization

Summary

RCML is a new windows resource file format developed to address significant needs from different functional areas across product groups. By allowing easier access to Win32 UI features than current RC files, RCML solves many problems with existing dialog boxes, especially with respect to localization and UI design. Simply changing the current RC format to accommodate different requests from a wide variety of groups would be a compatibility nightmare, which RCML does not have.

Design goals and justification

RCML is designed to address the needs of a group of customers. By allowing a large degree of flexibility in the file format, RCML does not need to solve every problem or nuisance. It allows our customers to add any functionality or feature that they see fit, thus decreasing the amount of specific work we need to do to ship a product. RCML currently focuses on the needs of the following functional areas:

· Localization

· Product Design

· Win32 Developers

· Windows UI Text Team

· MSAA (Accessibility)

Localization:

· Currently over $105 million is spent on fixing cosmetic UI bugs[1]. RCML should reduce the amount of layout changes a localizers needs to make by automatically resizing the dialog and intelligently layout the controls to meet the specific requirements of the culture/locale.

· Allow commenting in the resource file. This will allow developers to tell the localizers what should and should not be localized. For example, a file open control containing the file mask “.doc” should not be localized since it would obviously cause large errors.

· Provide the localization team with a set of XML tags that can be used to provide relevant information.

o We want to support the GML specification developed by LocStudio

Product Design:

· Provide an easy way to layout a dialog with pixel-perfect precision

· Allow the designers to make simple changes to the dialog without having to make code changes. This will cut down on the amount of needless communication between the developers and the designers. This way the developer does not need to implement the ideas of a designer, the designer can do it themselves.

· By keeping the RCML files external to the executable file, a designer can edit the RCML file without having to wait for the next build to see their changes. In fact, this also allows a large degree of flexibility in terms of having multiple people edit a dialog. Instead of having to check code in, all the designers can just work from one XML file.

· An XML format will allow the designer to easily read the RCML file instead of having to search through complicated code

Win32 Developers

· A developer should be able to easily convert an existing Win32 application over to RCML dialog with only minor code changes.

· A generator will be provided to easily convert existing Win32 dialogs into RCML. The new generated file can be edited easily by even a text editor like notepad, to take full advantage of all the new features that RCML provides

· Decrease the amount of platform specific code the developer has to write. Since RCML is based on a portable XML format, the developer does not really need to worry about the “under the covers” work that goes on. This means that a developer can easily port the dialogs over to a new platform with having to worry about changing their code.

Windows UI Text Team:

· Should be able to edit a dialog and show the changes that need to be made. Example:

RCML needs to replicate something like this. We will provide an easy way to view proposed changes. That way many people can look at it before it becomes changed. Also this will allow people to see the old version next to the new version and compare the two.

This will require some type of layering functionality. Maybe even overlay two dialogs on top of each other, with one being totally transparent except for the text.

scenarios

Darren the Developer is laying out a dialog according to Debbie the Designer’s specifications. After placing the sixteenth control he is getting tired of figuring out what x and y coordinate to place the controls in order to preserve a nice UI layout. After he is finally done, Debbie calls and asks to change the layout by a few pixels, in order to improve the design. The infuriates Darren because now he has to go back and recalculate all the absolute positions again. Not anymore. Since RCML uses relative positioning, Darren can change the x, y position of a single control and the others will move accordingly.

Larry the localizer is spending 80% of his time fixing cosmetic UI bugs that are a result of strings in other countries being longer than the U.S. equivalent. Thus he must resize all the controls and relayout all his dialogs. However, since RCML knows when text is being clipped, it will automatically resize the controls to adjust for text clipping. This makes Larry happy because now he can do the other fun things that localizers do.

Andrew the RCML developer is swamped with feature and functionality requests. She cannot handle them and it is starting to drive her up a wall. Luckily, she can always have people do their own features if they really want it. Since RCML is XML based, we can provide groups their own namespaces and access to the XML parser’s header files. This will allow them to implement their own functionality and features in case we cannot get to it. It is a good example of the extensible nature of XML and thus RCML

design

The contents of a list box will be able to be specified in the RCML file directly. A sample portion of an RCML file looks like this:

<List>

this is item one

this is item two

this is item three

</List>

This list box will come out looking something like this:

For a Combobox you will specify the contents directly in the RCML file also. The syntax will be the same as the list box. Anything separated by carriage returns between the open and end tags of a list or combobox will be treated as data items.

We will introduce fonts and colors on a per control basis. That means that each control can have its own font and color, thus it does not need to inherit these characteristics from the dialog itself. We will, however, still use DLU’s to do the layout. DLU’s are calculated by the dialogs font.

We will allow controls to be relatively positioned to one another. This means that you do not need to specify absolute positions for each control. You specify relative positioning in the follow manner:

Specify relative=”yes” or relative=”id#”. Relative is an attribute of all controls.

If specify relative=”yes”, this means that you will be relative to the previous control in the RCML file. This provides easy readability for the RCML file. However, you should be careful not to assume that since two controls are adjacent to each other on a dialog, that they are adjacent to each other in the RCML file.

If specify relative=”id#” than the control will be relative to whatever control is specified by the id#.

It is necessary to supply a Location Tag whenever you specify either relative=”yes” or relative=”id#”. Without the Location tag, the control will not be relative to any control and will be place at x=0, y=0.

The location tag specifies where the control lives on a dialog. Thus if you have <Location x=13 y=15> the control’s upper left corner will be placed at 13,15. However, if you specify both the location tag and the x and y attributes, the location tag will override the x, y attributes.

If a control is specified to be relative to another control, the location tag takes on a little bit different meaning. If control A is relative to control b, control A must have a location tag defined. The location is calculated from control A to control B. Thus if you specify:

Control A’s upper left corner will be x=150 y=150

Localization

Font/Color

No issues

Accessibility

We will be working closely with MSAA in order to provide full accessability support in RCML. In fact MSAA will have their own namespace in which to add any features/functionalities they desire. Currently they are busy with the MSAA 1.5 release and probably will not be able to spend a significant amount of time on RCML until December 1999.

security

There are no real security issues at this time.

Higher Resolution/DPI Monitors

There shouldn’t be any unusual setup issues.

cuts

None at the current time.

history

date	changes made	program manager
6/30/99	spec created	Kiran Raj