10 big points on future writing systems

i recently wrote up a 10-point bullet-list of the important aspects i believe will underlie future writing systems.

https://medium.com/the-bower/writing-the-future-take-2-c30cf6da65bf

here, i build out those points, for the consideration of programmers who are starting to build such systems, as well as the writers who’ll use them.

***

* the future is simple yet quite powerful

* the future is plain-text storage-format

* the future is flexible on storage places

* the future is instant easy collaboration

* the future is simple solid track-changes

* the future is light-markup to apply tags

* the future is work-in-progress output

* the future is multiplied output-formats

* the future is savvy on how outputs look

* the future is robust and radical to remix

***

and here we go…

* the future is simple yet quite powerful

writing tools must be simple, but they must be powerful as well. this is an important tight-rope to walk, but it’s a necessary one. and in this regard, it might be instructive to consider ms-word as a system that has failed this test. although it’s rather sophisticated, some features are not bug-free enough to be regarded as “stable”. but it is on the “simple” dimension that it has failed most notably. many of the new writing platforms suffer from undue complexity as well, and the features they deliver — so far — are far from ideal.

* the future is plain-text storage-format

the future will utilize _strext_ — my term for “structured text” — which is plain-text that contains “hints” within it that instruct relevant viewer-applications how that text should be formatted. plain-text has a lot going for it… first and foremost, it is flexible. you can use any text-editor to work on the file, online or offline. moreover, plain-text is easy to edit, with no distracting “markup” to get in the way, with brackets and braces serving as obstacles. it’s the best path for a track-changes system, which writers need. this kind of portability across systems and apps is extremely vital. and plain-text creates a tranquil environment, so good for writing, where the “distraction-free” mentality reigns, and the words flow. it does what writers want: “get out of my way and let me write.” further, plain-text is more “hackable” than other formats, meaning it’s easier to write code to input, manipulate, and output plain-text. indeed, lots of programs are already written to process plain-text, including spellcheckers, indexers, and so on. finally, for archival purposes, you can’t do better than plain-text.

* the future is flexible on storage places

if you’re a writer, you must be able to do your work anywhere. writers must be able to access our work both online and offline, which means our offline work must sync to the cloud frequently. most writers work alone. if we collaborate, it’s sequential/serial, not simultaneous, so sync-conflicts should not be a big problem. note that these twin flexibilities of plain-text and cloud-sync work in tandem to enable the writer to work anywhere, on any system.

* the future is instant easy collaboration

some writers do work in collaborative environments, so it’ll be good if our systems can manage the hassles of collaboration hassles, of which there are many. but as a starting approach, large-scale collaboration probably won’t be a full-on necessity, because most writers tend to write alone. but even if most writers don’t have co-authors, the good ones have an editor. with the use of plain-text, and cloud-storage, it’s simple enough to pass files back and forth, which is one of the most important parts. it’s true some authors will need even more powerful features, like the ability for several to write simultaneously within the same file. but present-day communication possibilities are more than enough for the vast majority of authors to work together even in real-time, talking on the phone (or with video-messaging) or even just with text-messaging. so there’s never gonna be much need to be actually working inside the same document at the same time without be able to communicate. what will certainly be needed, however, takes us to our next point.

* the future is simple solid track-changes

every author — even one working alone — should track changes. and it grows even more vital when you are working with others. most important, we want a track-changes capacity that is simple; we want to specify 2 files, and see the differences between them. and we want the difference-display to “make sense” writer-wise; in large part, this will mean using a display that is “phrase-based”. for quality collaboration, in the sequential manner of most writers, the ability to stet changes is a necessity. when we turn a file over to someone else, be it a co-author or an editor, we want them to feel free to make changes at will. but then, when we get it back, we want to be able to stet any of the changes that we don’t like. we don’t want to hassle with a “roll-back” to a previous version, we just want it to be easy to stet any of the edits that were made. which doesn’t mean we want to be forced to manually “approve” every edit; we don’t. but when we want to revert, it must be easy. again, it has to be easy, but it has to be powerful too. writers will let you know when you get it right.

* the future is light-markup to apply tags

even though we are using plain-text, we want it to be “structured”, because we don’t want to read plain-text itself, since it’s very ugly. we want the benefit of nice-looking text, and that requires markup. near-term, .html is a required output format, so we need .html tags. but the application of tags is a pain in the ass. i mean, seriously, who wants to do that kind of grunt-work manually? that’s what we have computers for. and — even worse — once your file is littered with tags, they obstruct the editing process. so it’s best if we can have the actual brackets-and-braces tags applied automatically, and only in the output-format files, not our original master-source input-file. fortunately for us, that puts us in the wheelhouse for light-markup. while “markdown” is the most well-known form of light-markup, consider others that are more powerful, reliable, and dependable. whatever the form of light-markup eventually coming to prevail, the most important thing is that it’s “structured text”, or “strext”.

* the future is work-in-progress output

amateur writers futz endlessly over the formatting. real writers just write. occasionally, real writers do procrastinate by doing formatting, but often regret that they wasted all of that time doing stuff that isn’t going to make it into the final product anyway. so there is often disdain for formatting, which is sad, because nice-looking work-in-progress output is tremendous. it’s a great way to proof, offering you the ability to view the manuscript in various formats, and in different environments, which gives you a fresh look at it. if you’re writing on your laptop, it’s great to proof on your ipad or your kindle; it really helps you spot problems when you’re in a completely different context. and if the output quality is high, indicative of a “final product”, it helps you to visualize completion, which is a useful motivator. when you can see the work that you did _today_ output as a nice-looking product that you can view on your kindle or ipad, it’s tremendously gratifying, and it stimulates you to write more. and, although it might seem over-the-top to you at first, print-on-demand with a print-run-of-one has gotten so inexpensive —(it usually costs more to _ship_ a single print-on-demand hard-copy book than it costs to _print_ it) — that you can actually order up an honest-to-goodness printed-and-bound book, using your work-in-progress file, if you need an extra dose of inspiration. (not that _i_ have ever done that, mind you, but i’m saying that _you_ could. you know, if you really _wanted_ to. not that _you_ would need an ego-boost like that. but, you know, i’m just saying we _could_ do it.) so our system has to be able to make nice output with the ease of a single button-click. so we can use it every day. the 2oth-century mode, where a book got formatted only when it was “done”, is dead and gone.

* the future is multiplied output-formats

burgeoning form-factors require multiple output-formats, of course, and we have to assume that there will be even more down the line. (can you say “iwatched that book?”) and of course we want all of those outputs to be very high in quality. goes without saying. so, make it so.

* the future is savvy on how outputs look

taking these last two points together, and extending them, the writer needs to know — even during the very process of writing — how the output will look, across the entire range of output-formats. wysiwyg did this for paper, and it was an innovation that proved itself worthy, back when we knew that paper was the ultimate destination, and the _only_ destination. but now we have a dozen different “ultimate destinations”, so we need multiple-output envisioning. our writing system needs to be able to show us what our stuff will look like when people read it on a phone, or a tablet, or a computer monitor, or a living-room wall, or a billboard.

* the future is robust and radical to remix

thanks to its use of structured text (_strext_), the future can do remix. that’s when somebody who is inspired by your stuff can easily take pieces of it so they can build on it. some writers mistakenly believe that making it “too easy” to “copy-and-paste” facilitates plagiarism. on the contrary, if the text is close enough to be easily recognizable, the search-engines of the future will establish who mounted it first. therefore, you should mount your work in a way that makes it easy to repurpose your exact words, so the future will give you proper credit. this will also ensure the future sees a radical building of newer works upon the older.

so there you go. the 10 points that i feel will be important building-blocks, serving as the foundation for the writing systems we will use in the future.

next up will be a review to see if some new writing systems pass this test…

if you have any feedback, i’d love to hear it.