Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

New client for touch #100

asolove opened this Issue Jan 17, 2012 · 16 comments


None yet
5 participants

asolove commented Jan 17, 2012

I have mentioned a number of times in other issues and in the hangout that I want to improve our experience on mobile devices. I would like to propose writing a second, touch-oriented client. We already have multiple servers speaking the same API, so we should be able to also write separate clients.

I would like to gather desiderata and technical suggestions before beginning, but obviously we will consider this just an experiment until we have something compelling to actually show.


  • Create a consistent and extensible set of UI patterns that are optimized for touch surfaces like phones and tablets. These devices do not have hover states, need larger click targets, and cannot distinguish between dragging and scrolling. Different types of servers, stories, and plugins need to be able to hook into these patterns to expose extra information or actions, that will then be presented appropriately to different types of devices.
  • Rewrite the client code in terms of a server-facing model layer and a user-facing interface layer. The model layer should be bootable in a scripting environment like node.js to make it easy to import data to the server or write bots that automatically change or edit data. The user-facing layer should work well across typesof devices, and allow the model layer to not worry about the type of device the site is being displayed on.


  • Use a front-end MVC library like Backbone or Spine rather than storing so much information in the dom.
  • Use localStorage and the html5 apps apis to make the wiki work offline, have a home screen icon, etc. to fit better in the mobile environment.
  • Coffeescript, of course.
  • Need to think about load-time performance as the amount of front-end code increases. That means either asynchronously loading modules or else combining and minifying all the code together.


I am suggesting the following roadmap for integrating this client as first an experiment, eventually an alternative, and eventually perhaps the default client for SFW:

  1. Create a basic implementation in a touch-client folder in the main project.
  2. Alter the ruby implementation of the server to serve the touch client javascript when accessed with urls that use "touch" instead of "view."
  3. Implement basic page and plugin rendering with the new client so we can play around with it.
  4. Add conventions for editing that work across multiple device types one by one


I am brainstorming a design that will use the same conventions, but with appropriate differences, for different device types. Right now my thoughts center on using little "handles," such as Appleuses in the iPhone/iPad versions of Numbers.

Each page and each plugin within it would have a little handle, that could be activated to expose edit actions on it.

I would love to hear everyone's thoughts and comments.


asolove commented Jan 18, 2012

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/#


WardCunningham commented Jan 19, 2012

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.

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.


asolove commented Jan 19, 2012

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?

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.


asolove commented Jan 19, 2012

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.


asolove commented Jan 30, 2012

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.


WardCunningham commented Jan 30, 2012

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.


WardCunningham commented Feb 1, 2012

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:


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.


nrn commented Feb 1, 2012

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.

jhulten commented Mar 5, 2012

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.

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


nrn commented Mar 5, 2012

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.


nrn commented Apr 5, 2012

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?


asolove commented Apr 5, 2012

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


asolove commented Jan 2, 2013

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

@asolove asolove closed this Jan 2, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment