... filters ... They are what they are—simple, consistent, mathematical realities. Their menu captions have absolutely no influence over what the program does. If you don't like a default caption, change it.
((ranting or not, decide yourself))
Shouldn't labels (including the names of menu option) be an indication of what they are used for? Of course, *you* are a long time user of PVD and have much more detailed knowledge about some of its workings, and thus *you* know what a filter does/checks, and thus *you* can easily change defaults by editing some translation.
But do you expect every user of PVD to try and test what a menu option does, explore how to do such translations, and then rename that option to something which indicates what it really does instead of what it is labeled on installing the program with the default settings? Then why doesn't nostra simply name all filters A, B, C, since you can change it anyway to suit your needs?
This time, i didn't start the thread, it was not a bug report, no request for immediate action, and this is the forum for feature suggestions. Thus i find it the perfect place to
suggest that some
misleading standard label is changed. simply changing a label is only a matter of changing a string and not even a real change in the program. of course, it is one small additional point in some todo list, but if something like the inconsistent labels
wish/
owned already caused several posts, would it be so bad to avoid confusion by making it consistent all over the program, so that everybody (and most of all relatively new users) would know what is meant, being able to use it more easily? so why are you arguing so strongly?
it is good if
you can change everything, but IMHO it is bad when
every user has to rename something (either as some translation, or at least in his mind remembering the different meaning of some labels)
from some other posts, we can see that you had problems with those names yourself, and that you find some labels poorly chosen. here are some references for this:
PVD has a filter dedicated to "ownership," but off-hand, I don't recall how it works.
Thanks for backing me up when I lose my mind. I had disabled my custom language file in which I've named the filter "Seen/available ~ Wish list," and then forgot what "Owned ~ Not owned" meant. :-[
hehe, that is the situation for most users who don't have customized language files.
Contrary to what the caption implies, this filter is simply triggered by ....
do you really want to explain that to every new user, or would it be better to change the caption so that the implications are easy/correct ?
You can argue there should be more or different attributes supported. But we've had that discussion before, and I believe the conclusion was there is no compelling need.
Please read what i had written in my post, and you see that i agree.
my only wishes about filters were that they are named according to what they do and that (as others also have suggested, including you) advanced searches could be stored, edited and recalled
in some future version and
in some way or another:
I will not add a new checkbox field (unless there is smth very important to solve with it).
true and reasonable
...
You use custom fields to add any number of checkboxes and achieve functionality you need. Advanced search can be used to filter by those fields.
yes, that is exactly what i do now, but the more custom fields and corresponding different advanced searches i use, the more important it will be in the future to store and recall (or whatever other method you might have for such a functionality) those searches for quick access and filtering.
...
If you prefer a Xmas gift of substance, wish for the ability to save advanced searches to a search menu. You would then have full-blown, fully customizable "filtering" at your fingertips, instead of just one more wimpy girly filter. 8)
sounds nice, maybe even having all the userdefined searches (which really are filters, aren't they?) as an additional item in the filters menu, with two buttons on the "advanced search" dialog to "store this search as new filter" and to "overwrite an existing filter with this search" (for editing a search)
next point ...
If you have some difficulty applying or adapting the program's design to your particular circumstances, it doesn't necessarily mean there's any deficiency in the program design. The deficiency can just as easily be said to be in your personal database management/workflow design.
If you have no difficulty applying or adapting the program's design to your particular circumstances, it doesn't necessarily mean there's no deficiency in the program design. Quite often, the fact itself that there are many people who first have to adapt the program to something or ask about details of its workings instead of being able to immediately use it "as is" is a deficiency. if many people have the same problem, it might be caused by something in the program which possibly could be improved. at least not every problem automatically should be called a
deficiency in the user's personal database management/workflow design.
In case you should think otherwise, I'm not joking or being dismissive about your confusion over the filter menu names. There's no requirement the fields those attributes are based on be used for exactly the same purpose the default menu captions and field names suggest.
... doesn't have to be used for that purpose. I use it to ...
So the default captions are not necessarily meaningful, and judging the program behaviour based on them is pointless.
you are mixing up something:
true, there is no requirement to use fields as the default labels suggest, but why do we have
default labels at all?
default labels should never indicate something misleading, but what the
default action (eg "test filepath for NULL") or the
default purpose is (eg "file exists"), so that every user easily can use it, and IF
you use them differently, it is
your responsibilty to care for the difference between name and function (by renaming, remembering, whatever).
It is also important that probably most users are no computer specialists, database managers, etc, and they should be given every opportunity to easily use the program in a way that seems to be obvious, eg suggested by some descriptions or labels, and
without the need to adapt the program to something different first or having to learn about internal workings by reading in forums for hours. This is even more true when there is no manual which explains something so that you simply can say "RTFM" :-)
i am not suggesting that a manual is missing for PVD since (after some basic info) most functions are relatively obvious, but i would find it nice if also less obvious things would be changed to make them more obvious, especially if this requires no program change but only some different words on a label.
stomping on peoples ideas (whether good or bad) stifles debate and leads to people not participating
or to reply, trying to lift them up again so that they are not forgotten in some stomped hole.
oh well, and while stomping and lifting them up, so much noise is produced that it might cause the same negative effects ...
I enjoy problem solving and finding creative ways to make processes work better.
....
Given the nature of my interest, I tend to see little difference between, or reason to favour, solutions involving program changes over those involving user adaptation to the program. I may even get some perverse satisfaction from devising a workaround to what might be considered an obvious program bug or design flaw. So if someone identifies a problem and seeks a program change as a solution, I'm likely to suggest an "adaptation" if I see one.
All this is fine with me, and i agree to the fullest ... IF you don't consider your "adaption" to be the
final solution to
everything including real bugs. else it would be really "perverse" :-)
I think that on problem reports, it is first priority to find what exactly the problem is, and whether it is only "not knowing how to do something" (a typical "help" case), or "not being able to do something" because of a missing feature (a typical feature
suggestion; btw: on a free software like PVD, there can't be feature
requests :-) or whether it is a real (big or small) bug which should be fixed sometime sooner or later.
If this is determined, we all are very grateful for any hints or solutions which tell us how something can be achieved while the feature is not (yet) implemented, or what can be done as temporary fix or workaround while a bug is not yet fixed. I often find those hints very enlightening on some program details and on how other things can be achieved, and i will never oppose a suggestion for workarounds, as long as those workarounds are not said to be
the solution to a real bug and that the bug need not to be fixed since there would be a workaround.
More importantly (and I think this is lost on some), there are other users reading the exchange—maybe out of specific interest in the issue at hand, maybe out of general interest about how the program works and how they might best use it. With that in mind, I usually like to put an issue in context by explaining how the program can still be used effectively despite the issue.
more support on that from me. I am eager to read such hints ...
as long as it's not labeled "since there is a workaround, there is no issue"
Without this, some posts are potentially misleading (i.e., readers who don't know what I know may think the program is broken and unusable—at least in some aspect), while others create the general impression the program is buggy.
every larger software is partially buggy or has shortcomings which could/should be improved. the difference is that some big companies fix bugs after years only (i still find some really bad "features" and "shortcomings" in Vista which i already had found in Win95/98), while nostra usually fixes important bugs in hours, other bugs also in time, and does feature improvements and new versions frequently.
thanks!even if some feature (like autocompletion :-) temporarily can't be fully used, the working "core" of PVD still is the best available. it would only be fatal if such a feature would be declared "fine as is", creating the impression that nobody cares for solutions.
But the subject matter is a good illustration of what I'm talking about. There's nothing wrong with the program's filter feature. .....
ok, let's illustrate :-)
after you explained it (!), there really is nothing wrong with the filter feature (its implementation), and neither with the rest of the above quote which i shortened ("....") and which gave some insights. The only part which was wrong was the impression which several users got from the labels of some filters (files etc), and that even more users didn't see the proper connections for other filters (wish/owned). therefore, in
my opinion, we should not stop after knowing a (for many people complicated) workaround but discuss how this aspect could be improved, and since you seemed to agree on the reason ("Contrary to what the caption implies", "forgot what Owned meant when personal language file was disabled") i would hope for a simple feature suggestion (with your support) to simply rename some filter labels and settle the problem permanently for standard default installations, also for future new users.
it is ok to disagree with ideas, but given your standing in forum it seems to stop participation rather than encourage. you dont have to respond to every post
Point well taken. I often consider encouraging discussion by keeping my mouth shut, but it seems I can seldom quite bring myself to do it. Or the deafening silence that results overwhelms me. ;)
no, please do
not keep your mouth shut. I am not at all against you making suggestions how to solve something, giving hints, how to work around something etc. With the insight you give in such hints, a discussion often can be better because people get more ideas or have a better understanding of what the program does or why.
It is only a matter how you present such an advice: whether you describe your info as a hint how something can be done differently or how your info can be used as a workaround or that something
might not have high priority, or whether you cancel a discussion by saying (what i called "authoritative answer", or CAD calls "with your standing in forum"; several people already have mistaken you as one of the developers) that something is no bug or that a suggestion would be pointless since no improvement would be needed when doing it like you suggest.
