Back around 1994, I worked for a University library system and we started offering web development training courses as part of our user education program. It seemed somewhat odd that a library should be doing that and not, say, the computing center, but we were interested in the whole burgeoning 'Net phenomenon from an information science point-of-view, so it sort of made sense.
My colleague, Paul, and I would teach librarians and patrons all about how to format and publish "pages" using "HTML" so that people could use "browsers" to access them. Since we taught in a Mac classroom, we would use SimpleText as our HTML editor. We taught people how to code links, ordered lists, unordered lists, apply bold and italic formatting, and properly use the 6 header tags. I still remember the excitement when background and link colors, tables, and inline JPEGs made their appearance. Sigh.
Not too long afterwards, software developers began creating "WYSIWYG" (what you see is what you get) tools. The first round of these products were buggy and produced awful HTML code in the background. We reluctantly added something called Claris HomePage to our curriculum, but we spent a lot of time in "code" mode so that our students would learn the standard and not just one vendor's interface to it.
One day, Paul and I met with the user education steering committee, one member of which was a rhetoric professor of mine and a web enthusiast. He questioned our need to continue to teach "raw" HTML since the WYSIWYG tools were pretty good and just going to get better. He foresaw a time when people wouldn't need to even look at HTML code, just as they don't look at the formatting code underneath a Word document.
I argued in favor of continuing to teach HTML since there was still signficant utility in going "under the hood" to fix formatting problems, and for the pedagogical reason that it was always better to teach people what was happening under the surface so they could choose their own path in how they wanted to use it.
His point-of-view eventually won out, however, and the user education program drifted more and more toward teaching tool-specific courses on general web page-making.
Flash forward 12 years to the present day. Again, this is a work-related story but I think it's cleansed of any identifiable detail. I just spent the morning reviewing about 50 pages of documents and email correspondence among a small group of people involved in a relatively small web site implementation within one of our units. There is a dispute about the deliverables and whether or not the third-party design group did everything they said they would do.
The chief source of conflict, I have determined, hinges on the word "template." The third-party designers feel they delivered an HTML "template" when they turned over source code for the main page design with placeholder text ("Lorem ipsum...") where the content should go. The other party says what they meant by "template" was a Dreamweaver template; a specially-coded HTML page for use in one particular web editing program. Without this kind of template, the "web developer" cannot fill in the content and edit pages on the site.
So, you now see why the title of this post is about how Promethean my forethought is. This is exactly the kind of scenario I envisioned 12 years ago: someone representing him/herself as a "web developer" but who is locked into one vendor's platform and unable to strip off the skin and monkey around with the insides. In this case, the extra work and all the time it has taken to sort out who meant what is costing the unit thousands of dollars, not to mention now about 4 hours of my time.