English > Feature Suggestions

What PVD is missing is...

<< < (5/10) > >>

patch:
IMO not commenting on threads I can see no merit in is a sound approach.

That way the thread dies if it truly has no merit.
On the other hand the thread may blossom if it has merit to others I was not aware of.
Listing my way of addressing a problem with in the current software constraints may help others in the immediate future but is clearly only one of many solutions.

Anson:

--- Quote from: rick.ca on October 08, 2009, 10:38:01 pm ---... 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.
--- End quote ---

((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:

--- Quote from: rick.ca on September 30, 2008, 03:14:24 am ---PVD has a filter dedicated to "ownership," but off-hand, I don't recall how it works.
--- End quote ---

--- Quote from: rick.ca on September 30, 2008, 05:49:20 pm ---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. :-[
--- End quote ---
hehe, that is the situation for most users who don't have customized language files.

--- Quote from: rick.ca on June 30, 2009, 09:55:13 am ---Contrary to what the caption implies, this filter is simply triggered by ....
--- End quote ---

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 ?



--- Quote ---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.
--- End quote ---

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:

--- Quote from: Anson on October 07, 2009, 10:09:16 am ---
--- Quote from: nostra on July 04, 2009, 01:28:46 pm ---I will not add a new checkbox field (unless there is smth very important to solve with it).
--- End quote ---
true and reasonable
...

--- Quote ---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.
--- End quote ---
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.
...

--- Quote from: rick.ca on July 04, 2009, 08:31:09 am ---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)
--- End quote ---
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)
--- End quote ---


next point ...


--- Quote ---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.
--- End quote ---

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.


--- Quote ---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.
--- End quote ---

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.



--- Quote ---stomping on peoples ideas (whether good or bad) stifles debate and leads to people not participating
--- End quote ---

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 ...


--- Quote from: rick.ca on October 09, 2009, 08:20:59 pm ---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.
--- End quote ---

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.


--- Quote ---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.
--- End quote ---

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"


--- Quote ---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.
--- End quote ---

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.


--- Quote ---But the subject matter is a good illustration of what I'm talking about. There's nothing wrong with the program's filter feature. .....
--- End quote ---

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.



--- Quote from: rick.ca on October 10, 2009, 01:32:15 am ---
--- Quote ---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
--- End quote ---
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.  ;)
--- End quote ---

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.

patch:

--- Quote from: Anson on October 11, 2009, 08:33:10 am ---my only wishes about filters were that they are named according to what they do and that (as others also have suggested, including you)
....
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.

--- End quote ---

Actually there is a manual http://www.nimidia.com/pvd_wiki/tiki-index.php?page=PVD-Manual&structure=PVD-Manual
It is maintained by all PVD users.
Perhaps updating the filter descriptions sections would make it clearer.

If the labels are not intuitive what should they be?

(btw I don't use that part of the program so would prefer not to update that part of the manual)

korbenPL:
win 7 x64

working fine? anyone with substantial experience?

nostra:

--- Quote from: korbenPL on December 08, 2009, 11:12:08 am ---win 7 x64

working fine? anyone with substantial experience?

--- End quote ---

Same here, no problems except the play button does not work as describe in another thread.

Navigation

[0] Message Index

[#] Next page

[*] Previous page