Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A complete rewrite of wiki as a single page application

c2.com

Post reply on HN
Print view View original

31–40 of 126 posts

Re: A complete rewrite of wiki as a single page application

#31

Post by cousin_it »

314 wrote: post #22
blueskin_ wrote: post #12

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 pag…

Why is the usability bad? Pages are pleasant to read in that aspect ratio and it seems to provide a good solution to what to do with the bits around the edges. I like the stack of places that I've been before as context and think that it encourages exploration and clicking around more than the original site.

A website's job is serving up pieces of information. Helping me navigate that information is the browser's job. That's why we have amazing innovations like the back button, tabbed browsing, and bookmarks. Imagine a world where every website had its own buggy implementation of those.

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

Re: A complete rewrite of wiki as a single page application

#32

Post by [deleted] »

emsy wrote: post #28
notthemessiah wrote: post #25

Earlier quoted context omitted.

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…

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 downl…

[deleted]

Re: A complete rewrite of wiki as a single page application

#34

Post by notthemessiah »

emsy wrote: post #28
notthemessiah wrote: post #25

Earlier quoted context omitted.

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…

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 downl…

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.

Re: A complete rewrite of wiki as a single page application

#35

Post by kephra »

blueskin_ wrote: post #12

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 pag…

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

Re: A complete rewrite of wiki as a single page application

#36

Post by 314 »

HelloNurse wrote: post #27
314 wrote: post #22

Earlier quoted context omitted.

Why is the usability bad? Pages are pleasant to read in that aspect ratio and it seems to provide a good solution to what to do with the bits around the edges. I like the stack of places that I've been before as context and think that it encourages exploration and clicking around more than the original site.

Delayed display of text is terribly bad. Consider the following scenario: 1) I click a link to "Decorator Pattern". 2) A new panel with the title and no text appears. 3) I assume a major malfunction. 4) The text of the page deigns to appear. 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 behav…

That sounds like server load, more than anything on the client side. When I used it everything was instant and snappy, so it might just depend on the number of visitors.

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.

Re: A complete rewrite of wiki as a single page application

#37

Post by 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?

Re: A complete rewrite of wiki as a single page application

#38

Post by lmm »

notthemessiah wrote: post #25
lmm wrote: post #16

Earlier quoted context omitted.

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).

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…

> Google Docs and Etherpad would fail to meet your definition of a page/document.

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.

Re: A complete rewrite of wiki as a single page application

#39

Post by mbrock »

kephra wrote: post #35
blueskin_ wrote: post #12

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 pag…

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

This is a specific issue to be solved with standard REST techniques. Do you know if the team is working on it? Maybe it's on a timeline, scheduled to be implemented next month? I haven't looked into it, but the current lack of this functionality does not mean that the "new wiki is doomed by design."

Re: A complete rewrite of wiki as a single page application

#40

Post by mbrock »

learnstats2 wrote: post #37

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 w…

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?

Post reply on HN