ER: less cutesy names, more to the point…
-
+1 I think this suggestion would definitely improve the interface, as well as helping user become familiar with what the packages actually do. When I see the project name next to the description of what it actually does, a mental association is created. Exploring all the neat little open source apps can be fun and interesting when you're at your comfortable desk and not under any time constraints, but when you're in a noisy uncomfortable datacenter trying to make something work at 3am, utility is virtue that is greatly appreciated.
-
So you're saying you feel more comfortable installing apps you don't understand into production as long as they're named a certain way?
-
I can see the point - a standard naming convention makes it much easier to manage an unfamiliar platform. I don't think the package names need to be removed, but the menu structure would benefit from a more standard naming convention (function, not package name).
-
@submicron:
So you're saying you feel more comfortable installing apps you don't understand into production as long as they're named a certain way?
I think you're arguing that by making it more difficult, this will somehow stop the uninformed from using/breaking pfSense. That is a futile battle. They will still wander into the forums asking questions.
+1 for convenience/clarity for all users
-
Nope, I'm arguing that people who can't spend a little time with Google to understand the tools they're using, probably shouldn't be installing/configuring a firewall. Similarly, I wouldn't want a mechanic to install brake pads on my car if they couldn't be bothered to look in the manual and understand how its intended to be installed properly. Making some arbitrary naming scheme to indicate the function of a package (especially when there is already a description) isn't really going to fix the actual problem.
-
@submicron:
Nope, I'm arguing that people who can't spend a little time with Google to understand the tools they're using, probably shouldn't be installing/configuring a firewall. Similarly, I wouldn't want a mechanic to install brake pads on my car if they couldn't be bothered to look in the manual and understand how its intended to be installed properly. Making some arbitrary naming scheme to indicate the function of a package (especially when there is already a description) isn't really going to fix the actual problem.
You really miss the point here. I ask for pfSense to refer to "high-performance, street-legal racing brake pads of dimension X" while currently it refers to "ECB yellow-stuff for souped up ricer".
Now if you waste your time, you can look up and realize that ECB yellow-stuff indeed are such brake pads, and you may learn that ricer and souped-up have a certain connotation in specific circles of car enthusiasts, but things should be named by their generic function and not by some cutesy project name or some unofficial insider slang.
After all, I'm not asking to have "http" to be renamed into "a universal means of getting some sort of information from the information superhighway", but I'm asking for an "http proxy" to be called "http proxy" rather than "squid" or "diapers" or whatever stupid/cutesy name a developer may give his baby.
PS: if you just started to google diapers trying to figure out what project I was referring to: it's a project I just started, which consists of zero lines of code and is used by nobody, but I can assure you it's an http proxy, and surely you know about it, right? Anyway, now you know why I don't care about squid, but I do care about an http-proxy. If it's squid, apache, etc. is utterly irrelevant except on the copyright page or some footnote. Because pfSense uses what it uses, and I configure it from a web interface, so it's not like I need to know about specific config files that are software specific.
-
As well, there will be people who have to support pfSense boxes others have built. By having a standard naming convention/menu structure that abstracts out package names it makes it easier for those folks.
-
Exactly Mr. Havok! ;)
Couldnt have said it better :)
@Cry:
As well, there will be people who have to support pfSense boxes others have built. By having a standard naming convention/menu structure that abstracts out package names it makes it easier for those folks.
-
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).
-
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
-
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.
-
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.
-
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).
-
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.
-
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.
-
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?
-
If someone supplies the code, perhaps, but it's not that easy, especially when you have to take the package menus into consideration.
