Re: Author-friendlier definition of <object> (was Re: fear of "invisible metadata")

Sander Tekelenburg wrote:
>> That leaves the challenge of how to phrase it so that
>> more authors will easily understand it without needing such an elaborate
>> explanation.

Lachlan Hunt  wrote:

> I don't think we need to dumb down the language in the spec for authors
> in this case.  It's a spec, not a tutorial.  Technical terms are fine,
> particularly in sections that are aimed more at implementers than authors.

"Dumb down" can be viewed as a pejorative term for a perceived
over-simplification. In "Why the Tech Industry Needs to Change Its
Language" [1], Jonathan Follett says:

> Written language can be a powerful tool for assisting in design,
> development, communication, and comprehension, not merely a method
> for documenting specs after something has already been built, or
> cleverly marketing an already-existing product to a target audience.
> Language can shape the thinking of those who develop technology, and
> lead them in new directions. Language matters, and should have a
> prominent place in the development cycle for technology.
> If we accept that integrating tech into our daily lives is vital, and
> that language shapes reality, then the rest will naturally fall into
> place. Literate, multi-disciplinary teams need to develop tech
> products from the beginning. It's too late to deal with design
> issues-be they industrial, graphic, or language-at the end of the
> process. Engineers and other developers need to think about language
> as they work, and, most likely, they are going to need the help of
> professional writers and speakers along the way.
> Specifically, there needs to be an 'explainer' or 'story teller' role
> built into tech teams—a multi-talented individual who can hold onto
> the vision of the final product; converse with engineers, marketers
> and designers; critique mercilessly; advocate for the everyday
> 'user'; and of course, provide the foundation for all the text
> describing the product and its use.
> The explainer needs to hold an important seat at the table, equal in
> power to any in the inner circle. The explainer needs to ask 'why are
> we doing this?', 'who cares?', 'how does this help the customer?',
> and 'is this confusing?' Most importantly, the explainer needs to
> understand the requirements, restrictions, and goals of everyone on
> the team in order to have a deep understanding of the final product.
> This position requires someone technically minded, who can learn
> quickly, write compellingly, and take a leadership role when
> necessary. In many teams, the project manager may take on some of
> these responsibilities—going forward, a separate position for these
> tasks is needed...
> In addition to clearer and more informative language, the world of
> high tech also requires imaginative descriptions. With new
> technology, we need new ways of thinking, and new ways of
> manipulating our language to create meaningful interactions.
> Ambiguity in language may be despised by engineers, but it's a key
> factor in expanding the way in which we think about these tools. Most
> tech specifications are dispassionate descriptions; we need the
> opposite. We need better imagery to build our virtual worlds. With
> words we need both flexibility and history: one to provide us room to
> imagine and the other to provide roots.

It is something to consider.

Best Regards,


Received on Tuesday, 26 June 2007 19:12:27 UTC