Futur AsciiDoctor project ?

[mgreau]

This issue is created to answer this question : What would it take to change if this project was becoming an official AsciiDoctor project (find a name, change Java package...) ?

[lordofthejars]

Hi I think it should become official because it is a really good tool. But I am the worst person to name things, but I will suggest some medical tool, in reference to Ascii(Doctor).

[ggrossetie]

Websockiidoctor ? :smiley:

[jnorthr]

i'd vote 4 'maxdoctor' :-)

[mgreau]

I plan to buy :

• ad-editor.io => for the editor
• ad-editor.org => for the dedicated website

WDYT ? (cc @mojavelinux)

[mgreau]

ad => for AsciiDoc and asciidoctor

[cmoulliard]

Maybe adcollab as new name as this is until now its goal to do collaborative work ...

[cmoulliard]

BTW, we could perhaps integrate what I have done with hyla to propose a great project where we can edit, watch, develop content in a collaborative way and generate too Slideshow (Revealjs, DeckJS, DZSlides, ...), PDF, sendmail ...

[mgreau]

yes you're right the "collaborative" keyword is something important

[mgreau]

@cmoulliard thanks, for now I prefer to keep it focus on all the currently used technologies (JavaEE7, angular, asciidoctorj, asciidoctor.js, asciidoctor-backends, asciidoctor-pdf...) and try to make a usable web tool before adding new technology.

[mojavelinux]

I definitely see this project as a good fit for the Asciidoctor organization. When you're ready, let's do it.

As for the domain name, I'm a fan of edit-adoc.io because it's a) active and b) reads like what it does.

I think we should consider a more compelling name for the project. I know names are really hard, but it's worth the effort to get it right because it makes it so much easier to get people behind it.

[jnorthr]

have always thought this was an excellent idea -

while drinking my cuppa this morning, the idea arrived: why not an asciidoctor server that i/we/any website could hit via websockets to dynamically render .adoc's and return a payload like docbook/html/pdf ? or maybe some kind of rest-style api ? well - ok - maybe i put too many sugars in my cuppa :-}

[mojavelinux]

why not an asciidoctor server that i/we/any website could hit via websockets to dynamically render .adoc's and return a payload like docbook/html/pdf ? or maybe some kind of rest-style api ? well - ok - maybe i put too many sugars in my cuppa :-}

We think alike. I agree. Having a native AsciiDoc server would be awesome. I even forsee us leveraging query parameters as a way to set attributes and options to alter the display. There is something big here.

[jnorthr]

yes, me thinks too ! Then we would only need to deploy asciidoctor and asciidoctor-pdf to a single point when a new version is released. Was scratching my head as to whether an http POST or PUT might be right as it carries the payload to the target a/d app - ( i dont know enough about websockets yet ). i would worry about the char.set/codepage issues as i work on several european languages that need special char.s, so utf-8 or utf-16 is a safer bet for me.

of course this would scale beautifully to several instances on an a/d server as there are no side-consequences or state held in the app - hmmm... hmmmm... yes...

[mgreau]

@mojavelinux Awesome ! :) +1 for edit-adoc.io

I think we should consider a more compelling name for the project.

What is the best way to do that ? create a doodle ? open an other issue for that ?

@jnorthr yes, it's a great idea ! I thought about it : AsciiDoc as a Service :) Indeed, a REST API will be cool !

[mojavelinux]

A doodle would work. Then post to discuss list. We'll go from there.

[jnorthr]

yes - doodle please :)

[lordofthejars]

add me please :)

2014-09-23 13:10 GMT+02:00 jnorthr notifications@github.com:

yes - doodle please :)

— Reply to this email directly or view it on GitHub https://github.com/mgreau/when-websocket-met-asciidoctor/issues/24#issuecomment-56504999 .

+----------------------------------------------------------+ Alex Soto Bueno - Computer Engineer www.lordofthejars.com +----------------------------------------------------------+

[jnorthr]

OK, as Max said - AsciiDoc as a Service - going down this line a bit more, if i key the following byte stream into a browser address bar+enter, my primitive module from a cloud foundry server returns what we would expect:

http://asciidoctors.de.a9sapp.eu/asciidoc.groovy?toc=toc&backend=html&theme=native&payload=%3D+My+Notes+About+AsciiDoctor%0D%0AMax+%3Cgreaumaxime%40gmail.com%3E%0D%0Av1.0%2C+2014-02-01%0D%0A%0D%0A%3D%3D+Nice+Tutorial%0D%0Ahttp%3A%2F%2Fasciidoctor.org%2Fdocs%2Fasciidoc-writers-guide%2F%5BWriter%27s+Guide%5D%0D%0A%0D%0A%3D%3D+Samples+And+References+%0D%0AWe+could

it's url encoded, so funny char.s are translated to hex, so for my french char.s look nice. Yes, was hoping for a websocket solution like you suggested - maybe next try -

[jnorthr]

found an extremely interesting website that let's us develop an API specification interactively. Then it publishes documentation about the declared API. So just for grins, have done edit-adoc api spec here: http://docs.editadoc.apiary.io/

now just need to fix the app code to make it work :-}

[mgreau]

Hi all,

OK so just to be clear and to be sure that I'm in phase with what we need to do : 1) the first step is to find a more compelling name for the github project name 2) in a second time, we'll need to find a domain name

So, I think I can post a message to discuss list for the 1) without doodle. Then when the github project will be move to the Asciidoctor organization, we'll post an other message to discuss list with a doodle to handle the point 2) .

Am I right? WDYT?

[mojavelinux]

Sounds about right. +1

[mojavelinux]

After seeing edit-adoc.io again, I had another idea for a name. Perhaps instead of what you are doing ("edit a doc"), it should read what it is ("a doc editor"), which leads us to adoc-editor.io as the domain name. Again, it's a play on words of "adoc" or "a doc", but it reads more like a product name. Perhaps you could just get both (and make the crown even richer, apparently).

[leif81]

which leads us to adoc-editor.io as the domain name.

That rolls off the tongue nicely :+1:

[jnorthr]

had started an api doc writeup here: http://docs.editadoc.apiary.io but it can be changed once we settle on a url [?]

On 27 November 2014 at 02:24, Leif Gruenwoldt notifications@github.com wrote:

which leads us to adoc-editor.io as the domain name.

That rolls off the tongue nicely [image: :+1:]

— Reply to this email directly or view it on GitHub https://github.com/mgreau/when-websocket-met-asciidoctor/issues/24#issuecomment-64734223 .

[mgreau]

Hi all,

Sorry for the late response. I'm back with some links to share with you. Indeed, I think that in order to find "the good names" (for the github project and for the product) we need to have a better idea of what features we want to propose to the asciidoctor users (just edit a doc or more...).

As I think we can offer a lot of features thanks to the awesome Asciidoctor team, I've started to develop a (better) frontend UI with AngularJS/Material Design/Firebase. For now, there is no call to the actual backend (WebSocket.java), I think it will be the next step (for PDF and slides features).

I let you discover what you can do with this UI :

• online version => http://editadoc-mgreau.rhcloud.com/#/home
• a 3 mn Video Demo of what you can do with this tools on a mobile (Nexus5) => https://www.youtube.com/watch?v=Iwr-S7TfvHg

I'd love to know what you think about it. I will post a message on the discussion list on Monday with the links.

Thanks. Maxime

[jnorthr]

Bonsoir Maxime - yes have been looking at all your hard work ! My what an effort too :-)

i like the easy github integration that works well and also the instant 'render' of an adoc after each keystroke - mighty good.

I'm guessing that there must be a SAVE button somewhere to keep recent changes safe ? (est -il un bouton SAVE endroit pour conserver les modifications récentes en sécurité?) I cannot find that yet. Also cannot see how to share a document with you/someone else using the github approach.

i have some time to help with documentation (in english) if you have any topics you need covered let me know.

think i may need to git clone your code so i can see how to make the dropbox idea fit in. It looks to me to be the same as github, but with more logic to read/write documents from dropbox. At least i know we can share documents within dropbox. More on that soon.

GR8 effort !! many thanx jim

On 13 December 2014 at 16:31, Maxime Gréau notifications@github.com wrote:

Hi all,

Sorry for the late response. I'm back with some links to share with you. Indeed, I think that in order to find "the good names" (for the github project and for the product) we need to have a better idea of what features we want to propose to the asciidoctor users (just edit a doc or more...).

As I think we can offer a lot of features thanks to the awesome Asciidoctor team, I've started to develop a (better) frontend UI with AngularJS/Material Design/Firebase. For now, there is no call to the actual backend (WebSocket.java), I think it will be the next step (for PDF and slides features).

I let you discover what you can do with this UI :

• online version => http://editadoc-mgreau.rhcloud.com/#/home
• a 3 mn Video Demo of what you can do with this tools on a mobile (Nexus5) => https://www.youtube.com/watch?v=Iwr-S7TfvHg

I'd love to know what you think about it. I will post a message on the discussion list on Monday with the links.

Thanks. Maxime

— Reply to this email directly or view it on GitHub https://github.com/mgreau/when-websocket-met-asciidoctor/issues/24#issuecomment-66879918 .

[mgreau]

Hi Jim and thanks :)

I'm guessing that there must be a SAVE button somewhere to keep recent changes safe

For now, each time you're updating your asciidoc, your datas are automatically saved to the backend (thanks to Firebase). As you can see on the video, even if there are troubles with your internet connection and you are still writing, it's not a problem, when you come back online all the work that you did during this "offline mode" is automatically synchronized and saved again (thanks again to Firebase) So I don't think (maybe I'm wrong) that we need a save button, or maybe when we know that the "offline mode" will last for long.

I cannot find that yet. Also cannot see how to share a document with you/someone else using the github approach.

Yes, I'm working on it, I'll add this feature next week. I'll do it as simple as possible in the first time. I think that we need to define the workflow that we want to create between users when they work on the same project (concurrent access, one version by user...). Technically, there should not be any problem whatever the solution we choose, especially if we use Firebase.

think i may need to git clone your code so i can see how to make the dropbox idea fit in.

Yeah, the dropbox integration will be cool too. For now, the code is on Google Drive, I will push it to github but I don't know if the best solution is to used this repo or to create a new repository and organized it like this :

• frontend (Angular / Material Design / Firebase (websocket backend with datas) / asciidoctor.js)
• backend (Java/WebSocket Backend / asciidoctorj / asciidoctorj-pdf / asciidoctorj-epub3)
• mobile (ionic framework / Firebase)
• doc (the asciidoc documentation for this editor)

Maybe @mojavelinux has an idea about it.

[mojavelinux]

Maxime,

This is incredible work. And I'm seeing a lot of favorites on Google+ and Twitter to your post.

Where this tool really stands out is the mobile support. We all know that the biggest barrier to writing is writer's block...and the solution to that is to relocate to a more creative space. If a writer can write from anywhere, that means we are giving them something they've never had before in technical writing (maybe you could use an offline notebook, but that would be hard to use for technical writing).

There's a future in this tool, no doubt in my mind.

-Dan

On Sat, Dec 13, 2014 at 8:31 AM, Maxime Gréau notifications@github.com wrote:

Hi all,

Sorry for the late response. I'm back with some links to share with you. Indeed, I think that in order to find "the good names" (for the github project and for the product) we need to have a better idea of what features we want to propose to the asciidoctor users (just edit a doc or more...).

As I think we can offer a lot of features thanks to the awesome Asciidoctor team, I've started to develop a (better) frontend UI with AngularJS/Material Design/Firebase. For now, there is no call to the actual backend (WebSocket.java), I think it will be the next step (for PDF and slides features).

I let you discover what you can do with this UI :

• online version => http://editadoc-mgreau.rhcloud.com/#/home
• a 3 mn Video Demo of what you can do with this tools on a mobile (Nexus5) => https://www.youtube.com/watch?v=Iwr-S7TfvHg

I'd love to know what you think about it. I will post a message on the discussion list on Monday with the links.

Thanks. Maxime

— Reply to this email directly or view it on GitHub https://github.com/mgreau/when-websocket-met-asciidoctor/issues/24#issuecomment-66879918 .

Dan Allen | http://google.com/profiles/dan.j.allen

[mojavelinux]

On Sun, Dec 14, 2014 at 4:33 PM, Maxime Gréau notifications@github.com wrote:

I don't think (maybe I'm wrong) that we need a save button, or maybe when we know that the "offline mode" will last for long.

Getting away from the need for a save button is the way forward, esp on mobile. We can use versions to allow them to go backwards. We shouldn't make them do work to go forwards.

I will push it to github but I don't know if the best solution is to used this repo or to create a new repository and organized it like this :

• frontend (Angular / Material Design / Firebase (websocket backend with datas) / asciidoctor.js)
• backend (Java/WebSocket Backend / asciidoctorj / asciidoctorj-pdf / asciidoctorj-epub3)
• mobile (ionic framework / Firebase)
• doc (the asciidoc documentation for this editor)

Maybe @mojavelinux https://github.com/mojavelinux has an idea about it.

Getting the code on GitHub is the most important thing to encourage collaboration...no matter where it ends up. Since we are thinking about new names, I would just make a new repository and push it there. It's easy to change repository names on GitHub and preserve links, so just pick something like "edit-adoc" and go for it.

I'll spread the word once the code is online.

Cheers!

-Dan

Dan Allen | http://google.com/profiles/dan.j.allen

[jnorthr]

yes! yes! i really like this structure so i can work on doc.s without interferring with any other code developments. once we have mutual/group access to a single document or folder (hopefully within this structure above) then someone (like me) can start the outline for a tutorial or website - written in asciidoctor natch ;-D

then we can produce slides, docbooks, pdf's or lowly html pages - Ha! i'm lovin' this already !!

On 15 December 2014 at 10:10, Dan Allen notifications@github.com wrote:

On Sun, Dec 14, 2014 at 4:33 PM, Maxime Gréau notifications@github.com wrote:

I don't think (maybe I'm wrong) that we need a save button, or maybe when we know that the "offline mode" will last for long.

Getting away from the need for a save button is the way forward, esp on mobile. We can use versions to allow them to go backwards. We shouldn't make them do work to go forwards.

I will push it to github but I don't know if the best solution is to used this repo or to create a new repository and organized it like this :

• frontend (Angular / Material Design / Firebase (websocket backend with datas) / asciidoctor.js)
• backend (Java/WebSocket Backend / asciidoctorj / asciidoctorj-pdf / asciidoctorj-epub3)
• mobile (ionic framework / Firebase)
• doc (the asciidoc documentation for this editor)

Maybe @mojavelinux https://github.com/mojavelinux has an idea about it.

Getting the code on GitHub is the most important thing to encourage collaboration...no matter where it ends up. Since we are thinking about new names, I would just make a new repository and push it there. It's easy to change repository names on GitHub and preserve links, so just pick something like "edit-adoc" and go for it.

I'll spread the word once the code is online.

Cheers!

-Dan

Dan Allen | http://google.com/profiles/dan.j.allen

— Reply to this email directly or view it on GitHub https://github.com/mgreau/when-websocket-met-asciidoctor/issues/24#issuecomment-66966288 .

[mgreau]

Thanks Dan. Ok I'll push the code on a new github repo in the next few days and let you know when it's ok.

[jnorthr]

Hurrah !!!

On 15 December 2014 at 23:25, Maxime Gréau notifications@github.com wrote:

Thanks Dan. Ok I'll push the code on a new github repo in the next few days and let you know when it's ok.

— Reply to this email directly or view it on GitHub https://github.com/mgreau/when-websocket-met-asciidoctor/issues/24#issuecomment-67078062 .

[jnorthr]

bonsoir maxime - will be pleased when you get a repo on github - then i can help you more.

Here is a wonderful tool from the firebase guys. It's a collaborative editor like yours and i think they may be using angularfire.js to do it. see : http://www.firepad.io/#1

it may give you more ideas. also i found this: https://kobra.io/#/ which looks cool too !

thx jim

On 15 December 2014 at 00:33, Maxime Gréau notifications@github.com wrote:

Hi Jim and thanks :)

I'm guessing that there must be a SAVE button somewhere to keep recent changes safe

For now, each time you're updating your asciidoc, your datas are automatically saved to the backend (thanks to Firebase). As you can see on the video, even if there are troubles with your internet connection and you are still writing, it's not a problem, when you come back online all the work that you did during this "offline mode" is automatically synchronized and saved again (thanks again to Firebase) So I don't think (maybe I'm wrong) that we need a save button, or maybe when we know that the "offline mode" will last for long.

I cannot find that yet. Also cannot see how to share a document with you/someone else using the github approach.

Yes, I'm working on it, I'll add this feature next week. I'll do it as simple as possible in the first time. I think that we need to define the workflow that we want to create between users when they work on the same project (concurrent access, one version by user...). Technically, there should not be any problem whatever the solution we choose, especially if we use Firebase.

think i may need to git clone your code so i can see how to make the dropbox idea fit in.

Yeah, the dropbox integration will be cool too. For now, the code is on Google Drive, I will push it to github but I don't know if the best solution is to used this repo or to create a new repository and organized it like this :

• frontend (Angular / Material Design / Firebase (websocket backend with datas) / asciidoctor.js)
• backend (Java/WebSocket Backend / asciidoctorj / asciidoctorj-pdf / asciidoctorj-epub3)
• mobile (ionic framework / Firebase)
• doc (the asciidoc documentation for this editor)

Maybe @mojavelinux https://github.com/mojavelinux has an idea about it.

— Reply to this email directly or view it on GitHub https://github.com/mgreau/when-websocket-met-asciidoctor/issues/24#issuecomment-66935615 .

[mgreau]

hi,

will be pleased when you get a repo on github - then i can help you more.

Sure, I'm working on it, I'll have something to share on Thursday night.

Here is a wonderful tool from the firebase guys. It's a collaborative editor like yours and i think they may be using angularfire.js to do it. see : http://www.firepad.io/#1

yes I knew it, but I think that we address others use cases (no code editing, no toolbar...)

[mojavelinux]

Based on feedback I've received about AsciiDoc tooling, and tooling for documentation in general, I can tell you that collaborative/simultaneous editing would be one of the killer features that would get people to adopt the tool. Right now, people are still using Google Docs a lot, not because they like editing a Word document, but because they like to work on the document together.

I was also thinking that comments in the margins may be an important feature to consider as well. We could either do it by:

a) attaching posts to line numbers in a database (I'm assuming Firebase will fit here) or b) using comment blocks or lines in the AsciiDoc code

I'm leaning more towards (a) since (b) will likely clutter the AsciiDoc file. We could have a shadow AsciiDoc file to hold the comments or, better yet, allow the comments to be exported to an AsciiDoc file. Of course, the comments can be written in AsciiDoc :)

[jnorthr]

yes, collaborative tools would be wonderful. The firebase guys did one sample here: http://www.firepad.io/ which seems cool.

Comments about the doc are useful when not part of the main flow of text. If line numbers had a different color to indicate attached comments, then hovering a mouse cursor over the editor tool's line number could open a tool-tip containing the additional comments would NOT interrupt the flow of text. Of course you'd need to be able to edit the tool-tip somehow so i'd vote for an 'asciidoc-tooltip' feature - FWIW

am doing some tool screenshots now so when Maxime uploads to github, they'll become part of a HOW-TO-USE doc. [?]

On 18 December 2014 at 09:21, Dan Allen notifications@github.com wrote:

Based on feedback I've received about AsciiDoc tooling, and tooling for documentation in general, I can tell you that collaborative/simultaneous editing would be one of the killer features that would get people to adopt the tool. Right now, people are still using Google Docs a lot, not because they like editing a Word document, but because they like to work on the document together.

I was also thinking that comments in the margins may be an important feature to consider as well. We could either do it by:

a) attaching posts to line numbers in a database (I'm assuming Firebase will fit here) or b) using comment blocks or lines in the AsciiDoc code

I'm leaning more towards (a) since (b) will likely clutter the AsciiDoc file. We could have a shadow AsciiDoc file to hold the comments or, better yet, allow the comments to be exported to an AsciiDoc file. Of course, the comments can be written in AsciiDoc :)

— Reply to this email directly or view it on GitHub https://github.com/mgreau/when-websocket-met-asciidoctor/issues/24#issuecomment-67454693 .

[mgreau]

...collaborative/simultaneous editing would be one of the killer features

Yes we need to work on it soon and as @jnorthr said, the Firepad library will help us to do that. I've already started to look at how we can integrated this lib.