Makes sense I guess. As a GUI-challenged person I still struggle with actually applying it though.
When I redesigned encapcalc I traded drop-down lists for a law of locality violation. And I still have no idea what a good UX for it would be.
I’d replace the list of the buttons on the left which add entries into the protocols field with simple checkboxes.
The current UI seems redundant on that score. You could of course have the checkboxes change the bg color around the entry to make “currently checked” status salient.
This also solves the law of locality violation you mentioned.
Checkboxes won’t do, it’s perfectly normal for a protocol to appear more than once (the IPIP “protocol” is just that—IPv4 packet sent as an IPv4 payload). Even if I make special cases for those, it will sill make total overhead calculation impossible (as in, “if I send my payload over IPv4 in GRE over IPv4, what’s the max payload size without fragmentation/how many bytes overhead will be”).
Visual calculation is also the thing I (and visitors) like about it.
Fair enough. I misunderstood the intended use. Still not sure I understand the tool completely, but do order and quantity matter in the protocol list, or just quantity? If the latter, “checkboxes with a count” might work. If the former, I can’t think of anything better than what you have (which seems fine, fwiw).