DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT

1. Mobile Editing Manifesto

1.1. Introduction

During the 2010 Snowy Hackfest, one of the main topics of discussion was the note experience on mobile devices. Certainly the most complex issue was editing. This document attempts to distill the discussions we had and the conclusions we made.

Disclaimer: although the context of these conclusions was the development of a mobile-focused HTML5 offline app distributed as part of Snowy, I don't see any reason that these same points wouldn't also apply to a native Android app like Tomdroid, or a hypothetical native iOS app, etc. While I haven't put a lot of thought into what the differentiators should be between "Snowy Mobile" and Tomdroid, I think sharing work on the editing experience might be in our best interest, especially with the various complexities involved.

1.2. Expected editing features in any Tomboy note client

• No matter how I edit text, I should feel confident that additions and small changes to an existing note will not cause loss of formatting or other data.
• No matter how I edit text, my note content should always be completely readable.
• When I type a title of another note, it should be displayed as a link to that note (making this feature optional is acceptable).
• When I create a note, instances of my new note's title in other notes' content should turn into links (may also be optional).
• When I rename a note, those links should be updated: either they should disappear, or the text should be updated to match the new title. I, the user, get to make this decision for each note (may be optional if above features are turned off).

• Coming soon: I should be able to protect any number of my notes with a password. I should be able to use different passwords if I want to. When a note is password-protected, it should be stored and synchronized in the encrypted format (really it only needs to be synchronized in encrypted format, but sync is way easier if it is also stored encrypted, and this provides some additional protection that the user may desire). The client should offer to save my password(s) so that I don't have to enter on each load/save. There is an implicit assumption here that although we should prevent letting the server have access to the password or unencrypted content, notes are not so important to protect that we can't cache the password on the client side.

1.3. Axioms about text editing on a mobile device

• Typing, the most basic action of editing, may be a frustrating experience.
• Especially, typing control sequences is pretty much out of the question (how much can gestures be of help here?).
• Many characters we have quick access to on a full keyboard are hidden 2 or 3 layers deep on a mobile device's software keyboard.
• Selecting text is hard to do and probably not well understood by most users, when compared with the desktop.
• Partially as a result of the above, but also due to the nature of a mobile device (which is usually a phone, too), it is unlikely that users will be spending extended amounts of time editing, and will probably not use rich text features as often as a desktop user.

1.4. Editing Format

• Implementing a traditional rich text editor in a mobile browser is a very difficult task. Most don't support contentEditable (supposedly latest iOS 4 release can do it, though?).
• So, a plaintext editor is required, which means that a plaintext representation of Tomboy note formatting is required.
• Variations on Markdown are in popular use on sites like github and stackoverflow.
• Markdown is designed primarily as an HTML authoring format. It has many features we don't need, and lacks a few that we require.
• Any alternate format must consistently round-trip back and forth with Tomboy XML without any change in formatting or loss of data.
• TODO: Explain approach to addin-introduced tags.
• A Markdown-like format seems be the friendliest approach:
  • Optimize format so secondary/tertiatry keyboard screens are not required for commonly-used features (bulleted lists).
  • Modify format to provide natural syntax for Tomboy-specific features.
  • Restrict variations in formatting to make parser implementation easier (initially we wanted to do this because we wanted to add the markdown format as a documented part of the spec, accepted on the server as an alternate to XML. now that we are not changing the spec or the server, but doing everything client-side, it is perhaps less of a big deal to toy with syntax).