Long-time user here. Laying out newsletters, flow charts, diagrams, and figlets. It has very few issues these days, and only a couple minor points of frustration in the UI. For my purposes, it's the best thing out there.
A couple of workflow tips for using Monodraw:
* Open a few docs in Monodraw at a time and leave them open for your different needs: text boxes, figlets, diagrams. Each with a few elements already waiting to be filled, cut & pasted, etc.
* For larger docs (e.g. newsletters) finish the writing in your text editor and bring it into Monodraw. Think Publisher or InDesign. Yeah, you can edit in here, but it's weird. Best for layout.
* Browse the sample file that opens by default when you load Monodraw. Good fodder in there.
* Snippets!
* Yes, it is just text but there is FILL to give order (front to back) of elements. This is really handy for making slides that expose a list one item at a time.
* Cut and Paste chunks in and out of your Monodraw file with your main document or take a clipped screen capture for dropping into a graphic or fancy format document (e.g. Illustrator). No need to export and paste.
While Monodraw seems to have business related features I feel the need to mention "Mœbius ANSI Art Editor"[0] a cross platform open source alternative.
Moebius is a new ANSI and ASCII Editor for MacOS, Windows, and Linux.
With a neat Moebius Server feature that allows collaboration by multiple users on the same canvas through a server instance.
This has like...none of the features of Monodraw? Drawings aren't objects - this is just a canvas. This is not an alternative to Monodraw - but an ASCII painting app.
Electron is a runtime environment that evolved out of a browser, not a browser. This app doesn't have any browser functionality I can see, like open arbitrary websites, but it does have its own system menus, icon, it's directly executable by the OS. By that logic no software written in an interpreted language can never be cross-platform, you'll always need a runtime environment.
Desktop files (on Linux & Windows) are just nothing than a text file with description/meta info and a link to local executable or any other sort of file* - that is NOT related in any way to executable at all.
> it's directly executable by the OS.
Because it is browser (Chromium) with a custom browser-extension by design.[0]
I learned about Monodraw from Thorsten Ball’s interpreter / compiler books. The book has really beautiful illustrations and ASCII drawings, when I asked the author they directed me to Monodraw
Ha! I was going to comment in here that I used Monodraw for the book and really fell in love with the tool.
What I did more recently is to use Monodraw to create diagrams of CFGs and put those next to the test cases (see [0] or [1]) which exercise those graphs - the power of ASCII, you can just copy the graphs into your code.
ASCIIFlow is a less full featured web app with similar functionality to Monodraw, for all the windows/linux/chromebook users wishing for an electron version
I was looking to see if this had been mentioned yet. As a Monodraw owner who recently has been forced to only use a Windows laptop for work I was pleasantly surprised a couple months ago by another article on hacker news that referenced this great web app. Just so happened in the comments here I also learned about Moebius which I also want to try out.
This is why I love the Mac. Even obscure apps have a beautiful interface and easy to use web site. I know this is incendiary, but I must say it: on Windows, this app's site would have seven giant, fake download buttons, the actual download would play an ad, and the app would look like something from a fever dream.
There was a windows compatible app posted here and I can't see ads or fakery. I do see the fever dream aspect, but you have to concede that we are talking about ANSI art here. Which is basically fever dream art in a lot of cases.
An implicit assumption in software seems to be that for it to stay relevant, it must be perpetually evolving. But there is something to be said for deciding a piece of software has reached it's intended potential and simply maintaining it.
Granted, it sounds like the author feels like there are more meaningful things to add or change, but that doesn't mean the software is any less relevant than it was 3 years back.
The post even mentions a Big Sur / Monterey visual refresh currently in development. As "maintenance mode" projects go, this looks like the best of the best.
Looks like a really great app! However, screen shots from older versions of Mac OS on a product page always make me a bit worried about the future of an app. Do you intend to update the UI and such to match Big Sur and the upcoming Monterey?
It's been on my list and we've made some progress but to be completely transparent, I've been extremely overloaded and it's been hard to set aside time for it.
So, I'll try to get to it eventually but no promises on timeline.
Remember, when embedding ASCII art in HTML, hide it from screenreaders and provide alt text. Otherwise it's an incomprehensible mess of seemingly random characters.
A simple approach is best. I don't have a screenreader on my current machine (as far as I know) so I can't verify actual behaviour right now, but according to MDN:
> ...most screenreaders will consider the element with role="img" set on it to be to be like a black box, and not access the individual elements inside it.
Neat! I'll make sure to do it this way. That makes me wonder, what else on the websites I (not a web dev) maintain might need special treatment for accessibility. Pity the Chrome dev tools don't seem to help with that.
Does it have layers like in photoshop? Or does the group functionality let you overlay and then move the group away without ruining the underlying drawing?
This allows you to write Markdown-style documents, including ASCII-art diagrams, but which render beautifully in any browser with JavaScript. Using Monodraw or ASCIIFlow as the front-end editor, you can drop most results in a Markdeep document. Bonus: good inline math typesetting plus loads of other awesome document features.
But I actually need more types of diagrams, so slowly, as one of many little side projects, I've been building a little library for all kinds of ascii diagram generation
This looks pretty cool, though unfortunately I'm not near my Mac so I can't really check it out. I'd be interested to know how its freehand pencil tool compares to JavE's (http://www.jave.de/). I always thought that was the coolest feature of JavE.
What's the purpose of being able to embed an image in the sheet? Is it intended to be an aid to `tracing' an image when creating ASCII art, or does it have some other purpose?
I’ve used images scattered around the art board for reference. I like to copy brandur’s diagrams a lot, so I’ll usually have a couple of his on my board to reference.
Ah, good ol' ambiguous-width box drawing characters. They are not ASCII and their width is not prescribed by the Unicode standard and mostly determined by domestic conventions. Stick to ASCII drawing for the maximal portability.
Long time Monodraw user here as well. While I still use it quite often for README.md docs, excalidraw has replaced most of the use cases I had, along with having a much nicer and upbeat feel (something I'm generally after when writing boring technical docs).
Anyway Monodraw is just awesome in its own way, and I really like the easy way you can draw stuff in it, ASCII is so restricting it simplifies design decisions for us art plebs quite a bit. I just wish there could be a way to export it as a xkcd / excalidraw style PNG after you've done drawing.
I get the hate that Electron gets for it's weight and overhead, but this is a perfect example of why Electron has value.
This app has no dependency on native OS for anything beyond writing data. It doesn't need to compile heavy code bases, it doesn't need fast GPU or other access. It could have very well been an electron app, and it would have the benefit of being widely available on many platforms.
I'd love to be able to use this app, but as a Linux and Windows user, I'm unable to. So I'll be searching for an alternative that runs on the platforms I have access to.
That said, no hate on the author for building the tool to their needs and desires. It's a fantastic looking app, and looks well executed. Wish I could use it.
The insistance on native feeling UI and shortcuts is something I only see from Mac users. I think the app would work perfectly well in Electron but would just attract the usual complaints from Mac users.
One potential conclusion: Mac users understand the productivity increase and the value of apps feeling native, since the Apple ecosystem is one of the primary places to get such a native experience today.
This shouldn't necessarily be interpreted as "Mac users are special flowers", but rather, "Mac users may have stronger opinions about this because they've experienced the benefits of native apps".
I've been around the block with operating systems, and was primarily a Linux user for many years. Later in my career, I started to appreciate the simplicity and consistency of the Apple ecosystem, and while I recognize that's not everyone's thing, it lets me focus on the job at hand and spend less time learning how to use new apps/tools. This is valuable.
That's a great conclusion. Sadly the way it's usually felt is through entitlement. I can't count the number of time where I've seen an electron/Flutter/anything app presented, and Mac users are once again asking for a native app while pretending to not understand why the app is cross platform in the first place.
If they're so attached to native apps, maybe they should build a website/community where people ready to pay more for native apps can say they want for example a native client for slack, discord, spotify, and then the companies can see if it's viable or not.
My problem is that these complaints are exactly like "the back button is broken", it doesn't bring anything new or interesting to talk about, people never propose to help a project or to pay money for new features, they just complain and never stop. This isn't good content for Hacker News in general.
I'd say that if you had to choose a desktop platform to build paid apps for Mac OS is the best choice. Mac users tend to spend (more) money on software.
Another take on it is that Mac decided to go a different path on a few different UI things in the past, and that has persisted to this day.
Look at how *nix, Windows, Sun, BSD, Chrome OS (which is basically a linux anyways) all use Ctrl, Meta (alt), and Shift for their hotkeys, compared to how Mac uses Hyper (cmd).
Also look at how Mac has one instance of an app's tool bar/menu that all windows share.
I'll agree that the consistent UI is a boon, but there's a large lack of discoverability imo, and some things that are just entirely lacking, like the ability to move windows around with hotkeys.
You've got the order reversed. Mac pretty much defined the modern WIMP UI and was the only real game in town for consumers & professionals from 1984 - 1990 when Windows 3 was released, and during this time an entire industry (DTP) was built atop Mac's strong UI foundations.
It's more accurate to say that in modern UIs the others decided to each go their own different paths and replicate part of what made the MacOS experience special, but they also tended to forget to include a lot of the little details that made it great, and have never had the same dedication to consistency.
Re: discoverability, there's an order to discovering advanced options in MacOS - hold Option and click on menus. You'll be surprised how far that gets you. The whole idea of MacOS and native apps is you learn how to use the system once, and you're rewarded from thereon out. Not all things are discoverable without these keys because not all things are relevant for everyday uses and can add clutter - its a design choice to make simple things easy and hard things possible. They're not always perfect but they're still the best game in town.
RE: moving windows with hotkeys, just get an app like Magnet, problem solved.
Because some of us are shut down with responses of "be happy you got this app at all" (Linux users) or somehow get ignored when we speak up (Windows users - though I guess Windows hw often having more cpu power and memory leads to less complaints?)
An Electron app always requires extra muscle memory. Every Electron app is different from the other, they all miss the UI consistency that makes the Mac so productive to use.
I'd be interested to hear as to why you couldn't achieve the functionality of this app in Electron.
I agree with you that it's almost impossible to get a native UI feel in electron, but that's not always the first priority.
If the end goal of the application is to present a custom interface for drawing on a monospace grid for ASCII art, I'm not sure I see the argument that a native UI is necessary over any cross-platform kit like QT or even an html based UI. I totally agree on shortcuts being a problem. Dealing with those cross-platform can be a headache when sufficient care is not being taken. Especially from an outsider to the platform.
As a long-time linux user, most of the interactions on OSX feel wrong to me, but I know it's me that's the problem. If I were to write shortcuts for the OSX platform, I'm sure I'd get most of them wrong. Conversely, if an OSX developer was writing shortcuts for a linux or windows platform, I'm sure they'd face the same issue. It really benefits to have a platform expert you can consult for testing.
I'm not trying to eschew the need and benefits of native apps here, I was trying to point out the fact that the large amount of hate for Electron (and similar web UI on desktop solutions) have their place.
Heck, this entire app could have been a web app. I'm sure a few out there exist to do very similar things.
There's dozens of ways to accomplish things in the wonderful field that is software development, and the whole "this tech is bad" cargo-cult is more a disservice than anything. There are pros and cons to every decision that goes into an application, and taking a stance against one method without considering the use cases and how it could benefit or hinder runs the risk of loosing out on promising tech or excluding people from using your project.
I've seen Monodraw a few times over the years, and I've lamented the fact that I haven't been able to use it, which is what drew me to make my original comment.
One example: native document-based Mac apps have file handling functionality in the window's titlebar (rename, move, tag, etc). It's very convenient. Electron apps don't.
Another: native Mac apps by default reopen where you left off. Open windows, open documents, etc. Electron doesn't get this functionality automatically; you could spend time recreating it, but it still would integrate with native settings.
Another small example: native Mac UI controls reflect the system-wide accent color the user's selected. With Electron, you'd have to either spend time rebuilding the functionality or omit it.
Mac users like Macs because Macs work like Macs. Electron apps ignore the benefits and features Mac apps usually get automatically and just revert to the lowest common denominator.
That's less of why the app couldn't be written in Electron and more of why Mac users wouldn't like an Electron app.
Perfectly valid reason why someone would want to write their app as a native app though, and I appreciate that.
Some of those are definitely things Electron gets wrong and should correct. Handling system-wide accent colors is exactly the kind of thing my UI kit (Electron in this argument) should be handling and not forcing everyone to re-invent.
I've never used or even heard of the titlebar file handling functionality and had to search that right now. This is exactly the kind of thing I've said about discoverability. I used OSX for three years daily, and I've been using it on and off as needed since around 2010. Some things that people love and use all the time are just not obvious to everyone.
It's totally possible to do this in Electron. I've used plenty of Electron apps that were simply ripped off MacOS and dumped on Linux (Kitematic, for example). The entire Mac-native UI works perfectly fine on Linux, the only issue I ran into involved some Mac-ified ini files.
Given the rapid development and maturity of virtualization, container, sandboxing, and emulation technology: to me it seems rather silly that it's not yet trivial to run macos and windows apps (and anything else one would want) transparently, side by side on the same machine. I'm not normally a microsoft fan, but their direction with WSL2/WSLg/WSA feels very interesting...
I like seeing devs embrace native frameworks. Electron apps just do UI so differently that its just a pain to use. For example dragging a file tab out of vs code doesnt create a new window like every other editor.
Just because it's not implemented yet doesn't mean it can't be implemented. Electron can do anything a native app can because it is a native app itself.
Anyway, you can do it without dragging which is actually even better. Just do Ctrl+K, O or on a Mac Cmd+K, O.
I think you underestimate a lot of the APIs for a platform and how they influence an app; Cocoa provides a lot for an application; for example, it can provide a lot of the structure for a document related app in terms of i.e undo/redo, window management, etc.
Get a Mac :) I would have not bought this app if it was not native. I love using it because the look and feel. I value this kind of beauty, call me a weirdo…
Lol. Had one for almost 3 years. Not interested in going back. I personally prefer my Linux laptop and home lab, with my Windows desktop for all things gaming and 3d CAD related.
I appreciate the vertical integration Apple has in all its products, but after feeling like I was fighting the system for almost 3 years, I was happy to no longer have to use it for my work machine.
To each there own though! I'm glad you enjoy it, and I'm glad to see Monodraw get the attention it deserves (it's genuinely a very cool app).
AppKit apps also don’t usually break that easily. It’s surprisingly simple to get an abandoned OS X 10.0-10.4 era Cocoa app compiling and running on modern macOS, I’ve done it a couple times just for kicks.
I somewhat understand the hate for electron but as a non-Mac user I'd much rather have access to this app - and I suspect the author would rather have me pay them for it. For such niche software it seems silly to build it so platform specific.
To get that kind of native feel in an electron app is either impossible or going to take a lot more work than just using native SDK's. There's a reason people hate on electron, because it's a bloated alternative that merely comes close to having a native feel.
A couple of workflow tips for using Monodraw:
* Open a few docs in Monodraw at a time and leave them open for your different needs: text boxes, figlets, diagrams. Each with a few elements already waiting to be filled, cut & pasted, etc.
* For larger docs (e.g. newsletters) finish the writing in your text editor and bring it into Monodraw. Think Publisher or InDesign. Yeah, you can edit in here, but it's weird. Best for layout.
* Browse the sample file that opens by default when you load Monodraw. Good fodder in there.
* Snippets!
* Yes, it is just text but there is FILL to give order (front to back) of elements. This is really handy for making slides that expose a list one item at a time.
* Cut and Paste chunks in and out of your Monodraw file with your main document or take a clipped screen capture for dropping into a graphic or fancy format document (e.g. Illustrator). No need to export and paste.