4 ms·

These ideas always seem to top HN. They are cute, but interactive diagram editors have been around a while and, unfortunately, are just faster to use and are mo

These ideas always seem to top HN. They are cute, but interactive diagram editors have been around a while and, unfortunately, are just faster to use and are more flexible. Maybe it'd make more sense to just have one of these tools implement export to ACSII?

wiremine 11y ago
> interactive diagram editors have been around a while and, unfortunately, are just faster to use and are more flexible Agreed. I think what is more helpful is taking a shorthand version of a diagram and generate it into a graph (flowchart.js is an example of this).
dr_zoidberg 11y ago
I think the appeal would be that, since it's text based, it's already supported by git/mercurial/svn/name-your-vcs. A binary format would need some sort of history/diff support inside it to work well with a specific plugin for s VCS. An XML-based format would integrate well with a VCS, but you lose the clarity of the ASCII based diagrams. It may seem "cute" or "toyish", but I woudl try to use it before giving an opinion. I certainly did that with markdown and ended up moving a lot of docs to that format, right in the repos with the code.
- davidjgraph 11y ago
  "since it's text based, it's already supported by git/mercurial/svn/name-your-vcs" But doesn't that still apply if you had a visual tool exporting to ASCII? It'd save you the difficulty of moving sections around in a text editor, but give you the visual diff.
  - vidarh 11y ago
    Now you then need to cut and paste back and forth from your documents in order to edit them.
    - davidjgraph 11y ago
      Not if you import that format as well, that's not impossible to implement.
      - vidarh 11y ago
        If you come up with a tool that will pick up on a diagram in a readable ascii format in the middle of a document, let me edit it, and then patch in the updated diagram without making any kind of changes to other portions of the file, then we'd be getting somewhere. Even then there'd be issues, as e.g. I might want to modify descriptions elsewhere in the file in between modifying the diagram. As a concrete example, I am doing that these days with a spec for a system I'm planning. I'm using a custom Markdown based processor with a filter that takes Graphviz/dot syntax inline, and while I edit the diagram, I'll also then often want to write something about what I've added to it. So if I was going to use an external program, the roundtrip from text editor -> diagram editor -> text editor would need to be very fast and smooth. Though to be really useful for me, it'd need to work for me via an ssh connection as well... It's really hard to beat plain text for some of these use-cases. At least without first getting more graphics capabilities back into our terminals.
  - kragen 11y ago
    No, "supported by git" means that if I edit the diagram and check it in, and you also edit the diagram and check it in, Git can usually merge the changes automatically if they don't conflict; and if they do conflict, it can give us a version of the file that contains both changes, with the conflict marked, and makes it pretty easy to produce a merged version. If your visual tool merely exports to ASCII, this won't work. If it stores its data in ASCII, it might. But it needs to be more than just "doesn't use control characters and non-7-bit characters" — it needs to have reasonably short lines that mostly don't reoccur and whose position, if meaningful at all, is meaningful only relative to the position of other nearby things, rather than by absolute line number or byte position or something.
- bphogan 11y ago
  This. I would love, as an author and teacher, to keep my flowcharts, diagrams, etc with my book code. Right now I'm using SVG for that, but it's kinda rotten.
  - davidjgraph 11y ago
    Is that same problem, i.e. you want to be able to diff your diagrams or do you want the actual data format embedded in your document. If it's the second, you can embed XML within SVG or a PNG. If you draw something simple in draw.io [0] (which I do co-author) and then "File->Export As" either "SVG with XML" or "PNG with XML" the diagram data is stored within the display format itself. This way you can just reload the SVG+XML or PNG+XML and carry on editing. But the PNG and SVG display as you'd normally expect. Does that solve your problem? [0] https://www.draw.io/?splash=0 https://www.draw.io/?splash=0
  - kragen 11y ago
    Yeah, I feel this pain too. MJD's Linogram might work. I've also tried writing the diagrams as Python to produce SVG, or in D3 (to produce SVG), which both work reasonably well but seem like a lot of work.
  - zwischenzug 11y ago
    I use draw.io, and export to xml.
  - smorrow 11y ago
    It should be easy to do flowcharts in pic(1). It's also more diff-friendly. GNU pic can target LaTeX directly, if that helps.
- mavroprovato 11y ago
  SVG/GraphML are text based too
  - rmc 11y ago
    SVG cannot be entered by humans in the same way this can
    - kragen 11y ago
      I don't agree. SVG is very human-editable indeed. It's easier than even PostScript or OpenGL.
    - mavroprovato 11y ago
      To each his own then I guess. Some may enjoy aligning pipe symbols and pluses, I don't.
      - vidarh 11y ago
        I don't either, but I enjoy cutting and pasting back and forth, or keeping diagrams in separate formats, or trying to write SVG manually even less.
- rmc 11y ago
  It is also supported in your text editor.
- eljimmy 11y ago
  Agreed. This could be very useful if leveraged into a Wiki-plugin.
- maaaats 11y ago
  Try removing one of the left boxes (not exactly easy in this format) and then view the git diff. Think about trying to fix a conflict with that!
  - dr_zoidberg 11y ago
    Indeed, side-by-side boxes editing/merging would be messy! But it still looks that something that could be integrated into a reasonably organized repository. Not the best of tools, but better than the alternative?
JoshTriplett 11y ago
> They are cute, but interactive diagram editors have been around a while and, unfortunately, are just faster to use and are more flexible. Personally, I build most of my diagrams in either graphviz or LaTeX/TikZ. Graphviz constructs certain types of diagrams very quickly, as long as you don't care deeply about precise placement and layout. And TikZ integrates perfectly with LaTeX documents, and makes complex diagrams and graphs more manageable and scriptable.
kitd 11y ago
I've had a need in the past to put small diagrams like this into source code comments. Having an ASCII form for them is really useful. I have used ditaa in the past but this one looks good too.
morsch 11y ago
I'd rather use a visual editor, but I've repeatedly turned to text-based diagram markup (mostly PlantUML) because I found the interactive tools to be painful to use. In most visual editors adding a new node takes lots of of mouse motions. In PlantUML it's pretty much just adding a line. Ideally I want a visual editor with an abstract understanding of what you can do in diagrams, a keyboard driven interface and automation of a good first approximation of what I want, giving me the ability to tweak the resulting layout. Drawing diagrams on a piece of paper or a whiteboard beats both approaches handily. Which is pretty sad.
deleted 11y ago
[deleted]
mraleph 11y ago
I wrote the original code (not this CoffeeScript port) so that I could create simple diagrams fast without resorting much to dragging stuff around with mouse. If you want to create a sequence of diagrams where each next one is just slightly different from the previous one then textual approach is simply superior to point-and-click style editing. Other parts of my motivation were outlined here[1]. Having this ASCII -> image converter also allows me to embed diagrams into blogposts as text without actually making images out of them. See [2] as an example of such embedding. [1] http://mrale.ph/blog/2012/11/25/shaky-diagramming.html http://mrale.ph/blog/2012/11/25/shaky-diagramming.html [2] http://mrale.ph/blog/2014/07/30/constructor-vs-objectcreate.html http://mrale.ph/blog/2014/07/30/constructor-vs-objectcreate....

wiremine 11y ago

> interactive diagram editors have been around a while and, unfortunately, are just faster to use and are more flexible Agreed. I think what is more helpful is taking a shorthand version of a diagram and generate it into a graph (flowchart.js is an example of this).

dr_zoidberg 11y ago

I think the appeal would be that, since it's text based, it's already supported by git/mercurial/svn/name-your-vcs. A binary format would need some sort of history/diff support inside it to work well with a specific plugin for s VCS. An XML-based format would integrate well with a VCS, but you lose the clarity of the ASCII based diagrams. It may seem "cute" or "toyish", but I woudl try to use it before giving an opinion. I certainly did that with markdown and ended up moving a lot of docs to that format, right in the repos with the code.

davidjgraph 11y ago
"since it's text based, it's already supported by git/mercurial/svn/name-your-vcs" But doesn't that still apply if you had a visual tool exporting to ASCII? It'd save you the difficulty of moving sections around in a text editor, but give you the visual diff.
- vidarh 11y ago
  Now you then need to cut and paste back and forth from your documents in order to edit them.
  - davidjgraph 11y ago
    Not if you import that format as well, that's not impossible to implement.
    - vidarh 11y ago
      If you come up with a tool that will pick up on a diagram in a readable ascii format in the middle of a document, let me edit it, and then patch in the updated diagram without making any kind of changes to other portions of the file, then we'd be getting somewhere. Even then there'd be issues, as e.g. I might want to modify descriptions elsewhere in the file in between modifying the diagram. As a concrete example, I am doing that these days with a spec for a system I'm planning. I'm using a custom Markdown based processor with a filter that takes Graphviz/dot syntax inline, and while I edit the diagram, I'll also then often want to write something about what I've added to it. So if I was going to use an external program, the roundtrip from text editor -> diagram editor -> text editor would need to be very fast and smooth. Though to be really useful for me, it'd need to work for me via an ssh connection as well... It's really hard to beat plain text for some of these use-cases. At least without first getting more graphics capabilities back into our terminals.
- kragen 11y ago
  No, "supported by git" means that if I edit the diagram and check it in, and you also edit the diagram and check it in, Git can usually merge the changes automatically if they don't conflict; and if they do conflict, it can give us a version of the file that contains both changes, with the conflict marked, and makes it pretty easy to produce a merged version. If your visual tool merely exports to ASCII, this won't work. If it stores its data in ASCII, it might. But it needs to be more than just "doesn't use control characters and non-7-bit characters" — it needs to have reasonably short lines that mostly don't reoccur and whose position, if meaningful at all, is meaningful only relative to the position of other nearby things, rather than by absolute line number or byte position or something.
bphogan 11y ago
This. I would love, as an author and teacher, to keep my flowcharts, diagrams, etc with my book code. Right now I'm using SVG for that, but it's kinda rotten.
- davidjgraph 11y ago
  Is that same problem, i.e. you want to be able to diff your diagrams or do you want the actual data format embedded in your document. If it's the second, you can embed XML within SVG or a PNG. If you draw something simple in draw.io [0] (which I do co-author) and then "File->Export As" either "SVG with XML" or "PNG with XML" the diagram data is stored within the display format itself. This way you can just reload the SVG+XML or PNG+XML and carry on editing. But the PNG and SVG display as you'd normally expect. Does that solve your problem? [0] https://www.draw.io/?splash=0 https://www.draw.io/?splash=0
- kragen 11y ago
  Yeah, I feel this pain too. MJD's Linogram might work. I've also tried writing the diagrams as Python to produce SVG, or in D3 (to produce SVG), which both work reasonably well but seem like a lot of work.
- zwischenzug 11y ago
  I use draw.io, and export to xml.
- smorrow 11y ago
  It should be easy to do flowcharts in pic(1). It's also more diff-friendly. GNU pic can target LaTeX directly, if that helps.
mavroprovato 11y ago
SVG/GraphML are text based too
- rmc 11y ago
  SVG cannot be entered by humans in the same way this can
  - kragen 11y ago
    I don't agree. SVG is very human-editable indeed. It's easier than even PostScript or OpenGL.
  - mavroprovato 11y ago
    To each his own then I guess. Some may enjoy aligning pipe symbols and pluses, I don't.
    - vidarh 11y ago
      I don't either, but I enjoy cutting and pasting back and forth, or keeping diagrams in separate formats, or trying to write SVG manually even less.
rmc 11y ago
It is also supported in your text editor.
eljimmy 11y ago
Agreed. This could be very useful if leveraged into a Wiki-plugin.
maaaats 11y ago
Try removing one of the left boxes (not exactly easy in this format) and then view the git diff. Think about trying to fix a conflict with that!
- dr_zoidberg 11y ago
  Indeed, side-by-side boxes editing/merging would be messy! But it still looks that something that could be integrated into a reasonably organized repository. Not the best of tools, but better than the alternative?

JoshTriplett 11y ago

> They are cute, but interactive diagram editors have been around a while and, unfortunately, are just faster to use and are more flexible. Personally, I build most of my diagrams in either graphviz or LaTeX/TikZ. Graphviz constructs certain types of diagrams very quickly, as long as you don't care deeply about precise placement and layout. And TikZ integrates perfectly with LaTeX documents, and makes complex diagrams and graphs more manageable and scriptable.

kitd 11y ago

I've had a need in the past to put small diagrams like this into source code comments. Having an ASCII form for them is really useful. I have used ditaa in the past but this one looks good too.

morsch 11y ago

I'd rather use a visual editor, but I've repeatedly turned to text-based diagram markup (mostly PlantUML) because I found the interactive tools to be painful to use. In most visual editors adding a new node takes lots of of mouse motions. In PlantUML it's pretty much just adding a line. Ideally I want a visual editor with an abstract understanding of what you can do in diagrams, a keyboard driven interface and automation of a good first approximation of what I want, giving me the ability to tweak the resulting layout. Drawing diagrams on a piece of paper or a whiteboard beats both approaches handily. Which is pretty sad.

deleted 11y ago

[deleted]

mraleph 11y ago

I wrote the original code (not this CoffeeScript port) so that I could create simple diagrams fast without resorting much to dragging stuff around with mouse. If you want to create a sequence of diagrams where each next one is just slightly different from the previous one then textual approach is simply superior to point-and-click style editing. Other parts of my motivation were outlined here[1]. Having this ASCII -> image converter also allows me to embed diagrams into blogposts as text without actually making images out of them. See [2] as an example of such embedding. [1] http://mrale.ph/blog/2012/11/25/shaky-diagramming.html http://mrale.ph/blog/2012/11/25/shaky-diagramming.html [2] http://mrale.ph/blog/2014/07/30/constructor-vs-objectcreate.html http://mrale.ph/blog/2014/07/30/constructor-vs-objectcreate....