Improving Usability: Streamlining Command Execution in the Plugin

[rsenna]

Hi,

First off, I really appreciate the effort and care that’s gone into this plugin. It’s a very good idea, with a lot of potential.

That said, I’ve been struggling with it. As a developer, my use case is simple: I want to run shell script files in my Obsidian vault, based on certain events. However, I often find myself wrestling with the plugin’s complexity, rather than focusing on my workflow.

I acknowledge the depth of its feature set, but at times, it feels like it does too much, and the many configuration options tend to get in the way rather than help. It also feels, at the same time, overflown with information, but hiding me data that I really need, in order to to fix or improve the scripts I'm trying to execute.

A few specific pain points:

• Automatic path escaping: I run external scripts against vault files, and both need paths to remain unescaped. The default behavior creates issues for me.
• Argument input UI: Entering arguments in a small textarea where each token needs a separate line feels cumbersome.
• Handling of stdout/stderr: The requirement to predefine how outputs are captured - per command, per shell, etc. - adds unnecessary friction before even running anything.
• Workflow segmentation: The multi-step setup process (define shell → add command → define arguments) feels more restrictive than helpful.
• Lack of execution transparency: It’s difficult to see what exactly is happening when a command runs.
• Too much configuration options: the fact I can define "generic" settings, but also override them - again, per script, per shell, per OS, etc. - without a simple and "unifying" way of either seeing all customizations that have been made, or quickly removing them, is in my experience a problem, and does not scale well after using the tool for a while...

To be clear, to me, the main issue isn’t the feature set itself, but rather the User Experience: right now, the UI feels closely tied to how shell commands are structured internally within the plugin. That’s understandable, but ideally, a UI should abstract those details away, rather than impose them on users. (That's just my assumption, but I think it's correct, seeing how frequently this happens in software development.)

A non-exhaustive list of things that might help, in my opinion:

• A simplified command overview: A list of all commands in a clean, single-page layout (e.g., a column grid) instead of multiple separate input controls (each with a set of toolbars, labels, icons, etc.)
• Clear execution preview: A way to see exactly what will be run, including the full shell binary path, arguments, and final command string.
• Improved output visibility: Instead of making users choose an output method beforehand, the plugin could simply capture everything, for all executions (maybe in a temporary file), and just provide us different ways to view it... That could include what I think should be best: a simple, single output window, which would just show all executions - full command paths, complete outputs, etc. (logged with timestamps, so we don't get confused.)

---

I hope this feedback is useful. I think this plugin meets an important need, but a more streamlined interface would make it better.

Of course, I might also have made mistakes in my criticism, and misunderstood how I should approach some of its features. If that's the case, I apologize in advance.

Thanks again for your hard work.

[Taitava]

Hi @rsenna and thank you for the feedback 🙂 , I appreciate it and also the time you have invested. 👍

I do think your points are valid and the UI in its current state is not so good for user experience. I have built this plugin one piece at a time, without concentrating so much on the big picture or the complete workflow for user. This is the background of this plugin, but it doesn't have to be it's future.

That said, I think I will need some help shaping it better. Not necessarily coding help, but some UI mockups or illustrations could give me even more concrete ideas on what could be potential goals for the UI. I know making them would need some effort. Your feedback has been valuable and it's definitely a good start already. If you would be interested in helping me with this further, maybe you could make some mockups/illustrations, please? And if there are others willing to participate too, please let me know.

There is also one thing I need to acknowledge: I haven't used much time developing this plugin for almost a year now. I do think the UI renewing would take a lot of my planning and coding time in addition to your (possible) time for making the mockups. I don't know how much time this would take. What I do know is that I cannot promise getting into coding these changes anytime soon. So with that in mind, if any mockups will be made, please note that I cannot commit to big changes at this moment. I don't want to lead anyone on, so please use your time so that you won't be disappointed if the process won't achieve its goals, or only achieves some of them. Please start from the most important parts (to you), let's see if we can find a solution to fix them first.

Now, I will go through each of the things you listed in separate comments below. If we want to continue discussing them longer, it might be good to start completely new discussions for each of them and link back here.

[Taitava]

Not enough information vs. overflow of information

I acknowledge the depth of its feature set, but at times, it feels like it does too much, and the many configuration options tend to get in the way rather than help. It also feels, at the same time, overflown with information, but hiding me data that I really need, in order to to fix or improve the scripts I'm trying to execute.

• Just to clarify, can you please tell me some examples of information that is overflown? I mean, is there some unnecessary (or rarely needed) information?
• Anyway, I understand your bigger point was that there's some important information missing, so we'll focus more on that. But I'm just curious if there's something excess, too? Maybe something that could be relocated to a better place, or removed completely?
• So, may I please ask you to make two lists: A) Current settings you do not use/need. B) Current settings that you see important for your use-cases? These don't have to be exhaustive lists, but they could help me understand seeing your particular needs. And the list A doesn't necessarily mean stuff to be removed, but maybe it could open my eyes to things that are not that important.

• Lack of execution transparency: It’s difficult to see what exactly is happening when a command runs.

Yes, definitely this plugin needs more transparency on what it does under the hood. Now it's too much a box where you can't know what will come out of it. I'm trying to grasp your feedback to understand concrete ways to improve the transparency.

[Taitava]

Escaping of variables

• Automatic path escaping: I run external scripts against vault files, and both need paths to remain unescaped. The default behavior creates issues for me.

This is something users encounter very frequently. In old discussions, I have been reluctant to disabling escaping as a default. I still think that generally variables should escape their values by default (with the ability to opt out), but I'd be willing to search for ways to make it less aggressive (without causing a risk of actually dangerous characters being left unescaped). Of course it depends on situation (e.g. what quotes are used for an argument if any, and what shell is used) what characters are dangerous in a particular moment. I am willing to find out better ways to handle character escaping. Maybe I'll start a new discussion about this some day. I might have some ideas, but I'll need to explore them more before posting.

• E.g. one old discussion about escaping: How do I NOT escape special characters from the {{clipbboard}}? #224

[Taitava]

Custom shell arguments

• Argument input UI: Entering arguments in a small textarea where each token needs a separate line feels cumbersome.

I assume you are talking about the arguments of custom shells? Now that I look at the field, I do agree that it's too small.

• Maybe separate lines are not the nicest thing, but the reason for them is that Node.js's child_process.spawn() takes the arguments as an array rather than a single string. If I'm not mistaken, the plugin can't use a single-line field for this, because then it would need to split the arguments string into an array. I don't know how to split it. It cannot parse the arguments like shells do, it just doesn't know how that particular shell would parse its arguments.
• I think this is one good example of what you said about how "the UI feels closely tied to how shell commands are structured internally within the plugin". It forces the user to adapt to how things work internally. For this particular feature however, I don't know how to make it better while still keeping the arguments working. Maybe increasing the height of the multiline field would improve it a bit, but it probably would still not be optimal. I'm open for ideas, though.
• (I tried putting the arguments on one line for two custom shells, Windows Subsystem for Linux and MinGW-w64. For WSL, the shell still worked with arguments one one line, but for MinGW-w64 I got an "invalid option" error, i.e. the shell could not parse the arguments when all was on one line.)

[Taitava]

Output capturing

• Handling of stdout/stderr: The requirement to predefine how outputs are captured - per command, per shell, etc. - adds unnecessary friction before even running anything.

• Per shell? I think there's no shell related settings to how stdout/stderr outputs are captured? Please let me know if I'm wrong.
• But anyway, your point is true that the output capturing settings add unnecessary friction when they have to be configured for each shell command separately.
• One problem I'm personally encountering is that the default setting for stdout is to ignore the output, and I will be changing that default for new commands to be notification balloon. This of course won't solve the overall problem you described, though.

• Improved output visibility: Instead of making users choose an output method beforehand, the plugin could simply capture everything, for all executions (maybe in a temporary file), and just provide us different ways to view it... That could include what I think should be best: a simple, single output window, which would just show all executions - full command paths, complete outputs, etc. (logged with timestamps, so we don't get confused.)

Yes, there could be a pane for all shell commands and their outputs.

• Users could keep the pane open while working on their notes, and move it to another Obsidian window if wanted.
• The pane would be focused on usage of the shell commands, i.e. it would not be a settings/configuration pane.
• It would show all executions of all shell commands by default (during the current Obsidian session). Each command could opt out from being captured/shown here.
• I wouldn't store the execution log to any file at least by default. User needs to be aware if their executions are stored permanently. But maybe there could be a manual export button, and perhaps later a setting to automatically export to a log file?

[Taitava]

Setup workflow, and too much settings

• Workflow segmentation: The multi-step setup process (define shell → add command → define arguments) feels more restrictive than helpful.

I think this is something that would benefit from having some mockups of an improved UI. This is definitely about the big picture that I have been missing so far. The UI should better instruct/direct users to start from defining a shell (if the built-in ones don't fit them) and then writing commands (+ arguments) and configuring their output and other behavior. It's a big puzzle with a lot of optional pieces. E.g. some users don't need events at all to trigger their commands, they only define manual commands. It would be good to continue working on concrete ideas on how this workflow could be improved. I don't currently have a clear picture on this.

• Too much configuration options: the fact I can define "generic" settings, but also override them - again, per script, per shell, per OS, etc. - without a simple and "unifying" way of either seeing all customizations that have been made, or quickly removing them, is in my experience a problem, and does not scale well after using the tool for a while...

Maybe each of the overridable setting could have some kind of popup list that could show all the places where that particular setting is overridden and the fallback default value? I.e. show the default value and all shell commands that override the setting. Perhaps the same list could be used to remove the overrides?

[Taitava]

UI is tied to internal structure

To be clear, to me, the main issue isn’t the feature set itself, but rather the User Experience: right now, the UI feels closely tied to how shell commands are structured internally within the plugin. That’s understandable, but ideally, a UI should abstract those details away, rather than impose them on users. (That's just my assumption, but I think it's correct, seeing how frequently this happens in software development.)

I agree, the UI reflects the internal structure of the plugin. For me to learn away from this kind of way of making software, I do need concrete examples of problems and what would be better alternatives. It's good that you have already brought some of them to my knowledge. We can continue to work on the solutions. It's not always easy for me to see what would be a good final result, even if I do understand something has a problem.

[Taitava]

Simplify command overview in settings

A non-exhaustive list of things that might help, in my opinion:

• A simplified command overview: A list of all commands in a clean, single-page layout (e.g., a column grid) instead of multiple separate input controls (each with a set of toolbars, labels, icons, etc.)

So, do you mean a read-only list of shell commands? (Maybe other creatable items too, if it's likely there will be a lot of them, such as custom variables for some users). So it would be a new listing, instead of replacing the current one that has the ability to edit the commands?

• I think this sounds good at least at first glance.
• Just need to think about a good place where users can open it, if it won't replace the current list. I think it needs to be a new modal, as Obsidian's main settings modal probably will not grow wide enough for a table like view.

[Taitava]

Improve execution preview

• Clear execution preview: A way to see exactly what will be run, including the full shell binary path, arguments, and final command string.

This is also something I have overlooked. There's a preview for how a shell command will look with its variables parsed, but I didn't realize it could also benefit from showing the shell path and arguments, too. However, this would need to be done in a way that it won't clutter the UI anymore, maybe a separate preview popup? Perhaps the current preview could be moved there? It would make the list of shell commands more compact.

[Taitava]

Finally

I hope this feedback is useful. I think this plugin meets an important need, but a more streamlined interface would make it better.

I think your feedback allows me to see a clearer vision of this plugin. I usually focus more on details and might not see a forest through the trees. For this reason, I want to welcome people to this project in the future who can help streamlining the plugin as a whole. 💪😎

Of course, I might also have made mistakes in my criticism, and misunderstood how I should approach some of its features. If that's the case, I apologize in advance.

I think you have quite a good approach to the features, I'm not seeing any clear mistakes in your feedback. Thank you for being constructive! 👍

Thanks again for your hard work.

Thank you again for your feedback! 🙂 The work is not easy. But hopefully with some help I can - we can - make it even better! 🎉

---

And please let me know if I misunderstood something, or if I didn't notice to answer to something.