a question/comment/suggestion: I'm slightly confused by the three different menu items search/select/list resources. They are very similar and often end up picking the wrong one.
I wonder if it might be more intuitive if these three items are merged into one "detailed search" screen? If the search text field is empty, it would then just list the resources like the current select/list does.
Cheers
Stephan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It might be worthwhile to merge the list and select menu items into one submenu (different to 'search') and, following the other feature request here regarding lists, add in a 'list all' item.
I think if I have 2 top menu items under Resources and one with a submenu, it might look like:
search
list (list all, select)
then the current list page can disappear because its functionality already exists in select.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's also my impression that "Browse" (clouds), "Select" and "List" overlap as functions to such a great extent that the user will probably just use one of them and stick with his choice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm happy to file a feature request, I just thought it might be useful to discuss first if there is a need for it, and what/how things should be combined.
Notis, you make an interesting point. I do like the cloud feature, especially for keywords, and I'd like to keep the choice to select from a cloud or from a list. But it also seems to me the actual functionality is very similar, so perhaps the cloud could just be a shortcut to the same consolidated search? I.e. when you click on a keyword it just performs the same search as it would when selecting that keyword from the select dialogue.
Reusing the same searches would also make the code easier to maintain in cases of future database changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I too like the tag cloud functionality -- it makes it easier to browse keywords for example and also to see their relative use so I would like to keep it. Clicking on a tag cloud keyword does provide the same functionality as selecting a keyword -- just a different gateway and, therefore, perhaps a different way of thinking about what and why you're doing the search. (That's why I've developed the soundExplorer plugin -- it's not there yet but I want to sonify the database and then see whether sound can be used to provide results from searches and whether this develops your thinking in different ways.)
I think much of the code is re-used and, in any case, I think about 99% of the SQL you see is generated on the fly and thus is generated from one 'SQL statement-generator engine' -- absolute hell to program (especially to account for all possible combinations and variations of search/select fields which stored statements could not possibly account for) but easier to maintain and upgrade.
Yes, it could always be better and there is some duplicate code scattered around but much of the v4 development was devoted to seeking out such programming and fixing it.
(Apologies, a bit of a quick and carelessly written email -- I don't plan on doing any wikindx development for at least a week as I have other things I must do. Plenty of time to discuss this before posting a FR.)
Regards,
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
a question/comment/suggestion: I'm slightly confused by the three different menu items search/select/list resources. They are very similar and often end up picking the wrong one.
I wonder if it might be more intuitive if these three items are merged into one "detailed search" screen? If the search text field is empty, it would then just list the resources like the current select/list does.
Cheers
Stephan
I'll have a look at it Stephan,
It might be worthwhile to merge the list and select menu items into one submenu (different to 'search') and, following the other feature request here regarding lists, add in a 'list all' item.
I think if I have 2 top menu items under Resources and one with a submenu, it might look like:
search
list (list all, select)
then the current list page can disappear because its functionality already exists in select.
Mark
If that makes sense to you, can you post it as a feature request please (bug reports and feature requests buried in forums tend to get lost).
Mark
It's also my impression that "Browse" (clouds), "Select" and "List" overlap as functions to such a great extent that the user will probably just use one of them and stick with his choice.
Hi Mark and Notis,
I'm happy to file a feature request, I just thought it might be useful to discuss first if there is a need for it, and what/how things should be combined.
Notis, you make an interesting point. I do like the cloud feature, especially for keywords, and I'd like to keep the choice to select from a cloud or from a list. But it also seems to me the actual functionality is very similar, so perhaps the cloud could just be a shortcut to the same consolidated search? I.e. when you click on a keyword it just performs the same search as it would when selecting that keyword from the select dialogue.
Reusing the same searches would also make the code easier to maintain in cases of future database changes.
I too like the tag cloud functionality -- it makes it easier to browse keywords for example and also to see their relative use so I would like to keep it. Clicking on a tag cloud keyword does provide the same functionality as selecting a keyword -- just a different gateway and, therefore, perhaps a different way of thinking about what and why you're doing the search. (That's why I've developed the soundExplorer plugin -- it's not there yet but I want to sonify the database and then see whether sound can be used to provide results from searches and whether this develops your thinking in different ways.)
I think much of the code is re-used and, in any case, I think about 99% of the SQL you see is generated on the fly and thus is generated from one 'SQL statement-generator engine' -- absolute hell to program (especially to account for all possible combinations and variations of search/select fields which stored statements could not possibly account for) but easier to maintain and upgrade.
Yes, it could always be better and there is some duplicate code scattered around but much of the v4 development was devoted to seeking out such programming and fixing it.
(Apologies, a bit of a quick and carelessly written email -- I don't plan on doing any wikindx development for at least a week as I have other things I must do. Plenty of time to discuss this before posting a FR.)
Regards,
Mark