Re: [Edu-sig] Another update from the field...
On 8/20/06, Dethe Elza <dethe.elza@gmail.com> wrote:
Eliot Kimber (aka Dr. Macro) has a great series on his blog about building an XML-based CMS. It is really applicable beyond XML (and most XML stuff is applicable to HTML). He advises (and is building open-source and blogged all the way) a solution on top of Subversion (versioning software).
Does Eliot consider Zope 3 a good example of XML-based CMS? I've seen it presented as Model-View-Controller, with ZODB providing an API to the model, XML controlling the View, and Zope + custom Python being the controller.
If HTML is the scary bit, I suggest looking at reStructured Text/ Markdown/Textile as alternatives (depending on need). All convert to nice (X)HTML. reST is the most complicated, but can also be converted to XML, PDF, PPT, and other formats, and you can add your own hooks to bring in more advanced features.
"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. Per my friend Gene Fowler's vision, I think we should just plan on spreading XML fluency at least to a point where fear of XHTML is the exception, not the rule. The basics aren't that hard -- arguably as simple as all the rules reST gives you. Gene's vision: http://controlroom.blogspot.com/2006/08/more-cast.html
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). The real site will debut on flextegrity.com in the near future, probably as a PHP site (i.e. I expect my good advice to be rejected).
A full-fledged CMS is often the wrong solution even for the high-end corporations that they're generally targetted for, and always require more effort than is anticipated.
--Dethe
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). Per Gene's vision, I want to see more mixing of XML with everyday language arts. Learn some tags at the same time you're learning basic punctuation, and the difference between a verb and a noun. No one finishing the Shuttleworth sequence, for example, should feel "afraid of HTML". Kirby
On Sunday 20 August 2006 22:39, kirby urner wrote: ...
whereas straight XHTML/CSS liberates you from anybody's Wiki or whatever framework.
People write and use wikis to have *human* friendly markup. (Specifically and most often more friendly to the person who wrote it, and people who think like them) XML & friends are machine friendly, human readable markup. There's a huge world of difference between the two - both in terms of human factors and practicalities. This often boils down to the fact that many complex (but human friendly) wiki markups are actually best parsed as context sensitive grammars (which is why they're often so repeated-pass regex heavy). Whereas machine friendly markup is more often (not always) single pass parseable. Also *often* the ability of wiki style markup to be understood in a plain text environment is much easier for people to parse, than <span class="machine">XML</span> style annotations. But far less parseable than a wysiwyg engine (such as included in dojo toolkit) which already does the parsing :-) (and spits out plain old HTML) (It's worth remembering a design goal of XML is machine friendliness and human readability, not the other way round - wiki markup tends to favour the human) Michael.
(It's worth remembering a design goal of XML is machine friendliness and human readability, not the other way round - wiki markup tends to favour the human)
Michael.
I find this an interesting discussion because it recapitulates a central theme on edu-sig over the years: how much hand-holding versus how much "they just need to learn it too"? Some have the model that technologists are supposed to infantalize non-technologists, by pandering to the vision of some "mindless consumer" wanting "no brainer" controls. In contrast, some believe humans are tool-users by nature, so once the tool is "good enough" by some reasonable standard, it's OK to tune out all the whiners and "still don't get it" types. Fortunately, there's not just one big fat omnitechnology out there that one either knows inside-out, or is completely clueless about. It's not that simple a picture. We all distribute our competencies and bring interesting "hands" to the table ("hands" in the sense of "in card games" but I'm also imagining a surgeon's). I'm really incompetent in so many dimensions, and I don't feel I'm underselling myself by admitting that. I take it for granted in everyone I meet. We're all "just chickens" in this soup, even if we sometimes look like superchick to one another, based on our specializations (allusions to 'Chicken Little' movie, http://worldgame.blogspot.com/2005/11/chicken-little-movie-review.html ). In other words, there's just too much technology out there to for anyone to credibly claim to have mastered it all. So if we just relax a little bit, we can at least agree on some regions of overlap, so-called background knowledge that's widely distributed across specialties. I would include XML in this category, and I'm talking about including minors (people under the age of 18) in this loop. They should be informed of it. No kidding. You'll see what I mean here: http://www.4dsolutions.net/winterhaven/ Plus I'm influenced by Gene Fowler's way of weaving it together: http://controlroom.blogspot.com/2006/08/more-cast.html Plus here's a mathcast I've just been working on: http://mybizmo.blogspot.com/2006/08/mathcast-storyboard.html Kirby
You'll see what I mean here: http://www.4dsolutions.net/winterhaven/
Nope, not there. Let's try here: http://www.4dsolutions.net/ocn/winterhaven/ Kirby
On Monday 21 August 2006 02:17, kirby urner wrote:
I find this an interesting discussion because it recapitulates a central theme on edu-sig over the years: how much hand-holding versus how much "they just need to learn it too"?
Actually, no, you miss my point. That's completely tangential to what I was saying, and totally irrelevant. I wrote a long reply to this, but realised I can shorten it dramatically. Knowing how something works so you can change it? Good (necessary even - up to the limit the person is capable of understanding (bell curves and all that)). Being forced to always use nuts and bolts because it "liberates you" from useful [1] tools that you can change [2] to suit your needs? Not so good. (Especially you merely want tools fit for purpose) [1] Useful is in the hand of the user and what they want to do with their time. [2] Assumption, but having chosen to write a wysiwyg wiki, blog and local editor because I've been bored of writing markup (wiki or HTML) after years of doing so, I'm happy to make that assumption :-) Put another way:
don't market pure XML/XHTML as "the right solution for everybody" any more than "computer programming for everybody" means we all program the same way, or all have to use Python.
A much more fun way of making your main point (which I think boils down to being able to get under the hood when you want/need to and being able to easily change systems) is to merely point at the film "Robots". Makes the point in a much more fun way :) (especially if you notice some possible references to a particular hardware manufacturers, who could be said to successfully "infantalize" (to use your derogatory term) technology in a way that millions of people want, demonstrably so by buying said technology by their millions...) Regards, Michael.
Actually, no, you miss my point. That's completely tangential to what I was saying, and totally irrelevant. I wrote a long reply to this, but realised I can shorten it dramatically.
Heh. As if yer point mattered. ;-D
Knowing how something works so you can change it? Good (necessary even - up to the limit the person is capable of understanding (bell curves and all that)). Being forced to always use nuts and bolts because it "liberates you" from useful [1] tools that you can change [2] to suit your needs? Not so good. (Especially you merely want tools fit for purpose)
Aye, there's the rub. What's the most fit tool for the job. Enter the wonderful world of self-fulfilling prophecies and other tautologies. Like *of course* you should use X, because X is the most fit for what you need right now... I don't think reST or Wiki rules are all that much easier than learning the amount of XHTML it'd take to do pretty much the same thing, plus you'll be encountering XMLs again and again, so the skills are transferrable. That doesn't mean you should always hand-code everything (I like starting with templates, and a large library of already-done CSS sheets). Telling a startup to show up on radar inside a Wiki or Blog for its web debut is crummy advice I think. It's OK to link to those things (as does python.org) but your flagship needs to feel like an outer frame (reskinning Plone does the trick, but a plain vanilla Plone implies "I haven't put much of my own creativity into this site" -- maybe not true, so why send that message?
Put another way:
don't market pure XML/XHTML as "the right solution for everybody" any more than "computer programming for everybody" means we all program the same way, or all have to use Python.
Interpolating into my text. Madlib idea. Right. Some use Ruby on Rails. Quite hostile to XML. I like it.
A much more fun way of making your main point (which I think boils down to being able to get under the hood when you want/need to and being able to easily change systems) is to merely point at the film "Robots".
Makes the point in a much more fun way :)
(especially if you notice some possible references to a particular hardware manufacturers, who could be said to successfully "infantalize" (to use your derogatory term) technology in a way that millions of people want, demonstrably so by buying said technology by their millions...)
Regards,
Michael.
The problem with infantalizating others is the people into it tend to also steal candy from babies. Kirby
On 20-Aug-06, at 2:39 PM, kirby urner wrote:
On 8/20/06, Dethe Elza <dethe.elza@gmail.com> wrote:
Does Eliot consider Zope 3 a good example of XML-based CMS? I've seen it presented as Model-View-Controller, with ZODB providing an API to the model, XML controlling the View, and Zope + custom Python being the controller.
Doubtful. I don't know of anyone who considers Zope 3 as a good example of much of anything, as it's too new. Zope 2 is an application server and framework you can use to build a CMS, but it certainly is not a CMS, XML or no. Plone is a CMS built on Zope 2, and Silva is an XML-based CMS built on Zope 2.
If HTML is the scary bit, I suggest looking at reStructured Text/ Markdown/Textile as alternatives (depending on need). All convert to nice (X)HTML. reST is the most complicated, but can also be converted to XML, PDF, PPT, and other formats, and you can add your own hooks to bring in more advanced features.
"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. Straight XHTML/CSS can be very liberating, but I've used/taught HTML for more than ten years and frankly I still prefer: There are three kinds of lies: * Lies * Damned Lies * Statistics to: <p>There are three kinds of lies:<p> <ul> <li>Lies</li> <li>Damned Lies</li> <li>Statistics</li> </ul> Granted, you can do this with a WYSIWYG HTML editor, but frankly, that isn't going to get you any closer to understanding the HTML than a lightweight format is. 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.
Per my friend Gene Fowler's vision, I think we should just plan on spreading XML fluency at least to a point where fear of XHTML is the exception, not the rule. The basics aren't that hard -- arguably as simple as all the rules reST gives you.
And the basics are great, as far as they go. The basics of reST are even simpler, just format your text the way we used to in email, back before HTML mail became the norm. You don't have to use all of reST any more than you have to code fully accessible, fully semantic HTML, for example not everyone needs to start with Mark Pilgrims treatise on accessibility: http://diveintoaccessibility.org/introduction.html
Gene's vision: http://controlroom.blogspot.com/2006/08/more-cast.html
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 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.
The real site will debut on flextegrity.com in the near future, probably as a PHP site (i.e. I expect my good advice to be rejected).
Too often true.
A full-fledged CMS is often the wrong solution even for the high-end corporations that they're generally targetted for, and always require more effort than is anticipated.
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.
Per Gene's vision, I want to see more mixing of XML with everyday language arts. Learn some tags at the same time you're learning basic punctuation, and the difference between a verb and a noun. No one finishing the Shuttleworth sequence, for example, should feel "afraid of HTML".
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
--Dethe "The Brazilian government is definitely pro-law. But if law doesn't fit reality anymore, law has to be changed. That's not a new thing. That's civilisation as usual." --Gilberto Gil, Brazilian Minister of Culture
On 8/20/06, Dethe Elza <delza@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
to:
<p>There are three kinds of lies:<p> <ul> <li>Lies</li> <li>Damned Lies</li> <li>Statistics</li> </ul>
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 :-D.
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 logo. 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 company website. 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 myspace.com/4dstudios.
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 started.
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
--Dethe
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 must). """ http://mybizmo.blogspot.com/2006/08/mathcast-storyboard.html Kirby
participants (3)
-
Dethe Elza -
kirby urner -
Michael