Hi,
An user has to deal with many different tools and systems day-in-day-out - aggravated by the fact that many tools (such as setting up a new site in SmarterStats) are only used very occasionally every few weeks or months.
That makes a well thought-out user interface even more crucial or render a product less useful. One problem with SmarterStats is the tendency of each developer re-using the same term for their little feature - with apparently no one managing the overall usability of the product by enforcing consistency of meaning for the terms used, or their uniqueness.
One example was the re-use of "Dynamic Pages" in various parts of the product to describe completely unrelated functions - which I have addressed before.
The other is the use of "Filter" and "Import"
In "My Settings" (v10) there is are "Filter Sets". Now, quick - what's a "Filter Set"? A grouping of individual filters of course. And in General Settings, I can define individual (Import-)Filters. Oddly those "Filters" can not be added to "Filter Sets" because a "Filter Set" is NOT a collection of those individual (Import)Filters. The "Filter Sets" are really just "Report Filters", while the once in "General Settings" are "Log Processing Rules" or "Log Parsing Rules".
Because, the word "Import" is already used in a completely different context: You encounter an "Import" function when you add a new site, but THERE it does NOT mean the process of parsing/processing log files, but here it means pre-configuring/inheriting certain site settings from IIS when you add a new site. Naturally an "Import Filter" has nothing to do with the "Import" function!
You see where I'm going with this? I am not a full-time user of SmarterStats - no one but the developers are. As the very typical OCCASIONAL user, I often find myself encountering the same terminology in different parts of SmarterStats, which often are completely unrelated and mean entirely different things - based on the context.
My suggestion is for an interface/product designer to go through the product and establish DISTINCT terminology for various major features - example:
- Dynamic Pages vs. Query Parameters
- Import Site Settings vs. Log Processing (instead of Log "importing")
- Log Processing Rules (instead of "Import Filters") vs. Report Filters
- Site Settings can be "imported".
- Log Files are "processed" (or "parsed" if you prefer).
- Log Processing Rules allow you to define what log lines to include/exclude during processing.
- Report output can be "filtered"
By using distinct and consistent terminology, it will be clear to a user that when he sees a filter mentioned on a screen or the documentation, it's something "dynamic", dealing with report output.
If he sees as "rule" he knows it deals with the processing of log files and is "permanent" (e.g., requires re-processing if you want rules to change)
If he sees "importing", he knows it's dealing with inheriting site settings.
... stepping off soap box :-)