test Litewrite, unhosted distraction-free writing

[Jan-Christoph Borchardt]

Jorin and I worked hard on getting Litewrite in proper shape, also at
the Remotestorage Hackday last Saturday in Stuttgart. And Niklas
helped us iron out the kinks in remotestorage support.

Now we need you to give the development version a good testing before
we deploy to litewrite.net – try it out at
http://litewrite.github.com/litewrite
We use remotestorage.js 0.7 so you need a 2012.04 remotestorage,
currently those are http://heahdk.net and http://5apps.com (they just
updated, yeah!)
The app is responsive and has a mobile view, so also try it on your smartphones!

Please open an issue for anything you find, tech issues, usability
problems and more! We also have some issues we are already aware of:
https://github.com/litewrite/litewrite/issues
Mainly annoying is the cursor misplacement:
https://github.com/litewrite/litewrite/issues/50 if you have any
pointers on how to fix it that would be a-awesome.

Future plans include inline Markdown support and the possibility to
publish documents, so you could basically run a blog off Litewrite, or
just quickly share like Pastebin:
https://github.com/litewrite/litewrite/issues/19


Any help is appreciated, we also hang out in the #unhosted and
#remotestorage IRC channels as jorin and jancborchardt.

Cheers!

[Melvin Carvalho]

On 23 October 2012 10:37, Jan-Christoph Borchardt <h...@jancborchardt.net> wrote:

Jorin and I worked hard on getting Litewrite in proper shape, also at
the Remotestorage Hackday last Saturday in Stuttgart. And Niklas
helped us iron out the kinks in remotestorage support.

Now we need you to give the development version a good testing before
we deploy to litewrite.net – try it out at
http://litewrite.github.com/litewrite

Looks great!

Only problem with this app (which I say every time) is that it's using the # anti-pattern to hide information from a server you may not trust.  This is particularly disadvantageous in a document system because you can no longer use the # character as it was intended to divide up a document and to point to data.  This really makes the whole system quite unusable in terms of interop.  Allow ALSO the use of ? with trusted servers so that the user can choose between trust of a server or linkability.  Please dont pollute the web by sharing incorrectly used indentifiers, of if you feel you MUST, allow people to opt out.

Aside from that, it looks great.  Minimal.  Simplistic.  Will this replace docrastinate?  I've been working on a personal task system something like task board too. 

In general, it's a great UI/UX as usual.  Looking forward to watching this project!
 

We use remotestorage.js 0.7 so you need a 2012.04 remotestorage,
currently those are http://heahdk.net and http://5apps.com (they just
updated, yeah!)
The app is responsive and has a mobile view, so also try it on your smartphones!

Please open an issue for anything you find, tech issues, usability
problems and more! We also have some issues we are already aware of:
https://github.com/litewrite/litewrite/issues
Mainly annoying is the cursor misplacement:
https://github.com/litewrite/litewrite/issues/50 if you have any
pointers on how to fix it that would be a-awesome.

Future plans include inline Markdown support and the possibility to
publish documents, so you could basically run a blog off Litewrite, or
just quickly share like Pastebin:
https://github.com/litewrite/litewrite/issues/19


Any help is appreciated, we also hang out in the #unhosted and
#remotestorage IRC channels as jorin and jancborchardt.

Cheers!

--

[shybyte]

Hi Melvin,

could you please explain how the "# anti-pattern"  can be avoided assuming that the app is pure javascript application with no server side components. 

As far as I know using e.g. the html history api makes only real sense of the server can provide the rendered full html for the first request (for example: http://diveintohtml5.info/examples/history/brandy.html)

This is not the case for an unhosted web app which can run from a simple static file server.

Probably I just don't get it.

Cheers, Marco

[Melvin Carvalho]

On 24 October 2012 20:26, shybyte <shy...@gmail.com> wrote:

Hi Melvin,

could you please explain how the "# anti-pattern"  can be avoided assuming that the app is pure javascript application with no server side components. 

As far as I know using e.g. the html history api makes only real sense of the server can provide the rendered full html for the first request (for example: http://diveintohtml5.info/examples/history/brandy.html)

This is not the case for an unhosted web app which can run from a simple static file server.

Probably I just don't get it.

sure in the javascript parser you search for ? as well as #

i can easily enough patch this, but it would be nice for it to go upstream
 

--
 
 
 

[shybyte]

> sure in the javascript parser you search for ? as well as #

I can see that this would work, but it would still NOT provide the usual benefits of the history.pushState approach like:

* beautiful urls (that match the serverside URLs)

* fast javascript less loading of the initial page

* crawlability from search engines

* accessibility from non JavaScript enabled browsers

* interop with other programs which just retrieve the html

So I don't know which benefits would remain. Is it more philosophical? 

With little javscript you can still use the #  to link to different parts of one page without history.pushState (#document/documentpart)).

And without javascript its not working anyway.

Cheers, Marco

[Melvin Carvalho]

On 26 October 2012 11:28, shybyte <shy...@gmail.com> wrote:

> sure in the javascript parser you search for ? as well as #

I can see that this would work, but it would still NOT provide the usual benefits of the history.pushState approach like:

* beautiful urls (that match the serverside URLs)

* fast javascript less loading of the initial page

* crawlability from search engines

* accessibility from non JavaScript enabled browsers

* interop with other programs which just retrieve the html

correct, that's a whole other problem in itself, but not one that's easily solved
 

So I don't know which benefits would remain. Is it more philosophical? 

Yes and no.

Its the ability to reference points within a document is lost which is a major weakness. It means you cant divide up a document, you cant embed data etc.  This is not a philosophical point.

Philosophically there's two problems.  1) if you get the identifiers wrong, it becomes very hard to change later  2) its an easy fix, but if left unaddresed, people are less likely to invest time on this app in terms of use/development etc.  under AGPL the option is to fork the app, but then you also have to ask whether that is worth doing too
 

With little javscript you can still use the #  to link to different parts of one page without history.pushState (#document/documentpart)).

And without javascript its not working anyway.

Yes but when you then have to set up a rule to treat the / as a special character so that the app doesnt think a/b and a are different docs.  Not really all that easy.
 

--
 
 
 

[Ian Bicking]

On Fri, Oct 26, 2012 at 5:42 AM, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 26 October 2012 11:28, shybyte <shy...@gmail.com> wrote:

> sure in the javascript parser you search for ? as well as #

I can see that this would work, but it would still NOT provide the usual benefits of the history.pushState approach like:

* beautiful urls (that match the serverside URLs)

* fast javascript less loading of the initial page

* crawlability from search engines

* accessibility from non JavaScript enabled browsers

* interop with other programs which just retrieve the html

correct, that's a whole other problem in itself, but not one that's easily solved
 

So I don't know which benefits would remain. Is it more philosophical? 

Yes and no.

Its the ability to reference points within a document is lost which is a major weakness. It means you cant divide up a document, you cant embed data etc.  This is not a philosophical point.

FWIW, if you are dynamically creating most of the page (which you would be with a dynamic page/app), then linking to portions of the page doesn't work well anyway – probably that piece of the page doesn't exist when the page first loads up, and the browser won't do anything on its own if the element is created later.  So you'd still need Javascript to position the page after the content is loaded.  (I have used the lazy hack location.hash = location.hash to force the browser to reconsider the fragment, but something as simple as document.getElementById(elementId).scrollIntoView() also works, and you could parse the elementId out of a larger location.hash.)

[Melvin Carvalho]

This may work for some simple apps.

But in my task board I envision a very dynamic task eco system where new tasks are added into your view and removed in real time.

Think minority report.

It's interesting that Ted Nelson calls the browser a "Part User Interface" (PUI) and Tim BL very often talks about widgets to make up a web page.  This is where I think the next generation of apps is going, and will be consistent with your social graph, payments, privacy settings and searchable etc. 

Thing is that Jan is one of the best UI designers in open source, imho.  So it's normally valuable to use his ideas to make really good user experiences.  Just replace the # with a ? (assuming that does not offend your sense of aesthetics) and you wont have a problem. 
 

--
 
 
 

[Ian Bicking]

On Fri, Oct 26, 2012 at 10:33 AM, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 26 October 2012 17:22, Ian Bicking <ianbi...@gmail.com> wrote:

FWIW, if you are dynamically creating most of the page (which you would be with a dynamic page/app), then linking to portions of the page doesn't work well anyway – probably that piece of the page doesn't exist when the page first loads up, and the browser won't do anything on its own if the element is created later.  So you'd still need Javascript to position the page after the content is loaded.  (I have used the lazy hack location.hash = location.hash to force the browser to reconsider the fragment, but something as simple as document.getElementById(elementId).scrollIntoView() also works, and you could parse the elementId out of a larger location.hash.)

This may work for some simple apps.

But in my task board I envision a very dynamic task eco system where new tasks are added into your view and removed in real time.

Think minority report.

It's interesting that Ted Nelson calls the browser a "Part User Interface" (PUI) and Tim BL very often talks about widgets to make up a web page.  This is where I think the next generation of apps is going, and will be consistent with your social graph, payments, privacy settings and searchable etc. 

My point is that when you overload #elementId you aren't losing a feature (the ability to link to a portion of the page) because the feature is already lost.  #elementId will make the browser scroll to the specified element only if the element is part of the initial HTML that is served up.  Given a dynamic web app, the most interesting things to link to are unlikely to be part of the initial page.

  Ian

[Melvin Carvalho]

Yes this is absolutely correct.

But we need to think beyond the browser.  Remember I said minority report?  I'm really thinking hard about projecting unified task lists onto a wall.

There's a dual operation of the # character in HTTP (in fact it extends further in media players) and that's not only to scroll to a point.  But to uniquely reference a data point WITHIN a document.  Just because at load time that element may not be there does not take away from the fact that it can be referenced, which is an amazingly useful thing.  If you ever read the fairy tale rumpelstitzskin you'll know that when you know the name of something, you gain power over it :) 

There's things called information resources and non-information resources.  When can leverage both, you can build that much more powerful systems.  Unfortunately much of this stuff is in the realms of imagination right now.  But hopefully we can put that right soon!
 

  Ian

--
 
 
 

[Ian Bicking]

On Fri, Oct 26, 2012 at 12:07 PM, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 26 October 2012 19:02, Ian Bicking <i...@ianbicking.org> wrote:

On Fri, Oct 26, 2012 at 10:33 AM, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 26 October 2012 17:22, Ian Bicking <ianbi...@gmail.com> wrote:

FWIW, if you are dynamically creating most of the page (which you would be with a dynamic page/app), then linking to portions of the page doesn't work well anyway – probably that piece of the page doesn't exist when the page first loads up, and the browser won't do anything on its own if the element is created later.  So you'd still need Javascript to position the page after the content is loaded.  (I have used the lazy hack location.hash = location.hash to force the browser to reconsider the fragment, but something as simple as document.getElementById(elementId).scrollIntoView() also works, and you could parse the elementId out of a larger location.hash.)

This may work for some simple apps.

But in my task board I envision a very dynamic task eco system where new tasks are added into your view and removed in real time.

Think minority report.

It's interesting that Ted Nelson calls the browser a "Part User Interface" (PUI) and Tim BL very often talks about widgets to make up a web page.  This is where I think the next generation of apps is going, and will be consistent with your social graph, payments, privacy settings and searchable etc. 

My point is that when you overload #elementId you aren't losing a feature (the ability to link to a portion of the page) because the feature is already lost.  #elementId will make the browser scroll to the specified element only if the element is part of the initial HTML that is served up.  Given a dynamic web app, the most interesting things to link to are unlikely to be part of the initial page.

Yes this is absolutely correct.

But we need to think beyond the browser.  Remember I said minority report?  I'm really thinking hard about projecting unified task lists onto a wall.

There's a dual operation of the # character in HTTP (in fact it extends further in media players) and that's not only to scroll to a point.  But to uniquely reference a data point WITHIN a document.  Just because at load time that element may not be there does not take away from the fact that it can be referenced, which is an amazingly useful thing.  If you ever read the fairy tale rumpelstitzskin you'll know that when you know the name of something, you gain power over it :) 

Sure; but the application can (and has to) come up with its own naming scheme.  E.g., if you add #t=1m10s to a youtube URL, it will start the video at 1 minute 10 seconds.  The browser doesn't know what that means, but when the youtube page loads it checks for its own custom naming scheme and applies it to the embedded video.  You could have a hash like #document/foo&mode=edit&position=para-3 and you parse that to mean that you want to load document/foo, you want to use an editor (as opposed to a viewer), and you want to start at a position "para-3", which in turn the application knows means the third paragraph.  You can have multiple pieces of information in the fragment, the browser can't understand them individually, but that's no loss.

[Melvin Carvalho]

On 26 October 2012 19:23, Ian Bicking <i...@ianbicking.org> wrote:

On Fri, Oct 26, 2012 at 12:07 PM, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 26 October 2012 19:02, Ian Bicking <i...@ianbicking.org> wrote:

On Fri, Oct 26, 2012 at 10:33 AM, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 26 October 2012 17:22, Ian Bicking <ianbi...@gmail.com> wrote:

FWIW, if you are dynamically creating most of the page (which you would be with a dynamic page/app), then linking to portions of the page doesn't work well anyway – probably that piece of the page doesn't exist when the page first loads up, and the browser won't do anything on its own if the element is created later.  So you'd still need Javascript to position the page after the content is loaded.  (I have used the lazy hack location.hash = location.hash to force the browser to reconsider the fragment, but something as simple as document.getElementById(elementId).scrollIntoView() also works, and you could parse the elementId out of a larger location.hash.)

This may work for some simple apps.

But in my task board I envision a very dynamic task eco system where new tasks are added into your view and removed in real time.

Think minority report.

It's interesting that Ted Nelson calls the browser a "Part User Interface" (PUI) and Tim BL very often talks about widgets to make up a web page.  This is where I think the next generation of apps is going, and will be consistent with your social graph, payments, privacy settings and searchable etc. 

My point is that when you overload #elementId you aren't losing a feature (the ability to link to a portion of the page) because the feature is already lost.  #elementId will make the browser scroll to the specified element only if the element is part of the initial HTML that is served up.  Given a dynamic web app, the most interesting things to link to are unlikely to be part of the initial page.

Yes this is absolutely correct.

But we need to think beyond the browser.  Remember I said minority report?  I'm really thinking hard about projecting unified task lists onto a wall.

There's a dual operation of the # character in HTTP (in fact it extends further in media players) and that's not only to scroll to a point.  But to uniquely reference a data point WITHIN a document.  Just because at load time that element may not be there does not take away from the fact that it can be referenced, which is an amazingly useful thing.  If you ever read the fairy tale rumpelstitzskin you'll know that when you know the name of something, you gain power over it :) 

Sure; but the application can (and has to) come up with its own naming scheme.  E.g., if you add #t=1m10s to a youtube URL, it will start the video at 1 minute 10 seconds.  The browser doesn't know what that means, but when the youtube page loads it checks for its own custom naming scheme and applies it to the embedded video. 

there's actually a media fragment specification for this for video and music so youtube is actually doing the right thing, you may consider music as divisible in the same way a doument is
 

You could have a hash like #document/foo&mode=edit&position=para-3 and you parse that to mean that you want to load document/foo, you want to use an editor (as opposed to a viewer), and you want to start at a position "para-3", which in turn the application knows means the third paragraph.  You can have multiple pieces of information in the fragment, the browser can't understand them individually, but that's no loss.

well this would be a standard in itself, which could be proposed ... however the class of applications will need to somehow know that this does not mean a new or distinct document ...

im not proposing a new standard just simply to leverage http according to best practices
 

--
 
 
 

[Melvin Carvalho]

btw all of the above applies to using ? without having to create any new standards

it's a myth that the # protects your privacy, one server still knows lots about your browser, ip address and cookies, and the other server knows what you are looking at

in "e prime" terms you gain a tiny amount of a privacy, and lose a large amount of modularity ... tho no one should ever be criticized for taking a design decision they believe in, even if the benefits are questionable, my point is that people should be given the choice (power vs privacy), and it's a one line change
 

--
 
 
 

[Jan-Christoph Borchardt]

Oi, please don’t derail the app review thread. Test
http://litewrite.net instead.


On Fri, Oct 26, 2012 at 7:43 PM, Melvin Carvalho

> --
>
>
>

[Melvin Carvalho]

On 26 October 2012 20:22, Jan-Christoph Borchardt <h...@jancborchardt.net> wrote:

Oi, please don’t derail the app review thread. Test
http://litewrite.net instead.

Apologies if the review was not well received.  It is genuine feedback, based more on the architecture than the UI. 
 

[Melvin Carvalho]

On 26 October 2012 20:22, Jan-Christoph Borchardt <h...@jancborchardt.net> wrote:

Oi, please don’t derail the app review thread. Test
http://litewrite.net instead.

Could you please explain what you mean by "derail"?