As with most UX matters, I think taking a second to formulate a couple personas might be beneficial here.
Persona 1: Taylor
- Age: 26
- Profession: Software engineer.
- Main goal: A place to record interesting thoughts to help explore curiosities and remember ideas for apps.
- Likes: Using things in the way they are intended to be used.
- Dislikes: Breaking our going outside of established standards.
- Confused by: Why anybody would want any WYSIWYG functionality in apps that aren’t built to be WYSIWYG from top to bottom.
- Quote: “Plaintext files are elegant because they’re strictly plaintext. If someone wants to do more than record and display plaintext, then they shouldn’t use a plaintext editor.”
Persona 2: Alex
- Age: 37
- Profession: Anthropology PhD candidate.
- Main goal: A better way of organizing his knowledge to help write research papers.
- Likes: Feeling like his tools are serving him instead of the other way around
- Dislikes: When software gets in the way – especially when he’s told that the obstacle is a feature instead of a bug.
- Confused by: Any code more complicated than the most basic parts of markdown formatting (italic, bold, headers, lists, and quotes).
- Quote: “When the code helps me think, show the code. When it just makes things more opaque, hide the code. I just want to get across the finish line easily and efficiently.”
These are incredibly basic personas, but I think they’re enough to let us begin reasoning about what different kinds of users might want. Instead of saying vague things like “users will want to do X” (which makes the user into an elastic entity that stretches and bends to fit any ideas whatsoever), forcing ourselves to instead ask “What would Terry/Alex want?” will keep us focused on making sure that the way we are imagining features actually serves the goals of the users.
Anyway, I imagine that Terry and Alex would want different things here. Terry would probably want Obsidian to implement Zotero integration the same way that it’s done with Zettlr and Sublime Text. Meanwhile, Alex would probably rather it be done in the kind of live preview way that Typora renders everything, looking to the way that Zotero designed the plugins for MS Word, LibreOffice, and Google Docs for ideas about what a GUI control panel might look like.
I don’t think Terry is better than Alex or vice versa. They just have different goals and values. So, they want different things from Obsidian.
Perhaps there’s a way of approaching this that’ll let Terry and Alex both be happy. Maybe it’s as simple as having a preference toggle to switch between “Show the code in the editor” and “Render the output in the editor.” As an interaction designer, this is the solution that I’d recommend, but of course it depends on whether or not the programmers can figure out how to implement the idea.
Edit: If one of the Obsidian devs would like me to produce mockups of the solution I’m proposing (no, not just what the toggle would look like in the preferences; I mean mocking up what the functionality would actually look in both modes), then let me know. I care enough about this functionality that I’d be willing to put the time into doing this.