A complete rewrite of wiki as a single page application
c2.com
c2.com
But, I'm having a hard time making sense of this UI. The panels popping up seemingly infinitely into the right side of the screen (every click makes a new panel) is unfamiliar and doesn't seem to provide a compelling value over giving the content a valuable piece of center page real estate. It feels like it is too proud of its cleverness, and that detracts from its value.
And, some other nitpicks: The "fork this page" feature uses a flag icon...which means "flag this" to any one who has ever seen a flag. The flashing icons at the bottom of every page, representing every edit throughout history, is hella distracting, and again makes the content play second fiddle to something else going on. There is no way to discover this thing in anything resembling an ordered fashion. Most of the links on the "front" page (I guess?) are dead ends, recent changes provides pages that have content but provide a haphazard approach to understanding what I'm looking at. The neat thing about a wiki is historically that you start in one place, and can follow links back and forth until you grasp your subject. In this case, the links seem to have taken a backseat to the other stuff (which is made up of flashing things, poorly chosen icons, and weird gradient squares that seem to exist for no reason), leaving me hanging here with no idea what this thing is for and how it works.
It pains me to say it, as c2 is wonderful (a little dated and simplistic, sure, but the world's first of anything doesn't need to be beautiful). Maybe it'll come to make more sense with time and further contribution from people who know what it is and why it is.
ps: if someone has an archive / mirror of c2.com, I'll be happy to leech.
Does that remind anyone else of HN? I sort of rather like the lack of features on HN in the same way that I like c2.com.
I assume they'll move it over to the Federated wiki at some point, but you can still view everything on the old wiki.
So, I agree that it's biggest problem is UI (and that's what I listed above as being wholly wrong about this thing), but I think it's dangerous to underestimate how much design determines the impact of an idea. I've seen lots of really cool ideas come and go, with bad design as the reason it never takes off. And, it's probably a bad idea to underestimate how hard it can be to fix a bad design, if the design is intimately tied to the implementation. I don't know if that's the case here, though there's certainly a lot of bad design ideas that seem to be important to the developers; at least, they must be important to the developers because they made them flash incessantly.
I've poked around some more since posting my initial comment, and I really can't get over how very distracting those flashing icons are, and can't imagine how anyone on the team is OK with it. How can designers of a content system (which a wiki is, at its core) do so much to make the content seem like the least important thing on the page? The user is literally directed to pay attention to everything but the content.
Again, I say all of this with an incredible amount of respect for Ward and the wiki. But, this thing is a mess.
I'll be most interested to see if they figure out a way to make federation easier to understand and use. At first I thought I wanted a globally editable central wiki with some company stuff and links out to individual wikis for project notes, developer knowledge base, and journals. It took a while for it to sink in that only the owner could edit the first one and really everyone needs their own to do anything. It's really hard to shift the mindset from shared state to single owner and fork to like, fork to change.
I agree with his sentiments and wish the internet were otherwise. I don't care how thoroughly brow beaten everyone is about this, I want it recorded that this is dumb and unnecessary.
But it's not that simple. Some uses of javascript genuinely add value - even to content sites. The real discussion is about cost vs benefit not "All interactivity is bad".
Shades of grey, dear sir. Shades of grey...
Being JS-heavy is something I found to be correlated with poor/untrustworthy content and someone trying to make money off you. I'm of course not talking about web applications here (like GMail or Google Docs) but web pages, which after all "should be text communicating a fucking message"[0].
I just don't want the HN party line to become a knee-jerk "all js on content sites is bad".
I'm a big fan of pjax etc as it can really speed up page load without any downside (assuming it's been implemented well). If the UX is good, performance are as fast or faster as a plain HTML site, everything is bookmarkable and you don't break my back-button then go crazy.
And on the whole I actually like the new c2 wiki.
What I find weird is that I can go 2 layers back on the same page, but then I suddenly have to use the browser's back button to go further up. I have to use the back button to close the right-most pane. And sometimes the back button does not work, or I have to use it multiple times to get "one step" back. Loading times feel worse, because you stare at a blank rectangle and wonder "is this article empty" and then it suddenly pops in.
I accidentally dragged a paragraph around and had to go back to the front page and follow a link there to remove the local copy I created. I also don't know how I would publish that copy if it were an intentional edit.
I'm sure it makes sense once you've understood it, but discoverability seems bad. Despite all its flaws TiddlyWiki seems to get the basic SPA wiki UI "more right" to me.
Then I tried clicking on "Category: Pattern" and page text took about a minute, not a few seconds.
Regarding the "stack" of previously read pages, it offers a typical stack behaviour: it can be blown away easily and efficiently. You can forget large pieces of history by the apparently harmless interaction of clicking on links in a previous pane.
Blowing away the stack by clicking is a bit of a pain. A couple of times something buggy happened where new pages overwrote some part of the old stack, but left the rest of it in place. I would like to see some option for expanding multiple branches at one level, but at that point it is probably a UI specifically for me rather than something that is generally usable.
One thing that was cute was that the stack of pages is exposed in the URL, which suggests that some nice greasemonkey tricks would be viable.
You are missing the point: with a normal page, server load looks like server load, whereas with "dynamic" tricks server load looks like a defective page and what you see cannot be considered the true content of the page.
Also, simplicity of core architecture leads to diversity of tools. If Google's first crawler had to execute JavaScript and make sense of single page applications, Google wouldn't exist today. So be careful when you encourage websites to become more complicated.
Tim Bray said it well in 2003: "Browsers are more usable because they're less flexible." https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePl...
Heh. We had a requirement to put in a back button. We put it in. Since no decent criteria were available to specify how it behaved, we just called history.back().
They did some user testing. Then they asked us to take it out again.
Never have I enjoyed taking on a ticket like I enjoyed taking out that stupid bloody back button.
e.g. compare http://c2.fed.wiki.org/methodology-subsets.html with and without javascript. The new wiki is doomed by design, because content can not be found by Google or any other search engine. And a wiki where the content can not be found is for the trashcan.
http://googlewebmastercentral.blogspot.com/2014/05/understan...
And webmaster tools has a tool to verify that content is scraped correctly.
Not saying there aren't other good reasons to do server-side rendering, but SEO is not a real one.
Fact of the matter is the new wiki UI is horrible. It doesn't have to be spelled out any more complicated than that.
Trouble awaits when you try to wedge a general-purpose application environment into a page-based document viewer.
1) If execution terminates by some timeout T, where T is at least several seconds, then index that.
2) If execution has not yet terminated by T, whether or not we have any idea whether it will terminate in the future, don't index.
Tune T so that it will get the vast majority of reasonable web pages. (Hypothesize, and test, T = 5 seconds or 30 seconds or something. Have a human look at the highest-PageRanked timeouts to figure out what's going on.)
This applies whether "the program" is server-side or client-side. The halting problem cannot be reduced to the timeout problem (since the halting problem asks if it ever terminates), and the timeout problem is pretty clearly computable.
I maintain a client side rendered website and while SEO can be problematic it can also be done.
I don't see C2 using any of these methods at first glance tho.
Moreover, static content. There's a big difference between using JS to do something interactive and useful which couldn't be done before (e.g. various games, calculators, and visualisations get this part right), and using it to incompletely emulate basic functionality that web browsers already have.
the 'Flash site' of the 2010s
I like that analogy - stuffing the whole site into Flash was a horrible idea, yet games and other useful interactivity (minus the annoying ads...) weren't so bad. Now the trend seems to be putting the whole site into JS, and while it could be argued that JS is more open than Flash, the end-result is just as unnecessarily wasteful of resources and inaccessible in the ways that the web was originally envisioned.
There probably are environments where live collaborative (Etherpad/Google Docs/etc. style) editing of communal content is useful, but I suspect that you're looking at "documentation hackathon" or something. For a project that's had useful content for two decades, the changes made in the last two minutes are not why I'm there.
An analogy could be made to Hacker News (or Reddit, or...) comments. While you could pretty easily build a system that does live chat, given that live chat is pretty much everyone's first project in a real-time framework, I think it's important to the nature of the site that changing comments don't show up immediately, because it gets you longer-form comments and things that are more interesting to read for someone who comes later. The process of reading IRC scrollback, when you weren't involved in the conversation, is not particularly enjoyable.
It is interesting how true that is. If you're there in real-time, the timing of the various messages and interactivity provides a lot of context to what is being said. You're also not reading everything all at once in a blast of data, instead you have time to read and consider each one appropriately.
Ward Cunningham is a respected and intelligent software designer who works on open projects for the public good. The immediate cynicism and dismissal I've seen of his new project so far makes me sad.
Why not look into what he's trying to do? [1]
Why not try to learn something about how it works, rather than look at it for twenty seconds and then complain?
If you see a car with a small knob for a steering wheel, you'll find that it is more difficult to use. And even though the engine of the car might be a radical improvement, this still doesn't mean that it can be used, mainly due to the pesky knob instead of a steering wheel. Obviously, after a while of using a knob to steer, you can get used to it, but that initial lack of usability means that many people decide that it's not worth the trouble.
Same with the website. You go to a website to use it. Sure, the idea behind the website may be wonderful and innovative, but if the access to it is unusable, then the innovation behind it all is for naught. When implemented well, the innovation is both shown in the explanation of it, and in the interface itself.
Everybody is dismissing it after 20 seconds because it doesn't work. The idea may be good, but the implementation is what is being shown to public. If it were the idea that were being shared, then it would be a link to, for example, a blog post or source code.
Finally, the reason that we're not trying to "learn something about how it works" is because it doesn't work, at least not yet. Which is why we are complaining.
First impressions are unreliable when it comes to understanding the value and potential of something that's in development.
The whole wiki spirit is to release early, adapt to feedback, and encourage collaboration.
When you say "it doesn't work" and "the innovation behind it is all for naught," I feel somewhat dejected.
The "value" of the old site is lost, the "potential" for improvement doesn't matter and doesn't exist, the "innovation" is a failed experiment that shouldn't have been "released early".
I just don't understand this leniency towards a bad implementation of a bad idea.
When you say that the "'potential' for improvement doesn't matter," what exactly do you mean?
Doesn't matter to whom? For what reason?
I am lenient and curious about most attempts at innovation in the field of web-based communication and collaboration.
Personally speaking, I like Ward Cunningham; I admire his previous work; I am interested in federation; and I generally encourage open source development of interesting communication tools.
When you say "the 'innovation' is a failed experiment," I read that as a claim that hopefully—and with effort—will turn out to be mistaken.
If you think there is nothing to learn from it, that's up to you.
Of these three components, all criticism of the C2 rewrite is focused only on the most accessible: the reading user interface, which is blighted by the fundamental bad idea of imposing a bizarre, dysfunctional SPA gateway on one of the most pure examples of hypertext in existence. Only this user interface is an impractical, grossly failed experiment; it's obvious that pages like those in the old C2 wiki, possibly with a few extra buttons and links to deal with federation-related metadata and features, would have been a far superior user interface.
Nobody complains about the idea of a federated wiki (either in general or referring this particular design) because, with the ugly bugs and bad user experience, it's simply irrelevant; even the editing user interface is practically hidden behind a wall of inconvenience and mostly ignored in comments.
Personally, I think federated wikis are a promising organization for the public web, but they won't be like this.
Actual software and sites, particularly when they replace a very good predecessor like in this case, should be judged by their actual quality, not by enthusiasm levels or fantasies about the future. As a production wiki, the C2 replacement has been published by mistake and it should be reverted ASAP and killed with fire, but as a research testbed it deserves rework and further experimentation: with a good user interface, which remains to be determined, people would be able to exercise the underlying federated wiki database, which I suspect to be good.
However:
(1) The federated wiki has not replaced C2. Ward has put up a notice saying that he plans to do so at some unspecified time in the future. Right?
(2) You claimed earlier that "the 'potential' for improvement doesn't matter and doesn't exist," which I point out is excessively negative and dejecting.
(3) Wiki has always been a research testbed and a place for experimentation. That's why the whole thing is done in public in such a way that any interested person may participate and give input. To help such projects, if one has any reason to believe that they may be valuable—as you now seem to agree—it is more productive to give constructive feedback through appropriate channels.
I guess when I did say "it doesn't work" that was a bit judgemental, sorry. I meant that it was incomplete, or at least unintuitive and/or cluttered to use. In the version that was given to everybody to try out, that is.
First impressions may be unreliable, but it's how the world works, most of the time, and unfortunately changing human nature is quite difficult (although I haven't really tried :P).
I did. It's literally unusable. I.e., one literally cannot use it in lynx, w3m, Firefox with JavaScript disabled.
As far as I can tell he took 20 years of work and threw it into a garbage disposal.
If you're concerned about this, have you considered opening an issue on the public repository?
Maybe you have some knowledge to share about how to make the site work well with JavaScript disabled?
Maybe you'll find that the team has thought about this, and are planning it?
A cursory look reveals an issue [0] closely related to this, mentioning that there are .html URLs that are supposed to work without JavaScript; that they have at some point verified the functionality with a screen reader; that Google should be able to index the contents; etc.
Maybe that would be a good place to bring up your concerns?
That's an interesting claim to make on a forum that frequently discusses new web technology, the progress in browser engines, the interesting new stuff that's being made.
In 1998 there was no Gmail, no Github, no Slack, no Discourse, and so on and so on.
C2 may have been perfectly usable, and I think it should remain as an archive, but there was barely any contribution anymore.
When you imply that Ward's "Smallest Federated Wiki" embraces the "bankrupty of the Web 2.0 era," it sounds to me like your pet peeve against JavaScript makes you discount the whole project.
I mean, you're very free to have your own views and opinions, but as someone who's very interested in this project, I'm pretty baffled by all the negativity, and the lack of a more than superficial interest.
The idea of a federated wiki is, it seems to me, very cool, and the fact that it hasn't been done yet indicates that the web has not peaked. So where you see "the bankruptcy of the Web 2.0 era," I see a fascinating development of the wiki idea by its original creator.
Yeah, the JS app seems a little unpolished, but also pretty cool in many ways. I don't know whether it's the best move to replace the old C2 wiki right now. Maybe Ward sees it as a way to get more people interested in the new project. I don't know.
As for me, I'm going to see if there's any way I can contribute and help the project. It would be nice to see some more of that attitude here, instead of only (in my view) superficial complaints.
I don't like to shy away from controversy. ;)
> In 1998 there was no Gmail, no Github, no Slack, no Discourse, and so on and so on.
No, but there was SMTP/IMAP/Exchange, which was better and didn't spy on you. There was ViewCVS, which was just peachy, and in any case the improvements in Github over CVS have to do with git versus CVS (i.e. the native apps and protocols), not the web frontend per se. There was also IRC and AIM, which were just peachy too.
It may well be that the 1998 peak was a local maximum, but I stand by the assertion that the web was better back then. The modern web is spectacularly bad for finding and consuming information. Want a simple how-to or product review? You'll be blasted in the face with images, video, and animation until your quad-core 2GHz/16GB RAM machine falls to its knees.
And to what end? Text is still, after thousands of years, the most efficient way to convey information. Anything you layer on top of it detracts, rather than adds.
I also think Ward's project is not fundamentally bad just because it uses JavaScript.
I think the idea of federated text sharing through free software and open protocols is lovely and that anyone making a serious attempt at this should be encouraged.
And I think that interactive web software can actually help, especially when it comes to inviting people who wouldn't enjoy setting up a Usenet client.
Also, I'd quibble about the word "better." Does the vast increase in non-technical users make the world better? Sure. Does it make the web better?
IMAP is a pretty good example of the kind of protocol that should be eaten by HTTP/RPC APIs.
(I've written a couple IMAP implementations, both client and server, and was [in the 1990s] responsible for the mail infrastructure for a popular ISP.)
I recently deployed a fedwiki farm for my team after playing with it myself and catching just a whiff of the possibilities. I had a litany of complaints myself, but was compelled to press on due to the intriguing promise of the goals of the project.
While some issues stem from the fundamental design of tracking individual paragraphs, I believe many of the problems will be designed away with better client side programming or alternative UIs in time. With this rollout of fedwiki on the original wiki, I now think all the issues will be defended or fixed sooner than I thought.
Could you explain a bit more about the issues with tracking paragraphs? It sounds like an interesting idea.
From perusing the GitHub documents briefly, it seems like the architecture is such that other UIs should be possible. Do you have a hunch about the possibility of making, say, an Emacs client?
So to edit a paragraph in the current UI you have to double click to get an edit box, then click to insert the cursor in the right spot. Adding a new paragraph requires a few clicks. Adding a new page and getting to that first edit box requires too many clicks.
Drag/drop as the primary mouse interaction also makes it hard to copy/paste text in and out of the wiki.
It's painful if you're used to orgmode.
But like I said, these are just UI gripes. You can see how they fall out of the fundamental design of the system, but I think focused client design could optimize editing and make it more familiar if that was a goal.
But seriously, in my eyes, a wiki is excatly what a SPA should not be used for, because of its document based nature. Trying to fix an overload problem with an SPA tackles the problem from the wrong side imho.
Wikipedia is a document collection that happens to be implemented and edited using a wiki. Wikis are much more general tools.
There are many "document collections" that are nearly impossible to crawl. Every have to use PACER or many other databases of scanned PDFs? Many web pages require you to reverse engineer HTML to gain a meaningful sense of structure, where Smallest Federated Wiki has APIs and is made in every way to be copied.
Indeed. They don't feel like pages or documents (indeed google docs is explicitly an editor and has an export step to produce a webpage), and I would not want a wiki (or wiki-like project) to be maintained in them. They serve a different niche.
> Right now we see a declining rate of collaboration on Wikipedia
For well-know reasons of deletionism and unnecessary barriers to new editors (see http://www.gwern.net/In%20Defense%20Of%20Inclusionism ). The way to fix wikipedia isn't to keep changing things, it's to go back to the policies that worked in wikipedia's golden age.
Lots of Youtube videos: https://www.youtube.com/results?search_query=federated+wiki
The elevator pitch for tech-minded people is that wikis are to SVN as federated wikis are to git. Instead of a shared wiki that people modify, each user has their own wiki which consists of both pages they've made or forked, so information propagates back and forth between users. It's a really compelling idea and I hope they can make it work.
The original wiki was full of the hope of the web.
Here, the UI is unintuitive. The site depends heavily on client-side processing. It loads slowly - there's no intelligent processing in advance. It uses canonical URIs OK, but the window.history updates late and the URIs are designed in a way that makes them difficult to share. The code is hosted on an ethically-dubious commercial site. The wiki has lost all the old data.
I'm doubtful of the author's claim that this will last 20 years except at his own behest - I don't see how this is an improvement?
The original wiki had plenty of UI quirks, too. How much time have you invested into figuring out how it works? Is the problem that the main page doesn't explain things clearly enough? Maybe you'd like to contribute some documentation?
With regards to loading times, that's an engineering issue to be improved. Efficient loading of documents is very possible with asynchronous requests; right now it looks a little glitchy, but this is not a fundamental issue.
Where is your hope?
No. There are several problems, the first of which is that I am served content as a Javascript-dependent blank page for no good reason.
I'm not sure why you think I would contribute to this project. It contradicts my ideals for the future of the web on many levels, as I already explained, and some of which you overlooked when making your comment.
Firstly, I do not want to support something that represents a backwards movement from my preference, and secondly, any change I would choose to make would likely be reversed as against the spirit of the project.
My belief is that the Benevolent Dictator for Life/cult of personality model of existing open technologies is broken and should be shunned. (With apologies to Ward Cunningham, who I do not mean anything personally towards). People committing their resources to this project are not providing for the diversity that 7 billion web users need.
I have plenty of hope. My hope is that other people will take this technology in a better or just different direction.
That's why I'm wondering if you have looked into the project's ideals and roadmap. Maybe they have different priorities than you would prefer. Maybe, as I said, they are already working on providing for your needs.
This is not a product someone is selling to you; it's a public work-in-progress with a pretty ambitious idea.
If you think that JavaScript applications in general are opposed to your ideal future of the web, then I understand your disappointment.
Javascript is great when it enhances webpages. When users get a faster and better web experience than they possibly could without it.
Javascript is awful when the fallback that remains, when it inevitably breaks, is worse than what had already existed in the past.
That said, I actually like the new website, except for the bottom bar. When i scroll quickly on iPad it doesn't always stay at the bottom, and it is especially ugly when there is one page being viewed. I'm sure there will be people with way stronger opinion on the radical UI change.
You might have forgotton how to use a wiki: you create pages that haven't been written yet.
Like all peer to peer networks, all you need is a clear documenting of the protocol and anyone can create their own servers or clients. This way people concerned with SEO can expose the wiki's contents easier, and users can design a more attractive user interface, all while addressing the same content and sharing it the same way.
If this works as a protocol, it should allow anyone to collaborate on documents that synchronize independent of a central source. This is really useful for people who need to be able to share some information in a multitude of ways and on different networks, online or offline. The only downside is it seems the addressable content has a limited scope. And of course, there's probably (i'm guessing?) not much in the way of access controls to prevent people from getting or modifying information they shouldn't have.
The only real drawback that I'm seeing so far is some link fragility. There are two countering forces at work here. You can take a link to someone else's content and mirror it back to your own SFW. If the source content changes and you don't take the "pull," your content is no longer relevant. This might mean for popular sources, lots of replicated copies of the source, but not always current. There is also a problem with the always available aspect. If someone is using content from another source, what do you do when the source goes down or just changes locations. At least with a non-federated wiki, the entire set of content goes offline together. That model is less prone to rot since it prunes entire branches and not just bits and pieces.
https://github.com/fedwiki/wiki-node-server/blob/master/lib/...
Am I missing something?
The wiki is federated, much like Usenet is through the network of NNTP servers. For more info, see Cunningham's documents "On Federating Wiki" [0] and "Federation Details" [1].
This is distributed in the sense that Git is a distributed source control system.
[0]: https://github.com/WardCunningham/Smallest-Federated-Wiki/wi...
[1]: https://github.com/WardCunningham/Smallest-Federated-Wiki/wi...