From: Andrew N. <as...@gm...> - 2009-11-20 15:00:17
|
After bringing up a new VuFInd install I noticed that advanced search screen has gotten a bit out of control. It needs to be cleaned up and streamlined. And while I was thinking about it - i felt a complete overhaul and a fresh though would help. I created a wiki page to storyboard a new advanced search screen. I'd be interested in collaborating with others on this - so please feel free to tweak it. If you have some more radical thoughts - please create a new page with your ideas/concepts. http://vufind.org/wiki/advanced_search Thanks! Andrew |
From: Demian K. <dem...@vi...> - 2009-11-20 15:33:38
|
I agree that the current advanced search screen needs some UI help. I have some ideas and a bit of free time today, so I'll see if I can make it a little friendlier in advance of the RC2 release. Here are a few thoughts regarding your proposal in the Wiki: 1.) I think what Greg has done is truly an advanced search -- it's going to appeal to librarians and technically-oriented users while confusing some other groups of people. Your approach is more what I would call a guided search -- it offers more explicit, user-friendly options but has less flexibility for power users. Both approaches are valid and have their own strengths and weaknesses. I think it's worth implementing them as separate modules and allowing users to choose which one to offer in their UI. We could spend time debating which approach is better, but I don't think that's productive -- I'd prefer to just build functionality and let individual libraries decide how to use it. If we are going to have a debate, it should be over how we present the options in the out-of-the-box themes, not whether we delete one approach and replace it with a different one. 2.) I don't think we need to get too hung up on exactly which fields display in your proposed search screen. VuFind's existing search options are now highly configurable, and we should stick with that model when building new functionality -- it would be easy to create a searches.ini section for this new form that lists field names and associated captions, and we already have settings for which limiters to display. Obviously, we do need to think about what options to offer by default... but my point is that we should aim to design a flexible system rather than building a hard-coded form in the template. 3.) Regarding limiters, and applying both to your proposal and to our existing search code, we should think about VUFIND-45 -- allowing multiple limiter values to be OR'ed rather than AND'ed. I'm not sure how to express this in the interface in a clear way, and it touches on our facet-revamping discussions of a couple months ago, but it makes sense to offer the option if we can do it in an understandable way. - Demian From: Andrew Nagy [mailto:as...@gm...] Sent: Friday, November 20, 2009 10:00 AM To: vuf...@li... Subject: [VuFind-Tech] New Advanced Search After bringing up a new VuFInd install I noticed that advanced search screen has gotten a bit out of control. It needs to be cleaned up and streamlined. And while I was thinking about it - i felt a complete overhaul and a fresh though would help. I created a wiki page to storyboard a new advanced search screen. I'd be interested in collaborating with others on this - so please feel free to tweak it. If you have some more radical thoughts - please create a new page with your ideas/concepts. http://vufind.org/wiki/advanced_search Thanks! Andrew |
From: Andrew N. <as...@gm...> - 2009-11-20 15:50:43
|
On Fri, Nov 20, 2009 at 10:33 AM, Demian Katz <dem...@vi...>wrote: > I agree that the current advanced search screen needs some UI help. I > have some ideas and a bit of free time today, so I'll see if I can make it a > little friendlier in advance of the RC2 release. > > > > Here are a few thoughts regarding your proposal in the Wiki: > > > > 1.) I think what Greg has done is truly an advanced search -- it's going to > appeal to librarians and technically-oriented users while confusing some > other groups of people. Your approach is more what I would call a guided > search -- it offers more explicit, user-friendly options but has less > flexibility for power users. Both approaches are valid and have their own > strengths and weaknesses. I think it's worth implementing them as separate > modules and allowing users to choose which one to offer in their UI. We > could spend time debating which approach is better, but I don't think that’s > productive -- I'd prefer to just build functionality and let individual > libraries decide how to use it. If we are going to have a debate, it should > be over how we present the options in the out-of-the-box themes, not whether > we delete one approach and replace it with a different one. > > Agreed, I think someone a few weeks ago mentioned something about an advanced search and a super advanced search. While it sounds silly - we could implement something along these lines. The Advanced search page could have a tabbed layout: "Guided Search" & "Power Search" or something along those lines. > > > 2.) I don't think we need to get too hung up on exactly which fields > display in your proposed search screen. VuFind's existing search options > are now highly configurable, and we should stick with that model when > building new functionality -- it would be easy to create a searches.ini > section for this new form that lists field names and associated captions, > and we already have settings for which limiters to display. Obviously, we > do need to think about what options to offer by default… but my point is > that we should aim to design a flexible system rather than building a > hard-coded form in the template. > Completely agree! > 3.) Regarding limiters, and applying both to your proposal and to our > existing search code, we should think about VUFIND-45 -- allowing multiple > limiter values to be OR'ed rather than AND'ed. I'm not sure how to express > this in the interface in a clear way, and it touches on our facet-revamping > discussions of a couple months ago, but it makes sense to offer the option > if we can do it in an understandable way. > > > Completely Agree! Filters should be OR'd. This does need a complete revamp of the faceting structure however as you have pointed out - so it may not be something that we can accomplish by RC2. Andrew |
From: Demian K. <dem...@vi...> - 2009-11-20 16:27:15
|
The "tabbed advanced search screen" approach definitely could be the way to go -- since the current advanced search is Javascript-dependent, it's easy to load dynamically, and the simpler guided approach would be a great fallback for users without Javascript support. On the other hand, maybe that's overkill and I'm letting abstract technical issues influence my opinion. I'm not sure without trying it first! In any case, I'm glad we're on the same page. I've opened two new JIRA issues to help track the issues we've just raised: VUFIND-177: More flexible facet behavior VUFIND-178: Implement "guided" version of Advanced Search. VUFIND-177 includes a link to the earlier vufind-tech discussion of facet issues, and I've also created links between your advanced search Wiki page and VUFIND-178. Hopefully this will make it easy to use the Wiki to update the model search form and JIRA to engage in discussions. - Demian From: Andrew Nagy [mailto:as...@gm...] Sent: Friday, November 20, 2009 10:50 AM To: Demian Katz Cc: vuf...@li... Subject: Re: [VuFind-Tech] New Advanced Search On Fri, Nov 20, 2009 at 10:33 AM, Demian Katz <dem...@vi...<mailto:dem...@vi...>> wrote: I agree that the current advanced search screen needs some UI help. I have some ideas and a bit of free time today, so I'll see if I can make it a little friendlier in advance of the RC2 release. Here are a few thoughts regarding your proposal in the Wiki: 1.) I think what Greg has done is truly an advanced search -- it's going to appeal to librarians and technically-oriented users while confusing some other groups of people. Your approach is more what I would call a guided search -- it offers more explicit, user-friendly options but has less flexibility for power users. Both approaches are valid and have their own strengths and weaknesses. I think it's worth implementing them as separate modules and allowing users to choose which one to offer in their UI. We could spend time debating which approach is better, but I don't think that's productive -- I'd prefer to just build functionality and let individual libraries decide how to use it. If we are going to have a debate, it should be over how we present the options in the out-of-the-box themes, not whether we delete one approach and replace it with a different one. Agreed, I think someone a few weeks ago mentioned something about an advanced search and a super advanced search. While it sounds silly - we could implement something along these lines. The Advanced search page could have a tabbed layout: "Guided Search" & "Power Search" or something along those lines. 2.) I don't think we need to get too hung up on exactly which fields display in your proposed search screen. VuFind's existing search options are now highly configurable, and we should stick with that model when building new functionality -- it would be easy to create a searches.ini section for this new form that lists field names and associated captions, and we already have settings for which limiters to display. Obviously, we do need to think about what options to offer by default... but my point is that we should aim to design a flexible system rather than building a hard-coded form in the template. Completely agree! 3.) Regarding limiters, and applying both to your proposal and to our existing search code, we should think about VUFIND-45 -- allowing multiple limiter values to be OR'ed rather than AND'ed. I'm not sure how to express this in the interface in a clear way, and it touches on our facet-revamping discussions of a couple months ago, but it makes sense to offer the option if we can do it in an understandable way. Completely Agree! Filters should be OR'd. This does need a complete revamp of the faceting structure however as you have pointed out - so it may not be something that we can accomplish by RC2. Andrew |