Tuesday, March 18, 2003

A new weblog (and new weblog software): I've been a pMachine user for some time now and only with reluctance have I begun fiddling with a homegrown weblog solution (in parallel with continued pMachine use and hacking). This might seem more than a little hypocritical since within the volunteer group for our school website I've been arguing vociferously for using commercial weblog tools rather than custom code. But, it is kind of consistent because my home-grown tool is just a thin, thin layer on top of email. The idea is to use IMAP message folders as the content database and therefore enabling use of vanilla email clients for weblog entry creation and (more interestingly) weblog management. So far so good - a little weekend hacking has resulted in a first cut at IMPblog. My active thread of musing will move to that weblog for a while - whether that becomes the "real" weblog is still a bit in doubt.

In any case, I think the point of this particular thread is over. Our school web site, built on pMachine, is thriving and I've now got several non-technical folks posting their own content. There are a total of 6 different weblogs spliced into the site, as well as a dynamic event calendar. So to me it's no longer a question of "whether" weblog technology is a good idea but "how" to apply weblog technology in the most pervasive and useful ways, and "what" kind of weblog technology is most suitable in the real-world school environment.

Tuesday, January 07, 2003

Long time, no post: Three months back, I stopped talking to myself and started actually working on a weblog-based school site. But since (surprise!) several people actually noticed this experimental weblog I feel obliged to provide an update. The first results are now live at Bryant Elementary School . While it may not be apparent, the home page news section, event calendar, and principals corner page are all powered by pmachine. This is just a first step towards empowering teachers and students to use weblog software. I've been very pleased with pmachine, particularly its flexibility out-of-the-box with in effect inside-out templates. Also with its modularity and accessibility when you need to get in and actually make code-level changes. Of which I had to do several to accomodate the unusual requirement that the weblog components (for the time being) integrate invisibly underneath a ColdFusion-based skeleton site architecture.

This weblog, which was just an experiment in the first place, may stay cold for a while until phase two - empowering of non-tech-savvy educators - begins. Or not, we'll see. There remains a real difference of opinion within the team who developed the site regarding the need to empower end users as well as re: the value of off-the-shelf CMS/weblog tools - truce was declared so that we could actually get a site launched (and hence the IMO completely gratuitous ColdFusion layer) but subsequent developments may merit more discussion.

Wednesday, October 16, 2002

page-oriented vs. site-oriented tools: Dan Bricklin, for whom I have a great deal of respect (despite lack of success to date in geting Trellix to use my company's imaging server products), some time back wrote a great article on the taxonomy of web dev tools - the more important distinction IMO being not client vs. server tools, not weblogs vs. more general web sites, but page-oriented vs. site-oriented tools.

Thus one summarization of my rants herein - without reference to "blogging" - is that I feel that in the long run use of site-oriented tools, rather than page-oriented tools, will be most suitable for Bryant.

Tuesday, October 15, 2002

Another tingling of doubt, this time about tools: Manila's the most obvious tool choice BUT the more I dive into the Frontier/Manila world the more I feel akin to a home-builder trying to do post&beam or maybe more aptly straw-bale construction. It's not so much whether it's better or worse than a conventional stick-framed house, it's that it's different : everything's scarcer, and there are fewer people who know what to do. When it comes right down to it UserTalk is a mature, but proprietary and Mac-centric, scripting language - and Frontier didn't even run on Windows until version 5, and still doesn't run on Sun or Linux, two server platforms that are MUCH more popular than Mac in server environments. I mean you could be scripting in Perl, VB/ASP, Java/JSP, JavaScript, PHP, Tcl, C#, Python, Smalltalk, ... - the list goes on but all of the above have multiple vendors and mature groups of professional programmers. UserTalk has to rank well below any of these in adoption. And similarly Frontier is much less established than BEA, Allaire, iPlanet, Tomcat, ASP.NET and many other app server environments, and its web server component is many orders of magnitude less widely used/customized than Apache or IIS. And of course the scads of JavaBeans and ASP components aren't applicable in Frontier. So while I love the yummy user-friendly goodness of Manila - is it really a sound "business decision" to choose something built on underpinnings that are this old and lonely? Note that the Mac angle doesn't buy us anything on the client side - this school's running all Intel boxes with Win98 or newer.

So maybe MovableType would be better after all. Note to self: investigate...

Actually I just don't know why DaveW & co. don't add-in a more widespread scripting language to Frontier and hide UserTalk and/or port the Manila webapp to a more standard environment (e.g. a .WAR tarball that could run in Tomcat or any JVM) and thus take advantage of readily available 3rd-party server componentry and be extensible through more widely-adopted scripting tools. I mean the XML schema and UI of Radio & Manila seem to me what give them a captive and loyal user base, does this schema or UI really require Frontier & UserTalk under the covers?

But on the other hand I guess the extent to which this reall matters depends on the extent to which programming and other customization is going to be required. Ideally the answer is "not at all" - if the schema and UI are all that's interacted with, then it wouldn't matter how it was implemented. So long as the bet can be made that Userland won't go under - but it's certainly demonstrated staying power over the years.
I got a reality check today: a nifty event calendar at another Seattle elementary school turns out to be implemented in raw FrontPage HTML, with events mostly input by hand-typing transcriptions from the printed weekly newsletter after the web page editor's kid carries it home. For me the message was twofold: first, don't underestimate the power of elbow grease (in this case copious volunteer parent effort) vs. automated processes; second, getting the information out is really what matter anyway, the process is just a means to the end: it's kind of like sausage: you like it, but you really don't nned - or want - to tour the sausage factory. So spending toomuch time or energy worrying about establishing a highly-accessible newsfeed- and template-based weblog-based CMS environment could be less fruitful than simply whacking out some static FrontPage html and getting some untrained PTSA volunteers to regularly hack in up-to-date content. I don't necessarily think that's the case in our situation - there is no question in my mind that weblog software makes things much easier - but KISS is probably a good principle to keep top-of-mind.

Sunday, October 13, 2002

Since the comment system I had to bolt-on to blogger is sucky (enough reason alone to move this blog to a more evolved SW system) I will take up into a post some of the discussion Ben posed in a comment on my dynamic/static HTML post. His comments were right on:

Scalability usually comes down to a cost issue. That is, how much would it cost to scale by writing better code vs. how much would it cost to simply throw more hardware at the problem. In either case, it is usually much more scalable to drive change on a web site from a database then via manual edits. You can employ a clever caching system to minimize the number of times a given page needs to get built but at the back end the HTML is still being generated dynamically. The issue for Bryant is pretty much a moot one though. It doesn't seem likely that the size of our audience will ever pose a significant challenge to the server's ability to keep up.

However, I don't want to risk being misinterpreted - I'm a huge proponent of avoiding manually editing HTML and I agree that handling massive hits is a non-issue for Bryant. But assuming we are generating HTML from a database, there is still a question of whether it's good to do this purely dynamically on a per-user basis vs. in a batch mode. Blogging tools generally do batch html creation; Large-scale CMS systems are a mix with for example Vignette doing it dynamically and Interwoven doing it batch. Even with caching there are still additional points of failure with the dynamic path for first-time requests and because you can't preflight all possible HTML files that might be generated.

So I still feel that unless there's a compelling need to present different HTML files to different users any web site (even without high-volume scalability concerns) is still better off - all things being equal - with a system that has minimal requirements as far as which app/DB servers have to be reachable at the time of a page request and where what HTML a requestor will receive at any given time is well-defined. And with the batch publish via FTP model the back-end DB servers don't have to even be on the same network as the public HTML servers which also affords some additional data security.

But if we need to do it dynamically, I couldn't possibly object - my company's product, PictureIQ TransForce, is a dynamic image server appliance, used in Japan where with 150+ different models of Internet-enabled mobile handsets and a wide disparity in screen size, graphics formats, colors, resolution, etc. it's not practical to pre-create all possible optimal images. And here in the U.S. we have some etailing customers who use us primarily to retain flexibility and save storage - since (for example) thumbnail product images that are never requested never have to be generated or stored. But in the Bryant case I just don't yet see the need for the increased complexity that true dynamic generation implies. But I confess I may be being swayed at present with the "KISS" philosophy of most Web log SW tools.
I've created a school site review blog for deconstructing other school web sites. Purely my own opinionated views but I wanted to keep track of them. I think I'm now seeing some patterns and uncovering some best practices. Overall the best sites also are the sites with most prominent news - at least, I don't think I'm imagining this correlation.
Of course Blackboard is the Big Kahuna of server-based solutions for online learning. It seems to be well-adopted particularly at the University level, with U.W. and U. of Puget Sound both using it locally as well as Renton and Edmunds school district. It seems to be focused on the class-level, not the school level. Basically a template-based classroom "portal in a box" for online course materials, online drop box for assignments, online testing, online discussions, and even real-time chat. More info is here and here. My take is that Blackboard is probably overpowered and overpriced for the more modest needs of our K-5 school. It seems that schools and districts that adopt it end up investing in lengthy deployment and training cycles. But, it's probably worth talking to a local user or two and getting a pitch from their sales team. At best it may turn out to be a fit, at worst it may give us insights into best practices and provide inspiration for future enhancements.

Saturday, October 12, 2002

A common design pattern: brochureware + documentitis: My alma mater illustrates a recurring theme in school Web sites: news comes in PDF files, links to which are buried inside relatively static brochureware-style Web sites. So for a parent to get current info, for example the timely news that Oct 12 is parent conference day, they would have to drill down 2 levels from the home page to click on the current newsletter, wait for the heavyweight Acrobat plug-in to launch, and then go to page 2 in a document clearly designed for print, not online viewing. OK, it works (after a fashion) but I think the usability is poor, and it affords absolutely no community-building effect. I'm not complaining about using PDF format - for distributing electronic documents that are, generally, to be printed, PDF is the obvious choice. The VHS school web site above has a very nice link to a collection of printable forms in PDF format. But for online information access PDF just sucks. And as someone who was once Adobe's engineering manager for Acrobat, and helped invent some of its features, if anything I should be biased in favor of this technology. But PDF really is a format for "electronic paper", and the computer display is a very different medium. It's funny I just now imagined that probably Jakob Nielson would have a rant on this and yep he does. Of course Adobe has long had a different view but it's just not reality. Acrobat's great electronic paper and 99.99% of Adobe's Acrobat-related revenue is all about print. Adobe passed on the opportunity to get PDF built-in to Netscape very early on as a peer format to HTML, in which case PDF might actually have become relevant as an online format, leading to fewer explicit-layout hacks in HTML. But that's another story.
Out in the real world: OK there's a thousand failed school web sites I could pick on, but instead I'd like to highlight one that works, but yet exemplifies some of my concerns: Evanston Township High School has a detailed, up-to-date site. I don't care for its organization or presentation but there's no doubt about it, it's current. But, at what cost? It's pretty clear that this Web site benefits from some serious dedicated webmaster resources, as indicated by the heavyweight publishing process described in their Web Site Guidelines And, how used is it? Sure there's news but it's buried away on sub-pages. And when you get down to the departmental or individual activity level its frequently stale brochureware. I'm suspicious that paper's still the primary source of current info and news for most students and parents. And there's little to no visible indication of an involved community - ok there's a set of discusion forums but it appears that only 1 out of 15 has an active discussion going. And, this is is a high school, with budget for technology staffers and presumably a quorum of tech-literate students. Our school by contrast has to deal with zero dedicated tech staffers and a K-5 student body. Don't get me wrong: I admire the accomplishment of the obviously hard-working folks who contribute to the ETHS web site. But I'd love to find a way to get there faster, cheaper, and better. I'm more and more convinced that a Weblog-centric implementation architecture with an RSS news feed information distribution mentality is the way to go.
Dynamic vs. static HTML generation: Dan at IMX has a short article highlighting scalability concerns with dynamically-generated HTML.
Another John Hiler article anecdotally illustrates the disruptive technology posed by Web log software. While it's a great story, I feel the real disruptive potential of Web log software is not merely undercutting high-end CMS systems but rather making content management for the first time a practical technology for small-scale SOHO/school/personal Web publishing, and thus radically transforming the market for low-end Web publishing tools (diminishing the need for HomeSite, FrontPage, etc.).
Personalization - is "MyBryant" needed? the majority of Web log software is oriented towards automating creating of essentially static web pages. While there are "community" features (such as comment systems) the typical Web log site doesn't provide for personalization. That is, each visitor gets the same experience. On the other hand corporate portal packages such as Plumtree inherently support personalization, as do some Web log software. John Hiler over at Microcontent News has a good taxonomic survey of Web log software.

My preliminary take is that, while each parent, student, and teacher definitely will want to access Bryant Web information in different ways this does not need to be implemented by a personalization system withint the Bryant Web site itself, given that "deep" personalization isn't required. The primary need appears to be "I want to see the info that's relevant to me" choices which the news feed features built-in to the Web log model already deal with. For example, I want to stay on top of Mrs. Paulson's Kindergarten class, the Chess Club, as well as school info - but I will be able to simply subscribe to the appropriate Web logs, aggregating them in my news reader of choice, or getting email updates. And, even more simply, bookmarking as favorites the relevant three "nav entry" spots for my needs.

Friday, October 11, 2002

Can it be long until Microsoft offers blogging? OK the image of blogging is a heady mix of body-pierced indy poets, feisty lefty/anarchist commentators, and evangelical open-source zealots so this may seem unlikely but really, it seems to me that blogging features make perfect sense in the Microsoft world view. blogware undercuts expensive full-featured CMS systems with something that's easier to use for the masses at the cost of more constrained capabilities: basically the M.O. of Microsoft in every market that they enter. After all, Microsoft is much more about structured information creation (e.g. Powerpoint, Excel, Visio) than free-form blank-canvas creativity. So in some sense Web logging is a better fit for Microsoft than FrontPage.

Tactically, blogging capabilities would seem a natural add-on to Outlook, which is already calendar- and collaboration-centric. It's also a great fit with the Microsoft Web services strategy in general, and Passport in particular. Not to mention a fit with MSN/Hotmail on the consume end. Naturally they will borrow heavily from the Blogger API etc. but ultimately decide they need to create Microsoft-specific interfaces. In fact I'm kind of surprised all this hasn't happened already - is BillG slipping up?

I find it interesting that - if one presumes that Web log authoring will say be built-in to Office 2004 and Web log server technology will ship bundled with Windows Server that the question of "should Bryant use Web log tools in creating its web presence?" could almost be a non-sequiter like saying "should Bryant use word processing tools in creating its printed documents?"
Stakeholders of school web sites

the primary information authors: teachers, administrators, librarians, PTSA and otherwise involved parents, activity leaders, children

the primary information consumers: parents, children, teachers

I find it interesting that much information communication in the school fits the 1:many author:reader pattern. E.g. teacher to parents of his/her students; chess club coordinator to chess club participants and parents; principal to school community; librarian to school community. Or in the case of school news or PTSA news it's perhaps several authors to many readers. Of course by using the term "reader" I don't intend to deprecate the commenting and other feedback and dialogue opportunities that can and should be encouraged. But it's simply a fact that this 1:many pattern is a match to the general organizational structure of a school. And, happily, is a great match to the assumptions built-in to blogging tools.
More on tool choices - of course to the degree that the Bryant site needs full-scale portal features Slash should also be considered. Perhaps even a step further down the difficult-to-administer open source slipperly slope from Movable Type, but clearly scalable and not narrowly blog-specific.
Tool choices. Pragmatically it probably comes down to Movable Type or Manila since both offer server solutions with multiple-author CMS features. Manila probably has a slight edge on supporting more general web site construction and Movable Type has a slight edge on adoption rate. But it may come down to whether a Windows server solution or a PERL/Unix solution is preferable to those who will have to setup and maintain the installation.
Well maybe it's not just convenient tools: another benefit is that Web logs inherently promote more usable Web content. Latest-information-first presentation, short pithy information "chunks", with "Read More..." links to details, cross-links to background information and other relevant sources, visible information creation dates to help provide context: these best practices for Web publishing are all well-supported by Web log tools and reinforced by the patterns of existing Web logs.

the "blank canvas" provided by traditional web publishing processes does not inherently guide content creators. but busy teachers and administrators don't necessarily have the time and inclination to become masters of Web publishing style - nor does a school web site have a compelling need to break new ground in Web publishing memes. so using tools which naturally guide communication into known, useful channels at the expense of some sacrifice in expressive freedom seems to be, on balance, a good tradeoff.
A very stale elementary school Web log site raises many questions. Probably have to call them and get a take on what happened. School board meeting minutes hint of staff turnover and technology challenges - and there's no sign of that this web site has been superseded by another - but it's all very murky. It looks like the school bloggers got significant help which makes the zombie state even more disturbing. Of course as per the below it's clear that blogware in and of itself isn't a silver bullet but still, this makes one wonder...
Of course a blogware-based Bryant website could still fail. There are cultural issues here - if teachers and administrators simply don't really need to disseminate timely information online, or if even a much-decreased level of required effort still is too much for overworked, underpaid educators, if more parental kibbitzing is more of a negative than a positive, and/or if there really aren't enough connected Bryant parents then it just doesn't matter. But - if that turns out to be the forordained outcome, then (assuming we're going to have any Bryant website at all) setting up up some blogware and slapping on a Bryant theme is likely to be orders of magnitude faster and cheaper than any other solution. So in other words, Bryant-via-blogware is definitely the right implementation architecture if it results in a vibrant, living web presence but it's probably still the right approach even if it doesn't!
Over on Syllabus Phillip Long has a good summary article about Web logs in education, including numerous links. His comment that "Blogging software makes the expression of writing, including the incorporation of hyperlinks for publishing on Web pages as easy as word processing" perfectly captures the primary benefit of blogging that I see applicable to Bryant at the school and classroom level.

I don't think that Bryant should blog because the Semantic Web is the Next Big Thing, because blogging is a transformational filtering mechanism in the dissemination of information, because the blogosphere is now the wellspring of creative expression on the planet, or any other high-minded philosophical motivations. Rather, I think Bryant should consider using blogging tools to foster creation of a live, community-building site that works, simply as a newly available alternative to using more cumbersome Web publishing tools and processes which risk our school site ending up as underused brochureware, if not stale and dead.

Will Richardson of weblogg-ed.com has a good presentation on Weblogs in the Classroom

The presentation covers many possible uses of Web logs, but my primary thought for Bryant - a Web log implementation of school and class home pages - is exemplified by
Delano High School and
British School of Amsterdam