Long doc with rambling thoughts and reactions

Happy to see a new EDA tool project and impressed with progress so far.

As someone who has been using EDA tools for a while (but hopefully not so long as to get stuck in old ways), and who thinks about software usability a lot, and with a lot of Opinions, I have created a doc where I’m capturing my thoughts as a new Horizon user and also recording some of my other thoughts on the topic of EDA tool design.

I will be updating it as I go. Trying to be as constructively critical as possible. Apologies if there is anything in there that has already been brought up elsewhere.

Wow you really put a lot of work into this writeup, thanks for that. Similar to you, I am quite opinionated on software usability (and I can assure you horizon has come a long way since I started using it). Having a fresh pair of eyes on the program can help a lot so thanks again.

I see @lukas already commented into the google doc already, however please be aware that extensive commentary such as yours can lead to open source maintainer fatigue even if it comes from a place of love ; )

I don’t know how experienced you are, but to avoid such things please consider a few points that might be useful for all open source contributions, not just for horizon-eda:

  • Try to create your critique/commentary/bug report in a way that makes the least work possible for the other side
    • Search for similar issues
    • Use the system the maintainers are using (in this case: Github Issues on the appropriate repo)
    • If it is a Bug try to find the minimal setup that reproduces it and share that. I cannot overstate this. Over 50% of the times it happened to me, that I realized I just did something wrong. So instead of writing a bug for something that could only be reproduced if the maintainer made the same mistake I made (unlikely), I could file an issue, why I expected it to work that way, and why it did not end up working, which is all about removing paper cuts and improving usability
    • If it is a small thing, that is objectively better in a different way (e.g. lack of documentation), consider adding the changes yourself and creating a Pull Request (PR) for it.
    • Consider/Describe the impact of your changes. It might work well for you, but might break other peoples workflow. E.g. some people prefer to click on things, others want their UI to be very much uncluttered and do as much as possible from the keyboard
  • Some issues are really just so minor that they could be enumerated in one overarching issue

Thanks for the writeup anyways.

Points very well taken. I am not totally new to OSS (have a couple of minor projects myself) so I can empathize to a degree. I have actually filed a few bugs on GitHub already. However, I wanted to record my experience in a separate doc as a new user since it’s such a fleeting resource. Some things that look like bugs might end up being user error as you say, so I wanted to record them outside of the main issue tracker—might be indicative of something that could be improved usability-wise if it’s not a bug but seemed like one.

Eventually I will hope to reorganize (separating personal desires from more concrete issues) the doc as I learn more and can provide better perspective.

I was discussing this with Lukas on IRC when he told me to add this here so hopefully he knows where I’m coming from.

1 Like

Thanks for understanding, I am happy for the fresh pair of eyes : )

I won’t comment on every point you made, just keep an eye on the latest commits :wink: There are some things that have been low-key annoying to me as well. Knowing that other people are bothered by them as well usually leads to me quickly fixing them. Some other points reminded me of things that still are the way they are due to some circumstance that is no more and are now easy to fix.

Other aspects are the way they are due to implementation complexity constraints, for example the way polygon selection works and there being no cut operation.

As most of the document is about things not being the way you expect them to be and not about actual bugs, I’ll take it as a source of inspiration on what to implement in the future.

On a general note, feedback I’ve got from non-new users usually aligns with my ideas pretty well, whereas new users are more likely to comment on basic functionality that they find odd, but seems to work well for more experienced users.

Thank you for responding to or addressing many of my comments! I have no doubt that some things will become more natural after more use, so I will continue to try to balance gut reactions with more informed takes. If I have any large bugs, I will try to file GitHub issues rather than putting them in the doc, since this is mainly for my ideas/inspiration for improvement and/or enhancement requests.