You can clone with
HTTPS or Subversion.
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.
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:
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.
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/#
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
See http://danwebb.net/2011/5/28/it-is-about-the-hashbangs for more discussion on Hash-Bang vs. PushState
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'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?
@nrn: There is some code here (https://github.com/asolove/Smallest-Federated-Wiki) but it hasn't gotten very far.
I'm going to close this issue (which mostly ended up covering necessary refactoring) and start a new discussion on mobile UI.