When I remove all content from a document it should be deleted. Right now it gets saved with empty strings as "content" and "title".

As a subtle indicator that the document (or the document list) has content below or above, is scrolled in any way, we should put in this shadow scroll effect: http://lea.verou.me/2012/04/background-attachment-local/

Add a function to go native fullscreen for even less distractions.

There should be a button to delete a doc and you should be able to see the last items you deleted.

Instead of the cursor moving around, the document should move around. It’s just an idea – I think iA Writer does it like that.

Where it should definitely happen is at the bottom and top: Currently if you just write, you will hit the bottom of the screen which is very ugly. Instead there shoul always be some padding to the bottom – but the scrollbar shoul reach the bottom, which is why I think this is not possible with CSS.

Observed behaviour:
As soon as I focus the #editor, little boxes appear around it's corners, that allow me to resize it. Doing so breaks the layout and causes the editor to overlap the document list irrecoverably.

Expected behaviour:
The editor already takes up as much space as it can, so I expect that browser feature to be disabled

Affected browsers:
reproducable with Iceweasel 8.0-3+b1 on Debian
not reproducable with Firefox 15.0.1, also on Debian

Possible solution:
Calling document.execCommand('enableObjectResizing', false, false); as soon as the document has loaded seems to solve the problem.

Once we deploy the app on 5apps (with all the gzip & file minify optimization) we should run some performance tests to check what we need to optimize further. For instance with the Webkit developer tools (Network, Timeline, Profiles, Audits).

I guess we have to listen to a remotestorage.connected event or something and then rerender the data? @nilclass?

At the moment, pressing tab (for example to indent a line) makes the editor lose focus and forces people to click into the text again to continue typing.

Instead, pressing tab should insert a tab space just like any normal editor does.

Currently we use the MIT license because I just added it initially. Because it’s an application rather than a library I would actually prefer we license it under AGPL so that when others make changes they have to redistribute them also.

What do you think @jorin-vogel?

When clicking a different document, currently the content just switches quickly. This is a bit confusing as your eyes are focused on the document list at the time it happens.

Instead, the documents should have a short fade out and the new one a short fade in (200 ms maybe).

It would be awesome if the editor would support auto-formatting for some symbols.
Ideas:

• links should be formatted as links
• the editor could support some markdown functionality

The date of a document is very important (see #24), especially as soon as it is possible to publicly share & publish (#19).

We should include that somehow. For thoughts on how to display the age in the document list, check out #24.

The date of the document should be shown in a format like »a week ago« (switching to »2 August 2012« on hover – omitting the exact daytime). Permanently on the top right of the document, unobtrusive and in cursive. moment.js will be useful for that.
For an unpublished document, this time should always update when the document is edited (or when it is left as last open). For a published document, the time should freeze as soon as it is published, even with changes afterward. (As we don’t have publishing yet though, that’s nothing to worry about at the moment.)

Since the stuff in src is just what the app actually is, it doesn’t seem to make sense to put it in the separate subfolder. @jorin-vogel can we just move it to the root folder and have grunt run through that?

Checking on the live version at http://litewrite.github.com/litewrite/, adding a document does not work.

The console gives me the error: Uncaught SyntaxError: Unexpected token << (main.js line 20)
When I run it on my localhost, I get: Uncaught TypeError: Cannot call method 'get' of undefined (main.js line 20)

Any ideas?

Currently when you start a new document, there is a shadow item added to the documents list. Especially with the sorting #24 coming in, there should be a placeholder title for a new document.

For instance »Start writing →« as document list element which hints towards the editor area. The placeholder would be in grey, and vanish immediately when a title is typed in.

Same for the actual document – when there is no text yet, the first line should have »Heading« or so as placeholder and the second one some text like »Distraction-free writing is amazing …«.

Is there a common way to save app settings to remoteStorage?

This is a bit of a sophisticated issue, more of a future plan.

Currently, undo basically works until you switch the document or exit Litewrite.

Instead, Litewrite should save deltas of last changes in the document JSON, so that you can Ctrl+Z until the document is empty. From any computer, however long the document is. This is inherent versioning, so we don’t need an extra versioning interface.

This only seems to happen in Chrome: On any new empty document, it’s automatically focused but the cursor is on the very top left of the viewport (basically invisible) rather than being on the left of the »Write …« placeholder.

Do you also get this? It’s very irritating because the blinking cursor is an indication that the field is focused and you can write. If it’s not present it seems the field doesn’t have focus – which it has, because you can just start writing.

You should be able to view and edit your docs on the go.
We need a mobile version of litewrite.
Is it possible to build one responsive version which runs on desktop and mobile or is it easier to build two separate versions?

Otherwise it’s not obvious that it actually is possible to have multiple documents.

When disconnecting your remotestorage by clicking the cube in the widget, localStorage should be cleared and the app should be empty.

@nilclass Does this need to be done in every app by the way or can this done by remotestorage.js automatically?

Once we have it in a reasonably stable and done state, we should put it on https://en.wikipedia.org/wiki/Full-screen_writing_program

Also search other distraction free writers (LightWrite, Typerighter) and mail their developers, as well as search for distraction-free writer articles and mail their authors.

The app should be able to work offline.

For some weird reason, the editor is getting set to »display:none«. No idea when or why that happens, but I’m unable to write anything in a new Litewrite instance. Any ideas @jorin-vogel?

Remove the dark background toggle, just settle on serif typeface for the text and bright background, because that looks way better.
Also improve vertical rhythm, sizes, etc. – check out The Elements of Typographic Style Applied to the Web for that. Also see gist.io.

Once it can be used as publishing engine (#19), offer better theming maybe.

Replace "New Doc" with an Icon to keep the UI as minimalistic as possible.

Currently, the document list just shows the first few words of the document, without cutting anything. Instead, it should just show the title.

For that, it’s probably best to either save the title in a different field or cut the content correctly.

There are two scenarios where it would be nice to see the #entries list scrolling smoothly to a certain position:

• When the user creates a new doc the list should scroll down to the bottom.
• And when the app is loaded the list should scroll to the currently open document.

@nilclass advised to have a threshold in the app that only saves to localstorage when users don’t make any action for ~300ms, to not obstruct typing flow.

Currently, every time you switch documents it resets to the top. Instead it should scroll to the part where you had that document scrolled last. That info should probably be stored in the JSON object of the document itself, so you also have it across machines.

Can be easily done using jQuery .scrollTop().
Same for the actual cursor position: http://stackoverflow.com/questions/499126/jquery-set-cursor-position-in-text-area

The build app can be used by opening build/index.html in your browser but to contribute to the project it takes a bit more effort:

• you must have node.js installed
• npm installall dependencies
• (sudo) npm install -g grunt to type gruntinstead of node_modules/grunt/bin/grunt
• run grunt buildto build the project
• put the project on a webserver to view src/index.html because it uses XMLHttpRequests:
  • put it on your local Apache
  • or type python -m SimpleHTTPServer 8000
  • or some other server

I can’t really pinpoint it, but maybe clicking the document button does nothing. Only after repeated clicking or clicking somewhere else first a new document is opened. There are no errors in the console, but it seems to more likely appear when you had another tab focused previously.

When you click multiple times on "New document" the app throws Uncaught TypeError: Cannot read property 'cid' of undefined.

At the moment require.js copies all files over to build/js/. This should be cleaned up in the build process.

Docs should be sortable via drag&drop and it would be nice to be able to throw them into the trash.

@jancborchardt :

1. Maybe there should be small gaps / headings in the list where the docs are from »last week«, »last month«, »last year« etc. Seems to be like a bit of a cop-out though.
2. Crazy intermittent thought: What about having variable spacing between the documents, depending on when they were last accessed? Let’s say the documents list would by default show in its height a course of a week, or a range so that a minimum of ~3 documents are always shown, whatever occurs first. This is probably just chartporn though.
3. Another interesting thing in combination with the small headings would be to change the brightness of the document title in the document list. The older the document, the brighter the type becomes (until a certain level where it is still readable). I implemented this in ownCloud for file size and date, and it proves pretty useful to get a quick feeling for where a specific file stands.

All three approaches sound interesting.

1. The first one looks straight forward but I would like to avoid the need for words in the UI.
2. This one sounds interesting but I have no idea how to implement it in a way that it is actually usable. Maybe you can explain the idea in a bit more detail.
3. And the last thought looks cool too as long as you can still read even the title of the oldest document in the list.

At the moment, the document addresses are numbered, for example litewrite.net/#3

Instead, the document title itself should be used as the address, for example litewrite.net/#todo-list

This is related to #18 limit document list to titles and #19 public sharing.

Currently it is possible to just not put anything in the first line, which leads to some confusing behavior.
The title stays empty at first, as specified in the code: »empty if content starts with '
'« (see #18)
Then, after switching to another document, the title in the navigation bar suddenly is the first piece of text in the document, and switching back to the original document, the formatting effectively changed to put the first line with actual text as the header.

Instead, it should not be possible to omit the first line. By initially not enabling a line break until something has been typed. On the other hand, it should probably be possible to put a line break before the first line after something has been written, in case something needs to be inserted before it.

What are your thoughts?

Since the app should be able to work without a connection to the internet and it can be used from more than one device there can occur conflicts between local and remote data.
This conflicts should be solved with the help of timestamps for each single document.
Does remoteStorage.js includes this functionality already?

We have to implement the idea @jancborchardt described in issue #12:

People should not need to sort documents manually, instead they should be automatically sorted by frequency + recency of use.

This will also make the notion of a trash obsolete. Not using a document for long (or rather, using other documents more >recently) will automatically bump it down in the list.

How should the position of a document be calculated based on frequency + recency?

And what happens with old documents? Will the list grow infinitely or should we delete the docs at the bottom?

Similar to what Etherpad and LightWrite do and similar to the measures in #29, we should have a welcome message in the textarea itself for every fresh user of Litewrite.
People can see that it’s for text, edit it, have a first document in the list, and we can give a very short description or tips.

The .editor textarea is not affected my the :first-line selector.
How can that be fixed?

The padding of the textarea seems not to work in Firefox.

In the moment we have no tests at all.

Currently, the document list is impossible to find for new people. At the same time, it should not be obtrusive at all during writing.

As a solution, the .aside should initially show for ~3 seconds and then fade. This should always happen when you newly open the app. (As in the old version.)

Otherwise it’s not obvious that it actually is possible to have multiple documents.

My ideas are:

• New document: alt+n
• Open next/previous document: alt+up/down

With remoteStorage support (#7), we can add the ability to publicly share an article. This would make the article show up at litewrite.net/#[email protected]/article (also see #17 about the document address).

Litewrite can then also be used as a publishing tool. If you hardcode your user address in, you could set it up on your personal server and publish articles at yourwebsite.com/#article

Implement some routes to reflect the current state of the application.
My suggestion would be:

• new document /
• /:title