Breakout Session Summary Transparencies
Needs of authors and users
W3C Workshop on Web Device Independent Authoring
Tuesday 3 October 2000
- Ability to write an application, that is independent of device modalities
- what are common interactions needed to be solved?
- Specialise for target device or modality?
- How does the developer decide between #1 & #2?
- How does the developer manage content written for multiple modalities?
- How do you package content into an application?
- Define / identify application components
- i.e. application type definition
- Developers need to validate the application is device independent and verify it
- Access to same application where modality makes sense
- Difficult modalities require higher usability to be accepted
- value must be greater than cost
- Users expect great experience regardless of device / modality that they select
- Consistent MMI [Man-Machine Interface] between local application and Internet experience on a single device
- Share application state between different devices
- Expect to be able to personalise experience on different modalities
- Is 'authoring once' a requirement?
- Ability to author different views from one source
- without getting bogged down with individual mappings
- Education / Guidance
- Equivalent in function but can be a different experience
- Access to all content
- even if it is not useful to all
- Notification when 'generic' content (not tailored or transformed)?
- customised content may be distrusted
- Tool support!
- important to ensure what we come up with gets used
- Standard / reference process model from creation to consumption
- Explicit interaction model. UML? State Machine?
- prospects for automation a concern, but must consider
- Repository for best practices
- Task centered (intention paramount indication)
- Dreamweaver objects
Used a process of brainstorming onto yellow stickies, then grouping.
Consistency and good structure
- Way too many variants
- Consistency across apps on same device (consistent user experience)
- Ability to define behaviour not just layout
- UI consistency e.g. standard style sheets
- Make markup closer to application model
- Good structure facilities translation to other languages
- Components (building blocks e.g. date picker)
- More specific semantics for UI – avoid overloading
- Too early to standardise interaction model
Evaluation and repair
- Evaluation and repair tools
- Should consider all issues at once
- don’t html validate, then access validate, since one stage may ruin the work of others
- Black box test cases
- Merged guidelines for authoring & tools
- Contexts, sharing across devices
- Suspend on one device, resume on another
- Shouldn’t require a special purpose authoring tool
- Make smarter authoring tools
- Support multiple authors & workflow
- Smarter UA reducing burden on authors
- Multimodal authoring tools - how?