Wednesday, December 19, 2007

Sunday, December 16, 2007

Thursday, December 06, 2007

Update : for people wondering how the whole new-SdiDesk-in-Adobe-Flex? thing is going. I solved something I thought was a problem yesterday.

I now have a (very fragile) Flex front end which can pass plain-text GeekWeaver programs to a web-server with GeekWeaver embedded, and get a compiled chunk of GeekWeaver out.

That's very cool ... unfortunately it also revealed yet more problems with the GeekWeaver compiler which need fixing before I can release the next version.

Still, it looks promising. The signs are better and better that something interesting is coming out in the next 3 months. :-)

Wednesday, November 28, 2007

He he! Perhaps NooRanch is NooVictorian ....

(I know, bad, bad pun)
What's this?

  • 1
  • 2
    • 21
      • 211
    • 22
  • 3
  • 4
    • 41
    • 42
    • 43
      • 431
        • 4311
  • 5


An HTML list that came out of GeekWeaver, when I called this recursive function :



::rec
.<ul>
:for x,, #__
.<li>
${x/=}
:hasChild x
:rec ++ #x__


on a chunk of OPML.

That's pretty much how it's going to look, folks.

::rec defines the recursive block (or function)

.<ul> creates the UL tag

:for x,, #__

is creating a loop through all the anonymous (unlabelled) children of the tree which is being passed to the call. (This list is represented by the symbol __)

Note that I'm trying to keep GeekWeaver as functional as possible so there's no real "assignment". x is scoped so that it only exists inside the block of the for-loop, it's bound once before the block is evaluated, but can't be updated after that.

${x/=}

This is the new way of accessing variables. x is actually bound to a sub-tree (Almost everything in GeekWeaver is a sub-tree, except a couple of weird cases like __ which is a list.)

Although a simple $x still works if you want the whole of a tree flattened into a string, ${} expressions give you a way to pull data from a single path in the tree. In this case we're just getting the text content of the root node of x.

But it's also possible to write stuff like this : ${company/employees/__3/name} which means from the symbol "company" get the labelled child "employees" from which get the non-labelled 3rd child, from which get the child labelled "name".

:hasChild, like :for, is a build-in function. If the tree in x has any children, it evaluates the body of the :hasChild tree. If not, it returns nothing. This tests for our "base-case" when we've hit a leaf of the tree we're recursing through.

The final line :

:rec ++ #x__

is the one which I've been struggling with for the last three months, ever since I started trying to figure out how to support recursion. I'm still not 100% happy with the solution I've come up with, but it's getting there.

:rec is calling the recursive block again. And obviously I need to pass the children of x as arguments. However the way the function is written, it is working on the anonymous children (inside the default variable __)

How am I going to get the children of x into the __ variable inside the next call of :rec? That's what ++ does. Not sure what I'm going to call this, I may call it a "pivot" although that may confuse as much as help. It captures something of the idea that I need to swing the anonymous children of x (#x__) around so that they can go into the next call of :rec as though they were children of the calling node

Like I say, don't know if I like this name or the ++ symbol being used for it. So consider both as provisional for now.

OK, I'm too tired to make the build with this stuff working tonight. I'll try to get a build together in the next couple of days, but meanwhile, if this looks interesting to you and you can't contain yourself, send me an email (interstarATgmail.com), say hello and I'll see what I can do.

Sunday, November 11, 2007

Hey! I like NeoVictorianism.

There's a movement I can sign-up for :


Built for people

Built by people

Crafted in workshops

Embracing irregularity

Inspired


Thursday, November 08, 2007

Just spent the last few hours downloading and playing with the beta of Flex 3, Adobe's IDE for Rich Internet Applications (ie. applications running on the Flash Virtual Machine) which is based on Eclipse and has an XML-based UI / form description language more or less like HTML.

I'm having two thoughts about it. One is a kind of sigh of relief. This is, after all, finally, The One. After years of fruitless searching I'm pretty sure here's a framework I can settle down with and commit to, and start making babies with. At least, it's more or less mature enough, handsome enough and well endowed enough to put these thoughts into a girl's head. A browser and a desktop? Holidays in Windows, Mac and Linux? Own grid and canvas. Tabbed notebook and some cute chunky buttons.

And it's all done in a way that's pretty self-evident when you look at a few examples. Forms and input widgets are described in XML. They layout nice; and you can start banging them in and prototyping the look of your interface in a couple of minutes. The round-trip from coding to running and testing is a bit slow on my poor 512MB Vista laptop, but it's going to be bearable. And the Eclipsyness of it all is comfortingly familiar if a trifle overblown.

As long as my next experiments turn out right (the one where I try to find a tutorial example of pulling data off a server over http, and the one where I try to compile with AIR into a stand-alone application) then I'm sold.

But there's another part of me going, "huh? Is this all there is? WTF?"

I mean, it's 2007 and I'm happy because I've finally found a way to make GUIs that's sufficiently lower than my pain threshold that I might actually get a piece of software released again. Zowie! But that's what I had with Visual Basic 6 - which came out in about 1997!

In fact, I was already a Pythonista before I started writing SdiDesk in VB. And I only pulled out VB (a language I thought I'd left behind for good) because I got impatient to see what the UI of an SdiDesk could look like and thought I'd prototype it. As often happens, the prototype spiraled out of control as I kept thinking, "maybe I can just also add ... " and within a month or so it had already started to grow into a real program. Another phase of development with some serious refactoring and cleaning up the internal architecture, and it was a quite respectable and powerful bit of software (If I say so myself; I'm talking about the time I made the tutorial screen-casts.)

(Then, of course, I hit the crisis of not wanting to be on the Microsoft treadmill and forced to upgrade to .NET; even though it was obvious that VB6 was as extinct as a very extinct thing from the Lower Devonian period. But also of not having any viable alternative. )

So there's a sense that Flex smells extraordinarily similar. I can see how you can knock out your prototype interface and start building backwards from it. That feels good. That's why it seems like this is plausible option to get development rolling again.

But, like I say, it *is* basically what I had 10 years ago. Except with javascript dressed up in Java's suit and tie to look more grown-up and respectable. And XML.

In fact, I was gchatting to Zbigniew earlier today, and realizd that all of this stuff is hardly a big advance on Hypercard back in 1985. Or perhaps Smalltalk 1972. Why the hell haven't we progressed further? Why am I struggling on each new platform to rediscover the level of comfort I had on the previous one? What's going wrong here?

I suppose it could just be that the idea of quick GUI builders is inherent in the idea of a GUI?

Or maybe we programmers of the noughties need to get our acts together and start coming up with serious new, cool shit. Stuff which couldn't have been thought up in the 60s and 70s. Stuff which is radically easier and more productive than something we had 10 years ago. Something like reinventing Lisp with a cleaner (non)syntax ... erm ... well anyway, I'm off to do more experiments with Flex and try to get it to talk to some kind of server.

If I succeed, then expect to see some interesting developments along the lines I mentioned earlier today ... steps towards a new SdiDesk, possibly a GeekWeaver development environment ... maybe even the long fabled, but never released SystemSketch. Or even the more outré things I've got buzzing around in my fevered imagination like "SexyCells" and "FlowerBrush".

Of course, it still sucks that Flex / Flash seems to have no musical ability whatsoever so Gbloink! doesn't look like an option. Which is a double pity because I think it would make a great Chumby widget and that would have justified me buying one.

:-(
37 Signals on why enterprise software sucks
Quick Note : I just had a revolution in my thinking, triggered by Enso but influenced by several other recent trends.

You write Enso "extensions" as XML-RPC servers sitting on your local machine, register them with Enso and it calls them using XML-RPC. I tried the example from the tutorial and it's very cute and simple. So I've decided this may be a way forward for the dilemma which has kept the "new SdiDesk" on hold for several years(!!!)

If you remember, the issue has been whether the new SdiDesk should be a "web"-application (accessed through the browser) or a desktop application? And how to implement the UI.

The problem with the "browser" answer has always been : "but how to do the network diagramming bit?" - which requires interactive vector graphics. SVG doesn't seem quite stable or cross-browser enough. Canvas isn't cross-browser. Flash is proprietory.

The problem with the "desktop application" is, well, the many rival Python GUI libs with different degrees of maturity. And the question of getting them to work cross-platform.

A meta-problem : I just don't have time and energy to go through learning lots of different GUI frameworks to decide which I want to use. And the ideal answer to the browser / desktop question is probably "both" which doubles the amount of work.

In fact, one of the motivations for GeekWeaver is to see if I can use it define a higher-level UI description that can be compiled down into both XHTML and a GUI widget-set.

Of course, with XUL, Open Laszlo, Adobe Flex, XUML etc. lots of people have been looking at something like HTML for defining desktop apps. too, but the free Python frameworks don't seem to have caught up with that yet. XUL sounds most promising especially with the open sourcing of Active State's Komodo ... but that's also a big complicated thing to even start looking into.

Anyway, inspired by the Enso extensions and Bruce Eckel's interesting example of hooking up a Python XML-RPC server behind an Adobe Flex application I've been wondering about blowing the project apart entirely into a number of services connectd only XML-RPC or something more ReSTful.)

So there'll be a WADS (SdiDesk PageStore) service, a GeekWeaver interpreter service, a "user navigation history service" etc. Even the glue which ties all this together will be another service that's neutral about the user-interface. Effectively the model, view and controller will be completely separate programs. (I know, I know ;-) )

Then there'll be a variety of different types of access with different UIs.

Now that Adobe's AIR has put Flash on the desktop and made it a serious rival to the Java virtual machine - I *am* tempted to put some time into learning it. It would give me a reasonable GUI widget set (including TreeGrid, yay!) and the vector graphics needed for networks. It will run both on the desktop and in the browser and on Linux, PC and Mac. The tools are free-as-in-beer (Flex beta) or free-as-in-speech (Open Laszlo). It's also possible to imagine generating the Flex XML or the Open Laszlo format directly from GeekWeaver. (Aside : I wish ActionScript hadn't borrowed quite so much from Java, but still, I'd only be using it for the front-of-the-front-end UI stuff.)

Then I want to experiment with Enso access - for example, Enso commands like "page HelloWorld" or "pagehistory ChocolateCake"

And there'll be web-browser access probably through a "gateway" that accepts http requests and spits out HTML for a browser. The only thing I don't know is whether I *really* should be using WSGI somewhere here.

Anyway ... that's a quick update of my thinking this week ... tune in soon for the next GeekWeaver release (really, it's coming together, and gonna be very powerful). Then it's back to work on this larger project.

Tuesday, November 06, 2007

Next installment of the must-read series on FogCreek's Wasabi.

Fascinating to see the problems they've come up against and the solutions. What Stefan calls "picture functions" sound close to GeekWeaver "blocks".

Thursday, November 01, 2007

Very interesting ... seems that FogCreek's Wasabi is a language to compile into the various parts of a web-app in ASP or PHP.

So kind of a competitor to GeekWeaver. :-) Better take notes.

I wonder if it's gonna be released to the public.

Tuesday, October 23, 2007

DAn McWeeney has a great post on what he calls "synthesizers" : which seem like generalist / hacker / blogger / communicator type.

Personally I think the existence of the web is pushing us all in the direction of being synthesizers.

Thursday, October 18, 2007

Important statement (actually essay / braindump) on my thoughts on widgets and YASNS over on my personal blog.

Wednesday, October 17, 2007

Mark Bernstein has a great post (and sounds like a great talk) on NeoVictorian Computing.

Wants to return software development to the personal and to making meaning.

Via Bill Seitz
Cool!

Thanks to Dave Stein I now have "programming" on my Behance Profile

Tuesday, October 16, 2007

New meme : GeekWeaver is Language Oriented Programming for everyone else.
Good weekend for GeekWeaver development ... you can now pass arguments to functions that are more or less table-shaped - like this :


:f Fruits
apples,, oranges,, pears
grapefruit,, passion-fruit,, grapes
bananas,, lychees,, mangos



It's not public yet, but it will be available in the next installer.

Also, although GeekWeaver is designed to be written in an outliner, I'm close to a plain-text mode which will look something like the above.

But I have a problem which I'm still not sure of how to solve. GW has to preserve literal text. So using spaces for indentation like Python is not so easy.


abc
xyz



could mean either a node "abc" with a child "xyz" or two nodes at the same depth : "abc" and " xyz". How can we tell the two apart?

Currently my plain text parser works with code that looks like this :


* abc
** xyz



Which keeps the continuity with wiki-markup and disambiguates from


* abc
* xyz



But it's pretty ugly if you really were going to do any serious programming with it.

Suggestions welcome.

Thanks to Zby for turning me on to Behance which seems to be an interesting combination of social networking for creatives backed by a GTD-style how-to-organize methodology for disorganized creatives, and has special stationery too. Yay!

Could fall between a lot of stools, or could be the next-big-thing (more fun than Linkedin, more serious than Bebo, easier to use than degenerate art)

I do like the explicit emphasis on trying to solve the problems of disorganized people.

I don't like that "software architect" is a creative label you can attach to yourself but "programmer" isn't.

Thursday, October 11, 2007

Monday, October 01, 2007

Just commented on a topic dear to the hearts of all smart, disorganized individuals over at Ward Cunningham's Vision Thing.

Friday, September 21, 2007

Resolver Systems seem to be a cool, python + spreadsheet company based in London - with the right attitude. Nice demo.

Hmmm ... and they're hiring ... (drifts off into daydreaming)

Wednesday, September 19, 2007

Joel Spolsky :


And your programmers are like, jeez louise, GMail is huge, we can’t port GMail to this stupid NewSDK. We’d have to change every line of code. Heck it’d be a complete rewrite; the whole programming model is upside down and recursive and the portable programming language has more parentheses than even Google can buy. The last line of almost every function consists of a string of 3,296 right parentheses. You have to buy a special editor to count them.


Spooky.

I mean, that wasn't exactly the whole GeekWeaver gameplan. But "high level" lisp-like language that compiles down into complex web-applications, is not so far off. I was thinking of Dojo as the Javascript library, PHP at the server, and Facebook itself (or Ning) as the layer at which applications can be glued together. So read with Marc Andreesen too.

It's the zeitgeist I tell ya'

Saturday, September 15, 2007

I'd forgotten that Processing Processing by Paul Ford was one of the inspirations for GeekWeaver.
Reading more discussions on the business of Joel has got me thinking about the problem of marketing GeekWeaver.

So here's the pitch ... in the classic 5 points of selling ;-)



    1) The pain you didn't know you had!


    Oh, the horror, the horror, too many tags too many files, you have to reach for the mouse and click to find the file menu and open up a new file and then scroll around in that silly little common dialog where the files are all represented by little yellow blobs that are 2mm square and then you click one and open and your hand has to come off the mouse and down to the keyboard and you try to scroll around but there are tags and tags and tags then you change something and you forget to close the tag and everything's position gets screwed up and you think ... oh if only I'd used CSS, but there wasn't time and anyway you have twenty pages the graphic designer made by copying and pasting in Dreamweaver (oh BAD Dreamweaver) and now the client wants them all changed and if you were working with a content management system you'd have put some common things into includable subtemplates but you don't have that and you think why am I watching the grains of sand draining through the hourglass of my life doing the same mechanical transformations on dozens of static html and xml files and you know the customer will only want them changed again next week .... aaaaiiiighhh why can't html be like a proper programming language instead of this ???? WHY GOD? WHY??


    2) The generic solution.

    Yes, a programming language. That would have the requisite controls over abstraction that I need. And a decent IDE. If only writing HTML files could be more like a programming lanaguage.


    3) Our solution is your solution.

    Fear not because GeekWeaver will solve all your problems.

    All your pages are kept in one file, which you can navigate around with the keyboard in the comfort of your favourite OPML editor. You never have to close an HTML or XML tag again with the .<tag> notation that takes advantage of the outline structure to know what blocks are meant to be inside what blocks. Never, ever copy and paste when you can define your own re-usable, parameterizable blocks at any level you like including outside the level of a single page ... that's right folks, you can define a reusable component which actually evaluates to a number of pages or other output files.


    4) Accept the price

    Think ... just think ... of the hours of your time that could be saved if your static web-pages (and everyone has a few tucked away somewhere - remember that old departmental intranet-site no-one's been updating in years? Remember that customer who needed to access the documentation off-line?) were all safely in GeekWeaver format? How much would that be worth? (And at 50 quid an hour you're underselling yourself, but hours of tranquility can be bought for a mere ... well, let's see download and install Python 10 mins on Windows, probably already have it on Linux and Mac. OPML editor? 5 mins on broadband. GeekWeaver ... 2 mins?


    5) Act now!

    Get it today! because it's Saturday and you know you'll be too busy wasting time manually editing HTML once Monday comes around. And if you're an early adopter, and send me emails, then I'm more likely to listen to your requests and stuff ...


An idea I had, over at Joel's Business of Software :

Here's a thought.

I was re-reading this a couple of days ago :

http://www.joelonsoftware.com/articles/fog0000000348.html

as I'm trying to persuade the overworked developers in the place I work to take some time out for this kind of cleaning.

And it occurred to me that there could be a market for specialist code-cleaners. After all, you have specialist office cleaners instead of making the clerical staff take the Dyson around after work. Why not somewhere you can outsource legacy code to simply be carefully and lovingly refactored and polished without any claim that this company are doing new development?

Normally companies from rich countries imagine they can bang out a few UML diagrams, ship them off where labour is cheaper and have it coded up. We all know that this is a fallacy (coding and designing are too tightly entwined).

But could "take my OK but ugly code, with these existing unit tests, and return it with identical behaviour but all the HTML tags closed and the variable names consistent" be a more viable way of dividing labour?

Anyone know of anyone currently offering this? Could "code cleaning" be a small service business? Maybe even part-time for people who have a few hours free each day to work from home, know how to code, but can't commit to a full development job?

Friday, September 14, 2007

I've done a slightly improved GeekWeaver screencast.

Still very sketchy, and without audio, but the SWF is smaller, and shouldn't crash.

It just concentrates on the basics :

* making several pages
* using the .tag notation with outline indenting to save on closing HTML / XML tags
* defining a reusable and parameterizable block (in this case, page template) and calling it for each page.

I'll try to get the next one done in a few days, with some more surprising capabilities.

Monday, September 10, 2007

I've been struggling with Python's distutils over the weekend, and I'm finally making some progress. There's a new GeekWeaver page and a new release.

The page is part of a revamp of my personal site, which is now being built with GeekWeaver. And the release is the first built with distutils.

I was hoping that it would put the code somewhere on the PATH so that you can include the GeekWeaver modules from anywhere, but that doesn't seem to be happening. So although the code goes into "site-packages" I'm not sure what that buys you at present. Any Python experts able to shed some light on this?

What's definitely happened is I tidied up the whole directory structure. Unit tests and library modules are in sub-directories, and you can run the program from wherever you like as long as you give the right path to the gwMain program.

If you go into the "examples" directory in this new distribution, you'll see some examples of .bat and .opml files. You should be able to run the .bat directly there. You can put your own projects in their own separate directories using this as a model.

As always, I'm keen to have feedback, questions and suggestions for GeekWeaver. It's starting to come together although I also need some proper docs and screencasts to really show what it's capable of. The example files show the most basic (but most useful) features of GeekWeaver, the fact you're using an outliner for your whole site, the fact you can manage multiple pages within the same file, the way you can use .< notation to save yourself having to close tags, and the definition of re-usable, parameterisable blocks.

There's a more complex example of GeekWeaver's power in the tests sub-folder. It's not that well explained yet, but it shows how you can produce tables, how you can map a block-call to a sub-list of items, define blocks which are bigger than a single page, and pass block-names as parameters to other blocks.

Thursday, August 02, 2007

I see Zbigniew beat me to blogging about wiki-wednesday. That's one of the perils of laying around in bed all morning.

He's dead right about Alan Wood's presentation being very exciting. I'm probably even more impressed by Wood's "Rel3" than Zby is.

What most impressed me was Alan's apparent good taste that seems to be formed by real experience. Rel3 isn't an attempt to take a particular genre of social software as it exists and force it into the enterprise, but a crafted, pragmatic response to particular needs.

Yes, it looks very like a non-threaded discussion forum. In fact it's also a bit like a page of "River of News" for a single issue being handled within a group. There are echoes of TopicExchange and explicit inspiration from Twitter.

Behind the scenes things seem just as interesting. Written originally in Java, then ported to Rails and now to Erlang. It's designed to use Amazon's S3 and EC2. (The fact that it keeps data in files on S3 prompted leaving Rails.) Each page (or conversation) allows files to be attached so you can manage Word, Excel, PDF docs, etc. When asked if he's thinking of creating some kind of Ajaxy online editor for collaborative documents, Alan sensibly says he won't re-invent the wheel but will provide hooks to other providers of this kind of stuff.

In other words, this is a very nice, minimal "glue" to tie together the people and resources that temporarily need to be brought together to solve a particular problem. After which the page doesn't hang around cluttering up your ontology when you have lost interest in it. (I mean, it probably *does* hang around. But Alan Wood, interestingly, contrasted Rel3 with wikis which allow a small group to work producing a more permanent document that must stake its claim to some part of the name-space.)

In this, it has some of the best features of other social software, in particular, I think it has potential to rival email's special power of spontaneous group forming and dissolving. Let's see if actually creating, subscribing and unsubscribing to pages can be quick enough.

Also, Alan has a very smart blog at Folknology

Thursday, July 12, 2007

Know what QEDWiki reminds me of?

Visual Basic.

And I mean that in a good way ... ;-)

Wednesday, July 11, 2007

IBM's QEDWiki looks pretty nice.

This is really taking wiki in the direction of application development tool that I've been dreaming about for ages.

Wednesday, July 04, 2007

Fairly crummy screen-cast of GeekWeaver basics (no sound, sorry)

Need to find a decent screen-recording software. Anyone got any suggestions?

More soon ...

Monday, July 02, 2007

OK ... everyone who's wondering why I've been so quiet and apparently unproductive lately ... very soft (in little more than a whisper) announcement ...


GeekWeaver is a mutant cross-breed of outlining, wiki-attitude, templating and some duct-tape that would like to be a programming language ...

tell you more soon ...

Tuesday, June 19, 2007

Listen everyone, I gotta come out to you all ...

I am now officially an outliner.

For a long time I thought that outlines, like all hierarchical documents, were limited and inferior to graph-shaped wikis.

Now I get it.

The point of the outliner is not the hierarachical structure as a navigation aid - free-form hypertext is still superior.

No, the point of the outliner is the collapse which lets you manage and manipulate bundles of items at the same time. That's something I never managed to get right in SdiDesk. Although I perceived the need for a "PageSet" to create a bundle that could be used for, say, exporting etc. I a) never got that working technically, which was partly because b) I never really made sense of it "conceptually" to myself.

What's great about the outliner is its "scale-free" / "fractal" / "recursive" / "self-similar" nature - which means the same operations (collapse, copy, move, publish) can work on anything from a short list, to a chapter to a volume composed of multiple chapters. I've really started to realize this over the last few months as I've used the OPML editor for more things that I'd have once used SdiDesk for.

Now, don't get me wrong. I still love wiki. It's still my favouritest type of software in the world, ever. And I still use SdiDesk every day. But now, I'm starting to appreciate that there's a need to manage a hierarchy of scales, and until I find out how to combine that with wiki-nature (and into SdiDesk), I'll probably be outlining most days too.

(In my day-job I also spend a whole lot of time with spreadsheets, but that's another story. SdiDesk was always meant to handle grid-shaped data, it just wasn't developed enough to be really usable.)

Thursday, May 31, 2007

Sig :


You talk to one person. You lunch with one purchaser. You present for one or more, same Powerpoint. Why the difference? It's all about people and a person is singular, always.

Tuesday, May 22, 2007

David Brin has a nice post summarizing his vision for "what we need from science" :

Given the daunting range of problems and opportunities that we face, I'd have to say that our most urgent scientific and technological need is to develop better methods for problem-solving.

Some pieces to the puzzle are already getting attention. Governments and big institutions are developing ways to combine sensor meshes and data mining with powerful analytic and projection tools. But this emphasis on centralized or professional-level anticipation ignores the other half of the solution -- generating a resilient citizenry. A populace so knowing and capable that all problems get noticed and addressed, quickly, by a billion eyes


Great point!

What Brin understands is that the "collective" and the "individual" are not in opposition but that smart, disorganized individuals can come together in dynamic, ad-hoc networks to solve problems.

Traditionally, we've relied on certain types of static "organization" (typically hierarchical and procedural) to achieve the benefits of acting collectively. These work. But at a high cost. They're often dumb (information flows badly through hierarchies because no one passes bad news up, and the top becomes a bottleneck); inefficient (participants waste their energy politicking against each other); and unpleasant.

In contrast, we want (and can start to seriously imagine being able) to retain our capacity for individualistic action while working together in loosely co-ordinated, ever changing but highly effective groups. The internet has taken us a long way in this direction, but as Brin points out, there's still room for more scientific understanding and other tools to take us further.

Thursday, May 03, 2007

Q : Phil! Why have you put a Grazr widget in your gutter?

A : Something's happening. And it's about OPML, Grazr, and widgets ...

;-)

Q : Oh, and I noticed you changed the template.

A : Er ... yeah. The look didn't go with the widget. I wanted something that was more, I dunno, evolvable.

Q : What are you up to, exactly?

A : You know, general house-keeping, wanting to learn about new things. The truth is I've been using the OPML Editor a lot recently. Even tried to write a several thousand word essay in it.

And it's good. Perhaps I'm getting the outlining religion ...

Friday, April 20, 2007

Cool video showing WikiCalc embedding YouTube. And showing several evolving lines of thought in the multiple texts being created.

Tuesday, April 17, 2007



Bleaahhhgh! Least inspiring Hughtrain cartoon evah!

Thursday, March 22, 2007

There's a new crop of business wikis. And some interesting discussion.

But what's wrong with this picture?


SystemOne, an enterprise-knowledge-management system masquerading as an ordinary business wiki. What's cool about this product is that it automatically creates, at the bottom of each page, a list of relevant other wiki pages, feeds, and Web search results. The autocreation of the links removes some of the need to manually create links to connect wiki pages together. This is a key feature if the wiki is to be used by a lot of people who aren't hypertext-savvy.


Answer : Everything is wrong here.

Firstly, what's the point of automatically making hyperlinks for people who aren't web-savvy? Or rather, why are you trying to get people who don't understand hypertext to use wiki? (In fact, in 2007, why are you even employing people who aren't hypertext savvy? But that's another story.) At the very least you should ask how exactly they are going to use wiki if they can't understand what hypertext is, or have some intuition about how to use it?

Remember, this is wiki we're talking about : all the hard graft of making links (like the trivially fiddly writing of "anglebracket a href", and the genuinely tricky part about finding the right URL to point to) has been eliminated by the simple WikiWord or [[double square bracket]] conventions. What's left is the only other difficult question : deciding what links to make.

SystemOne "solves" that part for you. But remember, the links are part of the valuable decision-making and information that goes into your wiki. Wiki links are not meant to mean that "this page is vaguely similar to that web-page". If I want to know what pages are vaguely similar I can use Google. Wiki links mean "I, the author, want the reader to notice this kind of similarity between this page or this paragraph or this word, and that page because I think it's significant." Which is far more precise and subtle piece of information.

A wiki which automatically creates links is as useless as a word-processor which claims to write your letters for you.

The purpose of creating documents is not to kill trees or fill up as much disk space as possible. The purpose of creating documents is to capture the value added by human intelligence. Attempting to automate away that, in order to help consume more wood-pulp or fill the screen with more blue-underlines is counterproductive. Bad links devalue the good links. The reader of a page is overwhelmed and confused.

Tuesday, January 30, 2007

Joel Spolsky on a good hack :


I think what makes a good hack is the observation that you can do without something that everybody else thinks you need. To me, the most elegant hack is when somebody says, "These 2,000 lines of code end up doing the same thing as those 2 lines of code would do. I know it seems complicated, but arithmetically it's really the same." When someone cuts through a lot of crap and says, "You know, it doesn't really matter."

For example, Ruby on Rails is a framework that you can use with the Ruby programming language to access databases. It is the first framework that you can use from any programming language for accessing databases to realize that it's OK to require that the names of the columns in the database have a specific format. Everybody else thought, "You need to be allowed to use whatever name you want in the database and whatever name you want in the application." Therefore you have to create all this code to map between the name in the database and the name in the application. Ruby on Rails finally said, "It's no big deal if you're just forced to use the same name in both places. You know, it doesn't really matter." And suddenly it becomes much simpler and much cleaner. To me, that is an elegant hack—saying, "This particular distinction that we used to fret over, just throw it away."