Re: PHP

> The main reason I have heard for people using PHP (and for my group using

My impression was rather different.  My impression, based on what
my employers do and the sorts of features in ASP (which was reputedly
modelled on PHP, mapped to Visual Basic) that Microsoft seem to supply
and about which questions get asked, is that they are used for creating
e-commerce sites on the web and for thin client business applications.
Thin client applications are in the heritage of the IBM 3270 applications
that were probably the first introduction of older computer users to
form based data entry.  They put most of the intelligence in the
central server.  (Your system will be a thin client application, but
most are probably traditional business applications, rather than 
information management ones.)

> content to people who have the content sooner and who know more about it and
> so are less likely to make errors.  So I guess it would be more correct to

I find this rather telling.  My understanding is that the design aim
of HTML was that it should be simple enough, and universally enough
available, for non-specialist users to create it.  Unfortunately, it
has moved back a long way towards its *predecessors* in complexity, due
to being used as a replacement for PDF etc.  (A lot of "progress" in HTML
is actually backwards!)

I would suggest that your real problem is that your users probably already
know too much HTML and have experienced too much bad HTML, so they need to
unlearn a lot and start again from the original principles of simplicity.
(This is going to get worse, as schools and popular books all teach HTML
as a presentational tool.)

In terms of modern accessibility criteria, the main problem in doing this
is probably images.  HTML wasn't really designed for embedded images (it
was designed as a language to glue other resources together, in which
the images would be separate resources, rather than part of a compound
page) and including them tends to make other presentation aspects more
difficult to avoid, although, even then, from a communication point
of view, simply alternating images and text is usually good enough,
and what most word processor users probably do, anyway.

> with a lot of change in who does this, people who are in marketing or course

I think this relationship between marketing and web authoring is also
atypical of most businesses.  In most businesses it seems to be that
the marketing department are the ones that first got to play with
web sites (I'm judging mainly by what's visible externally).  Typically
one found that the deepest technical content that the organisation was
prepared to release was in PDF, because the technical people were using
their traditional desk top publishing tools, and not allowed to
experiment, whilst the marketing people would be playing with the
latest dynamic HTML tricks, Flash, etc.  For the HTML parts, this is,
in my view, a total inversion of the niches for which HTML and page
description tools are appropriate.

I think the current situation is still that PDF is the normal format for
the non-marketing people, although there may be a move to authoring in
Word 2000 and then doing save to "HTML", which is not all that different,
as the authors still don't work in HTML.  (In more general business 
oriented areas, Word was probably used instead of PDF.)

> enter only text and occasional links.  We can tell them about clear and
> simple language and meaningful link text, but should we give them more

Note that these are not specific to HTML; they should be true of any
technical writing.

Coming back to the theme that HTML was designed for delegation
of authoring, HTTP also provides facilities, that are woefully
under-implemented, but are intended to allow browsers and web servers
to act as a simple content management system.  The POST method that
is typically used for forms is also defined as being appropriate for
annotating resources and there is a PUT method to allow the direct
uploading of new and replacement pages, together, I believe, with their
metadata.

> complete training?  Or constrain what they are allowed to put in?  Ideally,

There could be a case for severely constraining presentational markup
and requiring that they work within your style sheet, with new
classes added as needed.  Unfortunately, if you block <i> and <b>
people will realise that <em> and <strong> produce the same effect,
so they will write <td><strong>...</strong></td> for <th>....</th>.

There is probably also a good case for blocking script elements and
limiting script actions to a single function call plus return 
statement.

Received on Saturday, 26 January 2002 04:18:17 UTC