Adding a VLAN takes 26 clicks and 71 keystrokes across 6 screens

[mtlynch]

One of the things I've noticed recently in using OPNsense is that it's particularly labor-intensive to create a basic VLAN. I decided to measure how many clicks and keystrokes it actually takes, and it turns out for my flow it's:

• 26 mouse clicks
• 71 keystrokes
• 6 distinct dialogs
• 3 separate workflows

I shared more details and a full video of my VLAN creation flow in this post:

• Add a VLAN to OPNsense in Just 26 Clicks Across 6 Screens

[pfry]

OPNsense does have an extra layer of interface indirection ("lan", "wan", etc.) - it's a legacy element.

Do you have some ideas on streamlining the, uh, interface interface? It doesn't really bother me - it's an initial setup issue, and if I really want to monkey with it, I'll fight with an XML config.

[bimbar]

This might best be part of a wider discussion about usability, which, in my opinion, is not necessarily the top priority in opnsense development.

I think more focus on this would be beneficial.

[meyergru]

And how would you actually go about that?

I often pointed to the obvious fact that along with great flexibility and functionality, "easy going" for end-users goes out the window. I accept the fact that OpnSense is an expert tool.

As a simple example, take the fact that ISC DHCPv4 is a part of the initial rant (while that did not even include the firewal setup or IPv6). And at this point, we have no less than three (!) DHCP daemons, namely ISC, Kea and DNSmasq. Which would you choose if the process was indeed more streamlined?

The only approach I could imagine was a set of some kind of "helpers for common tasks", but these would have to be on top of the fine-grained settings menus. Also, they would be prone to break pre-existent settings, just because they have to be limited to default settings (which ones, BTW?) instead of the wide variety of potential settings.

I can already picture upcoming forum discussions about how the default X of helper Y "does not suit my needs, can we change it or at least make it selectable?".

[Monviech (Cedrik)]

I guess this mostly falls into the Macro/Wizard dicussion.

Technically a vlan, layer 3 interface and dhcp are different technologies. So the GUI does not intermingle them for maximum flexibility.

Since all new components are API enabled, crafty individuals could build their own workflows (e.g a script that does exactly what they want with all assumptions their environment requires)

These could also have their own GUIs as the plugin system is very advanced and can hook into existing models.

For more inspiration check out the new system wizard.

[bimbar]

I agree that this is not the best case for a bad UI, in other firewalls you would also have to do a lot of clicking to achieve this result.

However I would like to see some UI streamlining for firewall rules and aliases.

[Monviech (Cedrik)]

Ideas that are in the mind is e.g. creating a new Alias while having a Firewall Rules dialog open, but for that to ever happen we have to follow the roadmap a bit further and push the "Firewall - Automation - Filter" component which is entirely MVC and was reworked a lot during the past year. It's soon going to be called "Firewall - Rules [new]".

GUI improvements take a long time to develop and test.

[franco]

Basically what people are asking for is a setup wizard. We'll be extending the existing wizard with a few use-case type presets in 26.1 but nothing that resembles a non-first-time setup yet.

If this is viable then we can talk about extending this idea based on the new wizard structure, but you still need all the old pages if you ever want to go back and edit a specific parameter.


Cheers,
Franco

[bimbar]

Not really a wizard, but I'm a big fan of being able to edit things in context, so edit or create an alias while having a firewall rule open - a good example would be the way the old Sophos UTM did it, or Fortinet does it now.

[Patrick M. Hausen]

Not really a wizard, but I'm a big fan of being able to edit things in context, so edit or create an alias while having a firewall rule open

I use tabs for that :-P

[Monviech (Cedrik)]

Its more like:
- You already half finished a firewall rule
- You notice you need a new alias
- You can add it in a different tab, but you have to save the rule and then edit it again and then add the alias

I mean yeah its a planning issue but it interrupts the workflow surprisingly often. I dont know if often enough to create complex dependencies to solve this, but it would be a "nice to have" if at least the available aliases in an open firewall rule would update.