ABSTRACT
However, there are a few design models, in certain cases accompanied with incomplete suggested design patterns, on what actually constitutes abstract interaction objects and their particular so ware properties. Past work in the context of abstract interaction objects (Blattner et al., 1992; Duke and Harrison, 1993; Duke et al., 1994; Foley and Van Dam, 1983; Savidis and Stephanidis, 1998) refl ects the need to defi ne appropriate programming versions relieved from physical interaction properties such as color, font size, border, or audio feedback, and only refl ecting an abstract behavioral role (i.e., why an object is needed). is defi nition makes a clear distinction of abstract interaction objects from multiplatform interaction objects, the latter merely forming generalizations of similar graphical interaction objects met in diff erent toolkits, through standardized application programming interfaces (APIs). e so ware API of generalized objects is easily designed in a way off ering fi negrained control to the physical aspects of interaction objects, since the target object classes exhibit very similar graphical properties. For instance, a multiplatform “push button” off ers attributes like position, color, label, border width, and so on, since all graphical interface toolkits normally off er programming control of such push-button object attributes.
