Skinning involves an entity reformatting a bundle of functionality to make the experience of that functionality reflect it’s sense of self. When the entity is a simple one like a single human user, the task is a simple one as well. When the entity is a complex one with different parts that demand representation in the interface, things can get complicated.
I) A skinning system needs to account for different user spaces
- Institutional Gateway – traditionally has family resemblance to other institutional spaces. May have to obey institutional web style guides (logos, palettes, fonts)
- Personal spaces – can have an a) institutional branding as 1 above, b) a sub-institutional branding depending on affiliation (College of Life Sciences branding) or c) self selection (“cool dude” branding) – these are in descending order of probability, ascending order of complexity (and narcissism).
Personal spaces are any space that is restricted to just one user: spaces that index one of the following: 1) other spaces, 2) activity that takes place in other spaces, 3) spaceless activity that is meaningful to the user because of user’s relationship to that activity. Also any space where the user changes the dynamics of her relationship to the system: ie – changing one’s profile, notification options, etc.
- Shared spaces
Any space that is not private to one user *and* needs branding by virtue of what the space functionally is. Can have 1) institutional branding, 2) affiliation (Life Sciences) branding, 3) cascading affiliation (Life Sciences > Entomology) branding; 4) space type specific branding [a) t&l, b) research, c) club, ad hoc]. There is a cascade involved in that branding closest to the root determines branding unless lower nodes specifically override parts or all of the branding elements. How the cascade works in practice is left to the institution’s best judgement and restraint – but the ability needs to be there, it is important to the sense of self of the institution and it’s subunits.
II) A skinning system needs to account for different functional locales
A given functionality has unique rendering needs that it takes care of itself. All non specific needs are taken care of by skinning system. Widget A is very unique and has unique needs, but the UI idioms it shares with the rest are shared (Save button is blue and flush left, for example)
III) A skinning system needs to be easy to customize
- enable and encourage customizations via a canonical mechanism, allow customizations via other means (but not facilitate them or even account for them, an institution should be aware of the risks involved)
- common locales and procedures to customize should be provided, named appropriately, with a clear and documented cascade.
V) A skinning system needs to hint at what elements can best be skinned and to what degree it is recommended they be skinned. The institution can do as it pleases – but probably would appreciate the help and guidance.
VI) A skinning system needs to account for special user needs
A user should be able to override any and all skin definitions because of low vision, poor eyesight, color blindness, other factors. This has two facets: the skinning system should not trump user stylesheets (if that is how the system has chosen to deal with this issue), or the skinning system needs to provide a set of alternates, and the user choice of the system alternate is part of the user’s preferences.