next »

[fableman]

Name things for what they do/are not what there develop name is, everything else will make a mess.

Clean easy interface = "Less is more" is something alot developers should follow. (abit iphone thinking, put your self into some other guys head trying to do things without spending time on google).

[stephenw10]

Interesting topic. I have to say I agree although coming from a background of almost exclusively opensource firewalls I'm almost more familiar with the names than the generic terms. 

However looking through the GUI on 1.2.3 I can only see one reference (excluding packages) that might be confusing: OpenNTPD.
Perhaps CARP although that's also labled '(failover)'.

Steve

[rcfa]

Interesting topic. I have to say I agree although coming from a background of almost exclusively opensource firewalls I'm almost more familiar with the names than the generic terms. 

However looking through the GUI on 1.2.3 I can only see one reference (excluding packages) that might be confusing: OpenNTPD.
Perhaps CARP although that's also labled '(failover)'.

The package names was one thing. The other is lack of logical grouping. If we had menu entries like "proxy http" and "proxy sip" then e.g. the proxies would be all in a group without even trying. Similar for packages: snort is a funny name, but really it's an intrusion detection and prevention module. etc.

Then we get e.g. Darkstat (which by pure guessing one might think provides statistics about dark activities, such as hacking...)

Or take the Systems menu: shouldn't the General Setup be first, routing second, and something like logout last?

It's all there, but it's just not very accessible. A tiny bit of tidying things up and establishment of some (module/menu) naming conventions would make a huge difference in usability.

i'm not bitching, it's free software, just trying to give input on how to make a good thing better.

[jimp]

I don't much care what the name is, if the summary is right and includes a proper description, use ctrl+f to find it and be happy. If someone wants to call a package by a generic name, as long as the name of the underlying software is in the description it might be fine. I prefer to have the packages named after their specific underlying software, but I'm not dead set on that.

However, that doesn't work if you have multiple packages for the same purpose. Take DNS for example. There are tinydns and unbound packages. You can't just call them both "DNS Server" because even though they are both DNS servers, they also have vastly different capabilities and limitations, and struggling to find a generic term that distinguishes them all will create even more confusion and ambiguity.

Renaming packages will break them for existing users, so I don't see that ever happening. But the summaries can be updated if specific examples can be pointed out where a summary doesn't include a proper/useful description. Or perhaps (for 2.1 maybe) someone could add a column to indicate a package's general purpose that could hold the info you're after. Sprinkle a little sortable action on the table so you can sort by purpose, and everyone leaves happy (EDIT: It's actually already sortable).

It looks like maybe that is what the "Category" column was meant to cover in general, it could maybe be stolen/repurposed/etc for this.

[Cry Havok]

So how about a naming structure of (say) Server -> DNS -> Unbound and Server -> DNS -> TinyDNS and so on (eg Server -> Proxy -> HTTP -> Squid). That approach makes it easy for people to find the right menu options when they're dealing with something unfamiliar. You could even run 2 sets of menus the default (as it is now) and one like that for those who don't care what it's called (or don't have the time).

[jimp]

I was thinking more along the lines of how they are in the package list when installing, but you have to keep in mind that the menus are only a certain width, we can't put that much text there or it will wrap or look weird. Doing submenus is probably out of the question, browsers like IE choke enough on the menus as-is, I'd hate to see what they'd do with submenus.

It's not too much of a stretch to expect that if someone installed the unbound package that they look under Services > Unbound, but it could be clearer in some ways. Perhaps the package install process could print a list of newly added menu options once the install is complete.

[wagonza]

Unbound does say the following in the post install info section "Please visit Services: Unbound DNS to configure the Unbound DNS service...", however I have added some additional information to inform the user on where to configure the service in the Description field in the Package Manager page.

This doesn't address everybody's concern below but at least helps provide direction for a new user.

[Supermule]

Why not make the menu "floating" so people can drag items around to their liking?

A menu configuration tool for Pfsense, that is user friendly?

[jimp]

If someone supplies the code, perhaps, but it's not that easy, especially when you have to take the package menus into consideration.