Article Preview

COLUMN

Integumentary Customization, Part II

Using "Skins" in REALbasic Applications

Issue: 1.5 (April/May 2003)
Author: Toby Rush
Author Bio: Toby Rush is a music instructor, consultant, freelance programmer, web designer, husband, and dad in Greeley, Colorado.
Article Description: No description available.
Article Length (in bytes): 10,213
Starting Page Number: 44
Article Number: 1524
Resource File(s):

1524.zip Updated: 2013-03-10 14:55:29

Related Link(s): None

Excerpt of article text...

In the last column, we discussed four different levels of implementing "skins" -- customizable interfaces that allow a user to control the look and feel of a program. In this column, we're going to talk about how to set up a skin implementation in a way that makes it easy to design skins, and we'll dive into creating a skin implementation in a REALbasic program.

Given the levels of implementation we talked about last time--and the understanding that a program of this type necessarily involves handing some control of interface design to the skin designer--we can see that different types of implementations have different ways of reconciling the "skinning vs. good interface design" issue. A level I implementation is fairly static, and while the skin designer can impact the aesthetics of the program, the remainder of the interface (spacing, layout, type of controls) are unchanged. The other three levels are far more dangerous from an interface design perspective, since the skin designer is given free rein to replace well-designed controls with those that may be more aesthetically pleasing but less efficient or intuitive for the user.

The flexibility of a level IV implementation seems like it would be the most problematic in this regard, but in fact it has an interesting benefit. Since the skin designer may choose from a number of controls to construct the interface, the programmer can provide instances of the standard toolbox controls as well as custom controls which accomplish the same task but provide more design flexibility. If the standard toolbox controls are present as options, the undiscriminating skin designer will use these since they require less effort to implement. Should the designer wish to take the time to design a custom control, the capability to do so is provided.

In this way, we, as application designers, are playing the same role as the designers of the Macintosh interface: we are telling the skin designer that she may create her own custom controls if she wants, but it will require less time and effort on her part to use the standard controls we provide for her. If one of the options for the skin designer is a custom button which allows for different mouseDown, mouseUp and mouseOver pictures, the control template can be designed to enforce the "action on mouseUp" paradigm which pervades the Macintosh interface.

Making your Implementation Approachable for Skin Designers

When implementing skins in an application, a programmer must decide on what level of programming or design will be required to design skins for the program. Generally, a low level of required expertise is best, as it allows more people to create skins and increases the number of skins available for users who do not design skins. Unfortunately, a simple method of creating skins is not always possible, especially for higher-numbered levels of implementation. In this case, the programmer must strike a balance between simplicity and flexibility: an overly simplistic method will not provide for flexibility, but a method that requires high-level programming concepts will not be accessible to most people.

...End of Excerpt. Please purchase the magazine to read the full article.