what litewrite is about

[jorinvo]

I think we all agree that litewrite should be as simple as possible.
It's main purpose should be writing plain text without any distractions. It should work on any platform and the user should be free to store his data wherever she wants to.

However it's not clear how many additional features we can add without that the editor feels to bloated:

• Search: In may opinion searching for documents is a really important feature and it can be implemented without getting into your way (Search documents #91 for more).
• Publishing: This is quiet a big thing but I think we can add basic publishing without destroying the simplicity of the editor. The editor just needs a button to toggle whether the document is public or not and a second button when the document is published to get to the published version. We just have to find a nice what to integrate those buttons. Everything else doesn't affect the editor itself (see public sharing & publishing #19).
• Word count for document (word count on bottom of document #122): This is just a transparent number on the bottom of a document. Shouldn't get in the way of anyone.
• Show date for document (show date #25): Another simple and helpful info to display on a document.
• Image upload (image insertion via drag&drop #87): To support images we have to provide a place to upload images to and the documents can't be plain text anymore. I am not sure if this is what I want litewrite to be. We don't want to replace Word. Neither we want to build a blogging system. Litewrite should be about writing only.
• Link formatting (Enhanced Editor #11): The document could be plain text. But in the document we could mark all links and make them clickable. I like this idea. So even if we work just with plain text you could use litewrite so save links and link to other resources. At least for me this is a quiet common usecase: I take a small note and put a link next to it.
• Markdown support (Enhanced Editor #11): This is a difficult decision. Should litewrite be a plan text editor or a markdown editor? I am not sure about this one right now. But what I am sure about is that I don't want it to stay a html editor as it is right now through the unprotected contenteditable.
  If we go for markup we should definitely support inline-highlighting. However I don't like the idea that the published version looks different to the editor version. I don't want litewrite to become a publishing tool. Also, I am not sure if it is a good idea to support all markdown commands. Do we want images in the documents? And how about code highlighting? Should this be a part of litewrite?

@litewrite/contributors what do you think about this?

[jancborchardt]

(The previous comment seems to have been garbled because I replied via email, here’s the proper one:)

Great initiative on defining the core functionality! I pretty much agree completely, remarks inline.

Also, I'll be back in Germany in a week. In Munich then and visiting Stuttgart as well most probably, so we should do another hackday then!

I think we all agree that litewrite should be as simple as possible.
It's main purpose should be writing plain text without any distractions. It should work on any platform and the user should be free to store his data wherever she wants to.

Yes, and I think this includes expanding to support Dropbox, Google Drive and maybe ownCloud Files via WebDav (to share with the Notes app). There's an issue but I'm mobile atm :)

However it's not clear how many additional features we can add without that the editor feels to bloated:

Search: In may opinion searching for documents is a really important feature and it can be implemented without getting into your way (#91 for more).

Yep. It's an important function and we integrate it well. Especially with it being effectively hidden up top like you said in your last comment.

Publishing: This is quiet a big thing but I think we can add basic publishing without destroying the simplicity of the editor. The editor just needs a button to toggle whether the document is public or not and a second button when the document is published to get to the published version. We just have to find a nice what to integrate those buttons. Everything else doesn't affect the editor itself (see #19).

Yes. Very basic, with the published doc looking exactly like the document inside Litewrite, except not being editable.
Integration of those buttons I think is best inside the doc, top right or so, next to the date.

Word count for document (#122): This is just a transparent number on the bottom of a document. Shouldn't get in the way of anyone.

Yes.

Show date for document (#25): Another simple and helpful info to display on a document.

Yes, see above I think it should be placed top right somewhere.

Image upload (#87): To support images we have to provide a place to upload images to and the documents can't be plain text anymore. I am not sure if this is what I want litewrite to be. We don't want to replace Word. Neither we want to build a blogging system. Litewrite should be about writing only.

Exactly, this is where I think we should draw the line, at least for now. Litewrite is for pure text.

Link formatting (#11): The document could be plain text. But in the document we could mark all links and make them clickable. I like this idea. So even if we work just with plain text you could use litewrite so save links and link to other resources. At least for me this is a quiet common usecase: I take a small note and put a link next to it.

Yep! iOS Notes and other apps do it similarly. Quite useful to be able to click links.

Markdown support (#11): This is a difficult decision. Should litewrite be a plan text editor or a markdown editor? I am not sure about this one right now.

I think markdown editors can be plain text, and if we do it we should do it like that. It's just that seemingly all existing markdown editors ise this damned split view of editor and rendered view.

what I am sure about is that I don't want it to stay a html editor as it is right now through the unprotected contenteditable.
If we go for markup we should definitely support inline-highlighting. However I don't like the idea that the published version looks different to the editor version. I don't want litewrite to become a publishing tool.

Fully agree. We should only use text instead of contenteditable. And there it's probably good to go for something stable such as Codemirror, even if we don't do Markdown. Codemirror might even do clickable links or so already.

Also, I am not sure if it is a good idea to support all markdown commands. Do we want images in the documents? And how about code highlighting? Should this be a part of litewrite?

Not necessary for the first version at least. Most important are headlines, strong, italic, links and lists I guess. Then after that we could do image (only hotlinks) and other stuff.

@xMartin I'm also interested in your general opinion on these thoughts/principles.

[jancborchardt]

Also, here is a text I wrote some time ago on what I think Litewrite is about and why it’s needed. Maybe that is also good as second intro document titled »Litewrite vision« or something like that, with the first one being more of a »Get started« thing, and this one being a bit of a credits and roadmap thing as well. What do you think @jorin-vogel?

Litewrite was built out of a need to have a simple way of taking notes, having them everywhere, working on any device, regardless if on- or offline.

• simple design
• available everywhere (device compatibility + synced data)
• works offline

No current solution provides that. It's quite strange that something as benign as jotting down text isn't really solved unless you buy into one specific »ecosystem«. Either the design is complicated, or they only work on Apple hardware, or they are tied to Dropbox, or you can't do anything if you don't have wifi, or or or …

So we built Litewrite

• simple design: There are lots of other self-titled distraction-free editors which offer music, themes, different typefaces, etc etc. We don't, because we think that's unnecessary. If you want music you can listen to it using your favorite music player, if you want to change the font size you can zoom using your browser, …
• device compatibility: It’s a web app which works on all devices and operating systems.
• synced data: Notes are available everywhere, using the open remoteStorage standard. Compatibility with Dropbox, Google Drive, ownCloud, etc.
• offline: Once loaded, it’s essentially a desktop app. Thanks to AppCache and localStorage, both app and data are fully cached offline and synced whenever online.

Now of course it's far from perfect, but we and lots of others use it day-to-day. And that's also why we made it open source If you experience any problems or have suggestions, please let us know at http://github.com/litewrite/litewrite/issues
And if you know a little about web development you're welcome to dive into the code at http://github.com/litewrite/litewrite

Cheers,
Jorin & Jan-Christoph

[jorinvo]

Yeah, I think it's a good idea to mention those things somewhere however I would tend to put this into the first document too. And this should be shortened a bit.

[jorinvo]

So the only reason that this issue is still open is that we still want to include this text in the README.
@jancborchardt could you do that?