scripts: how to handle in device independent manner (8)
the "Janus" question: looking ahead, building forward, but
ensuring backwards compatibility (several votes for 1;
several for 8 or higher) -- problems: cost and difficulty of
upgrading; majority of users may be using cast off
equipment; ubiquity of newer technology
making older pages work on newer devices; trying to
interpret old content; anything already written for web is old;
expect authors to do more work than users (objection:
developers don't want to change content manually) --
important, but not easy-to-solve (9)
dialogs as basis for altering services (10) -- subset of
concentrating on function, rather than UI
most appropriate format to store content? transformation
easier from HTML document than XML document currently
because HTML has standard consistent structure; common
framework; proper use of schemas, RDF, etc. documenting
why XML app structured as it is in order to make
transformation easier and more dependable (9.5)
style in alternate modalities; getting authors to use @media
rules
browser sniffing/automatic discovering of UA (handling
browsers that don't support CC/PP) -- where and when? can
the user switch? can the user apply more than one
simultaneously (7)
should the client show something to server, or have server
discover client's capabilities (SMIL switch example) -- if client
is thick, might be smarter than faster thin client;
(part of preceding)
bandwidth issues/processing issues -- what is in the middle
between the client and the server? or, can you do it
anywhere through proxies; what about the middle? what
about transformation tool? does CC/PP allow you to provide
information about network; should device be able to sniff
server and work out what it wants; existing approach may
not be sufficient
(part of preceding)
for mobile devices one of the most important issues is the
business of describing issues; isn't standard way to do it in
WAP world; need to develop classes of devices so authors
know what to do; device classes and their descriptions
where to store content?
ways to standardize description; better structured
descriptions (this page has 3 frames 120 links, etc current) --
high level descriptions so people know what to expect when
content delivered -- methodology that allows description of
environment before delivered; levels of detail and
summarization; what is here, how is it presented; what else
is available; problems with ALT and its misuse (9)
don't just concentrate on markup, but interaction, as well
separating rendering and control from function (10):
A) separating form from function;
B) separating UI from function
C) separating interface from function
then can layover anything you like, based on capabilities and
preferences
bottom up rather than trickle down
SUMMATION: overarching principle; many others can be
subsumed under this
moving responsibility for backwards compatibility from author
to UA -- don't put onus on author (needs to understand and
learn too much; reauthored on each page, rather than
carried through)
standard interaction
multiple channels from single source or make choices as
traversing -- switch between modalities (hand held device
user might want to switch from visual to vocal display
depending on content); multi-modal (again, the "switch"
analogy)
how to get authors to focus on function? (7)
how to make author's intent explicit, rather than implied (8)