Just a preprocessor between the API and the storage system. #

There are lots of Markdown processors out there for all platforms. #

Prior art too, Stack Overflow and Github support Markdown on user-submitted posts. #

It's even possible to put the Markdown processor in the client, then the server would probably need to have a filter that checks against illegal forms of HTML. But it seems you already have one. But the new one would have to be more complex (to let some markup through and not other).#

A very sizable installed base of writers understands Markdown.#

It would signal respect for practical standards. I love that Markdown was basically the brainchild of two people, not some huge standards group. That's why it's so nice and simple. It's opinionated, personal. All of which is good! #

But the biggest benefit is that it makes Facebook posts visibly more interesting. #

Makes people ask "How'd they do that!"#

Markdown support would give us hyperlinks, but they're so important they're worth calling out separately. Without the ability to link, we're not really doing web stuff. #

Clearly not all posts have titles, short ones, tweet-length or a little longer, don't need them. But some posts like the one you're reading now, not only have titles, but they have sections that have titles. #

Little Facebook Editor needs a place to store the user's history and prefs. For now I'm using HTML 5 localStorage, but it has well-known disadvantages. If I access my Facebook account from different locations, from a tablet or a laptop or phone, the history and prefs should go with me. But without a simple server-based storage system, this is not possible. #

This problem could be solved a number of ways, and we don't need Facebook to do this, but it's a problem every developer would have to solve on their own, which makes it a good candidate for putting into the platform. It could also be solved by providing a simple server app that hooks into Facebook's identity system to provide storage. I've already done this with Twitter logins, but it's not a quick project. #

Update: I wrote up the functionality . #

I edit my content in an outliner, and the content is rendered to HTML. As with programming, there's source (the outline) and object code (the HTML). The easiest and most logical place to store the source code is with the post itself. That way we can just ask for the source, open it in the editor and the user can make changes and save. #

Experience has shown that when the content and rendering use the same navigation system, the blogging environment is an order of magnitude simpler. This was the initial breakthrough that made blogging possible for non-programmers in the late 90s, with the advent of the Edit This Page button. Without it, the user had to master two navigation systems, and understand the relationship between the two. #

Obviously there will be a lot more that can be done. But these are good places to start, good next steps. And ranked in order of desirability and my best guess as to what's the quickest hit, and easiest to implement. #

This article is cross-posted on Facebook (manually, for now). #