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.