
A complete rewrite of wiki as a single page application - chrisdotcode
http://c2.com/cgi/wiki?WikiWikiSystemNotice
======
SwellJoe
I believe the wiki is among the most amazing things to come out of the web
(and think Cunningham is a genius for inventing it, or discovering it, or
whatever process made it happen), and I can't count the number of times I've
lost an hour or two spelunking into the C2 wiki.

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.

~~~
agumonkey
I'm both sad and enjoyed by the move. I'm attached to the deceiptively poor
old wiki, because it contrasts with the great content quality. At the same
time, they're migrating toward something off the map of current technologies,
and so the spirit of the first wikiwikiweb is still alive.

ps: if someone has an archive / mirror of c2.com, I'll be happy to leech.

~~~
arethuza
"deceiptively poor old wiki, because it contrasts with the great content
quality"

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.

~~~
TeMPOraL
Yeah, I feel that too (though HN is a bit too bare-bones for me; I think of
Reddit as being the golden UI standard of this type of site). I do believe the
more superfluous JS you have on page the less likely it is that your content
is any good.

------
blueskin_
Wow, that's some bad usability there. Talk about chasing the shiny over form
_and_ function. Javascript pages are the 'Flash site' of the 2010s and I can't
wait until it's similarly consigned to its rightful place in the dustbin of
history. All they do is waste my CPU time and memory, force me to enable a
scripting language that is riddled with vulnerabilities just to see some
content, and run more slowly than real pages would.

~~~
kephra
Lets look, how this new wiki behaves without JS, from the viewpoint of a
search engine.

e.g. compare [http://c2.fed.wiki.org/methodology-
subsets.html](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.

~~~
ogig
This can be solved using any of these methods:
[https://developers.google.com/webmasters/ajax-
crawling/docs/...](https://developers.google.com/webmasters/ajax-
crawling/docs/specification)

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.

~~~
blueskin_
It can more easily be solved by just not crawling sites that have mandatory
javascript, because chances are their content is going to be crap and not
worth the time if they are that hostile to basic usability.

------
mbrock
The original wiki was a wonderful community, alive in that ineffable way that
very few online communities are, totally free and public. I wrote a blog post
[0] about how strongly it influenced me as a person and the gratitude I feel
for it.

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?

[0]: [http://swa.sh/the-original-wiki/](http://swa.sh/the-original-wiki/)

[1]:
[https://www.youtube.com/watch?v=BdwLczSgvcc](https://www.youtube.com/watch?v=BdwLczSgvcc)

~~~
hnyc
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.

~~~
mbrock
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.

~~~
HelloNurse
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.

~~~
mbrock
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.

~~~
HelloNurse
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.

~~~
mbrock
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.

------
emsy
The wiki I know for telling me all the new cool stuff is junk switches to a
SPA? That's ironic.

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.

~~~
notthemessiah
What's wrong with a single-page app? Wiki has always been a living document,
best that the implementation formalize and facilitate a nature. If you really
miss the classic format or need time to adapt, nothing stops you from using a
Federated Wiki client that generates a page from the JSON.

~~~
lmm
The canonical form of a wiki page should be a page; it really is a document
and so should be in a document format (in contrast, for something like a bank
statement the data is primary (in some sort of structured format with e.g.
numeric fields) and the page is merely a representation of it).

~~~
notthemessiah
You speak prescriptively of a canonical form, but I do not know what canon do
you refer to. What do you define as a "page"? Are you possibly arbitrarily
drawing a line at a HTTP GET request between the article and the edit button?
If that's the case, Google Docs and Etherpad would fail to meet your
definition of a page/document. Right now we see a declining rate of
collaboration on Wikipedia, so it's natural that the evolution of the wiki
would do more to encourage editing/forking:
[http://mashable.com/2013/01/08/wikipedia-losing-
editors/](http://mashable.com/2013/01/08/wikipedia-losing-editors/)

~~~
emsy
Speaking for me, it has nothing to do with philosophical principles like
"keeping the web as a web of hyperlinked documents" or to use html and http as
intended. Rather, it's using the right tool for the problem. Google Docs and
Etherpad are word processors first and then document collections. A wiki is a
document collection with the ability to edit. For a document collection, it's
important that you can simply download, copy and crawl the documents. Of
course this is possible with a SPA, but now your solving problems for your
tool instead of the other way round.

~~~
notthemessiah
[http://c2.com/cgi/wiki?WikiIsNotWikipedia](http://c2.com/cgi/wiki?WikiIsNotWikipedia)

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.

------
mourique
This is based on the Smallest Federated Wiki Ward Cunningham has been working
on since 2011. I think it's great that they're moving to new architecture, and
the SFW looks great. The interface is still pretty arcane, though.

~~~
cpach
That sounds interesting. Do you have any more details on this architecture?
c2.com seems to be overloaded at the moment.

~~~
andolanra
This is the (admittedly somewhat long) transcription of a talk I use to
introduce people to the idea: [http://hapgood.us/2014/11/06/federated-
education-new-directi...](http://hapgood.us/2014/11/06/federated-education-
new-directions-in-digital-collaboration/)

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.

~~~
jcoder
So, the bar for contributing to the wiki has been raised from "has access to a
computer" to "has access, knowledge, and resources to run a wiki server"? I
hope one or more WaaS (wiki as a service) providers will emerge where a user
account == a fed wiki node.

~~~
andolanra
That's already how it works. You could run your own node and share information
back and forth with other nodes, or you could use an account on an existing
node. This is clearly the case: if you go to the C2 Federated Wiki, you'll
note the _Login_ button.

~~~
jcoder
Ah, thank you. Still wrapping my head around the new architecture.

------
learnstats2
I feel sad about this :(

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?

~~~
mbrock
It seems to me like the people contributing to this project still have lots of
hope for the web.

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?

~~~
learnstats2
> Is the problem that the main page doesn't explain things clearly enough?
> Maybe you'd like to contribute some documentation?

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.

~~~
mbrock
I think the Federated Wiki concept is very interesting, and I agree that it
would be very nice to serve functioning static pages—this could be added and
probably should.

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.

~~~
learnstats2
Here is my philosophy of Javascript, since it might be relevant here:

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.

------
xiaq
Best wishes on the switch, but I'm afraid that the leap being taken is too
big. Suddenly we go from bare HTML served by cgi to a single-page, style-rich
and interaction-rich JavaScript application.

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.

~~~
edwintorok
Is the switch complete yet though? The new wiki seems to have almost no
content...

~~~
notthemessiah
[http://c2.fed.wiki.org/migrating-wiki.html](http://c2.fed.wiki.org/migrating-
wiki.html)

You might have forgotton how to use a wiki: you create pages that haven't been
written yet.

~~~
edwintorok
Actually it looks like that the pages themselves just take a long time to
load: for example clicking on 'extreme programming' shows the title 'extreme
programming' and a blank page. Initially I assumed there is no content, but if
I wait 5-10s then the content will be shown. This is very confusing: why show
the title and empty page while loading the body?

------
wtbob
This…this is abominable. Without JavaScript, there's no search; there's almost
no content. With this change, Ward's wiki has gone from an invaluable resource
to Geocities.

------
jrochkind1
Not preserving the URLs (or the content?) in the transition, really?

------
chinpokomon
With regards to SEO, I think a lot of you are missing something special about
SFW, and that is that each page has a JSON representation. The client only
exists to render the human readable view, but the JSON is fully crawlable by a
spider. In a lot of ways, this borrows from the days of XML pages where the
content was rendered using XSLTs. In this case, the content as well as page
revision history and links are preserved as a single JSON object. This
actually may make SFW content more crawlable.

------
harryf
Holy SEO Fail Batman... Google only returning ~ 19 pages (
site:c2.fed.wiki.org * ) vs. 80K from c2.com

------
jcoder
It looks like each page a user navigates to is appended to the URL. I hope the
team develops the notion of "browsing modes" with the option (on by default I
would think) to use canonical URLs for a given page. Otherwise, a user trying
to visit a bookmark at a later date will (1) wait for all prior pages in their
browsing stack to load before the page they bookmarked, and (2) may
potentially exceed a maximum URL length depending on how that particular wiki
is served.

------
peterwwillis
What's important about this isn't the server or client, but the protocol.

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.

~~~
chinpokomon
This is precisely my take. I wasn't familiar with SFW until last night (this
post), but I've been playing around with this concept for awhile myself.

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.

------
mark_l_watson
I had to play with the new UI a while before figuring it out. No delete panel
but when you go back in time to the left and click a different link,
everything that had been to the right of the "clicked panel" disappears. So,
you have to sometimes use your browser's "open in new tab" functionality to
remember a context for later use - this goes against the one page web app
concept, but makes it workable for me. BTW, interesting that the Node server
code is written in CoffeeScript.

------
austinstorm
Smallest Federated Wiki is a great choice for the spirit of C2. But the
interface is much more confusing than the old site, and lags behind similar
wikis like TiddlyWiki.

------
NolMan
The page claims that the new wiki is written with a distributed database but
from what I can tell it just writes pages to the file system?

[https://github.com/fedwiki/wiki-node-
server/blob/master/lib/...](https://github.com/fedwiki/wiki-node-
server/blob/master/lib/page.coffee#L52)

Am I missing something?

~~~
mbrock
He doesn't mean that each server uses a distributed database to store its
documents.

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...](https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/On-
Federating-Wiki)

[1]: [https://github.com/WardCunningham/Smallest-Federated-
Wiki/wi...](https://github.com/WardCunningham/Smallest-Federated-
Wiki/wiki/Federation-Details)

~~~
shoover
That said, there are also options to use databases for page storage on the
back end: [https://github.com/fedwiki/wiki-
node](https://github.com/fedwiki/wiki-node).

------
talles
Is this _new links to the right_ a new trend? It's the second time this month
I'm seeing one of those.

------
orvr
this is a sad day for the internet. Maybe hn seems like the only site left for
us low bandwidth people. Another site not loading...

------
grhmc
"Log in with LiveJournal"

------
hungnv
it took me seconds to load the new wiki (the welcome page), slow by design?

