Talk:Vision Statement
From html4all
Contents |
What is a Vision Statement?
A vision statement helps outline what we want HTML to be. It answers the question "Where do we want to go?” It
- is a vivid description of desired outcomes that inspires, energize and helps create a mental picture of our target.
- concentrates on the future.
- articulates dreams and hopes.
- is a source of inspiration.
- remind us of what we are trying to build.
~ Laura
First Draft Mockup
Our vision is for HTML to be a language that
- Communicates medium-neutral semantics. Presentational elements have no place in it.
- Must allow for explicit associations of related pieces of content when this association aids conveying content and content relationships to users.
First Draft Feedback and Suggestions
- Jason: I would suggest adding "the language or languages in which the page is written" as well, to embrace internationalization as an integral part of this vision.
- First Draft Survey Results
- Gez's addition: "Wider range of elements with roles, states, and other properties that can be communicated effectively to assistive technologies for web application."
- Debi's addition: "HTML should be capable of providing equivalent information to any browser user, regardless of platform or processing capacity, through the ability to universally provide alternative content for users of less powerful equipment or assistive technology."
- Leif's addition: "HTML should focus offer necessary semantics to support more kinds of texts, such as poetry, law, plays, religious texts (bible texts) etc."
- Leif's addition: "language that allow for _implicit_ assocations of related pieces, when this association aides conveying the content and content relationships to users."
- Leif's comment regarding removal of the B-element
- Catherine's addition: "ensure that the future language be as inclusive as possible, that it not shut the door to future improvements with regards to accessibility and that it preserves actual gains that are relevant."
- Gregory's addition: "is fully interoperable, device-independent, internationalizable, and accessible. It should provide for a richer, more interactive user experience than HTML currently provides, which is consistent across platforms and specific user agents and which communicates bilaterally with third party assistive technologies."'
- Phil's addition: "add HTML is a document markup language rather than just 'a language'. since by so doing I am making a tacit statement concerning the purpose of the language (which is to communicate the semantics of a document such that it can be optimally rendered regardless of the medium into which the rendering takes place)."
- Phil's addition: "rich, meaningful and/or extensible, vocabulary..."
I began incorporating the feedback from first draft into the second draft mockup - Laura
Second Draft Mockup
Our vision is for HTML to be a document markup language that
- Is interoperable, device-independent, internationalizable, universal, and accessible.
- Provides accessibility advances with graceful migration, while preserving past gains that are relevant.
- Is accessible by design, but must allow for explicit associations of related pieces of content if this association aids in conveying content and content relationships to users, whenever implicit associations do not provide this functionality.
- Communicates semantics regardless of medium.
- Models the logical structure of information, not its appearance.
- Offers a rich, meaningful and/or extensible, vocabulary for marking up text.
- Includes all necessary elements and properties for web applications to effectively communicate to assistive technologies.
- Provides for a full, interactive user experience which is consistent across platforms and user agents and which communicates bilaterally with third party assistive technologies.
Second Draft Mockup Discussion
Maybe we should think of combining some of these?
Please share your thoughts and comments. Thanks! - LauraCarlson 06:21, 19 October 2007 (PDT)
Zara: Hi Laura, I think you have done a great job of including the various suggestions offered through the survey, in a synthesised manner. Here is my attempt at editing this latest mock-up:
Our vision is for HTML to be a markup language that:
- Is interoperable, device-independent, internationalizable, universal, and accessible by design.
- Provides accessibility advances with graceful migration, while preserving past gains that are relevant.
- Offers a rich, meaningful and/or extensible, vocabulary for marking up text.
- Allows for explicit associations of related pieces of content if this association aids in conveying content and content relationships to users, whenever implicit associations do not provide this functionality.
- Communicates semantics regardless of medium.
- Models the logical structure of information, not its appearance.
- Includes all necessary elements and properties for web applications to effectively communicate to assistive technologies.
- Provides for a full, interactive user experience which is consistent across platforms and user agents and which communicates bilaterally with third party assistive technologies.
A few explanations :
- I removed the word "document" from the title because I felt it was redundant and unnecessary. However, if this is wrong, please ignore that suggestion.
- I rearranged a few of the items just to try to kind of have a logical evolution of ideas that go from more general to more specific.
- I removed the "accessible by design" idea from the "explicit associations of related pieces of content blablabla" item and put the idea with the first item. I just thought it would fit better there as it seems like a more general idea and also made the explicit association item too wordy with too much stuff going on.
- I wonder about the 7th item, where it says "(...) for web applications to effectively communicate to assistive technologies". Do apps communicate to or rather with AT ?
Hope this is useful.
From Laura: Hi Cathrine,
Yes, This is very useful, indeed.
The reorganization is very logical and helps the flow. Excellent.
It was Phil's idea to add the words 'document markup language' and Gregory's/Gez's ideas to add the 6th and 7th bullet. Think we need their input to proceed. - LauraCarlson 08:49, 29 October 2007 (PDT)
From Gez: (regarding the last two bullet points)
"I'm basically saying the same as Gregory, except Gregory's version is worded much better worded. I would go with Gregory's version."
From Phil: "Google stats. suggest that "HTML" co-occurs with 'Markup language' at least ten times more frequently than it does with 'Document markup language'"
Suggested change from Debi: "..explicit associations of related pieces of content if this association aids in conveying CONTEXT and content relationships to users...'"
Third Draft Mockup
Our vision is for HTML to be a markup language that:
- Is interoperable, device-independent, internationalizable, universal, and accessible by design.
- Offers a rich, meaningful and extensible, vocabulary for marking up text.
- Allows for explicit associations of related pieces of content if this association aids in conveying context and content relationships to users, whenever implicit associations do not provide this functionality.
- Models the logical structure of information, not its appearance.
- Provides for a full, interactive user experience which is consistent across platforms and user agents and which communicates bilaterally with third party assistive technologies.
Third Draft Mockup Discussion
I tried to incorporate the latest founders comments. Please share your thoughts. Thanks! - Laura, 04:52, 1 November 2007 (PDT)
From Gez:
There are a couple of things I don't understand. For example, what does "graceful migration" mean? Also, the bullet about communicating semantics regardless of medium seems redundant, as medium is covered by device independence in the first bullet, and rich semantics are covered by nearly all the other bullet points.
From Laura: Hi Gez, Thanks so much for checking it.
"Graceful migration" is supposed to mean "orderly transition." If we are to work things out of the system, it must be because they are being replaced with something better, and via an orderly transition not just dropped (id/headers etc). Would this be better:
"Provides accessibility advances in an orderly manner, while preserving past gains that are relevant."
Can you think of a better way to say it? Or do you think we should just delete "graceful migration"? Is it too confusing?
I'll nuke the communicating semantics bullet. I agree it is redundant. Thanks for catching that. I've been wanting to stream line things and that helps. - Laura 17:55, 6 November 2007 (PST)
From Gez:
> "Graceful migration" is supposed to mean "orderly
transition." If we
> are to work things out of the system, it must be because they are
> being replaced with something better, and via an orderly transition
> not just dropped (id/headers etc).
Ah, I think I might understand it now. What was confusing me was reading the statement in relation to, "Our vision is for HTML to be a markup language that ...". I read the points that followed to be essential features of the language. Can you think of examples of accessibility features that might/have been dropped by the HTML working group that aren't covered by the other features listed?
> Would this be better:
> "Provides accessibility advances
in an orderly manner, while
> preserving past gains that are relevant."
Personally, I would still be thrown by that statement unless someone gave me an example of what it meant, but then I'm easily thrown.
> Can you think of a better way to say it? Or do you think we should
> just delete "graceful migration" part? Is it too confusing?
I can't think of a better way of saying it without re-phrasing the vision statement.
From Laura: Hi Gez,
If you are confused by it, others will be too. So I'll delete "graceful migration". Does it make sense now? Thank you! - Laura 04:47, 7 November 2007 (PST)
From Gez:
Yes, it does make sense now. I'm still not sure what it adds that isn't covered by the other bullet points. It's also the only point that isn't a desired feature of the language, but concerned with the process of constructing the specification, although I would understand it as it's currently worded without anyone having to explain it to me.
From Laura: Hi Catherine,
Do you think that we need the second bullet point in the Vision statement? It is:
- "Provides accessibility advances, while preserving past gains that are relevant."
That point was included in response to your comment on the last survey:
"ensure that the future language be as inclusive as possible, that it not shut the door to future improvements with regards to accessibility and that it preserves actual gains that are relevant."
Gez pointed out and I tend to agree that we may not need it.
> I'm still not sure what it adds that
> isn't covered by the other bullet points. It's also the only point
> that isn't a desired feature of the language, but concerned with
the
> process of constructing the specification, although I would understand
> it as it's currently worded without anyone having to explain it
to me.
It does seem to be a broader repeat of the fourth bullet:
- "Allows for explicit associations of related pieces of content if this association aids in conveying context and content relationships to users, whenever implicit associations do not provide this functionality."
Your thoughts? it would be good if we could trim the doc by a bullet if possible. The simpler and more coherent the better.
Thanks! - Laura 06:28, 7 November 2007 (PST)
From Catherine:
When I wrote that in the survey, it was not necessarily to have it explicitely included in the Vision Statement but more a question of ensuring that that idea came through. However, and when I say this, please keep in mind that I do not program for a living but only to save my life when necessary, I do not see how the other bullet item relates to my initial idea but to be honest, I find that this probably the item that is the least limpid, extremely technobabbly. Anyway, you guys are the experts and if you feel that the vision statement without explicitely stating the second bullet item takes it into account, I will of course defer to your judgement.
From Laura: Hi Catherine,
Hey, I'm no expert. Far, far from it. I agree it is the least technobabbly point. Maybe it is the one that non-techy people will relate to most. I'm much more inclined to leave it in now.
Gez what do you think?
From Gez: Hi Catherine and Laura,
I don't disagree with the point itself, but it's more concerned with the process than a language feature. When I read, "Our vision is for HTML to be a markup language that:", I was expecting the points to follow to be features of the language, rather than the process (that's how the topic came up, as I asked Laura what graceful migration meant). I don't have a problem with the point being kept as it is, but what about having another vision statement about process?
From Laura:
> I don't disagree with the point itself, but it's more concerned
with
> the process than a language feature. When I read, "Our vision
is for
> HTML to be a markup language that:"
I think I get it now Gez.
The process says:
Provide accessibility advances, while preserving past gains that are
relevant.
The language says:
Allow for explicit associations of related pieces of content if this
association aids in conveying context and content relationships
to
users, whenever implicit associations do not provide this
functionality.
Example is:
Keep headers until we have something better and in place.
> what about having another vision statement about process?
Are you thinking a process point to correspond to each language point?
From Catherine:
I am not sure what you mean by process. When I made the comment in the survey, I was relating it to how HTML5 had proposed to eliminate certain important accessibility features. My concern was that it was important to ensure that the language retain any relevant past gains (such as longdesc if deemed necessary) and that it not be locked down, that it be flexible enough to allow ameliorations with regards to accessibility.
I do not know what you mean by process but if that is what it means than yes, we could have a statement about process. However, I think it might be perhaps sufficient to have different sections in the general Vision Statement instead of having a bunch of statements. So our Vision Statement could have a section on features, process, whatever else comes along. But I think we do not need to wait until all these sections are completed to at least adopt a 1.0 version or else we could be at it all year ;)
From Laura:
> So our Vision Statement
> could have a section on features, process, whatever else comes
along. But
> I think we do not need to wait until all these sections are completed
to
> at least adopt a 1.0 version or else we could be at it all year
- )
I agree. It could be a living document.
Maybe remove that point for now. Hold it in reserve for version two, when we could add process points?
From Gez:
> The process says:
> Provide accessibility advances, while preserving past gains that
are relevant.
>
> The language says:
> Allow for explicit associations of related pieces of content if
this
> association aids in conveying context and content relationships
to
> users, whenever implicit associations do not provide this
> functionality.
Yes, that's it. A feature is a benefit we would expect from the language, and the process is how we get there.
> > what about having another vision statement about process?
>
> Are you thinking a process point to corresponds to each language
point?
I was thinking in terms of the processes we would like the working group to take, but not necessarily related to each language point. For example, include Catherine's point about retaining existing accessibility provisions, but include other points if they're relevant, such as what to do when there's a deadlock in the process.
From Laura:
> Yes, that's it. A feature is a benefit we would expect from the
> language, and the process is how we get there.
Got it. Thanks for your patience.
> I was thinking in terms of the processes we would like the working
> group to take, but not necessarily related to each language point.
For
> example, include Catherine's point about retaining existing
> accessibility provisions, but include other points if they're
> relevant, such as what to do when there's a deadlock in the process.
Makes sense to me.
I'll pull that point for now, if that's okay with you, Catherine.
We can save it for a separate process doc or a new process section to be added to this doc in future version.
From Catherine:
Should remove the word "or" from the second bullet item (sorry I missed it earlier). It seems to me that all of these are good things to have for a vocabulary. So it would be "Offers a rich, meaningful and extensible vocabulary for marking up text".
From Laura:
Done!
