I love the collaborative features of Google Docs and Google Sheets.
The thing that's missing from "Google Docs" is a decent collaborative outliner called "Google Trees", that does to "NLS" and "Frontier" what "Google Sheets" did to "VisiCalc" and "Excel".
And I don't mean "Google Wave", I mean a truly collaborative extensible visually programmable spreadsheet-like outliner with expressions, constraints, absolute and relative xpath-like addressing, and scripting like Google Sheets, but with a tree instead of a grid. That eats drinks scripts and shits JSON and XML or any other structured data.
Of course you should be able to link and embed outlines in spreadsheets, and spreadsheets in outlines, but "Google Maps" should also be invited to the party (along with its plus-one, "Google Mind Maps").
More on Douglass Engelbart's NLS and Dave Winer's Frontier:
I guess one issue these tools have had historically (collaborative outliers, and Wave along with it) -- was what are they actually for?
Google Docs is for writing documents, letters, school essays, etc... The output is a document of some kind.
Sheets is for performing calculations, modeling numbers, etc... the output is normally some calculated value (or values). The benefit of this over just writing a single function/program is that you can potentially have more insight into the way that calculation is performed, but in general, the output is some calculation.
But outliners are different... what is the result? The NLS demo describes a shopping list. Which is nice, and you can slice and dice the data around, but fundamentally, it's a shopping list. And that function can be achieved with Google Docs for 80% of the functionality. Sure, it doesn't make moving bananas and carrots into a 'produce' category easy, but with copy and paste, it's a pretty well solved problem.
But the basic outliner functionality you're describing -- what's it actually used for? What's the payload that you're organizing?
Even Dave Winer's tools were used not for making lists, but for making websites. There was a "payload" present. You were managing data for websites (at least, as far as I can understand it, I didn't have a Mac at the time, so never used most of the UserLand programs).
So, would you say the "point" for these tools is making other tools? For example, using Frontier to manage websites? Or Wave to make a chatting tool?
In my mind, this was the problem that Wave came across... it wasn't easy to describe what it did in a simple way. It wasn't email. It wasn't chat. It wasn't collaborative writing. It was the backend that made that all work. It was incredibly ambitious, and that made it difficult to get people to use.
If it was "just" chatting -- I think that would have made a huge difference. Users don't care that you're using OT to write messages on the fly... they just want to be able to chat with friends or colleagues.
So, what is the killer application for a collaborative outliner? Why would I need one? I'm genuinely curious as to your thoughts, as you've clearly spent a lot of time thinking about this.
One thing an outliner lets you do that you can't do with something like Wave or a tree structured discussion group is to arbitrarily rearrange the tree.
You're right, you can represent tree-structured outlines in Word or Docs (or JSON in Excel or Sheets as I described here [1]), but it's clumsy and not well supported by the user interface.
[1] Representing and Editing JSON with Spreadsheets: https://medium.com/@donhopkins/representing-and-editing-json...
Where Frontier really shines is in its user interface and feature set, which makes navigating and creating and editing outlines very easy and efficient.
Frontier's main use was (tree structured) content management and scripting, and making websites is a popular application of that. It was extremely useful for making tools, and like Emacs, its power came from its extensibility.
Its pre-web predecessors [2] were ThinkTank (which started on the Apple ][ with a keyboard based interface) and MORE (which added a mouse-based drag-and-drop interface, that made it much easier to use without spoiling the ease of use of the keyboard interface, and also formatted graphics for making charts and slide shows).
[2] MORE (application): https://en.wikipedia.org/wiki/MORE_(application)
Beyond obvious stuff like content management, blogging, and scripting, I think there are many other killer applications of programmable outliners (just as emacs and spreadsheets have many applications), some old hat, and others undiscovered!
I wrote some more [3] about Dave Winer's work on Frontier, and linked to some screencasts he made that show how he uses it to organize his thoughts (about the history of outliners, in this case, which is beautifully self-referential).
I think the most important point that comes through in Dave's demos is that the operating system and user interface shell should support generic outlining and scripting at a very basic, built-in, ubiquitous level. But I believe Windows, OS/X, iOS and Android have a hell of a long way to go!
[3] https://news.ycombinator.com/item?id=20672970
Dave Winer's second outliner screencast:
https://www.youtube.com/watch?v=mgUjis_fUkk
Dave Winer's the many lives of Frontier screencast:
https://www.youtube.com/watch?v=MlN-L88KScw
Dave Winer on The Open Web, Blogging, Podcasting and More:
https://www.youtube.com/watch?v=cLX415mHfX0
>UserLand's first product release of April 1989 was UserLand IPC, a developer tool for interprocess communication that was intended to evolve into a cross-platform RPC tool. In January 1992 UserLand released version 1.0 of Frontier, a scripting environment for the Macintosh which included an object database and a scripting language named UserTalk. At the time of its original release, Frontier was the only system-level scripting environment for the Macintosh, but Apple was working on its own scripting language, AppleScript, and started bundling it with the MacOS 7 system software. As a consequence, most Macintosh scripting work came to be done in the less powerful, but free, scripting language provided by Apple.
>UserLand responded to Applescript by re-positioning Frontier as a Web development environment, distributing the software free of charge with the "Aretha" release of May 1995. In late 1996, Frontier 4.1 had become "an integrated development environment that lends itself to the creation and maintenance of Web sites and management of Web pages sans much busywork," and by the time Frontier 4.2 was released in January 1997, the software was firmly established in the realms of website management and CGI scripting, allowing users to "taste the power of large-scale database publishing with free software."
When I worked at Google, we made a prototype of a non-grid spreadsheet-type thing. More graphical than tree-like, but the same underlying engine could be used for other purposes.
Videos:
1. The FLOW Shell: https://drive.google.com/file/d/0B6Qg3A0fSZHoNk5EX3ZkREEwbUk...
2. FLOW 2D Turtle Graphics: https://www.youtube.com/watch?v=4wO_RrftJTE
3. Background: https://www.youtube.com/watch?v=-fbq-_H6Lf4
Programmers love trees but they really aren’t the basis of good user experience.
I spent years building tree oriented uis before realizing.
The specific application envisaged in the parent post is a solution without a problem, that scratches the programmers itch.
Can you share some experiences and insights? Maybe UIs that you think are better alternatives in specific contexts
Essentially all the existing Ui paradigms are better.
Trees are fiddly and poky things to navigate.
Tree oriented uis leave information hidden and require lots of clicks. Ugh.
Special cases and complexities constantly arise in tree oriented uis and clear consistent solutions are often hard to fit in to the system.
Programmers love trees though because truth is a lot of data is in tree form so the assume that data structure should be surfaced to the user.
It not correct though. Simple flat uis are much better.
My obsession with trees culminated in building a major business system that realized my dream of a fully tree oriented ui. It was shit.
I totally redesigned and rebuilt it several years down the track.
Now I don’t put trees in uis.
I agree that generalized trees require too many clicks.
What I really like are the limited depth, non-collapsing trees in a lot of UIs now. Like in Slack, where the left nav has few top level nodes—pinned channels/chats, channels, and chats—that make it easy to get exactly what is needed. It’s not perfect (like I would prefer an aggregated pin that simply shows everything from all pins in one conversation dialog), but it is visually clean and efficient. And instead of a giant tree to enumerate all channels, you use a dedicated search interface that makes it easy to add entries to tree with a single click (without having to interact with the tree).
GUI based file system navigation is another example where surfacing a tree works well.
Here is a short demo of a prototype of a tree-based spreadsheet I'm working on: https://youtu.be/pphY94boHq4 I intend to make it collaborative at some point, but I'll have to study OT and CRDT first :-)
This looks interesting, but the syntax seems like a major obstacle. "( /( * --->n( +--->n1 ) )2 )" instead of just "n * (n+1)/2" seems very unwieldy. Why the big arrow prefix on variables?
Yes, the syntax is a problem. I'm working on it, but I have not yet found a consistent and ergonomic design of the structure editor that covers the infix notation.
All function parameter usages in function bodies are just "ordinary" links to their corresponding declarations, and it just happens that links are rendered as "-->" followed by the name of the cell pointed to by the link. Instead of the arrow symbol I could render the link with some distinct background pattern or color. I might also make the arrow shorter, I guess.
Here's your tree-like spreadsheet (with no collaborative features): http://strlen.com/treesheets/
I have read about this idea many times and wonder how it hasn't been made yet.
I personally feel like lisp in the right clothing could accomplish what you describe. I am currently working on http://colortree.app to do some of this, but it is still in its early stages.
not tree - graph. graph is universal. tree is MongoDB. Thats not what you want. Graph is what makes this problem hard.
Are you really implying Google Sheets has killed Excel?
No, where did you get that idea? Google sheets and docs simplified, cloudified, and collaboratified their predecessors. No more emailing around and renaming multiple copies of different versions of the same spreadsheet or document.