So at the end of April 1995, I joined other early contributors to the Web in Australia in Ballina.

According to Helen Ashman and Adrian Vanzyl's report on the conference in the ACM SIGLINK Newsletter (Vol. IV No.3) there were 140 participants and the conference and at least that many more on the waiting list!

Again it's hard to convey nowadays just how small the Web community was at this time (early 1995), especially in Australia. So it was with huge excitement that I found out there was going to be a conference: The first Australian World Wide Web Conference (AusWeb95).

I submitted an extended abstract for a paper on the Hellenistic Greek Linguistics site as a case study of how to run a collaborative academic project on the Web. It talked about the mailing list archives and even how I achieved Greek display via GIFs of each character along with a Perl program that would translate BETAcode (which is what was used for representing Ancient Greek in ASCII at the time) into HTML IMG elements referencing the GIFs.

My paper was accepted so I just had to work out, as an undergraduate student how to fund it: flying cross country, accommodation, and the conference registration itself as there was no student discount.

The linguistics department said they had no money to send undergraduate students to conferences. Phil Dufty at UCS offered to fund my flight. The conference organisers arranged for me to stay at a local caravan park rather than the conference hotel.

I was continuing to dive more in to SGML at the same time as trying to keep up with developments happening on the Web (despite not being able to participate in the W3C).

I was also running courses on HTML at the university that were very spec-based. Looking back I was very pedantic about SGML and markup and the HTML specs and was quite a jerk about it.

But I was getting frustrated at the amount of bad information out there!

At the very start of 1995, I had launched the Hellenistic Greek Linguistics site. Here's the announcement to the LINGUIST LISTSERV (January 2nd, 1995):

ANNOUNCING: Hellenistic Greek Linguistics on the Internet [with apologies for any multiple postings]

I am pleased to announce new resources designed to bring together scholars interested in the study of Hellenistic (including New Testament) Greek Linguistics.

These resources include World Wide Web pages (accessible with such programs as Lynx, Mosaic and Netscape) as well as a mailing list. As well as general discussion, the list (which is archived on the Web pages) provides a forum for discussing the new reference grammar planned as a complete revision of Blass, Debrunner and Funk's standard work.

The Web pages include bibliographies and a (newly started) electronic archive of papers.

To browse the Web pages, go to the URL:

http://tartarus.uwa.edu.au/HGrk

To subscribe to the mailing list, send a request to:

jtauber@tartarus.uwa.edu.au

and to send a message to the entire list, write to:

greek-grammar@tartarus.uwa.edu.au

Please feel free to make enquires to jtauber@tartarus.uwa.edu.au

James K. Tauber (jtauber@tartarus.uwa.edu.au) 4th year Honours Student, Centre for Linguistics University of Western Australia, WA 6009, AUSTRALIA

We had a compulsory introductory courses we made all students who got Internet accounts do that covered the basics of netiquette, password security, email, network news, and the Web.

I remember during the Web part of the course introducing people to Lycos as the search engine, IMDb (then called the Cardiff Internet Movie Database and mirrored various places), and Yahoo (when it was running at akebono.stanford.edu/yahoo).

In 1995, I was in my final (honours) year and working at UCS doing both basic systems administration of the student systems and providing user support, including running training courses.

A few weeks ago, I had a great example of an interest that consumed my attention for a day but didn't last beyond that.

My wife and I went to the ballet.

I've always had this happen with ballet: I get obsessed with it briefly and then my interest fades. Back when I was 8 or 9 I attended my younger sister's ballet performance and wanted to become a dancer. It never went anywhere. A couple of times as an undergraduate, I went to the ballet. Always loved it at the time but nothing ever came of it.

So anyway, we went the ballet a few weeks ago. When I came home I spent hours reading up on terminology, watching videos of great dancers doing particular moves. I was obsessed. For just that day.

I woke up the next day and went back to Greek and linguistics. Maybe Carl Djerassi would call that the equivalent of meeting up with the same person every few years for just one night.

TeuxDeux

A while ago my friend and colleague Greg Newman recommended https://teuxdeux.com as a task manager. I've tried a lot of different task managers but none have really stuck. TeuxDeux has.

I think the main reason is it takes such a simple approach. There's no attempt to have projects, tags, contexts, priorities or anything like that.

You just have a list for each day plus labelled lists not attached to any day.

Items not completed on the day just get moved to the next day. Markdown is supported in items and I sometimes use this to make little headings to separate tasks into sub-lists (--- also works nicely as a separator). There is very basic support for recurring tasks.

What I like most about the approach is:

• it's very easy to plan out a week and see what you have coming up at a glance
• it's perfect for ticklers: I can easily put items in the list for a day next week or next month
• it's nice having a few non-date lists available at a glance

Regarding the third point, I'll note that I don't use it for all my lists of things (I use https://workflowy.com for that) but it's nicely to have a few lists easily viewable. Although they claim it's useful for Someday / Maybe items, I prefer those not to clutter my thoughts on a daily basis so I put them in workflowy and use the non-date lists in TeuxDeux for things like monthly or quarterly goals, daily routines, etc.

If you're well setup with something like Todoist, Things, or Nozbe, you might find TeuxDeux a little too basic but if you've found you can't stick with one of those heavier tools, and are really looking for something just slightly better than a text file or physical note book, TeuxDeux is worth checking out.

One final thing I find interesting about TeuxDeux: the developers say it's complete. It does what they set out to build and they aren't adding new features just for the sake of it. That's refreshing approach and I think it's worked well for this product.

Just read this exception message in some code:

"You cannot log responses in a session that has completed."

which is slightly ungrammatical to me (I would need to use the passive "has been completed").

It's interesting the difference between "complete", "finish" and "end" in the context of, say a course.

A student can complete a course but a course cannot complete. A student can finish a course and a course can finish. A course can end but it is somewhat borderline to say a student ended a course (although I might be able to say "the student ended the course on a high note", certainly not "the student ended the course").

GraphQL fits in to a LOT of this stuff.

Open a New Terminal Window

tell application "Terminal"
    do script ""
    activate
end tell

Open a New Safari Window

tell application "Safari"
    make new document
    activate
end tell

As I continue to learn more about Redux, I can't help but relate it to some of these ideas.

But there's this theme running through all of this which is this idea of a single tree (okay, DAG in the case of git) representing state: whether it be an entire filesystem or an information store for an individual or enterprise.

A few years later when I was going deep to try to grok git, I started thinking about generalising git's approach to versioning beyond blobs to data structures.

This led to Rev which was specifically about applying git-like concepts to Python data structures—an idea I still think has merit and would be interesting to go back to.

I was pretty deep into SVN at the time and SVN actually presented a really interesting model of tree versioning that was relevant to all this.

But back to the mid-2000s:

Around this time I helped a friend, Ashley Aitken, with a startup idea he had for a single-tree information management solution aimed at enterprises.

The node publishing features of WorkFlowy remind me a lot of what Ashley was thinking of (although his was a lot more advanced and he was doing a lot of work on versioning).

Around this time I was still thinking a lot about tree-based personal information managers.

The only record of my ideas at the time I can find is this blog post: Using the Leo Outliner as a PIM.

Briefly jumping ahead to the present, I recently started playing around with WorkFlowy and it continues this idea of "single-tree information manager".

By 2003, I was thinking about the idea of a filesystem entirely made of Python objects. This directly led to the somewhat different idea of the Cleese OS project.

The TL;DR so far is basically:

• a single tree representing an entire file system all the way into the files themselves: basically no distinction between directory trees and the tree structure internal to files.
• software as functions that manipulate the tree and which themselves are nodes on the tree
• a shell for navigating around the tree like Unix-shell on a filesystem
• information from external sources grafted onto the tree

A month later (March 1999), in reply to a different thread I posted:

Wouldn't that be great? The UNIX pipe model has suffered from not having a standard structured format, as has the /proc file system. Not to mention what this could do to an OS like Plan9 where "everything is a file" and textual formats abound...

This is pretty much what I was suggesting a little while ago on this list (in the same breath as überdocument). I'm still trying to find the time to work a bit more on it. I certainly have a lot of ideas about it so if others are interested in helping with implementation, I'd love them to drop me an email. My idea involves a layer on top of the operating system that treats the operating system as one big XML document (hence the phase "überdocument shell" which I used at the time).

I'm thinking of calling it "Plan X" which both includes the mandatory "X" for association with XML and suggests, via roman numeral, a continuation of the thinking of Plan 9.

Two days later, I wrote to xml-dev:

[Isn't it funny they way you can carry around a crazy idea in your head for ages and then, out of nowhere comes just the discussion to trigger externalisation]

AN INITIAL IDEA FOR AN XML ÜBERDOCUMENT SHELL

What I would like to see initially, is a shell-like application that has an interactive command-line that takes shell-like notions such as a working directory (and the ability to change same), starting of applications, redirecting of input/output to/from files, piping to other application and applies them to an XML überdocument.

So this "shell" would have the notion of a working element (command 'pwe' (=pwd) will tell you what the working element is). You can change working element with the command 'ce' (=cd) followed by an XPointer.

Elements contain XML content or they could reference an unparsed entity (for the issue of whether by ENTITY attribute or XLink see below). Some unparsed entities (perhaps with an appropriate NOTATION) are applications that can be "run". Instead of files, these applications work on nodes in the überdocument element tree.

I imagine that applications would be a lot more modular as most of them would be working on exposed data structures. Rather than a monolithic email/PIM application, you'd have simple applications (applets? no; how about application elements => "applements"). One applement would POP your mail and graft in on to an element in the überdocument. Another (perhaps just XT running an XSL stylesheet) would list the subject headings. Another would enable you to read email. An editor applement would let you compose a reply message and then a final applement would send the mail via SMTP.

A GUI can come later, but for now, I'd love to see an implementation of what I've just described. In something like Python it should take no time at all to do.

<sidebar>

Is the überdocument a single XML document with multiple entities or more than one XML document?

At first I thought that entities would provide the perfect mechanism for an XML überdocument to be spread over multiple files. For at least two reasons, I now suspect XLink might be the way to go:

1) you can give the links semantics which might prove to be very useful 2) you avoid the document entity != legal external parsed entity problem I raised in an early post

That having been said, it is important to note that the whole point of the "überdocument" notion is that it is logically treated (perhaps not at the XML parser level but at a level not too higher up) as a single document. Changing working element involves giving an XPointer not URI+XPointer.

</sidebar>

To be clear: there's nothing XML-specific about the concept. It would apply to any tree structure with annotated nodes (including JSON and plain JS objects).

This concept then got extended and in February 1999, I wrote the following to the xml-dev mailing list:

For a while now, I've been thinking what an OS (or more likely shell) would look like if it took Unix's "everything as a file" to "everything as an XML element".

A system would be a single XML "uberdocument" (physically, separate entities, including unparsed for any non-XML files on the system but logically, the one XML document). Applications (which would themselves be nodes in the element tree) would operate on other nodes in the element tree.

There would be an application, for example, that got mail via POP or IMAP, represented it in XML and then attached it a particular point in the uberdocument. XSL could be used to sort the mail. XSL would also be used to view the mail.

It's XML for the sake of it, but I think it would be fun to try out.

Back in 1998, I wrote a draft of a paper called Rethinking websites as single documents the TL;DR of which is: what if you viewed the splitting of a web site into different web pages as just presentation. The logical structure of a site could be a single (semantically marked-up) document.

I'm learning about Redux from Flora Worley and the Dan Abramov videos she recommended.

The initial principle of a single state tree reminds of a whole bunch of different projects and ideas I've dabbled in.

I think it's important to distinguish the meta expert from someone who is just better at teaching X than doing X.

For example, there are world-class sports coaches who aren't world-class at the sport they coach.

That's not who I have in mind with the term Meta Expert.

Perhaps even my real-estate example isn't a great one. The "problogger" is perhaps the best example because technically they are blogging professionally but they just blog about blogging. Hence the "meta".

joeld says:

Meta Experts may be too kind a term. In many instances of this kind of activity, there is more bullshit involved than "Meta Experts" would suggest.

I think sometimes it's legitimate which is why I chose a neutral term :-)

Most recently I've noticed how many self-professed multi-passionate / multipotentialites are focused on businesses around career counseling, etc for multi-passionate / multipotentialites.

Deciding that your focus on life is helping multipotentialites is great but it's not really being a multipotentialite yourself.

A lot of "how we do growth hacking" or "most important metrics for your SaaS startup" type posts are from founders of companies that build tools for growth hacking or for doing SaaS metrics.

There's nothing wrong per se with this type of content marketing. But they always run the risk that how you track metrics for your metric tracking tool SaaS company isn't the same as how you track metrics for any other kind of SaaS company.

A classic one are the people that tell you how to get rich in, say, real-estate who actually make more of their money, not from real-estate, but telling people how to make money in real-estate.