 |
danbricklin.com/log
|
|
|
About wikiCalc 0.1
|
What is wikiCalc?
The wikiCalc program is a web authoring tool that creates normal web pages. It is for creating and maintaining web pages that include data this is more than just unformatted prose, such as schedules, lists, and tables. It combines some of the ease of authoring and multi-person edit ability of a wiki with the familiar formatting and data organizing metaphor of a spreadsheet.
Like ListGarden, it can be run client-side as an application that publishes by FTP or server-side using CGI. It will, hopefully, run on Window, Mac, and Linux/Unix. When run client-side it needs no server-side CGI setup (unlike most wiki systems) but can still support multiple authors at different locations (it has a simple check-in/check-out scheme built-in). It can publish to basic web hosting space like most people get from their ISP or with an inexpensive shared hosting account.
wikiCalc is written in Perl and I'm planning to release it under the GPL, with an optional dual-license for those who don't want GPL (and want to pay me...). I do not have a business model that makes me want to force people through servers I control, so it gives me freedom in system architecture. I just try to make available a variety of architectures to choose from so you can use what best suits you, not just me.
The program can do many common spreadsheet operations while authoring, including numeric calculation and sums across ranges, formatting, and copy/paste/insert/fill (though it is not meant for heavy duty spreadsheeting or serious calculations). It handles freeform text in a wiki-like manner and works well with large blocks of text. It publishes through a template much like many blogging systems so you can easily create pages with a common graphic design and boilerplate.
The user interface runs through a browser using a bit of Javascript to make it respond quickly and appropriately to clicks on the screen and some keystrokes like Enter, but most processing is done in the application and not in the browser like a full AJAX system (this is at present -- who knows where it might go if necessary). It does not do anything with RSS or XML at present, but the Alpha version can import text in simple list and CSV formats to make testing easier.
Why did I create it?
Why did I do this? I was looking for a follow-on product to ListGarden. ListGarden was quite well received and continues to get new users every day. I've learned a lot about the Open Source development and business world from it. However, RSS creation on a standalone system is a very small market. Most people who create RSS feeds are using a content management system of some sort (such as a blogging tool) that creates the RSS for them. I don't get much time to program and would rather help more people for each hour spent. If users of a future product are as happy with my work as ListGarden users tell me they are, it should be worth it. Also, my consulting practice has benefited quite a bit from having released ListGarden compared to the time spent developing it.
The logical place to go after a product that created simple lists (RSS feeds and companion HTML pages) was to move further into the list/data publishing area. I knew there was a need for sharing lists and tables of data online through the web. Products like Intuit's Quickbase that let small workgroups share task lists and prospect lists were being used, much as Lotus Notes has been used for years. Unlike those professionally managed systems, I wanted a simple standalone product that didn't need someone else's service and that was easy to set up and in any budget. I wanted something a kid's soccer team, small office, or PTA could use.
The user interface problem, as I looked into it, was that it is tough to make an easy to use product that lets regular people do enough customization of the output of many forms of simple data. All of that forms set up and report generation set up is such a mess to make easy. But people want something, I guess, and will even put up with generic layouts, though in general people really do need to customize things. Quickbase was being used even though in the past to customize the output you sometimes had to find someone geeky enough to create XSL transforms, something few people know how to do (I think it has improved since but you have to pay extra).
Then one day it hit me. What is, reportedly, the most common type of database system for maintaining and sharing simple databases? A spreadsheet. Oh, no! That means that I should implement a spreadsheet as part of the system. Compared to my low key ListGarden, how very public that would be, going back to my past, and, worse yet, since it will be Open Source everybody can check out my messy coding style and find my novice bugs in an area connected to my name and reputation. I've only prototyped spreadsheets before and did a little bit of the code. Bob Frankston (VisiCalc) and Bill Lynch (Slate's At-Hand pen computer spreadsheet) did most of the actual spreadsheet engine coding, not me. I hadn't worked out all of those hard problems before. I decided with trepidation to go ahead. However, when Dave Winer came out with his OPML tools, Mr. Outliner creating another outlining tool, I knew that I was another part of a wave that's OK to ride.
A spreadsheet is a metaphor that many, many people understand and are comfortable with for creating interesting layouts - probably a lot more than those who know how to do HTML editing with tables. The spreadsheet metaphor with its common functions very explicitly lets you work with a style of table cells that allows you to create and maintain a myriad of layout arrangements appropriate for data presentation. It isn't just a table -- it's a two dimensional space on which you can place items wherever you like and where you know how to rearrange things. I felt that while you would edit in a spreadsheet with the A-B-C 1-2-3 grid showing, the final output, like the printout from the productivity product, would be static and only show cell borders where you explicitly set them. Calculating is for authoring and maintaining, not reading, in this case. Anyway, most data will probably be static text or numbers. You usually will only need a little bit of calculating at most, such as for line numbers or totals.
As I was starting to code, I kept thinking about names. I wanted something that sort of explained what this was. I tried SpreadGarden because it is like ListGarden and "Garden" is a registered trademark my company owns, but that sounded too much like using fertilizer, not web authoring. Then one of the few people who saw an early version suggested "wikiCalc". Again: Oh, no! Calling it "calc" too blatantly reminds people of my past and makes it sound like I did this for the name, but it describes the product so well that I just had to use it. It's such a good name. (Pretty much everybody I told about it smiles and tells me to use it.) I checked with Bob Frankston. He didn't mind. And wikiCalc.com was available... Unfortunately, with a name like that I had to make sure that the program calculates and not just stores numbers, even from day one. Sigh. There went a lot more programming before I could show it off in alpha.
So, now I have a new product -- one that will probably have more users (or at least try-once'ers) than ListGarden and give me more experience with the world of Open Source products to help the business models and Open Source part of my consulting practice and speaking business. I hope it helps more people share the data they need to online and that it serves as a learning experience about differing authoring system architectures. This should be interesting.
- Dan Bricklin, 9 November 2005
How to find out more: The wikiCalc Alpha Test home page has screen shots and instructions for downloading and running.
January 12, 2006: A new release, version 0.2, is now available. This version uses AJAX techniques for improved cell editing and runs on Mac and Linux/Unix as well as Windows, client-side and server-side.
January 25, 2007: Version 1.0 shipped. See "wikiCalc goes 1.0!".
|
|
|
© Copyright 1999-2018 by Daniel Bricklin
All Rights Reserved.
See disclaimer on home page.
|