Some ideas of mine:
1. complexity specific UI
Each description should have at least one totally generic UI - the absolute fallback. this one might be pretty basic.
The technical requirements of the display may be very different (e.g. two-line text display, full-screen graphic display, etc.)
May result in an attribute for display a UI structure is targetted for.
2. platform specific UI
It should be possible to define additional UI structures for special platforms.
I don't think it's possible to define something, which can be used under Windows XP and Mac OS-X, not even Mac OS-9 and OS-X. A driver would have to know an awful lot to filter certain features out depending on the actual platforms and as result of that - if possible at all - filtering some parts of the dialog may look pretty orphaned.
This might be handled by an attribute Platform with a predefined list of entries (e.g. Generic, Win9X, WinXP, OS9, OSX, KDE, etc.). Fall back to Generic in case there is no structure for the platform the actual driver is working on. Not thoroughly thought of.
3. locale specific UI
might be good to have some locale specific structures.
just thinking of different strings lengths or right-to-left issues.
would result in an attribute Locale with a predefined list of entries.
it is my personal belief that the information how a feature should be used in one or more user interfaces should not be stored with that feature. the driver would not expect to read it that way and it would be rather confusing to read and get the picture.
Instead I think of multiple UI structures with references to features as needed.
Regards
Norbert
Norbert Schade
69 Prescott Drive
North Chelmsford, MA 01863
978-251-1017
norbertschade@attbi.com
This archive was generated by hypermail 2b29 : Thu Mar 27 2003 - 13:04:05 EST