 |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
|
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
jc at trillian.mit.edu wrote: > I had a similar case recently. I've helped a few nonprofits build web > sites, and several have started off looking into Drupal, Joomla, etc. > After a month or so of this, with nothing working, I've combined a > few scripts that I've collected or written anew with a few of their > designs for the pages they want, and in a week or two they were > happey with the results. > > ...they've looked at HTML manuals, and run terrified from the > incomprehensible technical gobbledy-gook that they saw. HTML is this > horrible stuff that mere mortals don't stand a chance of > understanding, right? > > Then I show them the effect of wrapping them in a simple <html><body> > ... </body></html> wrapper, and adding <p> tags between paragraphs. It's funny that back in the days before CMSs we accomplished the two most important features they offer - separating the appearance of a site from the content, and making it user friendly to add/edit content - with some primitive tools that seem to have disappeared. The first objective was accomplished with frames. And then later when frames were shunned, with (Apache) server includes[1]. Server includes didn't gain much traction, as they were quickly eclipsed by PHP, Cold Fusion, ASP, Mason, and other templating languages, that offered much more functionality, but usually at the expense of requiring a programmer or "web designer." The other objective was accomplished with GUI HTML editors. For a while there, there were actually some decent competitors to Microsoft Front Page, including a few open source tools[2]. As developers we hated most of these (mostly Front Page) for the ugly HTML they generated, because sooner or later we'd be faced with making modification to the HTML outside the tool. These days the ugliness is still there, being generated by most CMSs, we just don't have occasion to look at it. The CMSs seem to have killed off the market for HTML editors, but it looks like the successor to the Mozilla Composer is still being updated[3]. I don't think there is any significant benefit to having content producers learn HTML, if they can find a suitable HTML editor. I imagine today with the help of CSS and something like server side includes, you could create a pretty functional poor man's CMS, where your non-technical content producer creates a new page by doing something like: 1. create a new directory named after the content title. 2. copy some boilerplate files to the directory, which might include an index.html with the server include directives, and an empty context.html file. (Steps 1 and 2 could be implemented with a shell script.) 3. load the content.html file into their GUI HTML editor and add content. The content then doesn't need to have any presentation markup. Headers, footers, and navigation all come from the server includes, and can be updated site-wide by editing in one place. Content styling comes from the site-wide CSS included by the boilerplate index.html. The user only has to concern themselves with the simple structural markup in content.html. -Tom 1. http://httpd.apache.org/docs/2.2/howto/ssi.html 2. http://en.wikipedia.org/wiki/Nvu 3. http://bluegriffon.org/pages/Download -- Tom Metro The Perl Shop, Newton, MA, USA "Predictable On-demand Perl Consulting." http://www.theperlshop.com/
 |
|
| BLU is a member of BostonUserGroups | |
| We also thank MIT for the use of their facilities. | |
