DIY Web Publishing Introduction | DIY Start Page  |  Main Home Page

DIY Web Publishing: Introduction - First Principles

Today, there is no lack of books and guides to the technical side of putting websites together. There are hundreds of books (go into Borders sometime) on all the different ways of constructing HTML code, etc. Technical help is also available free online, or obtainable by pressing F1 to pup up a web-authoring application’s Help page. There is little help available, however, with the organisational aspects of online publishing. I believe this is a fundamental problem. I know from experience teaching and tutoring adults that they soon lose their way even if they have an illustrated step-by-step guide to technical procedures in front of them.

You can see this step-by-step approach all the time in computing magazines, with titles on the pattern of “Learn How To … In Ten Minutes.” Such articles show you a numbered series of screenshot images with captions giving instructions. Their appeal is that you only have to follow the illustrated directions - you don't need to know or learn anything. When I was teaching, we used to call it the paint-by-numbers approach. But if you have a slightly different operating system or software package, you'll probably be in difficulty right off, for the menu or keyboard commands will differ. Even if you have an identical setup and all goes smoothly at first, you'll run into problems if you then try to change, move, or add something. Instructions are embedded in a specific scenario which is chosen to avoid difficulties. And even if you complete your website or other task in 10 minutes, it'll look like it, and you’ll find when you try to improve it, you’ve learned virtually nothing. There's almost no transfer of skills involved with this approach.

Nevertheless, the approach has been adopted in education for IT training courses as it saves delivery costs - instead of the old theory-and-then-practice approach, you just get the practice. It also seems to deliver success (the accompanying tests are set up the same way, as a step-sequence, without the pictures or explanatory text). In the official view, the most important thing to make Britain's population IT-literate was “confidence building”. This approach has the same appeal as giving IT books and courses calculated titles like "Web Design For Dummies" and "Computing For The Terrified". However this ‘confidence building’ aspect is something of a confidence trick, an illusion. With most adult IT training courses, the students are office workers who don’t need real teaching as they already have most of the skills, and simply need the certification to fulfill official requirements. However this is not the case with adults learning web design: they’re interested in DIY website-creation. Following the examples of others, at first I made the same mistake when I started teaching web-design basics. I soon found that if students were to actually learn enough to manage on their own after the course was over, I needed to shift the focus from the ‘monkey-see, monkey-do’ approach of following a demo to emphasize organizational aspects.

The technicalities of what buttons to push can be more meaningfully delivered within this context. The keyboard and menu commands vary in any case, depending on which software package you’re using. Nevertheless many adult courses offered are 'application courses', meaning they teach a specific package like Excel 2000 or Frontpage 2003. Students often take such courses as they have just bought, or are contemplating buying, the package being used in the course. Often they are, or have been, using a different software package or version of it at home, adding to the confusion. The push-button command sequences being variables, a real skills transfer cannot really be built on them. (Office workers have regular “top-up” courses to deal with this issue.)

This spring, the Web's foremost expert on accessibility and usability issues, Jacob Nielsen, argued it is a waste of time to teach IT skills based on specific software applications, as such learning soon becomes obsolete. Instead, he argued, people should be taught at a more abstract level to understand issues, which they can then apply at 'application' i.e. software-specific level. This is actually a well-proven traditional teaching approach - 'theory before practice'. But it brought predictable reactions from some of the 'techies' who dominate the IT message boards, reactions which exposed their own lack of consideration (in both senses).

With web design, the old hands mostly said they learnt it via a specific application, namely Dreamweaver. If you don’t know it, Adobe-Macromedia's Dreamweaver is the premier web-authoring software package, technically classed as an HTML editor but with a ‘WYSIWYG’ (what-you-see-is-what–you-get) graphic interface, so you can see what the web page looks like as you work on it. In the web design field, Dreamweaver was what is known as the ‘killer application’ which draws a whole new user base, just as Excel did with office workers. However when I got my first version (DW v1.2, 1999-) and took a course in it, almost everyone in the (all-male) class were IT pros who already knew how to hand-code in HTML. For pre-Dreamweaver, web-authoring applications were maddening limited, amateurish or over-elaborate affairs, which corrupted the HTML code. So professionals just learned the HTML strings they needed and typed them into Notepad. Even if they didn’t know the HTML string they needed, they could just copy and paste bits of source code downloaded from webpages they liked, and adapt these. So no 'theory' teaching was needed - they already understood the concepts and issues before they started memorising menu commands.

The other response Nielsen’s argument got from techy writers was that when they started, they didn’t take courses or use textbooks, they just learned the application by trial and error. Again, courses and textbooks were not so widely available in the early days, so this argument just begs the question. There's also a demographic factor here, where the 'early adopters' in any field are a self-selecteing group made up of the keenest and most 'savvy'. After that you get a law of diminishing returns setting in. In fact it's widely recognized in adult education that as you include more and more people in a skill (a skilled population being essential to democracy), it becomes harder and harder to teach, as the early adopters are replaced by (to use the official NIACE terms) 'drifters' and 'strugglers'.

The argument in favour of teaching via applications was also made by analogy that you can learn to drive a car using any make or model, and just adapt this to each new car. However this implies you know how a car works, what a steering wheel is for etc. - which is where the analogy falls down when applied to anyone besides the techy enthusiasts who have spent a quarter of their lives at a PC. A car is an object familiar to us from everyday observation if not experience, but for most adults there is no comparable background of familiarity with web design – often not even with how computers work as an operating environment. Many users don’t actually know where files are stored on their computer, or even know how to use Windows Explorer to view their file and folder directories (which is why Microsoft and Google are now emphasizing file-finding functions). However to create hyperlinks, you need to be able to understand about matters like file paths. The most common problem encountered with DIY websites is broken links. The underlying problem here is DIY-ers who don’t know how to create or fix links, as they don’t see the need to learn about file-name and file-path requirements. Memorising menu commands for each new application is not only difficult, but pointless if you don't understand what’s going on underneath. There's little point in teaching someone "here's how to create a Timeline in Dreamweaver" when they don't know what a Timeline is in the first place. And if you try to explain this – objects inside layers with timed behaviours attached , you'll find you have to keep backing up further and further to explain about layers, Javascript-based 'behaviours', and so on.

The step-by-step guide procedural-guide format is used as it gives the beginner a “quick fix” sense of mastering an entire task such as creating a web-page. Any sense of achievement nevertheless is illusory. On this site therefore, we will concentrate on the basic organisational steps, outlining the necessary tasks, and examining related technical issues likely to trip up the beginner who does not understand them. In other words, here we will cover:
- what you need to understand in terms of issues, and
- what you need to be able to do in terms of hands-on skills.

Here, we break the creation of a website down into ten types of task, expressed by simple verbs: organize, plan, design, write, edit, illustrate, produce, publish, manage, optimize. Although they are given in the order you are most likely to need to embark on these tasks, it's not a strict one-after-the-other sequence like the step-by-step how-to guide – so there'll be some overlap. It's a modular approach, so you can consult the relevant section as you work on each task. As far as anything really tricky goes (like incorporating multimedia objects), I’ve omitted this until the final stage, ‘Optimise’.

Each of the ten tasks will have its own page outlining issues, procedures, etc. on a page of its own. I'll be adding content to each as more issues occur to me. The site's main home page will be updated to reflect which pages are online so far.

Go To List Of Ten Organizational Tasks


Return To Top