The Plain Text Project

I recently just upped my StandardNotes subscription (the Black Friday ad is still active), and I'm now locked in for ~5.5 years. It's a very plain-text webapp/mobile app that aims to be simple and long-lasting, yet feature-full by means of optional extensions. It's not perfect, but I've been using it for a few months now without any data loss/major bugs encountered, and was excited to use it to ditch Google Keep/Google Authenticator.

It's amazing what you can do with simple text, especially with a Markdown-supporting editor.

I tried to love standard notes but I had several times where note contents were overwritten or missing between machines. I looked at the API for syncing and it did not give me confidence.

Using pass + git now. Works great.

I think more and more people are realizing that simpler is almost always better, and not only when it comes to software. I've found that this approach works best for nearly all aspects of life.

The hard part is simplifying complex things. We have so many odd pieces (usually due to legacy reasons or conflicting designs) which don't quite fit into an otherwise simple solution.

Plain text could probably work for most forms of communication and data formats. It's when you need to separate, categorize, and interact with the information that you need more than plain text.

This website briefly addresses plain text's shortcomings, so to add to that, in terms of software UX, I would say plain text should be used as a starting point while adding interactive elements (e.g., buttons) and layouts only as necessary. By layouts I mean visual separation of categorized information via whitespace and/or color variations. I've found that this results in extremely intuitive interfaces that are both easy for users to digest and developers to maintain.

We seem to be following a trend where "winning" software has little to no learning curves, as they are becoming the simplest possible tools for daily use. I'm not sure if it's a result of the fact that most people are tech savvy, or if we're just getting better at building software and designing interfaces. It's probably some combination of both.

Looks good in lynx, but having the site be a .txt would be cute, if annoying.

I've been kicking around the idea of a plain-text GUI to demonstrate what a "GUI Markup Standard" may work like. Making a graphics-enabled version is a lot work for a demo.

VB-classic also had a text-based mouse-able GUI option for a short while, but it never took off. It was based on ANSI escape sequences for DOS consoles, which is sort of in-between "pure text" and graphics. A pure-text GUI is also doable, but console approach is probably more compact because it can use colors as cues instead of symbols.

An alternative or supplement to a markup standard is a text-based screen designer. Both a pure-ASCII and console text UI can be defined using plain text for semi-WYSIWYG designing. Rough example:

     $ Employee Edit Form
     * _thisLine.title
     $
     $ Last: [#last    ] First: [#firstname] MI: [#MI]
     * #last:fullname=last_name, required=true; #MI:fullanem=mid_initl
     $ 
     $    {#Save}    {#Cancel}   {#Other}
     * #Save:click=_thisForm.submit; #Cancel:click= _thisForm.close
     * #Other:click=specialProcedureX(), display="Other Options"

Symbols and conventions:

     $ = start of template line
     * = start of definition or command line
     [...] = input widget template
     {...} = button template
     # = start of reference name. 
     "fullName=" = use if actual database name is diff from reference name
     ; = definition or command separator
     "type=" = to define widget type, such as SELECT (not shown)
     "display=" use if actual label is different from reference label

Notes: "type=label" can be used to make bold or italics. The definition line(s) don't have to follow the template lines in most cases. One can thus optionally put most definition lines at the bottom. It may make interpreting the template easier for some people.