New client for touch about smallest-federated-wiki HOT 16 CLOSED

I went ahead and started exploring this direction, pushing it to a branch here: https://github.com/asolove/Smallest-Federated-Wiki/tree/touch-client/touch-client

This commit does nothing more than render the titles of the requested stories, but this is done dynamically and with what I hope will be meaningful objects.

There is pretty good Backbone documentation online for those who want to follow along: http://documentcloud.github.com/backbone/#

from smallest-federated-wiki.

I'm excited to have serious attention focused on the touch platform. I've been afraid to get started with touch for fear of getting it wrong. We'll need effort and daring to get it right. Here's why it's worth it:

Tablets make for comfortable study. Soon readers will refactor everything they read, as they read it. This will be the "killer application" of federated wiki. This mimics the professor who teaches a new classes to learn new material with their own notes becoming lecture notes and then the first draft of their next book. Careful reading becomes publishing.

I've encouraged Adam to modularize the client code in the process. Sam and I had a go at integrating backbone.js a while back. It didn't work. Our conclusion: we need to build out from new models and think through the proper placement of every line of code as we go.

This is the challenge ahead. One client, with clean models, serving all html5 platforms, enabling a new kind of community engaged in a new kind of scholarship.

from smallest-federated-wiki.

One option for rebuilding the frontend is http://brunch.io/

It's a integrated toolset for building rich HTML5 frontends. I've been using it for 4-5 months now and really like it. It makes it really easy to cleanly organize your code and includes integrated js testing via Mocha and minifying of js/css.

from smallest-federated-wiki.

Kyle, that's interesting, Brunch is almost exactly the stack of libraries I am used to, and it solves the problem of how to build the assets independently of which server people are using. Do you have a sense of how stable Brunch is or how much trouble we would be in if Brunch stopped active development but we wanted to move forward with the same library stack?

from smallest-federated-wiki.

I've used it for ~5 months with zero problems. So stability is fine. There's 14 contributors / 54 forks / 637 watchers at the moment so that's a decently wide base.

I haven't made the jump to making changes to the Brunch code itself as it's met my needs perfectly so far but my understanding is the core Brunch code is fairly slender + it's written in coffeescript so it'd be pretty easy for this community to modify. That and the 1.0 release has moved to a plugin architecture so it'd be easy to add custom build steps for SFW.

from smallest-federated-wiki.

Sounds good: structured tests and builds would be very helpful. I'm going to try setting this up on my remote branch for those who are interested in watching or contributing to the touch client.

from smallest-federated-wiki.

I spent some time on this yesterday and got to the point of being able to display and browse a local wiki similarly to the existing client: https://github.com/asolove/Smallest-Federated-Wiki I would appreciate if those interested would go look at the structure of the code there and see if the objects make coherent sense.

The net step, it seems to me, will be to rewrite the way editing works. Because the current plugin implementations are not ideal for touch-based clients, I would like to suggest that we rewrite them but I'm not sure how much opposition there is to that idea. Specifically, instead of allowing plugins to arbitrarily bind events, I'd like to expose a handful of hooks they can use (to specify different allowed user actions) and that way we can have a single implementation for how those actions are displayed in the UI. That way we can change the UI in one place and have all plugins change to match.

For example, the chart plugin might specify that it has options like: pick dataset, select chart type, add caption. When you enter edit mode on a chart, those options would be displayed in a contextual menu and lead to the right action. The central codebase would also expose reusable components for modal dialogs, contextual menus, text editors, etc. that the plugins could use.

from smallest-federated-wiki.

The emit/bind plugin interface has out lived its usefulness. I'll open another issue (#112) where we can discuss improvements. Hopefully if we work that forward together then we won't have a difficult merge between mouse and touch versions.

from smallest-federated-wiki.

I've looked at a lot of the client code in the last 24 hours. I'm pretty familiar with the control and data flows once again. I'm thinking I should record my understanding in some sort of document that might suggest model objects and model lifetimes. I found creating new pages client-side particularly difficult.

One challenge is getting capitalization and punctuation from a link text to the title field of a new page on the disk. (We don't do this yet. We use the down-cased slug as the title.) For example, say I have a link that looks like this in source:

[[Tim O'Reilly]]

Clicking on this link should make a page in the database under the key:

tim-o-reilly

That has a title field that looks like:

"title": "Tim O'Reilly"

If you think of new page creation as having six phases, it use to be I needed it in phase 6 but lost it in phase 1. I now have a path from phase 2 to phase 6 so I only have one more phase wall to hurdle.

from smallest-federated-wiki.

Yeah, the title was the main thing I was after when I tried to tackle this. I was looking at getting the inner html of the a tag that called the event that led to the 404... but i'm not sure if that was going to be a fruitful approach or not.

from smallest-federated-wiki.

Thinking about the client side vs. SEO... When I go to http://twitter.com/jhulten (which can be reached statically) I get the static content and I am redirected to http://twitter.com/#!/jhulten which I presume uses something like backbone.js to route the application.

This allows the page to be indexed without all the javascript. Its allowed to be, if you will, stupid. What if we did something similar. http://wiki/page (no trailing .html) would return the static page with just enough javascript to redirect to http://wiki/#page

The bonus in regards to this issue is the ability to pick a client based on the browser while still having indexable content.

from smallest-federated-wiki.

Twitter is actually getting rid of their hash-bang urls - http://ngriffith.com/2012/02/20/hash-banging-the-intertubes/ arguing that browsers that still don't support PushState can just reload each page.

I think it'd be better to just go straight to PushState. Hash-bang urls are quite ugly and un-webby. It's not too hard to have the server be able to create a simple html page for the robots that then Javascript decorates for the humans after loading.

See http://danwebb.net/2011/5/28/it-is-about-the-hashbangs for more discussion on Hash-Bang vs. PushState

from smallest-federated-wiki.

Arrgh, renewed discussion here reminds me that I need to implement server side rendering on the express server.

We are already using pushState for all of our history interaction, but I agree that there is no reason to change that. I think the better fail over for federated wiki for browsers that don't support pushState is to just ignore the url, but otherwise function normally.

I had imagined that eventually if you went to a /view/something/view/something-else url that you would get a full page with prerendered html, and all the links in the page would be to /view/slug instead of /slug.html, meaning that if you manually open links in new tabs, or browse without javascript enabled, etc, everything would just work as expected. But if javascript was enabled it would hook itself up to the page when loaded.

from smallest-federated-wiki.

I've been thinking about exploring a backbone client, and seeing how that fits with our goals, just wondering if there was any movement on this first?

from smallest-federated-wiki.

@nrn: There is some code here (https://github.com/asolove/Smallest-Federated-Wiki) but it hasn't gotten very far.

from smallest-federated-wiki.

I'm going to close this issue (which mostly ended up covering necessary refactoring) and start a new discussion on mobile UI.

from smallest-federated-wiki.