Because first impressions are important.

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.

I have some fundamental disagreements with "first impressions are important" when it comes to public software.

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.

That the rebuilt C2 wiki doesn't work is a fact; the problems are, unfortunately, so obvious and so serious that the first impression is uncommonly bad, there is no need to look further.

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.

Is it the whole concept of a federated wiki that you think is 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.

A federated wiki consists of three main parts: a federated database of content (which is supposed to be the interesting part), a user interface for reading that content, and a fairly different but unavoidably related user interface for editing and administration (both likely to resemble their counterparts in a non-federated wiki, but a bit more complex because of the richer information model).

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.

That seems like a more reasonable position.

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 still stand by what I say that "first impressions are important". Perhaps they are less emphasized in public software, however, they still count for quite a lot (as is seen by reading the comments). Technically, your first impression was of the idea that it was trying to convey rather than the application itself that was linked to. To others, it was the application and not the idea.

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 am not really disagreeing with you, but I would like to point something out: if this UI becomes widely used, then the cost of getting used to it is not so important. BTW, this is why I like Bootstrap: my web sites may look similar to millions of other sites, but no one is likely to have problems using it.

True. Let's wait and find out if this catches on. :)

Take a look at a movie from the 1990s, where a character pulls up say a news article on the internet. Just text and some pictures. So usable! The web peaked in 1998, when everything was plain HTML but you could Google-search it, and everything since then has been the moral progeny of the <blink> tag. So when a perfectly usable site like C2 embraces the bankruptcy of the Web 2.0 era, I think people are justified in expressing their frustration.

The web peaked in 1998?

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.

> That's an interesting claim to make on a forum that frequently discusses new web technology

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.

SMTP/IMAP isn't better than webmail. IMAP is an awful protocol. It's less secure than HTTPS. It doesn't do a better job of avoiding "spying" than webmail does. You can sync multiple clients with IMAP, but webmail accomplishes the same task so seamlessly clients don't even need to be aware of it.

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 think we agree on a lot of things.

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.

The web is better now because there are more people using it. All the things that you dislike were requirements to onboarding all those people.

Fair enough, but I think increased usage is more the result of a confluence of more widely-available broadband (including mobile), as well as new applications that would've been possible without rich media. Garnish aside, Facebook and Twitter are slinging a few textual quips and images around.

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?

We didn't need half those things, because we had email, usenet, and IRC. Those were actually pretty good. I certainly had far better discussions on usenet back then than i've ever had on the web since.

Right on.

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.

Good to hear that someone else is interested!

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?

Because of drag/drop refactoring and the detail in the page journal, they have to track the history of every paragraph, which requires UI for interacting with individual paragraphs. You can't have just a big old textbox for the whole page and do things as we always have (maybe you can get close with the right diff algorithm).

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.

I started playing with it last night. It looks like the was a significant fork a few months back that separates the client from the server. Conceivably, you could take the client and figure out how to build a different UI.

> Why not look into what he's trying to do?

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.

It's unusable for you and at this point in time.

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?

[0]: https://github.com/fedwiki/wiki-client/issues/39