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

61–70 of 126 posts

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

#61

Post by vegedor »

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 linear stack does not represent my browsing habits too well. If it would, couldn't I just use the history? Although there is difference in UX, i.e. the visual clue where I came from is hidden in a context menu, the use case is the same.

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

#62

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

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

#63

Post by mikeash »

zAy0LfpBZLC8mAC wrote: post #52
Touche wrote: post #50

Earlier quoted context omitted.

Google executes JavaScript.

That can impossibly be true. JS is turing complete, turing completeness means that the halting problem is undecidable, which means that at best Google will execute JS with some random resource limit to avoid infinite resource consumption, which in turn means that whether Google will actually see the content is ultimately undefined. And even worse: other search engines might, due to lack of standardization of the avai…

Everything you said applies to humans using normal web browsers as well. And yet people still fill pages with JS, and browsers still execute it, and people still see stuff.

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

#64

Post by jcoder »

andolanra wrote: post #9
cpach wrote: post #3

Earlier quoted context omitted.

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

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

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.

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

#65

Post by mikeash »

HelloNurse wrote: post #41
314 wrote: post #36

Earlier quoted context omitted.

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…

"That sounds like server load, more than anything on the client side." 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.

There's no reason the page can't display some sort of progress indicator while it waits for data. If it doesn't actually do this here then that's silly, but that's a problem with the implementation, not the concept. I'm seeing more and more apps that perform potentially long-running tasks (usually involving network access) without any indication that anything is happening. It's frustrating.

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

#66

Post by ogig »

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 can be solved using any of these methods: https://developers.google.com/webmasters/ajax-crawling/docs/...

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.

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

#67

Post by zAy0LfpBZLC8mAC »

mikeash wrote: post #63
zAy0LfpBZLC8mAC wrote: post #52

Earlier quoted context omitted.

That can impossibly be true. JS is turing complete, turing completeness means that the halting problem is undecidable, which means that at best Google will execute JS with some random resource limit to avoid infinite resource consumption, which in turn means that whether Google will actually see the content is ultimately undefined. And even worse: other search engines might, due to lack of standardization of the avai…

Everything you said applies to humans using normal web browsers as well. And yet people still fill pages with JS, and browsers still execute it, and people still see stuff.

With one minor difference: Humans at least have full-blown human intelligence which they can use to heuristically determine when the execution is "complete". Not that that makes all that much more sense ...

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

#68

Post by mikeash »

zAy0LfpBZLC8mAC wrote: post #67
mikeash wrote: post #63

Earlier quoted context omitted.

Everything you said applies to humans using normal web browsers as well. And yet people still fill pages with JS, and browsers still execute it, and people still see stuff.

With one minor difference: Humans at least have full-blown human intelligence which they can use to heuristically determine when the execution is "complete". Not that that makes all that much more sense ...

Yeah, that does make it better, but it's still not perfect. Witness the complaints right here about how you can't tell whether you got an empty page or it just hasn't finished loading yet.

Trouble awaits when you try to wedge a general-purpose application environment into a page-based document viewer.

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

#69

Post by HelloNurse »

mbrock wrote: post #57
hnyc wrote: post #51

Earlier quoted context omitted.

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

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

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.

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

#70

Post by userbinator »

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…

just to see some content

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.

Post reply on HN