[Caml-list] [ANN] Prose v1 - a collaborative text editor

[Caml-list] [ANN] Prose v1 - a collaborative text editor

[Adrien Nader]

Hello,

I am happy to announce the first release of Prose, a collaborative text
editor started after being both frustrated and horrified by Etherpad
Lite.
Etherpad Lite is heavily used in groups I am involved in or close to:
FFDN, DIY ISPs, Éxégètes Amateurs, Framasoft, ... (all being horrible
leftists and libre-ists). It occurred to me that its bugs,
administration costs and limitations were hampering us.

It realistically aims at replacing Etherpad Lite with something better
on every aspect for both clients and servers: lower CPU, memory and
network usage, more features, fewer bugs and an active development.

The code is hosted on https://gitlab.com/adrien-n/prose and can be
downloaded either through git or through tarballs on
https://gitlab.com/adrien-n/prose/tags .
A demo is available on http://prose.yaxm.org/pads/caml-announce . Any
document name can be used and the website root is an alias for
"default".

Its development has been in line with the vision of the new French
President to make France a « Startup Nation ».
As such, the current release works, has an UI that shouldn't change too
much but also has a few caveats that aren't immediately visible. It is a
« minimum viable product », i.e. « a product with just enough features
to satisfy early customers, and to provide feedback for future
development. » [1]. It is believed the AGPLv3 license will scare
absolutely no angel investor.

I haven't conducted thorough benchmarks because performance is very
clearly in favor of Prose:
- lower network usage for cold and hot browser caches, almost optimal,
- much much lower CPU usage
- > 4 times lower server-side memory
- > 5 times lower page load time

Installation is not documented through an Ansible role which is stored
under ansible/ in the sources. Ansible code is not very fun to write but
reading it shouldn't be an issue and it guarantees the procedure is
always up-to-date.

The project wouldn't exist without Ocsigen and QuillJS.
QuillJS [ https://quilljs.com/ ] is a rich-text editing widget which
features Operational Transform [2] for edition deltas.
Ocsigen [ https://ocsigen.org/ ] is already well-known in the OCaml
world; it does most of the hard work an everything else is based on it.

The code has been quite heavily documented and its entrypoint is
prose.eliom.
One of the project goal has been to make an ocsigen project that could
be used by others to learn. Maybe it has now grown too much for that but
it should still be possible to extract interesting blocks and make a
nice tutorial using it.

Besides general improvements, future version will introduce client-side
storage, session-handling and encryption along with more export formats.
Tests, bug reports and contributions are warmly welcome. Development is
carried on gitlab which handles oauth2 and authentication using accounts
from twitter, facebook, github and bitbucket is possible.

[1] https://en.wikipedia.org/wiki/Minimum_viable_product
[2] https://en.wikipedia.org/wiki/Operational_transformation

-- 
Adrien Nader

Re: [Caml-list] [ANN] Prose v1 - a collaborative text editor

[SP]

Nicely done Adrien.

-- 
    SP

Re: [Caml-list] [ANN] Prose v1 - a collaborative text editor

[Sébastien Hinderer]

Dear Adrien,

I find it awesome that such a tool is developed in OCaml and wish it all
the possible success.

Has accessibility already been taken into account? Is there any plan on
this for future developemnt? I am asking because most of the pads I know
lack this feature.

Thanks,

Sébastien.

Re: [Caml-list] [ANN] Prose v1 - a collaborative text editor

[Adrien Nader]

Hi Sébastien,

On Tue, Jul 11, 2017, Sébastien Hinderer wrote:
> Dear Adrien,
> 
> I find it awesome that such a tool is developed in OCaml and wish it all
> the possible success.
> 
> Has accessibility already been taken into account? Is there any plan on
> this for future developemnt? I am asking because most of the pads I know
> lack this feature.

Accessibility has not really been taken into account so far. However I
definitely see that as an issue. My main problem with doing it is that
this is not a field I know and I definitely welcome pointers to
resources I could learn from.

Actually, my own machines typically force white text on dark
backgrounds, including for web pages. As such I already avoid things
that wouldn't render properly (CSS and font icons) and try to label
interactive elements (although I haven't managed to do it for everything
yet, see e.g. https://gitlab.com/adrien-n/prose/issues/42 ).

That said, this also depends on Ocsigen and I don't know how well it
fares on this. IIRC there are APIs related to accessibility but I
haven't looked at them and I can't tell whether they cover everything
needed (it's not unlikely they do).

It's also important to take the JS library into account. I think it
doesn't fare too bad in this aspect but I haven't checked properly.

There are also some features that I don't know how to make accessible.
On a graphical display, and especially with colors, it is easy to notice
edits from others without being interrupted. This relies either a lot on
peripheral vision, or on eyes being able to quickly jump to the proper
position when the text suddenly shifts after words or lines are
inserted. Hopefully, while these situations happen, they are not the
norm. Material to learn from is welcome for this too.

All in all, this is going to take a few months to get into the code but
again there are many things that still need to be done.
rhere is already a ticket on gitlab about this:
https://gitlab.com/adrien-n/prose/issues/24 . It is not very detailed
and I guess I'm both missing some things and wrong on others so input is
welcome. :)

Best regards,

-- 
Adrien Nader

Re: [Caml-list] [ANN] Prose v1 - a collaborative text editor

[Sébastien Hinderer]

Dear Adrien,

Many thanks for your prompt and positive response!

Adrien Nader (2017/07/11 15:09 +0200):
> Hi Sébastien,
> 
> On Tue, Jul 11, 2017, Sébastien Hinderer wrote:
> > Dear Adrien,
> > 
> > I find it awesome that such a tool is developed in OCaml and wish it all
> > the possible success.
> > 
> > Has accessibility already been taken into account? Is there any plan on
> > this for future developemnt? I am asking because most of the pads I know
> > lack this feature.
> 
> Accessibility has not really been taken into account so far. However I
> definitely see that as an issue. My main problem with doing it is that
> this is not a field I know and I definitely welcome pointers to
> resources I could learn from.

Well, I am not an expert either. I mean, I face accessibility issues as
a user, but that does not necessarily mean I know how to fix them as
people tend to believe. I should probably learn that, too.

The W3C has a work group on accessibility, the WAI (Web Accessibility
Initiative).

This group has published:
- The WCAG, Web Content Accessibility Guidelines:
https://www.w3.org/WAI/intro/wcag
- Tge ATAG (Authoring Tools Accessibility Guidelines):
https://www.w3.org/WAI/intro/atag
 
And a few other documents that may be a bit less relevant here.

I also did a little presentation on accessibility. It is not focused on
web accessibility but may be of interest to those curious about how
blind people use computers:
http://brl.thefreecat.org/conf.mkv

The presentation is in french, sorry about that.

And the video has a bug (when I run X the content of the screen is not
displayer), I hope this will be fixed soon.

> Actually, my own machines typically force white text on dark
> backgrounds, including for web pages. As such I already avoid things
> that wouldn't render properly (CSS and font icons) and try to label
> interactive elements (although I haven't managed to do it for everything
> yet, see e.g. https://gitlab.com/adrien-n/prose/issues/42 ).
> 
> That said, this also depends on Ocsigen and I don't know how well it
> fares on this. IIRC there are APIs related to accessibility but I
> haven't looked at them and I can't tell whether they cover everything
> needed (it's not unlikely they do).
> 
> It's also important to take the JS library into account. I think it
> doesn't fare too bad in this aspect but I haven't checked properly.
> 
> There are also some features that I don't know how to make accessible.
> On a graphical display, and especially with colors, it is easy to notice
> edits from others without being interrupted. This relies either a lot on
> peripheral vision, or on eyes being able to quickly jump to the proper
> position when the text suddenly shifts after words or lines are
> inserted. Hopefully, while these situations happen, they are not the
> norm. Material to learn from is welcome for this too.

I am not sure how to make such features accessible either. Intuitively,
I have always thought that a pad that can be modified by several persons
in parallel is intrinsically inaccessible. However, I don't know whether
this is actually true or not. And even if it's true, there may be some
kind of "best effort" way to provide at least some degree of
accessibility. I will investigate on this.

> All in all, this is going to take a few months to get into the code but
> again there are many things that still need to be done.

I think it's really not a big deal if it takes time. Roughly speaking we
start with "nothing" (no accessible alternative at all) so any single
thing happening would be an improvement over what currently exists.


> rhere is already a ticket on gitlab about this:
> https://gitlab.com/adrien-n/prose/issues/24 . It is not very detailed
> and I guess I'm both missing some things and wrong on others so input is
> welcome. :)

When you are blind, sometimes it's even difficult to simply
figure out what exactly is not working or what you don't have access to,
because you don't have access to it. I mean, say there is a button to
underline something. If the screen reading system does not present this
button to me, I won't be able, by myself, to tell you that this button
is not accessible, because I don't even know it's here.

That's why, IMO, sometimes the most effective way to progress is to
physically meet and see together what works and what does not. If you
are in Paris and would like to, we could organise such a meeting.

Cheers,

Sébastien.

Re: [Caml-list] [ANN] Prose v1 - a collaborative text editor

[Adrien Nader]

Hi,

On Tue, Jul 11, 2017, Sébastien Hinderer wrote:
> Dear Adrien,
> 
> Many thanks for your prompt and positive response!
> 
> Adrien Nader (2017/07/11 15:09 +0200):
> > Hi Sébastien,
> > 
> > On Tue, Jul 11, 2017, Sébastien Hinderer wrote:
> > > Dear Adrien,
> > > 
> > > I find it awesome that such a tool is developed in OCaml and wish it all
> > > the possible success.
> > > 
> > > Has accessibility already been taken into account? Is there any plan on
> > > this for future developemnt? I am asking because most of the pads I know
> > > lack this feature.
> > 
> > Accessibility has not really been taken into account so far. However I
> > definitely see that as an issue. My main problem with doing it is that
> > this is not a field I know and I definitely welcome pointers to
> > resources I could learn from.
> 
> Well, I am not an expert either. I mean, I face accessibility issues as
> a user, but that does not necessarily mean I know how to fix them as
> people tend to believe. I should probably learn that, too.
> 
> The W3C has a work group on accessibility, the WAI (Web Accessibility
> Initiative).
> 
> This group has published:
> - The WCAG, Web Content Accessibility Guidelines:
> https://www.w3.org/WAI/intro/wcag
> - Tge ATAG (Authoring Tools Accessibility Guidelines):
> https://www.w3.org/WAI/intro/atag
>  
> And a few other documents that may be a bit less relevant here.
> 
> I also did a little presentation on accessibility. It is not focused on
> web accessibility but may be of interest to those curious about how
> blind people use computers:
> http://brl.thefreecat.org/conf.mkv
> 
> The presentation is in french, sorry about that.
> 
> And the video has a bug (when I run X the content of the screen is not
> displayer), I hope this will be fixed soon.

Thanks for the links. I have poked a few people on IRC too and there's
now a fair bunch of links in the ticket.

> > Actually, my own machines typically force white text on dark
> > backgrounds, including for web pages. As such I already avoid things
> > that wouldn't render properly (CSS and font icons) and try to label
> > interactive elements (although I haven't managed to do it for everything
> > yet, see e.g. https://gitlab.com/adrien-n/prose/issues/42 ).
> > 
> > That said, this also depends on Ocsigen and I don't know how well it
> > fares on this. IIRC there are APIs related to accessibility but I
> > haven't looked at them and I can't tell whether they cover everything
> > needed (it's not unlikely they do).
> > 
> > It's also important to take the JS library into account. I think it
> > doesn't fare too bad in this aspect but I haven't checked properly.
> > 
> > There are also some features that I don't know how to make accessible.
> > On a graphical display, and especially with colors, it is easy to notice
> > edits from others without being interrupted. This relies either a lot on
> > peripheral vision, or on eyes being able to quickly jump to the proper
> > position when the text suddenly shifts after words or lines are
> > inserted. Hopefully, while these situations happen, they are not the
> > norm. Material to learn from is welcome for this too.
> 
> I am not sure how to make such features accessible either. Intuitively,
> I have always thought that a pad that can be modified by several persons
> in parallel is intrinsically inaccessible. However, I don't know whether
> this is actually true or not. And even if it's true, there may be some
> kind of "best effort" way to provide at least some degree of
> accessibility. I will investigate on this.

That would be tremendously helpful. The software is already planned to
be able to extract information from the content (the outline at least)
and more may be added but presenting that well to blind users is
something I have troubles designing. That said, such information and
notices can also be an unwanted distraction including to non-blind
users.

> > All in all, this is going to take a few months to get into the code but
> > again there are many things that still need to be done.
> 
> I think it's really not a big deal if it takes time. Roughly speaking we
> start with "nothing" (no accessible alternative at all) so any single
> thing happening would be an improvement over what currently exists.

 :) 

> > rhere is already a ticket on gitlab about this:
> > https://gitlab.com/adrien-n/prose/issues/24 . It is not very detailed
> > and I guess I'm both missing some things and wrong on others so input is
> > welcome. :)
> 
> When you are blind, sometimes it's even difficult to simply
> figure out what exactly is not working or what you don't have access to,
> because you don't have access to it. I mean, say there is a button to
> underline something. If the screen reading system does not present this
> button to me, I won't be able, by myself, to tell you that this button
> is not accessible, because I don't even know it's here.
> 
> That's why, IMO, sometimes the most effective way to progress is to
> physically meet and see together what works and what does not. If you
> are in Paris and would like to, we could organise such a meeting.

I am indeed in Paris and believe meeting would be very helpful.
There's probably a bit of homework I should do first however: there are
for sure several issues that I can already notice and fix.

Best,

-- 
Adrien

Re: [Caml-list] [ANN] Prose v1 - a collaborative text editor

[Sébastien Hinderer]

Dear Adrien,

Many thanks for your response.

Just contact me privately when you are ready and we will organize a
meeting.

Cheers,

Sébastien.