Category Theory
Zulip Server
Archive

You're reading the public-facing archive of the Category Theory Zulip server.
To join the server you need an invite. Anybody can get an invite by contacting Matteo Capucci at name dot surname at gmail dot com.
For all things related to this archive refer to the same person.


Stream: community: general

Topic: quiver: a modern commutative diagram editor


view this post on Zulip Nathanael Arkor (Nov 25 2020 at 16:20):

Hi everyone,
I've been working on a new editor for commutative and pasting diagrams. It's called quiver and you can find it here: https://q.uiver.app/
image.png

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 16:21):

I want to make typesetting commutative diagrams as easy as drawing them by hand: once you've created a diagram, you can export to LaTeX or take a screenshot to share (on Zulip, for instance). I've spent a lot of time making the interface intuitive and quick to use, so hopefully you should be able to pick it up quickly — but if you have any questions, let me know. I'm also very happy to receive feedback, feature requests, bug reports, etc.

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 16:21):

Finally, there's a blog post that shows off some of the features (including higher dimensional cells, flexible grid, macro support, and more). The editor is open source on GitHub.

view this post on Zulip Jules Hedges (Nov 25 2020 at 16:28):

By the way: The link to the app from the blog post 404s (but the one you posted here works)

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 16:32):

Thanks, it should be fixed imminently!

view this post on Zulip Eduardo Ochs (Nov 25 2020 at 16:36):

Do you also accept requests like "can you help me to port your implementation of XXX to this other program for diagrams?" I am the author of this - http://angg.twu.net/dednat6.html - and I am not fluent in Tikz at all, and because of that the Tikz backend of dednat6 only supports a few kinds of arrows and modifiers at the moment... I think that with a little bit of help I can make it output Tikz code similar to yours...

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 16:42):

I'd be happy to chat privately about that with you. Let me note also that the editor is open source (you can see the code for exporting to tikz-cd here).

view this post on Zulip Matteo Capucci (he/him) (Nov 25 2020 at 16:46):

Man that app is really awesome. Thanks a lot for creating it!

view this post on Zulip Jules Hedges (Nov 25 2020 at 16:48):

Out of curiosity, how long have you been working on this? How long does it take to make something this shiny?

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 16:54):

I started working on it at the start of December 2018. The basic functionality has been there for a long time, but certain features (e.g. curved arrows) took much more time and I wanted to wait till they were completed before I advertised it.

view this post on Zulip Jason Erbele (Nov 25 2020 at 17:18):

Is there a recommended browser for quiver?
In Safari I get a blank page, aside from the quiver logo linking to GitHub. Seems to run OK in Firefox... until I try clicking on the Export to LaTeX button. No sign of any LaTeX code, and adding new objects/arrows seems to be frozen. I can get the shareable link and continue working from there, though.

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 17:22):

@Jason Erbele: thanks, those bugs slipped through at the last moment. It should work in all three of those browsers. I'll work on a fix now.

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 17:28):

It should be working in both Safari and Firefox now (you may need to empty your cache). Thank you for catching it (that was my nightmare :sweat_smile:)!

view this post on Zulip Morgan Rogers (he/him) (Nov 25 2020 at 17:52):

That was a very quick fix, no wonder you got this cool app working in less than two years :grinning_face_with_smiling_eyes:

view this post on Zulip Jason Erbele (Nov 25 2020 at 18:26):

Works perfectly in both Safari and Firefox now. :tada:

view this post on Zulip Shea Levy (Nov 25 2020 at 18:29):

Woah, this looks awesome! @Nathanael Arkor haven't looked through the details yet, maybe this is there, but is there a way to export the diagrams as structured data that could be consumed by some other program besides for rendering? E.g. could be cool to use this to generate proofs

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 18:31):

There isn't currently, but the editor uses a custom data-structure internally, and it would be easy to either expose that, or add another export format.

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 18:32):

I think it would be very cool to facilitate interactive theorem proving or similar :)

view this post on Zulip Ralph Sarkis (Nov 25 2020 at 19:10):

Amazing website Nathanael!

I will definitely use quiver over my previously preferred editor starting today. :grinning: I'd love to be able to parse older diagrams I have drawn in tikzcd to make small adjustments on quiver. I have posted this issue in case you prefer this way to make feature request.

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 19:13):

Thanks! I agree that would be nice to support too. I'd like to see what the most popular features that are missing from quiver are, so I can figure out how to prioritise the next steps, so that's helpful!

view this post on Zulip Fabrizio Genovese (Nov 25 2020 at 19:58):

This is really nice and polished. Kudos!

view this post on Zulip Ivan Di Liberti (Nov 25 2020 at 20:26):

This is so brilliant that I am speechless. Thanks, Nathaniel.

view this post on Zulip Henry Story (Nov 25 2020 at 21:30):

Should it be called Globulars, as it has arrows between arrows ;-)

view this post on Zulip Nathanael Arkor (Nov 25 2020 at 21:47):

That could be a tad confusing, as there's already a web-based higher-dimensional string diagram editor called Globular :)

view this post on Zulip Notification Bot (Nov 30 2020 at 10:47):

This topic was moved by Matteo Capucci to #practice: software > quiver: a modern commutative diagram editor

view this post on Zulip Notification Bot (Nov 30 2020 at 13:49):

This topic was moved here from #practice: software > quiver: a modern commutative diagram editor by Matteo Capucci

view this post on Zulip Marko A. Rodriguez (Nov 30 2020 at 19:55):

Very nice application. I've been using https://tikzcd.yichuanshen.de/ for a year or so now. Features I like about tikzcd are:

  1. The diagram code is base64 encoded in the URL. Thus, your "file" is a URL. (I see you do the same -- great)

  2. No extra required LaTeX packages beyond tikzcd.

I wish quiver/tikzcd supported SVG exporting. What I have to do is take the LaTeX code snippet, cut and paste it into LaTeXiT (https://www.chachatelier.fr/latexit/), then render to SVG and save. Be nice if I could get LaTeXiT out of the workflow via an [export] button in quiver.

In conclusion, congrats on creating something good.

Screen-Shot-2020-11-30-at-12.51.49-PM.png

view this post on Zulip Nathanael Arkor (Nov 30 2020 at 20:18):

quiver.sty currently contains the packages that quiver diagrams require to render in LaTeX (e.g. tikz-cd and some tikz libraries), as well as a TikZ style for fixed-height curves, though it will soon also contain some extra arrowhead styles for improving the appearance of some arrowheads in combination with 2-cells.

view this post on Zulip Nathanael Arkor (Nov 30 2020 at 20:19):

Previously, it would export entirely self-contained diagrams, but this meant that each diagram had to be a lot larger on average, and there was some duplication. This way the individual diagrams can be much smaller. Personally, I don't find including a single .sty file to be much of an inconvenience.

view this post on Zulip Nathanael Arkor (Nov 30 2020 at 20:20):

The reason SVG export is not currently supported is because KaTeX, the LaTeX renderer used by quiver (and, incidentally, by Zulip), does not support SVG export. There is no problem, technically speaking, exporting the diagrams without the labels as SVG. KaTeX are working on supporting SVG export eventually, but I do not think it is a high priority for them.

view this post on Zulip Nathanael Arkor (Nov 30 2020 at 20:21):

If someone fancies hacking on KaTeX to speed up the process… :smile:

view this post on Zulip Nathanael Arkor (Nov 30 2020 at 20:26):

Also, regarding 2, the same is true of quiver: you just need the quiver LaTeX package and nothing else :)

view this post on Zulip Matteo Capucci (he/him) (Mar 18 2021 at 08:59):

@Nathanael Arkor is there a way to draw an == arrow?

view this post on Zulip Jason Erbele (Mar 18 2021 at 10:44):

It's doable. Set the arrow level to 2, and make the arrowheads empty on both sides.

view this post on Zulip Matteo Capucci (he/him) (Mar 18 2021 at 11:14):

ah! great!

view this post on Zulip Ralph Sarkis (Apr 12 2021 at 19:38):

I am writing here and not in a Github issue because it is not really a feature request (I don't see myself using it in the near future), more an idea that still needs some mulling over but that could probably be nicely implemented within quiver. I have found most written diagram chasing proofs to be a big hassle to read because a single big diagram is drawn and you must visualize which parts are drawn at each step of the proof. My idea to solve this would be to have a diagram for each step and indicators in the text to see which diagrams the reader should look at. Obviously, this demands more work from the writer because they have to edit a diagram for each step. Thus, I was thinking that within quiver, there could be a way to put every part of the diagram (objects and arrows) into groups and then quiver generates a diagram for each group displaying only the parts within that group. This way, one could draw the whole diagram on quiver, select the parts of the diagram that should be displayed at step 1,2,etc. and quiver generates a diagram for step 1,2,etc. automatically.

A better way (imo) to display this would be to have a slideshow instead of many diagrams and inside the text, there are indicators to tell you when to move to the next step. This would be very hard to implement on a pdf I guess, but that could be done as an extension of the embedding capabilities quiver already has in webpages.

view this post on Zulip Jules Hedges (Apr 12 2021 at 20:30):

Once you start thinking there's an endless number of fun ideas for improving presentation, where one of the big barriers is the limitations of the pdf format itself. Another possibility is to have the diagram all in one go, but mousing over each cell of the diagram reveals a section of popup text explaining why it commutes, with links to the needed assumptions

view this post on Zulip Jules Hedges (Apr 12 2021 at 20:31):

Animating a diagram to be revealed parts at a time can be done with TikZ + beamer, although it would be a bunch of effort

view this post on Zulip John Baez (Apr 12 2021 at 20:34):

It's really important that diagrams show up a bit at a time as one is explaining them. There's a nice way to do this called a blackboard.

view this post on Zulip John Baez (Apr 12 2021 at 20:35):

Getting high-tech tools to work almost as smoothly as talking while writing on a blackboard is a big challenge, but worthwhile because of course the high-tech route has certain advantages.

view this post on Zulip Conor McBride (Apr 12 2021 at 20:48):

I've been doing a bit of thinking about how to expose the quantifier alternation in explaining what proposition is represented by a diagram. I.e., what's the game? My rule of thumb is to label phases starting from 0, with even phases being demonic and odd phases being angelic. The key insight is that you need only bother labelling a thing which arrives strictly later in the dialogue than its boundary.

view this post on Zulip Mike Shulman (Apr 13 2021 at 00:07):

John Baez said:

Getting high-tech tools to work almost as smoothly as talking while writing on a blackboard is a big challenge, but worthwhile because of course the high-tech route has certain advantages.

I've found that a wacom tablet is just about as smooth as a blackboard for me.

view this post on Zulip John Baez (Apr 13 2021 at 00:07):

Yeah, you're good at that. My tablet usage still sucks.

view this post on Zulip John Baez (Apr 13 2021 at 00:08):

I just can't write smoothly as I can on a board.

view this post on Zulip Mike Shulman (Apr 13 2021 at 00:09):

Are you using a tablet that's also a screen, so you can see what you're writing directly under your pen? I wouldn't give that up for the world, although I know people who claim to be fully satisfied with the kind of tablet where you have to write on a black plastic board and only see what you're writing on a separate screen.

view this post on Zulip John Baez (Apr 13 2021 at 00:10):

No, I'm not using that - maybe that's the problem, writing while looking somewhere else.

view this post on Zulip Mike Shulman (Apr 13 2021 at 02:16):

Jules Hedges said:

Animating a diagram to be revealed parts at a time can be done with TikZ + beamer, although it would be a bunch of effort

I've done it, and I don't think it's that bad. It could be even easier with built-in quiver support.

view this post on Zulip Eduardo Ochs (Apr 13 2021 at 02:28):

I've tried to use "animated" (in the Beamer sense) diagrams and I didn't like them much. Here is one of my favorite low-tech solutions - I guess that it is similar to what @Conor McBride uses. Here is how Freyd states that a category has all equalizers:
freyd1.png
and here is how to write that as a single diagram:
freyd2.png

view this post on Zulip Jason Erbele (Apr 13 2021 at 14:15):

Selecting a bunch of things to duplicate would make it easier to make piece-by-piece diagrams in the style of Freyd. I haven't played around enough with quiver to find that option.

view this post on Zulip Fawzi Hreiki (Apr 13 2021 at 14:35):

Unfortunately, I don't think you can copy-paste in quiver

view this post on Zulip Nathanael Arkor (Apr 13 2021 at 14:46):

I think perhaps a more intuitive UI would be having layers for the commutative diagram, equipped with an order. That way, you wouldn't have to update each duplicated component each time you wanted to edit something. Then quiver could export the diagrams with the right Beamer commands to reveal the diagram in the correct order.

view this post on Zulip Nathanael Arkor (Apr 13 2021 at 14:46):

(Having copy-and-paste would be a useful feature independently.)

view this post on Zulip Mike Shulman (Apr 13 2021 at 17:24):

Although sometimes one also wants to remove something from the diagram in a later slide.

view this post on Zulip Jason Erbele (Apr 13 2021 at 18:28):

For removing elements from a diagram in a later slide, I think an intuitive UI would allow editing frame by frame, where each existing frame is independent of the others (or can be edited independently of the others, at least), but adding a new frame would include everything from either the last frame or the currently selected frame (and would either insert at the end or immediately after the current frame – ideally frames could be shuffled, too).

view this post on Zulip Jason Erbele (Apr 13 2021 at 18:37):

In my fantasy (I have no idea how much it would complicate the backend...), re-inserting a deleted element in a subsequent frame would allow that element to still be updated across all frames where it appears.

view this post on Zulip Nathanael Arkor (Apr 14 2021 at 10:28):

Yes, per-frame visibility would likely be the best way to go.

view this post on Zulip Alexander Gietelink Oldenziel (Jun 14 2021 at 21:06):

Conor McBride said:

I've been doing a bit of thinking about how to expose the quantifier alternation in explaining what proposition is represented by a diagram. I.e., what's the game? My rule of thumb is to label phases starting from 0, with even phases being demonic and odd phases being angelic. The key insight is that you need only bother labelling a thing which arrives strictly later in the dialogue than its boundary.

I'm missing a bit of context but demonic/angelic sounds to me like positive/negative connectives.
If we think of a proposition as a dialogue or debate then positive means the burden of proof is on the proponent, while if it is negative the burden of proof lies on the opponent. Does this make any sense?

view this post on Zulip Eigil Rischel (Jun 22 2021 at 09:18):

Yes, I think this is roughly what is meant by demonic/angelic. So when you're explaining a statement like f,gh:\forall f,g \exists h : \dots, the choice of f,gf,g is "demonic", because it's made by the opponent, while the choice of hh is angelic, because it's made by the proponent.

view this post on Zulip Jules Hedges (Jun 22 2021 at 10:27):

Yeah, the idea is that a formula is true iff the Player wins against the Opponent, if Player is an angel who magically choses the best strategy to make the formula true, and Opponent is a demo who magically choses the best strategy to make the formula false. Which is a slightly more memorably way of thinking about "there exists a P-strategy such that for all O-strategies..."

view this post on Zulip Kale Evans (Aug 06 2021 at 18:02):

@Nathanael Arkor The tool is super intuitive. It was immediately obvious how to use it. Great stuff.
Does the save feature work yet? When I attempt to save a diagram, it appears nothing happens. And I didn't have to sign in to use the tool

view this post on Zulip Nathanael Arkor (Aug 06 2021 at 18:03):

The save button updates the URL to be a permanent link to the current diagram. So you can copy and paste that URL somewhere else to have it saved.

view this post on Zulip Tom Hirschowitz (Feb 18 2022 at 15:10):

I've recently started to use quiver quite intensively, not only for typesetting diagrams, but for making them commute, i.e., for actually doing proofs. I find it very efficient, because it's much easier to get back in time and try other branches, etc, than on paper.

So huge thanks to @Nathanael Arkor for this great tool!

However, my library of diagrams is starting to grow huge and messy.
Has anyone else run into this problem? How did you solve it?

Similar question: I don't understand enough of quiver's internals to manipulate the diagrams I've saved. So, for instance, how could I version-control them as I do with latex files?

(Maybe I should mention that I often work offline, so cloned the source from github, and normally launch firefox index.html for each new diagram.)

view this post on Zulip Nathanael Arkor (Feb 23 2022 at 17:56):

I don't know whether this really answers your question, but I generally include each diagram inline in the LaTeX file (rather than as separate files). It's rare that I need to reuse the same diagram exactly, so this seems to make the most sense to avoid a proliferation of files. The diagrams themselves are then version-controlled just like the rest of the LaTeX document.

view this post on Zulip Tom Hirschowitz (Feb 28 2022 at 16:01):

Thanks for your answer, @Nathanael Arkor! Your strategy makes sense for someone like you, who often gets things right on a first try. But I always need to get back and edit old diagrams. So for the moment I:

But this is quite error-prone (I don't get only diagrams wrong). And also, the url is only valid on one computer.

E.g., how hard would it be to parse tikzcd code produced by quiver itself?

view this post on Zulip Nathanael Arkor (Feb 28 2022 at 16:07):

If you have created a diagram in quiver, you can always modify it later if you keep the URL. The URL will be of the form: PATH_TO_QUIVER?q=CODE. If you're working locally, then PATH_TO_QUIVER will be something like C:/Applications/quiver/index.html. If you move to a different computer (where quiver is located at a different path), you can change the PATH_TO_QUIVER part without changing the CODE part and modify your diagram there.

view this post on Zulip Nathanael Arkor (Feb 28 2022 at 16:08):

The CODE contains the entire diagram. It is not being saved locally: it is being saved in the CODE itself.

view this post on Zulip Nathanael Arkor (Feb 28 2022 at 16:09):

E.g., how hard would it be to parse tikzcd code produced by quiver itself?

Not so hard, but unfortunately I don't have the time to work on this at the moment :(

view this post on Zulip Nathanael Arkor (Feb 28 2022 at 16:10):

Though it's less important if you're only editing diagrams quiver created.

view this post on Zulip Tom Hirschowitz (Mar 01 2022 at 07:57):

Oh, nice, that's a start. Thanks!

view this post on Zulip Mateo Carmona (Mar 15 2022 at 21:46):

Many thanks for this incredible resource.

I would like to know if it is possible to draw an arrow from a \bullet to itself. Something like a loop (sorry if this is evident).

view this post on Zulip Nathanael Arkor (Mar 16 2022 at 12:10):

Unfortunately, it is not yet possible to draw loops. There has been some progress on the feature, but I've been too busy to work on it recently.

view this post on Zulip Mateo Carmona (Mar 16 2022 at 14:27):

Thanks, I understand

view this post on Zulip Nathanael Arkor (Apr 13 2024 at 13:35):

I haven't previously been mentioning the updates to quiver in this thread, since they have mostly been smaller quality-of-life improvements. However, in the latest update, quiver now supports looped arrows (e.g. endomorphisms), which has been the most requested feature since the initial release. So, if the lack of support for loops had been holding you back from trying quiver before, now might be a good time to try it out :)
https://q.uiver.app/
loop.mp4

view this post on Zulip Nathaniel Virgo (Aug 16 2024 at 06:01):

Is there a guide to using the keyboard shortcuts for Quiver? I feel like there's an intended workflow but I haven't been able to figure it out, e.g. how to use the tab key and how to create nodes and arrows with labels on both without using the mouse.

view this post on Zulip Nathanael Arkor (Aug 16 2024 at 22:42):

I should write a tutorial on navigating with the keyboard in quiver. I'm away at the moment, but once I get back, I'll try to put one together.

view this post on Zulip Matteo Capucci (he/him) (Aug 22 2024 at 07:25):

'show hints' has been quite instructive for me

view this post on Zulip Matteo Capucci (he/him) (Aug 22 2024 at 07:26):

though I realized Italian keyboard layout, where ; is shift+,, invalidates most of the keybindings

view this post on Zulip Martin Brandenburg (Feb 19 2025 at 16:02):

Hi @Nathanael Arkor

In this message, you asked for feedback on Quiver. I'd be happy to share my thoughts here. This will be a rather detailed message, focusing primarily on the user interface and accessibility aspects of Quiver.

A Quick Disclaimer

Everything I mention here is, of course, just my personal perspective. If you disagree with any point, that's absolutely fine! I'm also evaluating Quiver as if I were a first-time user, to highlight areas where new users might struggle.

Feedback

1) There's nothing in the UI that clearly explains how to create nodes and arrows, which is the core functionality. The top menu doesn't include these options either.

2) The top menu is the first thing a user sees, but it doesn't provide the most essential information for getting started. Many of its features might not be needed when creating an initial diagram.

3) The keyboard shortcuts listed in the top menu may not be relevant for new users. Perhaps they could be moved to a separate menu for more advanced users.

4) The font size in the top menu is quite small, making readability difficult.

5) The "Show Hints" feature in the top menu isn't self-explanatory. It appears to display keyboard shortcuts, but it's unclear whether they can be used in that context.

6) As a new user, I don't immediately understand the purpose of "Show Queue." What is being queued, and why?

7) When clicking on a cell, the prompt says "Add vertex." However, this doesn't explain how to actually create the vertex. Since the user has already decided to create a vertex, a clearer prompt like "Click again to create a vertex" might be more helpful.

Suggestion: Consider allowing vertex creation with a single click.

8) When a vertex is created, an input field appears at the bottom, but it lacks a visible label. As a new user, I didn't immediately realize that this field allows editing the LaTeX content for the vertex. This could make the feature less accessible.

9) The same issue applies to the color input field. It lacks a visible label and, when not in focus, has a black font on a black background, making it nearly invisible.

10) Since a vertex is created with a double-click, it would be intuitive if another double-click removed it. However, this doesn't happen. Instead, removal requires pressing the "Backspace" key or using the "Delete" option in the top menu.

11) The UI doesn't provide clear guidance on how to create arrows. While it's not difficult to figure out, a brief guide for new users would improve usability.

12) The blue background used to indicate focus may not be sufficient for accessibility. Using the browser's default outline would improve visibility, making it clearer when, for instance, a label input field is active while creating an arrow.

13) The process of creating an arrow might feel unintuitive to new users because two things open simultaneously: the label input field and the arrow menu on the right.

14) The arrow menu presents a large number of options, which can be overwhelming. Perhaps the most commonly used options could be displayed more prominently, with the others accessible via a "More" button.

15) The contrast in the arrow menu is quite low. Both the text and graphical elements are dark, making them difficult to distinguish against the black background. A white font color would improve accessibility.

16) The purpose of the buttons in the arrow menu (arranged in a grid) isn't immediately clear. It took me some time to understand that they control the arrow's tail, line, and tip. Adding visible labels would make this more intuitive.

17) The grid layout in the arrow menu can be misleading. It visually suggests that items in the same row are related, but they are actually independent. Perhaps restructuring the menu into three clearly labeled sections—"Arrow Tail," "Arrow Line," and "Arrow Tip"—would help. These sections could be collapsible by default, reducing visual clutter.

18) The term "Level" is not self-explanatory. Since it actually refers to the number of lines, renaming it to "Lines" might make more sense.

19) The "Position" slider in the arrow menu initially seemed to control arrow placement, but it actually adjusts the label's position. This is confusing because other sliders in that section modify the arrow itself. Clarifying its purpose would help.

20) Some buttons in the arrow menu use HTML tooltips (which appear on hover). These are not accessible and are not recommended by the WAI. Visible labels or ARIA labels would be a better alternative.

21) The outline for the color input field in the arrow menu has low contrast. With the default color, it appears as a black box on a black background, making it hard to locate.

22) Bottom menu: It's unclear what "Macros" is for and what kind of URL should be entered there. A brief explanation in the UI would be helpful.

23) There is no dark mode.

24) Quiver is not very usable on mobile devices, as everything appears too small.

I hope this feedback is helpful! Thanks for your work on Quiver. It's a great tool, and I appreciate the effort that has gone into it. Let me know if anything here needs clarification.

Best regards,
Martin

view this post on Zulip Mike Shulman (Feb 19 2025 at 16:28):

I've found quiver fairly intuitive to use, but I can agree that a lot of those would be (in my opinion, minor) improvements. A few counter-opinions though:

3) I like encouraging new users to use keyboard shortcuts; there's nothing intrinsically advanced about a keyboard shortcut, and any and all users may like to see them. I don't see any drawback to including them on the menu.

10) Disagree. I think it's pretty standard that clicks and double-clicks "open" or "run" things. Creating a vertex falls into that category for me; deleting one does not. I can't think of any other UI where a double-click deletes something. The key on the keyboard is labeled "Delete" for a reason.

17) I like the idea of labeling the columns, but I wouldn't want them to be collapsed by default; having to click extra things to expand to get to the options I want is annoying.

view this post on Zulip David Egolf (Feb 19 2025 at 18:11):

This reminds me - I've recently noticed that if one zooms in too far while typing a morphism label, the label gets cut off.

Here's what I get if I type an example morphism label when zoomed in:
zoomed in

And here's what I get when I type the morphism label when zoomed out:
zoomed out

view this post on Zulip David Egolf (Feb 19 2025 at 18:13):

It can be a bit tedious to keep changing the zoom level for purposes of labelling morphisms. (I like to work while fairly zoomed in, as it makes things a bit easier to see.)

view this post on Zulip Aaron David Fairbanks (Feb 19 2025 at 19:43):

Since you asked for feedback @Nathanael Arkor, the main features that feel missing for me personally are rectangle selections, copy+paste, and dragging selections with the mouse.

view this post on Zulip Nathanael Arkor (Feb 20 2025 at 20:44):

@David Egolf: this looks like a bug. Could you let me know what browser you are using, and provide a link to an example of a diagram where this happens? If you have a GitHub account, it would be more convenient to report it there.

view this post on Zulip Nathanael Arkor (Feb 20 2025 at 20:45):

@Aaron David Fairbanks: by "dragging selections with the mouse", do you mean moving objects/arrows around? If so, that's already possible by clicking and dragging in the region surrounding an object (you can move multiple objects at once if you hold shift to select multiple objects at once). Here's a GIF that shows the process.

view this post on Zulip Nathanael Arkor (Feb 20 2025 at 20:46):

Rectangular selections and copy and paste are features I intend to add, but need some thought regarding their exact behaviour.

view this post on Zulip David Egolf (Feb 20 2025 at 20:53):

Nathanael Arkor said:

David Egolf: this looks like a bug. Could you let me know what browser you are using, and provide a link to an example of a diagram where this happens? If you have a GitHub account, it would be more convenient to report it there.

I'll create an issue on GitHub. (Edit: I have now done so.)

view this post on Zulip Nathanael Arkor (Feb 20 2025 at 21:36):

@Martin Brandenburg: thank you very much for the detailed feedback! I'll give detailed responses below (I'm on the move, so apologies if they're a little terse).

1 & 11) When you first open quiver, you get a window explaining exactly how to create diagrams. (Though I think it would be helpful to have a button to open this again easily after dismissing it.)

2) This is the norm for software. When you first open Microsoft Word, for instance, you see all the options from the start. I think it is more confusing to have the interface change over time, as this leads to buttons not appearing in consistent locations, which is counter-intuitive.

3) I don't understand why you believe keyboard shortcuts would not be relevant/useful for new users? I don't view keyboard shortcuts in any program as being an advanced feature.

4) I do agree that it would be better to use a larger font size. At the moment, I'm not sure how to address this without relegating some of the options to a sub-menu; there is a trade-off here between discoverability and readability. However, perhaps it would be worth the trade-off to move some of the less common buttons. I'll have a think about it.

5 & 6) I agree. I've been meaning to write a tutorial to explain how these features work, as they are a little difficult to discover, but as ever there are always other things that end up taking priority. I will try to get to this soon.

7) I'll experiment with modifying the text.

Suggestion) This would conflict with the current behaviour to deselect objects/arrows.

8 & 9) Do you have a suggestion for what might help: perhaps adding something like "Label:"/"Colour:" to the left of each input?

10) I don't understand why you believe that the action to delete something should be the same as the action to create something? I don't think I can think of a single example in software where this is the case. Using backspace or delete for deletion is essentially universal.

12) Could you explain why you think this? Certainly there is user familiarity with the default browser effect to denote selection, but the blue highlight effect is used consistently in quiver and is very visible.

13) The input field is in the same place for arrows as for objects, and it's hard to ignore the side panel with arrow styles. Could you say how long it took you to understand how to modify arrow labels/styles?

14) Could you clarify what you mean by "overwhelming"? This seems a very strong reaction to having a panel with quite a few options. It doesn't take more than a few minutes to play around with the options to see what they do.

15 & 21) Probably it would be a good idea to increase the contrast, yes. I shall play around with this.

16) To clarify, could you say approximately how long it took you? Did you spot the selected arrow changing as you clicked the buttons, or not? It's helpful for me to understand how other people discover quiver. The design definitely assumes some experimentation on the side of the user, but my hope was that it was fairly clear what most of the options do by looking at how they affect the selected arrow.

17) I can see your point about the grid pattern. It would be possible to add collapsible sections, but I would not want to make anything collapsed by default, because I feel this harms discoverability. And once a user has learnt what the buttons do, I feel there is little reason to collapse the sections. I'll have a think about it.

18) I'll admit I wasn't sure the best word to use for this option. I don't think "Level" is ideal. I'm not convinced by "Lines" either, though, because arrows typically involve more lines than just the "body" lines, so I think this is misleading.

19) I do think it would help to separate the options affecting the label from the options affecting the arrow itself. This is one of the aspects I plan to revisit in the future (especially with multiple labels per arrow).

20) ARIA labels could be a good idea, though I would be very happy to hear from someone who uses a screen reader or relies on such accessibility features. I suspect quiver is not accessible at all for this use case, in which case ARIA labels are essentially irrelevant.

22) It would be helpful to add information about this to quiver itself, I agree. For now, it's explained on the GitHub page.

23) I would be happy to merge a pull request for dark mode if anyone wanted to submit one.

24) This is certainly true, but it is a lot of work to make a commutative diagram editor work on a small screen, and an extremely small proportion of users will wish to do so. I don't see that there are many use cases. I don't think this is worth the time investment, but I would be happy to merge a pull request if someone felt differently.

view this post on Zulip Aaron David Fairbanks (Feb 21 2025 at 07:51):

Nathanael Arkor said:

Aaron David Fairbanks: by "dragging selections with the mouse", do you mean moving objects/arrows around? If so, that's already possible by clicking and dragging in the region surrounding an object (you can move multiple objects at once if you hold shift to select multiple objects at once). Here's a GIF that shows the process.

That's great! I did not know this.

view this post on Zulip Matteo Capucci (he/him) (Feb 23 2025 at 20:25):

I feel the need to say that currently quiver is like 99% the way to perfect for me. Great stuff @Nathanael Arkor.