[Edu-sig] Another update from the field...
kirby.urner at gmail.com
Mon Aug 21 18:50:30 CEST 2006
On 8/20/06, Dethe Elza <delza at livingcode.org> wrote:
> > "Convert to nice (X)HTML" where though? You're still implying some
> > engine doing the translation, whereas straight XHTML/CSS liberates you
> > from anybody's Wiki or whatever framework.
> All three lightweight markup tools I mentioned have python
> implementations. So to your question, "convert where," the answer
> is, "wherever *you* want." It's just Python.
The problem is that in this model I'm advising a client as to whether
to go with a CMS (a PHP one it so happens, called website.baker) or to
develop XHTML/CSS skills inhouse.
The CMS is being used as a way to avoid having to learn much XHTML,
but I think this makes them way too dependent on a framework.
According to this model, "it's just Python" is no help to them. They
don't have Python or know how to use it. I'm not volunteering to make
my skills mission critical to them (my whole M.O. is about being
valuable without becoming indespensible).
One might ask why I'm even bringing this up then.
Answer: I think Plone and other CMS people in Python World should
think twice about hooking clients on a CMS when all they really need
is bare bones XHTML/CSS. The learning curve is about the same when it
comes to the basics, and the latter skill set is more transferrable
(as are the skills).
Also, since this is a discussion list focused on education:
I think schools should keep XHTML front and center, plus talk about
the DOM, and not buy into some CMS-based approach for letting students
each publish a website.
That's in school. On your own time, if you want a page in myspace.com
(a framework) or whatever, go right ahead (it's a free country). But
recognize your dependence, and the associated costs (e.g. mandatory
banner ads cluttering up your page).
> There are three kinds of lies:
> * Lies
> * Damned Lies
> * Statistics
> <p>There are three kinds of lies:<p>
> <li>Damned Lies</li>
But if using the former means you had to develop within a CMS, then I
don't think it's worth the savings in typing. XML is quite
consistent: every tag is paired with an ending tag except sometimes
> I'm all in favor of knowing how to sling
> raw HTML in a text editor, but also for knowing when to take
> shortcuts and save yourself some headaches. The lightweight markup
> tools tend to produce very clean HTML, too, while what I've seen from
> WYSIWYG tools has left permanent scars on my retinas.
DreamWeaver produces pretty clean HTML, plus has a facility to strip
out all the poopka you get if you "Save As HTML" from Microsoft Word
(and there, you *do* get incredible amounts of clutter).
I'm recommending that startups with simple needs (no ecommerce,
basically a cyber business card, a presence pictures and contact info)
invest in a WYSIWYG XHTML editor, and develop those minimal skills
it'd take to avoid using *any* server-side infrastructure other than
the web server itself. At least to start.
It's not all about text after all. There's picture placement,
borders, links between pages. Why lock them in to using WikiWords, or
the chronological blog structure? The shortcuts you need should be in
the client, the web site design tool, not on a server.
> >> If getting the content up on the web is the problem, a wiki or blog
> >> tool might be the answer, or simply showing them how to share a
> >> remote directory to the desktop for editing.
> > Too non-standard for a basic company website. This is a small startup
> > that can't afford to look too quirky, given the invention itself is
> > already on the wild side. For a sneak peak:
> > http://www.4dsolutions.net/flextegrity/ (I'll be taking it down within
> > 12 hours, so expect a broken link pretty soon -- sharing with you
> > because you track the Bucky stuff some).
> Looks interesting. How the site looks should be up to the CSS
> though, not the tools used to write it. I understand that most wikis
main.css contained all the coloring and font info. I started with a
canned template in DreamWeaver that matched the color theme on their
However, as I suspected, the client already feels tied to the PHP
website.baker solution, and is going ahead with the CMS. At the end
of the day, someone will have worked hard to develop competence within
a specific framework, and will have content that cannot easily be
enhanced or moved independently of that huge server-side engine.
That same time and energy could have gone into developing a
free-standing XHTML site, movable anywhere, and requiring a skillset
that's broadly shared in our culture.
I'd have been just as skeptical of using heavy server-side processing
had the client chosen Plone. It's not a Python vs. PHP thing. It's a
framework-as-crutch vs. rolling-your-own thing.
> and blog tools have default layouts that mark them as distinctively
> wikis and blog, but they don't have to, and they're usually pretty
> easy to customize. Of course, I'm speaking as a guy who is writing
> his own blog software because the existing ones weren't easy enough
> to customize for me, so take my opinions with a grain of salt. Heck,
> most simple websites don't need more than a standard template, static
> files, and some server-side includes.
Blogs don't allow the customary tree structure you'd expect in a
Customizing the look of a Wiki is to suggest some framework where the
client has to effectively fill in a CSS template, either with straight
CSS (as in myspace.com) or through some API. It also implies using a
Wiki for purposes it was not design for i.e. a lot of static text and
graphics with no need for community collaboration.
So again, we're locking the client into some clunky "engine" for no
other reason than that they don't want to learn XHTML/CSS, even with a
WYSIWYG like DreamWeaver.
Speaking of myspace.com, I think that *is* an option if you just want
a simple banner page and don't mind the advertising.
I'd never recommend it as the home site for a company, but as a
storefront or footprint in a populous bazaar it works, e.g. see
> > Yes. A CMS is a wonderful thing when it's the right tool for the job,
> > but in too many cases it's promulgated as a way to make the web
> > "friendly" to newbies, whereas just learning a little HTML in a
> > WYSIWIG editor would be a kinder gentler thing to share with them
> > (keeps them free of the CMS itself, a gravitational field).
> CMSii (what's the plural of CMS?) may be marketed as making things
> easier, but they're also about vendor lock-in, management control,
> and knowledge capture.
Exactly. Vendor lock-in. A scrupulous vendor will steer people away
who'd be better served just learning the basic tools of the trade.
Otherwise they'll take out their frustration
out on the CMS later. "Can't say I didn't warn you".
What I see as a goal for education systems is to promote
self-sufficiency at the individual and community level.
What are the minimal tools you'll need to get your self and your
enterprise launched effectively, *without* depending on a lot of
"doers" who will charge for this and that service?
Of course you need a lot more than just a few web skills -- but you
should have those as part of the complement (along with some
understanding of bookkeeping).
Once you have the luxury of being able to hire helpers, then maybe go
for a bigger framework, but still you should have a lot of the skills
inhouse. Being overly dependent on technologies you could have
avoided in the first place is the pitfall.
These lessons go for development work in general:
Self-sufficient communities develop appropriate technologies they know
how to operate and maintain themselves.
Dependent communities use a lot of borrowed money to pay a lot of
consultants and at the end of the day are worse off than when they
> Hear hear. I fully agree and support that vision. On the other
> claw, XML/HTML shouldn't be put on a pedastal either. XML is the new
> ASCII. I'm amazed that there are still conferences and such talking
> about the wonders of XML. It's time to move past that and work with
> the formats that matter (of which XHTML is one). XML is important,
> but it's low-level important.
> > Kirby
Yes, agreed. XML in the abstract is a bit too abstract. The focus
should usually be a particular XML. Per my blog:
Curriculum objective: gradually increase a student's comfort level
with XML, with previews of and forays into such markups as SVG, XHTML,
MathML, DocBook, X3D plus roll-your-own XMLs (and/or SGMLs if you
More information about the Edu-sig