From MAILER-DAEMON Mon Feb 5 22:50:20 2001 Date: 05 Feb 2001 22:50:20 -0500 From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Message-ID: <981431420@turing.acm.org> X-IMAP: 0980637739 0000000033 Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From perlman@turing.acm.org Fri Jan 26 19:33:50 2001 -0500 Return-Path: Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by turing.acm.org (8.11.0/8.8.7) with ESMTP id f0R0Xor01169 for ; Fri, 26 Jan 2001 19:33:50 -0500 Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by mail.acm.org (8.9.3/8.9.3) with SMTP id TAA06354 for ; Fri, 26 Jan 2001 19:33:58 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa21051; 26 Jan 2001 19:33 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Fri, 26 Jan 2001 19:33:33 -0500 To: director@hcibib.org From: John Pane Subject: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 1 Hi Gary, The HCI Bibliography FAQ says: >Why does a site promoting HCI have such an unusable search syntax? >Thank you for volunteering to provide a new search engine! The >glimpse search is difficult to use, and unlike any syntax used by >any search engine. But glimpse is reasonably flexible and it is >provided for free on the free server used by the HCIBIB. At some >point, a form interface to hide the syntax might be added. I have done some research on how to improve user performance on boolean queries. In my study, untrained users performed significantly better using a form-based method to formulate queries than they did with the boolean operators. http://www.cs.cmu.edu/~pane/VL2000.html http://www.cs.cmu.edu/~pane/CHI2000.html I have implemented a web page that uses this form-based method to make queries to the HCI Bibliography. It is not as expressive as the full glimpse language, but I think many people would find it very useful as an entry point. The results page does show their query translated into the glimpse syntax, so it may even help them to pick up the glimpse syntax. I would be grateful if you would look at it and let me know what you think. If you agree that it would be useful to include this as a part of the HCI Bibliography, I would be happy to help make any refinements that are necessary. The page is currently at: http://www.cs.cmu.edu/~pane/www.hcibib.org/ Cheers, John Pane From perlman@turing.acm.org Fri Jan 26 23:36:09 2001 -0500 Return-Path: Received: from localhost (perlman@localhost) by turing.acm.org (8.11.0/8.8.7) with ESMTP id f0R4a8703947; Fri, 26 Jan 2001 23:36:08 -0500 Date: Fri, 26 Jan 2001 23:36:07 -0500 (EST) From: Gary PERLMAN To: John Pane cc: Gary perlman Subject: Re: Form-based queries for the HCI Bibliography In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: A X-Keywords: X-UID: 2 Very nice. I definitely want to use it, with full attribution, asuming you want to do it. This is a preliminary response; I need to read the papers before I make a longer response. I would like to: * change the form so that surrounding spaces are trimmed * consider putting "OR"s between the columns (I know you might prefer to avoid any mention of operators) * consider putting "AND"s or "WITH"s between the rows * consider reducing the number of rows to at most 4, maybe 3 * remove the background * figure out how to link it in (Advanced Search may be too imposing, but Simple Search seems too simple. How about Paned Search? Or, Panefull Search? Sorry, I could not resist, but I think Paned Search is accurate and fun. More drastically, I might want to explore something closer to conjunctive normal form. Instead of your form, which produces: (col1.row1 and col1.row2 and col1.row3) or (col2.row1 and col2.row2 and col2.row3) or (col3.row1 and col3.row2 and col3.row3) I think it might be more effective to first "OR" all variations, and then AND the disjunctions: (col1.row1 or col1.row2 or col1.row3) with (col2.row1 or col2.row2 or col2.row3) with (col3.row1 or col3.row2 or col3.row3) Take your example: Allen Cypher and KidSim or Alexander Repenning and AgentSheets I think it would be more likely to do a query like: Allen Cypher OR Brad Myers OR Brad A Myers OR ... and PBE OR Programming by Example OR Programming by Demonstration WHat do you think? Gary On Fri, 26 Jan 2001, John Pane wrote: > Hi Gary, > > The HCI Bibliography FAQ says: > >Why does a site promoting HCI have such an unusable search syntax? > >Thank you for volunteering to provide a new search engine! The > >glimpse search is difficult to use, and unlike any syntax used by > >any search engine. But glimpse is reasonably flexible and it is > >provided for free on the free server used by the HCIBIB. At some > >point, a form interface to hide the syntax might be added. > > I have done some research on how to improve user performance on > boolean queries. In my study, untrained users performed significantly > better using a form-based method to formulate queries than they did > with the boolean operators. > http://www.cs.cmu.edu/~pane/VL2000.html > http://www.cs.cmu.edu/~pane/CHI2000.html > > I have implemented a web page that uses this form-based method to > make queries to the HCI Bibliography. It is not as expressive as the > full glimpse language, but I think many people would find it very > useful as an entry point. The results page does show their query > translated into the glimpse syntax, so it may even help them to pick > up the glimpse syntax. > > I would be grateful if you would look at it and let me know what you > think. If you agree that it would be useful to include this as a part > of the HCI Bibliography, I would be happy to help make any > refinements that are necessary. > > The page is currently at: > http://www.cs.cmu.edu/~pane/www.hcibib.org/ > > Cheers, > John Pane > From perlman@turing.acm.org Sat Jan 27 09:09:14 2001 -0500 Return-Path: Received: from localhost (perlman@localhost) by turing.acm.org (8.11.0/8.8.7) with ESMTP id f0RE9CV06762; Sat, 27 Jan 2001 09:09:12 -0500 Date: Sat, 27 Jan 2001 09:09:12 -0500 (EST) From: Gary PERLMAN To: John Pane cc: Gary perlman Subject: Re: Form-based queries for the HCI Bibliography In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 3 I forgot one problem with glimpse booleans: * bugs in the search engine sometimes return zero hits The only way I've found around this has been to rewrite queries, especially "canned" ones for re-execution until they work. For a boolean query with no matches, the UI could warn that the expression may be too complex, although that is less than satisfactory. Another topic I forgot to mention was that of rewriting a query for maximum recall, although I hinted at that by suggesting to trim external spaces. For example: user interface requires a space between "user" and "interface". This will not match a hyphen or a newline. A better query is: user.interface The . matches any character. Gary On Fri, 26 Jan 2001, Gary PERLMAN wrote: > Very nice. I definitely want to use it, with full attribution, > asuming you want to do it. This is a preliminary response; > I need to read the papers before I make a longer response. > > I would like to: > * change the form so that surrounding spaces are trimmed > * consider putting "OR"s between the columns > (I know you might prefer to avoid any mention of operators) > * consider putting "AND"s or "WITH"s between the rows > * consider reducing the number of rows to at most 4, maybe 3 > * remove the background > * figure out how to link it in (Advanced Search may be too imposing, > but Simple Search seems too simple. How about Paned Search? > Or, Panefull Search? Sorry, I could not resist, but I think > Paned Search is accurate and fun. > > More drastically, I might want to explore something closer > to conjunctive normal form. Instead of your form, which > produces: > (col1.row1 and col1.row2 and col1.row3) > or > (col2.row1 and col2.row2 and col2.row3) > or > (col3.row1 and col3.row2 and col3.row3) > I think it might be more effective to first "OR" > all variations, and then AND the disjunctions: > (col1.row1 or col1.row2 or col1.row3) > with > (col2.row1 or col2.row2 or col2.row3) > with > (col3.row1 or col3.row2 or col3.row3) > Take your example: > Allen Cypher and KidSim > or > Alexander Repenning and AgentSheets > I think it would be more likely to do a query like: > Allen Cypher OR Brad Myers OR Brad A Myers OR ... > and > PBE OR Programming by Example OR Programming by Demonstration > WHat do you think? > > Gary > > On Fri, 26 Jan 2001, John Pane wrote: > > > Hi Gary, > > > > The HCI Bibliography FAQ says: > > >Why does a site promoting HCI have such an unusable search syntax? > > >Thank you for volunteering to provide a new search engine! The > > >glimpse search is difficult to use, and unlike any syntax used by > > >any search engine. But glimpse is reasonably flexible and it is > > >provided for free on the free server used by the HCIBIB. At some > > >point, a form interface to hide the syntax might be added. > > > > I have done some research on how to improve user performance on > > boolean queries. In my study, untrained users performed significantly > > better using a form-based method to formulate queries than they did > > with the boolean operators. > > http://www.cs.cmu.edu/~pane/VL2000.html > > http://www.cs.cmu.edu/~pane/CHI2000.html > > > > I have implemented a web page that uses this form-based method to > > make queries to the HCI Bibliography. It is not as expressive as the > > full glimpse language, but I think many people would find it very > > useful as an entry point. The results page does show their query > > translated into the glimpse syntax, so it may even help them to pick > > up the glimpse syntax. > > > > I would be grateful if you would look at it and let me know what you > > think. If you agree that it would be useful to include this as a part > > of the HCI Bibliography, I would be happy to help make any > > refinements that are necessary. > > > > The page is currently at: > > http://www.cs.cmu.edu/~pane/www.hcibib.org/ > > > > Cheers, > > John Pane > > > From perlman@turing.acm.org Sat Jan 27 12:19:38 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0RHJbr07637 for ; Sat, 27 Jan 2001 12:19:38 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa27582; 27 Jan 2001 12:19 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sat, 27 Jan 2001 12:19:20 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 4 On 1/26/01, Gary PERLMAN wrote: >Very nice. I definitely want to use it, with full attribution, >asuming you want to do it. This is a preliminary response; >I need to read the papers before I make a longer response. Gary, I am delighted that you would like to use it. Thank you for the detailed comments. I agree with them to varying degrees. I will write my thoughts about each of them below. >I would like to: > * change the form so that surrounding spaces are trimmed > * remove the background Your best judgement on the graphic design is fine with me. See below for my comments about the words ("include records with") at the top of the background image. > * consider reducing the number of rows to at most 4, maybe 3 This is fine. I went back and forth about how many rows and how many forms (columns) to include. I decided to err on the side of "too many" because I didn't want to over-constrain the expressiveness. But it does look a bit imposing when there are a lot of slots. I'm happy to go with your best judgement here. > * figure out how to link it in (Advanced Search may be too imposing, > but Simple Search seems too simple. How about Paned Search? > Or, Panefull Search? Sorry, I could not resist, but I think > Paned Search is accurate and fun. I will trust your judgement here on what to call it. Using a pun on my name is ok with me. Right now, the user is taken to to the standard results page after doing a query with my page. This has the advanced search at the top, so they would have to use the back button if they want to return to the filled-in template for refinement. Do you think they should be taken to a results page that has the simple search template at the top? If so, some work may have to be done on the server side so the the template on the results page is filled in with the query that was just performed. I have chosen to turn on two of the options from my simple searches page: highlight terms and whole word. Do you think these are good choices for the simple search? While I prefer to keep the page as uncluttered as possible, we may decide that a small subset of the options have to be visible on the page. Candidates seem like: whole word, case sensitive, approximate match. >* consider putting "OR"s between the columns > (I know you might prefer to avoid any mention of operators) > * consider putting "AND"s or "WITH"s between the rows I agree that additional cue words may be helpful to help indicate how the terms will be combined. But we use must choose these words very carefully. For reasons discussed in the VL paper, I believe that using AND or OR would be a mistake. If we use them in their "boolean operator" sense as you suggest above, it would probably help the people who are good at boolean expressions, but other people would probably interpret them incorrectly just like they do in other situations. Anecdote: So far, I have showed this page to only one other person, my wife who is a social worker. After figuring out how to use it and trying it a few times, her first suggestion was to put AND between the forms (columns). This makes perfect sense from a natural language point of view, but (as you suggest above) OR is the correct boolean operator to put there. This gets directly to the essence of the problems with the boolean operators. It is partly a question of how experienced the users will be. In this case, perhaps most are well-versed in boolean expressions from the other search engines that they use? >More drastically, I might want to explore something closer >to conjunctive normal form. Instead of your form, which >produces: > (col1.row1 and col1.row2 and col1.row3) > or > (col2.row1 and col2.row2 and col2.row3) > or > (col3.row1 and col3.row2 and col3.row3) >I think it might be more effective to first "OR" >all variations, and then AND the disjunctions: > (col1.row1 or col1.row2 or col1.row3) > with > (col2.row1 or col2.row2 or col2.row3) > with > (col3.row1 or col3.row2 or col3.row3) >Take your example: > Allen Cypher and KidSim > or > Alexander Repenning and AgentSheets >I think it would be more likely to do a query like: > Allen Cypher OR Brad Myers OR Brad A Myers OR ... > and > PBE OR Programming by Example OR Programming by Demonstration >WHat do you think? I see your point here. Do you have a log of actual searches that we could examine? It would be very interesting to see what kind of queries are prevalent, especially among the less advanced users. This is a big departure from the interface I studied, so we would no longer be able to rely on the study's results (which showed my interface to be more effective than boolean expressions). Nonetheless, we may find that it is a better choice for this application. I think there are a couple of important reasons why my match forms are effective: First, each form is implicitly an abstraction of a record (or a page or a document). Therefore I think people naturally expect that all the terms on a form must be present in a record for it to match. The words at the top of the form reinforce this. Second, the clear boundary between the forms helps people to keep straight which dimension is conjunction and which dimension is disjunction. Again, the words on the top help with this. I think it would be good to try to preserve these features. This may be challenging if we decide to use conjunctive normal form, but I am open to exploring it. Aside: on my search page, users can type multiple comma-separated terms into a single slot and the right thing will happen. At the extreme, they could type an entire glimpse expression into a single slot and the right thing will happen. I'm not suggesting that this is a feature we should rely on, however. >I forgot one problem with glimpse booleans: > * bugs in the search engine sometimes return zero hits >The only way I've found around this has been to rewrite >queries, especially "canned" ones for re-execution >until they work. I have noticed odd apparent bugs in the search engine. In particular, I am mystified by the following behavior: {John F;Pane;Albert T;Corbett} finds one document {John F.;Pane;Albert T} finds the same document {John F.;Pane;Albert T;Corbett} does not find that same document Why does the document match when there is a . after my initial, or when Corbett's last name is present, but not if both are there at the same time? >For a boolean query with no matches, >the UI could warn that the expression may be too complex, >although that is less than satisfactory. This seems like an issue that is independent of the new search page. It seems applicable to both the simple and advanced searches, and can't be detected until after submitting the query to glimpse. >Another topic I forgot to mention was that of rewriting >a query for maximum recall, although I hinted at that >by suggesting to trim external spaces. For example: > user interface >requires a space between "user" and "interface". >This will not match a hyphen or a newline. >A better query is: > user.interface >The . matches any character. This could be detected by the search interface, and either a warning message could be displayed or the space could automatically be replaced with a . before submitting the query to glimpse. Both of these seem like bad ideas to me, but maybe there is something we could do. Ultimately, we may decide it is best the way it is now, where the results page gives the suggestion. In summary, I think it is important to figure out what problem is being addressed by the new search page. Why are users dissatisfied with the current search page? Are they all experts at using boolean expressions, and are simply dissatisfied with glimpse because of its odd syntax? Or, are many of them subject to the notorious problems of boolean expressions as well as the odd glimpse syntax? In the former case, it may be wise to leverage the boolean knowledge and make the search similar to what people are accustomed to using, by showing the boolean operators between rows and columns or maybe even letting them type queries with AND and OR and translating the expression into glimpse for them. In the latter case, it may be better to avoid explicitly mentioning the boolean operators and stick closer to the original match form design. The good news is that the latter may not be any hindrance to the experts, as long as we make the search page expressive enough (especially with respect to the comments above about conjunctive normal form). One idea: "help for experts", that briefly explains the interface in terms of the boolean operators and maybe mentions the possibility of putting glimpse operators inside the slots. Cheers, John From perlman@turing.acm.org Sat Jan 27 14:28:02 2001 -0500 Return-Path: Received: from localhost (perlman@localhost) by turing.acm.org (8.11.0/8.8.7) with ESMTP id f0RJRkL08199; Sat, 27 Jan 2001 14:27:46 -0500 Date: Sat, 27 Jan 2001 14:27:46 -0500 (EST) From: Gary PERLMAN To: John Pane cc: Gary perlman Subject: Re: Form-based queries for the HCI Bibliography In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 5 Comments below... On Sat, 27 Jan 2001, John Pane wrote: > On 1/26/01, Gary PERLMAN wrote: > >Very nice. I definitely want to use it, with full attribution, > >asuming you want to do it. This is a preliminary response; > >I need to read the papers before I make a longer response. > > Gary, > > I am delighted that you would like to use it. Thank you for the > detailed comments. I agree with them to varying degrees. I will write > my thoughts about each of them below. > > > >I would like to: > > * change the form so that surrounding spaces are trimmed > > * remove the background > > Your best judgement on the graphic design is fine with me. See below > for my comments about the words ("include records with") at the top > of the background image. I did not convey this item well: > > * change the form so that surrounding spaces are trimmed I meant that if a user included leading or trailing spaces like: [ ben shneiderman ] the form would be interpreted as: [ben shneiderman] As for the background, I am a minimalist. > > * consider reducing the number of rows to at most 4, maybe 3 > > This is fine. I went back and forth about how many rows and how many > forms (columns) to include. I decided to err on the side of "too > many" because I didn't want to over-constrain the expressiveness. But > it does look a bit imposing when there are a lot of slots. I'm happy > to go with your best judgement here. I think it is easy to add slots. With FirstSearch, our old advanced interface had 4 slots like: Find: [ ] in [indexlist][v] and[v] [ ] in [indexlist][v] and[v] [ ] in [indexlist][v] and[v] [ ] in [indexlist][v] ([v] is a pulldown menu control). We switched to 3 for our new system, with no comments fom users. Most of our searches, despite coming from the advanced screen, are one and two term searches. > > * figure out how to link it in (Advanced Search may be too imposing, > > but Simple Search seems too simple. How about Paned Search? > > Or, Panefull Search? Sorry, I could not resist, but I think > > Paned Search is accurate and fun. > > I will trust your judgement here on what to call it. Using a pun on > my name is ok with me. > > Right now, the user is taken to to the standard results page after > doing a query with my page. This has the advanced search at the top, > so they would have to use the back button if they want to return to > the filled-in template for refinement. Do you think they should be > taken to a results page that has the simple search template at the > top? If so, some work may have to be done on the server side so the > the template on the results page is filled in with the query that was > just performed. It would be pretty simple to show the user the search form they used to get to results. That would make it much easier to refine searches. > I have chosen to turn on two of the options from my simple searches > page: highlight terms and whole word. Do you think these are good > choices for the simple search? While I prefer to keep the page as > uncluttered as possible, we may decide that a small subset of the > options have to be visible on the page. Candidates seem like: whole > word, case sensitive, approximate match. I wish glimpse has a "starts with" option, so "computer" would match all terms that start with computer. Case sensitive is almost never a good choice except for acronyms (e.g., GOMS), but lower case often works well. Glimpse does not allow turing on options per term, only per query, though, and it would be difficult for users to express that level of detail. WordPerfect had a nice method: lower case matches either, but upper case only matches upper case. > >* consider putting "OR"s between the columns > > (I know you might prefer to avoid any mention of operators) > > * consider putting "AND"s or "WITH"s between the rows > > I agree that additional cue words may be helpful to help indicate how > the terms will be combined. But we use must choose these words very > carefully. For reasons discussed in the VL paper, I believe that > using AND or OR would be a mistake. If we use them in their "boolean > operator" sense as you suggest above, it would probably help the > people who are good at boolean expressions, but other people would > probably interpret them incorrectly just like they do in other > situations. AND means "whatever the user wants it to mean", sometimes AND and sometimes OR. I think WITH is better, but ALL may be useful (e.g., all must match). I've not seen any problmes with OR, but ANY might go well with ALL. > Anecdote: So far, I have showed this page to only one other person, > my wife who is a social worker. After figuring out how to use it and > trying it a few times, her first suggestion was to put AND between > the forms (columns). This makes perfect sense from a natural language > point of view, but (as you suggest above) OR is the correct boolean > operator to put there. This gets directly to the essence of the > problems with the boolean operators. There are two problem areas, I think. One is the ambiguity of AND. The other is when you get into combining operators and users make up their own semantics, particularly for distribution of one operator over another. > It is partly a question of how experienced the users will be. In this > case, perhaps most are well-versed in boolean expressions from the > other search engines that they use? I would not assume "good logic" from any user group. > >More drastically, I might want to explore something closer > >to conjunctive normal form. Instead of your form, which > >produces: > > (col1.row1 and col1.row2 and col1.row3) > > or > > (col2.row1 and col2.row2 and col2.row3) > > or > > (col3.row1 and col3.row2 and col3.row3) > >I think it might be more effective to first "OR" > >all variations, and then AND the disjunctions: > > (col1.row1 or col1.row2 or col1.row3) > > with > > (col2.row1 or col2.row2 or col2.row3) > > with > > (col3.row1 or col3.row2 or col3.row3) > >Take your example: > > Allen Cypher and KidSim > > or > > Alexander Repenning and AgentSheets > >I think it would be more likely to do a query like: > > Allen Cypher OR Brad Myers OR Brad A Myers OR ... > > and > > PBE OR Programming by Example OR Programming by Demonstration > >WHat do you think? > > I see your point here. Do you have a log of actual searches that we > could examine? It would be very interesting to see what kind of > queries are prevalent, especially among the less advanced users. I've got hundreds of thousands of searches. But keep in mind that most users do not use complex queries. > This is a big departure from the interface I studied, so we would no > longer be able to rely on the study's results (which showed my > interface to be more effective than boolean expressions). > Nonetheless, we may find that it is a better choice for this > application. > > I think there are a couple of important reasons why my match forms > are effective: > > First, each form is implicitly an abstraction of a record (or a page > or a document). Therefore I think people naturally expect that all > the terms on a form must be present in a record for it to match. The > words at the top of the form reinforce this. > > Second, the clear boundary between the forms helps people to keep > straight which dimension is conjunction and which dimension is > disjunction. Again, the words on the top help with this. > > I think it would be good to try to preserve these features. This may > be challenging if we decide to use conjunctive normal form, but I am > open to exploring it. I need to read your papers. > Aside: on my search page, users can type multiple comma-separated > terms into a single slot and the right thing will happen. At the > extreme, they could type an entire glimpse expression into a single > slot and the right thing will happen. I'm not suggesting that this is > a feature we should rely on, however. For FirstSearch, even experienced users are surprised to find out that any query can go into any box. > >I forgot one problem with glimpse booleans: > > * bugs in the search engine sometimes return zero hits > >The only way I've found around this has been to rewrite > >queries, especially "canned" ones for re-execution > >until they work. > > I have noticed odd apparent bugs in the search engine. In particular, > I am mystified by the following behavior: > {John F;Pane;Albert T;Corbett} finds one document > {John F.;Pane;Albert T} finds the same document > {John F.;Pane;Albert T;Corbett} does not find that same document > Why does the document match when there is a . after my initial, or > when Corbett's last name is present, but not if both are there at the > same time? These bugs, the last of "begins with" (or wildcards like *), and the lack of a field-specific searc have made me think about writing my own index and search engine. It would take two weeks though, so I have been reluctant. > >For a boolean query with no matches, > >the UI could warn that the expression may be too complex, > >although that is less than satisfactory. > > This seems like an issue that is independent of the new search page. > It seems applicable to both the simple and advanced searches, and > can't be detected until after submitting the query to glimpse. I agree that it is independent. > >Another topic I forgot to mention was that of rewriting > >a query for maximum recall, although I hinted at that > >by suggesting to trim external spaces. For example: > > user interface > >requires a space between "user" and "interface". > >This will not match a hyphen or a newline. > >A better query is: > > user.interface > >The . matches any character. > > This could be detected by the search interface, and either a warning > message could be displayed or the space could automatically be > replaced with a . before submitting the query to glimpse. Both of > these seem like bad ideas to me, but maybe there is something we > could do. Ultimately, we may decide it is best the way it is now, > where the results page gives the suggestion. Generally, this has been the biggest problem in queries. Most search engines interpret at (A B) as (A and B), but glimpse interprets it is (A followed by space followed by B). Interpreting space as "any character" seems reasonable to me, especially since it increases hits, which is conservative. The suggestions are only partially useful, maybe because so many tend to come up. A single button to rewrite the query has always seemed risky to me. So the idea of having slightly different semantics on a different form is attractive to me. > In summary, I think it is important to figure out what problem is > being addressed by the new search page. Why are users dissatisfied > with the current search page? Are they all experts at using boolean > expressions, and are simply dissatisfied with glimpse because of its > odd syntax? Or, are many of them subject to the notorious problems of > boolean expressions as well as the odd glimpse syntax? I think the biggest problem is the odd glimpse syntax. I can gather data on this from the logs. For even simple queries, the syntax is so hard that most users do not get to the harder syntax of booleans. > In the former case, it may be wise to leverage the boolean knowledge > and make the search similar to what people are accustomed to using, > by showing the boolean operators between rows and columns or maybe > even letting them type queries with AND and OR and translating the > expression into glimpse for them. > > In the latter case, it may be better to avoid explicitly mentioning > the boolean operators and stick closer to the original match form > design. > > The good news is that the latter may not be any hindrance to the > experts, as long as we make the search page expressive enough > (especially with respect to the comments above about conjunctive > normal form). One idea: "help for experts", that briefly explains the > interface in terms of the boolean operators and maybe mentions the > possibility of putting glimpse operators inside the slots. > > Cheers, > John Here is a little more on CNF. The strategy is to find all variations of a term (dog dogs canine) and find the intersection with some other term(s) (bite bites attack attacks). Most of the canned queries in the HCIBIB (search for internet resources with U.hcibib) are of that form. So, CNF is a strategy more than a model. So, on our list: * log analysis (I can send you the whole thing - 35 megabytes) or I can do some pre-analysis (e.g., separate canned queries) * read your papers * more back and forth, if you don't mind From perlman@turing.acm.org Tue Jan 30 11:05:01 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0UG50g16224 for ; Tue, 30 Jan 2001 11:05:00 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa20446; 30 Jan 2001 11:04 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Tue, 30 Jan 2001 11:04:52 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 6 Hi Gary, A few comments on your last message... On 1/27/01, Gary PERLMAN wrote: >I did not convey this item well: >> > * change the form so that surrounding spaces are trimmed >I meant that if a user included leading or trailing spaces like: > [ ben shneiderman ] >the form would be interpreted as: > [ben shneiderman] Ah, I see. This would be no problem to implement. If we do this automatically, we must make sure that "whole word" search is turned on, right? > > > * consider reducing the number of rows to at most 4, maybe 3 >> >> This is fine. I went back and forth about how many rows and how many > > forms (columns) to include. ... > >I think it is easy to add slots. With FirstSearch, our old advanced >interface had 4 slots like: > Find: [ ] in [indexlist][v] > and[v] [ ] in [indexlist][v] > and[v] [ ] in [indexlist][v] > and[v] [ ] in [indexlist][v] >([v] is a pulldown menu control). We switched to 3 for our new system, >with no comments fom users. Most of our searches, despite coming from >the advanced screen, are one and two term searches. I agree that it should be as small as possible while still supporting most of the searches that people (especially beginners) will want to make. We can always put some slots back in if the users complain. > > Right now, the user is taken to to the standard results page after > > doing a query with my page. This has the advanced search at the top, >> so they would have to use the back button if they want to return to >> the filled-in template for refinement. Do you think they should be >> taken to a results page that has the simple search template at the >> top? If so, some work may have to be done on the server side so the >> the template on the results page is filled in with the query that was >> just performed. > >It would be pretty simple to show the user the search form they used >to get to results. That would make it much easier to refine searches. Ok, great! > > I have chosen to turn on two of the options from my simple searches >> page: highlight terms and whole word. Do you think these are good >> choices for the simple search? While I prefer to keep the page as >> uncluttered as possible, we may decide that a small subset of the >> options have to be visible on the page. Candidates seem like: whole >> word, case sensitive, approximate match. >I wish glimpse has a "starts with" option, so "computer" would >match all terms that start with computer. Case sensitive is almost >never a good choice except for acronyms (e.g., GOMS), but lower case >often works well. Glimpse does not allow turing on options per term, >only per query, though, and it would be difficult for users to express >that level of detail. WordPerfect had a nice method: lower case matches >either, but upper case only matches upper case. Given your comments, my current inclination is to have "highlight terms" and "whole word" turned on, and not to show the checkboxes for any of the options. Do you think this is the best choice? > > >* consider putting "OR"s between the columns >> > (I know you might prefer to avoid any mention of operators) >> > * consider putting "AND"s or "WITH"s between the rows > > >> I agree that additional cue words may be helpful to help indicate how >> the terms will be combined. But we use must choose these words very >> carefully. For reasons discussed in the VL paper, I believe that >> using AND or OR would be a mistake. If we use them in their "boolean >> operator" sense as you suggest above, it would probably help the >> people who are good at boolean expressions, but other people would >> probably interpret them incorrectly just like they do in other >> situations. > >AND means "whatever the user wants it to mean", sometimes AND and sometimes >OR. I think WITH is better, but ALL may be useful (e.g., all must match). >I've not seen any problmes with OR, but ANY might go well with ALL. One idea might be to make the form (column) headers look something like this: include records with all of | also include records with all of | ... ___________________________ | ________________________________ | ... ___________________________ | ________________________________ | ... ___________________________ | ________________________________ | ... ___________________________ | ________________________________ | ... That is, put the words at the top of each form instead of between slots, and "with all of" to indicate conjunction and "also" to indicate disjunction. However, this does not address the DNF vs. CNF issue. > > Anecdote: So far, I have showed this page to only one other person, >> my wife who is a social worker. After figuring out how to use it and >> trying it a few times, her first suggestion was to put AND between >> the forms (columns). This makes perfect sense from a natural language >> point of view, but (as you suggest above) OR is the correct boolean >> operator to put there. This gets directly to the essence of the >> problems with the boolean operators. > >There are two problem areas, I think. One is the ambiguity of AND. >The other is when you get into combining operators and users make up >their own semantics, particularly for distribution of one operator >over another. Yes. This is especially a problem with the scope of NOT. But since glimpse doesn't have NOT, I guess we don't have to worry about that one. > > >More drastically, I might want to explore something closer > > >to conjunctive normal form. ... > > >WHat do you think? >> >> I see your point here. Do you have a log of actual searches that we >> could examine? It would be very interesting to see what kind of >> queries are prevalent, especially among the less advanced users. > >I've got hundreds of thousands of searches. But keep in mind >that most users do not use complex queries. For those user searches that have more than a single keyword, do you have a sense for which operator most often appears outermost (at the top of the parsed expression tree)? Clearly, in the examples on your canned search page it is AND, suggesting CNF would be best for you and other experts. Even if the prevalent tendency of the general user population indicates DNF, maybe it would be good to nudge them towards the expert strategy of using CNF. > > >Another topic I forgot to mention was that of rewriting >> >a query for maximum recall, although I hinted at that >> >by suggesting to trim external spaces. For example: >> > user interface >> >requires a space between "user" and "interface". >> >This will not match a hyphen or a newline. >> >A better query is: >> > user.interface >> >The . matches any character. >> >> This could be detected by the search interface, and either a warning >> message could be displayed or the space could automatically be >> replaced with a . before submitting the query to glimpse. Both of >> these seem like bad ideas to me, but maybe there is something we >> could do. Ultimately, we may decide it is best the way it is now, >> where the results page gives the suggestion. > >Generally, this has been the biggest problem in queries. >Most search engines interpret at (A B) as (A and B), but >glimpse interprets it is (A followed by space followed by B). >Interpreting space as "any character" seems reasonable to me, >especially since it increases hits, which is conservative. >The suggestions are only partially useful, maybe because >so many tend to come up. A single button to rewrite the query >has always seemed risky to me. So the idea of having slightly >different semantics on a different form is attractive to me. Having different semantics on this page is fine with me, and no problem to implement what you are suggesting. But translating the space to dot still requires adjacency, which is not exactly what you say the users are expecting (AND). Translating the space to a semicolon (AND) would increase recall even more, but would that be too extreme when the user really wants adjacency (as in "user interface")? > > In summary, I think it is important to figure out what problem is >> being addressed by the new search page. Why are users dissatisfied > > with the current search page? Are they all experts at using boolean >> expressions, and are simply dissatisfied with glimpse because of its >> odd syntax? Or, are many of them subject to the notorious problems of >> boolean expressions as well as the odd glimpse syntax? > >I think the biggest problem is the odd glimpse syntax. >I can gather data on this from the logs. For even simple >queries, the syntax is so hard that most users do not get to >the harder syntax of booleans. Good, the glimpse syntax is definitely the easier problem to solve! >Here is a little more on CNF. The strategy is to find all variations >of a term (dog dogs canine) and find the intersection with some other >term(s) (bite bites attack attacks). Most of the canned queries in >the HCIBIB (search for internet resources with U.hcibib) are of that form. >So, CNF is a strategy more than a model. Yes. As mentioned above, perhaps we want the interface to encourage beginners to adopt this strategy. >So, on our list: > * log analysis (I can send you the whole thing - 35 megabytes) > or I can do some pre-analysis (e.g., separate canned queries) > * read your papers I probably do not need the whole log. To the extent that you know (or can easily determine) the prevalence of some high level features, that will probably be enough. For example, what fraction are simple keyword searches, how many involve more than one operator, and what form do most queries take (DNF or CNF or something else)? > * more back and forth, if you don't mind I'm enjoying the back-and-forth, and happy to have the opportunity to make a positive impact on this very useful resource. Cheers, John From perlman@turing.acm.org Tue Jan 30 11:09:38 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0UG9Wg16257 for ; Tue, 30 Jan 2001 11:09:33 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa20479; 30 Jan 2001 11:09 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Tue, 30 Jan 2001 11:09:04 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 7 > > I have noticed odd apparent bugs in the search engine. In particular, >> I am mystified by the following behavior: >> {John F;Pane;Albert T;Corbett} finds one document >> {John F.;Pane;Albert T} finds the same document >> {John F.;Pane;Albert T;Corbett} does not find that same document >> Why does the document match when there is a . after my initial, or >> when Corbett's last name is present, but not if both are there at the >> same time? > >These bugs, the lack of "begins with" (or wildcards like *), >and the lack of a field-specific search have made me think about >writing my own index and search engine. It would take two weeks >though, so I have been reluctant. P.S. It is kind of shocking that this bug is still there in glimpse. Is it still under active development? Do the developers acknowledge the existence of the bug? From perlman@turing.acm.org Tue Jan 30 15:09:46 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0UK9jg19294 for ; Tue, 30 Jan 2001 15:09:45 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa22140; 30 Jan 2001 15:09 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Tue, 30 Jan 2001 15:09:42 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 8 On 1/27/01, John Pane wrote: >First, each form is implicitly an abstraction of a record (or a page >or a document). Therefore I think people naturally expect that all >the terms on a form must be present in a record for it to match. The >words at the top of the form reinforce this. > >Second, the clear boundary between the forms helps people to keep >straight which dimension is conjunction and which dimension is >disjunction. Again, the words on the top help with this. > >I think it would be good to try to preserve these features. This may >be challenging if we decide to use conjunctive normal form, but I am >open to exploring it. With these points in mind, I have created another design that uses DNF. I'd appreciate your thoughts. I haven't yet implemented some of the other ideas we've been discussing. http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ John From perlman@turing.acm.org Tue Jan 30 15:56:18 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0UKuIg19718 for ; Tue, 30 Jan 2001 15:56:18 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa22740; 30 Jan 2001 15:56 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Tue, 30 Jan 2001 15:56:09 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: X-Keywords: X-UID: 9 On 1/30/01, Gary PERLMAN wrote: >I think that is CNF (a conjuct of disjunctions). Yes, sorry about that mistake in my message. >I think e.g., would be better than i.e., >but I am a little wary of the mysterious labels. >The numbers are clear enough, but what are the parentheses >and and the commas? Is the first box a name for the line >and the others are the actual values? All good points. I guess we should avoid the abbreviations of Latin terms. >Then, in the instructions, the term "or" might be confusing. I assume you mean the word or in the explanation of the example? Alternative wordings welcome. >I'd allow for more smaller boxes. You have three size=30 boxes. >I'd go with four size=15. Ok. >The prompt: "Find records that match all of" could be put on >any search form, so I'd move it closer to the action. >Maybe somthing like: > >match any [__________] [__________] [__________] [__________] > > with > >match any [__________] [__________] [__________] [__________] > > with > >match any [__________] [__________] [__________] [__________] I am concerned that this would be interpreted as a disjunction of the rows, rather than a conjunction. For example, someone might think all the records matching the first line should be combined in the results WITH all the records matching the second line, etc. I like the numbers and the "all of" because it is like a list of requirements. >Half the screen is help that I doubt users will read. >I think you can put in one example, such as: > >color colour >coding highlight visual search >1996 1997 1998 1999 Are you suggesting that I take out the explanatory text with the example, the help text itself, or both? I'd prefer to leave some help text in. >(actually, parsing NNNN-NNNN and creating a date range would be nice). That would be nice. Would have to be careful to make it bulletproof. We don't want the user's browser to run out of memory or crash when Javascript tries to expand a typo such as 199-2000. Cheers, John From perlman@turing.acm.org Tue Jan 30 16:39:05 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0ULd4g20334 for ; Tue, 30 Jan 2001 16:39:05 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa23098; 30 Jan 2001 16:38 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Tue, 30 Jan 2001 16:38:46 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 10 Gary, Here is another attempt. http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ John On 1/30/01, Gary PERLMAN wrote: >I think that is CNF (a conjuct of disjunctions). > >I think e.g., would be better than i.e., >but I am a little wary of the mysterious labels. >The numbers are clear enough, but what are the parentheses >and and the commas? Is the first box a name for the line >and the others are the actual values? > >Then, in the instructions, the term "or" might be confusing. > >I'd allow for more smaller boxes. You have three size=30 boxes. >I'd go with four size=15. > >The prompt: "Find records that match all of" could be put on >any search form, so I'd move it closer to the action. >Maybe somthing like: > >match any [__________] [__________] [__________] [__________] > > with > >match any [__________] [__________] [__________] [__________] > > with > >match any [__________] [__________] [__________] [__________] > > >Half the screen is help that I doubt users will read. >I think you can put in one example, such as: > >color colour >coding highlight visual search >1996 1997 1998 1999 > >(actually, parsing NNNN-NNNN and creating a date range would be nice). > >I've have printed your papers. > >Gary > >On Tue, 30 Jan 2001, John Pane wrote: > >> On 1/27/01, John Pane wrote: >> >First, each form is implicitly an abstraction of a record (or a page >> >or a document). Therefore I think people naturally expect that all >> >the terms on a form must be present in a record for it to match. The >> >words at the top of the form reinforce this. >> > >> >Second, the clear boundary between the forms helps people to keep >> >straight which dimension is conjunction and which dimension is >> >disjunction. Again, the words on the top help with this. >> > >> >I think it would be good to try to preserve these features. This may >> >be challenging if we decide to use conjunctive normal form, but I am >> >open to exploring it. >> >> With these points in mind, I have created another design that uses >> DNF. I'd appreciate your thoughts. I haven't yet implemented some of >> the other ideas we've been discussing. > > http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ >> >> John >> From perlman@turing.acm.org Tue Jan 30 17:48:15 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0UMmBg21032 for ; Tue, 30 Jan 2001 17:48:15 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa23958; 30 Jan 2001 17:48 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Tue, 30 Jan 2001 17:48:11 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 11 Gary, I have implemented the changes you suggest below. I think we are converging. Here are some things that aren't done yet: * trim leading and trailing spaces * replace embedded spaces with dot or semicolon * possibly implement year ranges * integrate it into the hcibib John On 1/30/01, Gary PERLMAN wrote: >It works for me. >I'd drop the numbers. >Change "include" to "Display" or "Retrieve" (the latter may be too jargony). > >I find the Help awkward. It does not use the same terminology as in the form. > For a record to match, ALL rows of search boxes must match. > To match a row, ANY of the search boxes in the row can match. > Blank boxes and lines are ignored. > >I'd put the Reset button next to the Search button, and move your name over. > >I'd add a label to the glipse version at the bottom, like: > Glimpse search engine syntax: > >On Tue, 30 Jan 2001, John Pane wrote: > >> Gary, >> >> Here is another attempt. >> http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ >> >> John >> >> >> >> >> >> On 1/30/01, Gary PERLMAN wrote: >> >I think that is CNF (a conjuct of disjunctions). >> > >> >I think e.g., would be better than i.e., >> >but I am a little wary of the mysterious labels. >> >The numbers are clear enough, but what are the parentheses >> >and and the commas? Is the first box a name for the line >> >and the others are the actual values? >> > >> >Then, in the instructions, the term "or" might be confusing. >> > >> >I'd allow for more smaller boxes. You have three size=30 boxes. >> >I'd go with four size=15. >> > >> >The prompt: "Find records that match all of" could be put on >> >any search form, so I'd move it closer to the action. >> >Maybe somthing like: >> > >> >match any [__________] [__________] [__________] [__________] >> > >> > with >> > >> >match any [__________] [__________] [__________] [__________] >> > >> > with >> > >> >match any [__________] [__________] [__________] [__________] >> > >> > >> >Half the screen is help that I doubt users will read. >> >I think you can put in one example, such as: >> > >> >color colour >> >coding highlight visual search >> >1996 1997 1998 1999 >> > >> >(actually, parsing NNNN-NNNN and creating a date range would be nice). >> > >> >I've have printed your papers. >> > >> >Gary >> > >> >On Tue, 30 Jan 2001, John Pane wrote: >> > >> >> On 1/27/01, John Pane wrote: >> >> >First, each form is implicitly an abstraction of a record (or a page >> >> >or a document). Therefore I think people naturally expect that all >> >> >the terms on a form must be present in a record for it to match. The >> >> >words at the top of the form reinforce this. >> >> > >> >> >Second, the clear boundary between the forms helps people to keep >> >> >straight which dimension is conjunction and which dimension is >> >> >disjunction. Again, the words on the top help with this. >> >> > >> >> >I think it would be good to try to preserve these features. This may >> >> >be challenging if we decide to use conjunctive normal form, but I am >> >> >open to exploring it. >> >> >> >> With these points in mind, I have created another design that uses >> >> DNF. I'd appreciate your thoughts. I haven't yet implemented some of >> >> the other ideas we've been discussing. >> > > http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ >> >> >> >> John >> >> >> From perlman@turing.acm.org Tue Jan 30 19:04:02 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0V042g21649 for ; Tue, 30 Jan 2001 19:04:02 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa24758; 30 Jan 2001 19:03 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Tue, 30 Jan 2001 19:03:56 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 12 Gary, I have implemented all of the following: > > * trim leading and trailing spaces > > * replace embedded spaces with dot or semicolon replace with dot for now, subject to further discussion > > * possibly implement year ranges string must be exactly NNNN-NNNN, limits range to 50 years >Example change "include" to "display" >How about dropping the Help to size=2 and slipping it in between the slots >and the Search button? Try the Help label over the Reset, and the text >under the slots The following is not done yet. If it were up to me, I would not include it, but feel free to override me: >Do you think the record type limiter should be included? >It could be done as radio buttons. John On 1/30/01, Gary PERLMAN wrote: >For implementation, I think I'll probably code it in the form handler, >but JavaScript is okay for now. > >How about dropping the Help to size=2 and slipping it in between the slots >and the Search button? Try the Help label over the Reset, and the text >under the slots > >Example change "include" to "display" > >Do you think the record type limiter should be included? >It could be done as radio buttons. > >The fun with spaces might wait until log analysis. > >Gary > >On Tue, 30 Jan 2001, John Pane wrote: > >> Gary, >> >> I have implemented the changes you suggest below. >> >> I think we are converging. Here are some things that aren't done yet: >> * trim leading and trailing spaces >> * replace embedded spaces with dot or semicolon >> * possibly implement year ranges >> * integrate it into the hcibib >> >> John >> >> >> On 1/30/01, Gary PERLMAN wrote: >> >It works for me. >> >I'd drop the numbers. >> >Change "include" to "Display" or "Retrieve" (the latter may be >>too jargony). >> > >> >I find the Help awkward. It does not use the same terminology as >>in the form. >> > For a record to match, ALL rows of search boxes must match. >> > To match a row, ANY of the search boxes in the row can match. >> > Blank boxes and lines are ignored. >> > >> >I'd put the Reset button next to the Search button, and move your >>name over. >> > >> >I'd add a label to the glipse version at the bottom, like: >> > Glimpse search engine syntax: >> > >> >On Tue, 30 Jan 2001, John Pane wrote: >> > >> >> Gary, >> >> >> >> Here is another attempt. >> >> http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ >> >> >> >> John >> >> >> >> >> >> >> >> >> >> >> >> On 1/30/01, Gary PERLMAN wrote: >> >> >I think that is CNF (a conjuct of disjunctions). >> >> > >> >> >I think e.g., would be better than i.e., >> >> >but I am a little wary of the mysterious labels. >> >> >The numbers are clear enough, but what are the parentheses >> >> >and and the commas? Is the first box a name for the line >> >> >and the others are the actual values? >> >> > >> >> >Then, in the instructions, the term "or" might be confusing. >> >> > >> >> >I'd allow for more smaller boxes. You have three size=30 boxes. >> >> >I'd go with four size=15. >> >> > >> >> >The prompt: "Find records that match all of" could be put on >> >> >any search form, so I'd move it closer to the action. >> >> >Maybe somthing like: >> >> > >> >> >match any [__________] [__________] [__________] [__________] >> >> > >> >> > with >> >> > >> >> >match any [__________] [__________] [__________] [__________] >> >> > >> >> > with >> >> > >> >> >match any [__________] [__________] [__________] [__________] >> >> > >> >> > >> >> >Half the screen is help that I doubt users will read. >> >> >I think you can put in one example, such as: >> >> > >> >> >color colour >> >> >coding highlight visual search >> >> >1996 1997 1998 1999 >> >> > >> >> >(actually, parsing NNNN-NNNN and creating a date range would be nice). >> >> > >> >> >I've have printed your papers. >> >> > >> >> >Gary >> >> > >> >> >On Tue, 30 Jan 2001, John Pane wrote: >> >> > >> >> >> On 1/27/01, John Pane wrote: >> >> >> >First, each form is implicitly an abstraction of a record >>(or a page > > >> >> >or a document). Therefore I think people naturally expect that all >> >> >> >the terms on a form must be present in a record for it to >>match. The >> >> >> >words at the top of the form reinforce this. >> >> >> > >> >> >> >Second, the clear boundary between the forms helps people to keep >> >> >> >straight which dimension is conjunction and which dimension is >> >> >> >disjunction. Again, the words on the top help with this. >> >> >> > >> >> >> >I think it would be good to try to preserve these >>features. This may >> >> >> >be challenging if we decide to use conjunctive normal >>form, but I am >> >> >> >open to exploring it. >> >> >> >> >> >> With these points in mind, I have created another design that uses >> >> >> DNF. I'd appreciate your thoughts. I haven't yet implemented some of >> >> >> the other ideas we've been discussing. >> >> > > http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ >> >> >> >> >> >> John >> >> >> >> >> > > From perlman@turing.acm.org Wed Jan 31 00:53:36 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0V5rYg25837 for ; Wed, 31 Jan 2001 00:53:35 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa27169; 31 Jan 2001 0:53 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Wed, 31 Jan 2001 00:53:02 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 13 On 1/30/01, Gary PERLMAN wrote: >I am afraid the "." is a problem. I keep on getting zero hits. >So please remove the ".". Ok, it is done. >I like the date ranges a lot. You could also match: > NNNN- >and fill in the current year (or 2001 if you are losing steam). Ok, it is done; and it determines the correct year to use. >For me, the most common reason for not searching from >the HCIBIB home page is that it does not have a type limiter. >But I am not your average user. I'll check the logs to see >if I am the only person in the world to use it. Could be. Ok, let me know what you determine. >I'd like to pass the design around ot some people here >to get comments. And I may run some impromptu usability tests. >Is that okay with you? Sure. Comments and usability testing would be great. Hopefully it won't delay the release for too long. >I keep wondering if the example should not be a separate form >with the values filled in. It could even work. Then I wonder >if the default form should come up with a real query (which >would require users to click reset, so it might have problems). Another possibility is to have an "Example" link, which fills in the slots when you click it. I have implemented this for you to try and see if you like it. >I'd start "display a record if it" with "Display". Ok, it is done. >Maybe drop the longer horizontal rules (I am a space fanatic). I tried it without these horizontal rules and it didn't look as good to me. I would prefer to leave them in, if that would be ok with you. >Maybe move the "Simple search by..." up to the top of the form >on the same line as Search, but in a cell on he right. >Then move the Search+Reset buttons to the left of Help. Ok, it is done. I am pretty happy with how it is developing, though it is not perfect. It is now to the point where I am spending a little too much time fiddling around with little html quirks so that everything wil display right, which is out of my area of expertise. I should probably leave those things to an html wizard. John > >Gary > >On Tue, 30 Jan 2001, John Pane wrote: > >> Gary, >> >> I have implemented all of the following: >> >> > > * trim leading and trailing spaces >> > > * replace embedded spaces with dot or semicolon >> replace with dot for now, subject to further discussion >> >> > > * possibly implement year ranges >> string must be exactly NNNN-NNNN, limits range to 50 years >> >> >Example change "include" to "display" >> >> >How about dropping the Help to size=2 and slipping it in between the slots >> >and the Search button? Try the Help label over the Reset, and the text >> >under the slots >> >> >> The following is not done yet. If it were up to me, I would not >> include it, but feel free to override me: >> >Do you think the record type limiter should be included? >> >It could be done as radio buttons. >> >> >> John >> >> >> >> >> On 1/30/01, Gary PERLMAN wrote: >> >For implementation, I think I'll probably code it in the form handler, >> >but JavaScript is okay for now. >> > >> >How about dropping the Help to size=2 and slipping it in between the slots >> >and the Search button? Try the Help label over the Reset, and the text >> >under the slots >> > >> >Example change "include" to "display" >> > >> >Do you think the record type limiter should be included? >> >It could be done as radio buttons. >> > >> >The fun with spaces might wait until log analysis. >> > >> >Gary >> > >> >On Tue, 30 Jan 2001, John Pane wrote: >> > >> >> Gary, >> >> >> >> I have implemented the changes you suggest below. >> >> >> >> I think we are converging. Here are some things that aren't done yet: >> >> * trim leading and trailing spaces >> >> * replace embedded spaces with dot or semicolon >> >> * possibly implement year ranges >> >> * integrate it into the hcibib >> >> >> >> John >> >> >> >> >> >> On 1/30/01, Gary PERLMAN wrote: >> >> >It works for me. >> >> >I'd drop the numbers. >> >> >Change "include" to "Display" or "Retrieve" (the latter may be > > >>too jargony). >> >> > >> >> >I find the Help awkward. It does not use the same terminology as >> >>in the form. >> >> > For a record to match, ALL rows of search boxes must match. >> >> > To match a row, ANY of the search boxes in the row can match. >> >> > Blank boxes and lines are ignored. >> >> > >> >> >I'd put the Reset button next to the Search button, and move your >> >>name over. >> >> > >> >> >I'd add a label to the glipse version at the bottom, like: >> >> > Glimpse search engine syntax: >> >> > >> >> >On Tue, 30 Jan 2001, John Pane wrote: >> >> > >> >> >> Gary, >> >> >> >> >> >> Here is another attempt. >> >> >> http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ >> >> >> >> >> >> John >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 1/30/01, Gary PERLMAN wrote: >> >> >> >I think that is CNF (a conjuct of disjunctions). >> >> >> > >> >> >> >I think e.g., would be better than i.e., >> >> >> >but I am a little wary of the mysterious labels. >> >> >> >The numbers are clear enough, but what are the parentheses >> >> >> >and and the commas? Is the first box a name for the line >> >> >> >and the others are the actual values? >> >> >> > >> >> >> >Then, in the instructions, the term "or" might be confusing. >> >> >> > >> >> >> >I'd allow for more smaller boxes. You have three size=30 boxes. >> >> >> >I'd go with four size=15. >> >> >> > >> >> >> >The prompt: "Find records that match all of" could be put on >> >> >> >any search form, so I'd move it closer to the action. >> >> >> >Maybe somthing like: >> >> >> > >> >> >> >match any [__________] [__________] [__________] [__________] >> >> >> > >> >> >> > with >> >> >> > >> >> >> >match any [__________] [__________] [__________] [__________] >> >> >> > >> >> >> > with >> >> >> > >> >> >> >match any [__________] [__________] [__________] [__________] >> >> >> > >> >> >> > >> >> >> >Half the screen is help that I doubt users will read. >> >> >> >I think you can put in one example, such as: >> >> >> > >> >> >> >color colour >> >> >> >coding highlight visual search >> >> >> >1996 1997 1998 1999 >> >> >> > >> >> >> >(actually, parsing NNNN-NNNN and creating a date range >>would be nice). >> >> >> > >> >> >> >I've have printed your papers. >> >> >> > >> >> >> >Gary >> >> >> > >> >> >> >On Tue, 30 Jan 2001, John Pane wrote: >> >> >> > >> >> >> >> On 1/27/01, John Pane wrote: >> >> >> >> >First, each form is implicitly an abstraction of a record >> >>(or a page >> > > >> >> >or a document). Therefore I think people naturally >>expect that all >> >> >> >> >the terms on a form must be present in a record for it to >> >>match. The >> >> >> >> >words at the top of the form reinforce this. >> >> >> >> > >> >> >> >> >Second, the clear boundary between the forms helps >>people to keep >> >> >> >> >straight which dimension is conjunction and which dimension is >> >> >> >> >disjunction. Again, the words on the top help with this. >> >> >> >> > >> >> >> >> >I think it would be good to try to preserve these >> >>features. This may >> >> >> >> >be challenging if we decide to use conjunctive normal >> >>form, but I am >> >> >> >> >open to exploring it. >> >> >> >> >> >> >> >> With these points in mind, I have created another >>design that uses >> >> >> >> DNF. I'd appreciate your thoughts. I haven't yet >>implemented some of >> >> >> >> the other ideas we've been discussing. >> >> >> > > http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ >> >> >> >> >> >> >> >> John >> >> >> >> >> >> >> >> > > >> From perlman@turing.acm.org Wed Jan 31 08:47:36 2001 -0500 Return-Path: Received: from localhost (perlman@localhost) by turing.acm.org (8.11.0/8.8.7) with ESMTP id f0VDlX800420; Wed, 31 Jan 2001 08:47:33 -0500 Date: Wed, 31 Jan 2001 08:47:33 -0500 (EST) From: Gary PERLMAN To: John Pane cc: Gary perlman Subject: Re: Form-based queries for the HCI Bibliography In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 14 The example search is really cute. I think you have got a great idea there. I wonder if it can be applied in other systems. With no paying customers to complain, release can be independent of testing. On the other hand, releasing yet another UI to the HCI community with no usability testing seems undesirable. I'll take your word on the lines. One option when it is integrated is to 1. remove the red "Search" 2. Move "Search interface by: John Pane" under my "Cobbled" line possibly with the John Pane link leading to a page specifically on these efforts, background research, etc (i.e., one link). I'm going to a seminar this morning, so I can finish your papers. On the type limiter -- I admit to being overly optimistic here -- the initial prompt could read: Display [any type of record][v] if it but I suspect the trickiness might end up confusing. One thing to think about is how to integrate two user interfaces. The current one has the box, but shows a lot of options. I think it takes up the same space as the matrix. Perhaps the matrix could be the default, to which I would add an option to show options, perhaps showing current option settings (e.g., highlight, whole word). There are no interleaved comments below. On Wed, 31 Jan 2001, John Pane wrote: > On 1/30/01, Gary PERLMAN wrote: > >I am afraid the "." is a problem. I keep on getting zero hits. > >So please remove the ".". > > Ok, it is done. > > > >I like the date ranges a lot. You could also match: > > NNNN- > >and fill in the current year (or 2001 if you are losing steam). > > Ok, it is done; and it determines the correct year to use. > > > >For me, the most common reason for not searching from > >the HCIBIB home page is that it does not have a type limiter. > >But I am not your average user. I'll check the logs to see > >if I am the only person in the world to use it. Could be. > > Ok, let me know what you determine. > > > >I'd like to pass the design around ot some people here > >to get comments. And I may run some impromptu usability tests. > >Is that okay with you? > > Sure. Comments and usability testing would be great. Hopefully it > won't delay the release for too long. > > > >I keep wondering if the example should not be a separate form > >with the values filled in. It could even work. Then I wonder > >if the default form should come up with a real query (which > >would require users to click reset, so it might have problems). > > Another possibility is to have an "Example" link, which fills in the > slots when you click it. I have implemented this for you to try and > see if you like it. > > > >I'd start "display a record if it" with "Display". > > Ok, it is done. > > > >Maybe drop the longer horizontal rules (I am a space fanatic). > > I tried it without these horizontal rules and it didn't look as good > to me. I would prefer to leave them in, if that would be ok with you. > > > >Maybe move the "Simple search by..." up to the top of the form > >on the same line as Search, but in a cell on he right. > >Then move the Search+Reset buttons to the left of Help. > > Ok, it is done. > > > I am pretty happy with how it is developing, though it is not > perfect. It is now to the point where I am spending a little too much > time fiddling around with little html quirks so that everything wil > display right, which is out of my area of expertise. I should > probably leave those things to an html wizard. > > > John > > > > > > > >Gary > > > >On Tue, 30 Jan 2001, John Pane wrote: > > > >> Gary, > >> > >> I have implemented all of the following: > >> > >> > > * trim leading and trailing spaces > >> > > * replace embedded spaces with dot or semicolon > >> replace with dot for now, subject to further discussion > >> > >> > > * possibly implement year ranges > >> string must be exactly NNNN-NNNN, limits range to 50 years > >> > >> >Example change "include" to "display" > >> > >> >How about dropping the Help to size=2 and slipping it in between the slots > >> >and the Search button? Try the Help label over the Reset, and the text > >> >under the slots > >> > >> > >> The following is not done yet. If it were up to me, I would not > >> include it, but feel free to override me: > >> >Do you think the record type limiter should be included? > >> >It could be done as radio buttons. > >> > >> > >> John > >> > >> > >> > >> > >> On 1/30/01, Gary PERLMAN wrote: > >> >For implementation, I think I'll probably code it in the form handler, > >> >but JavaScript is okay for now. > >> > > >> >How about dropping the Help to size=2 and slipping it in between the slots > >> >and the Search button? Try the Help label over the Reset, and the text > >> >under the slots > >> > > >> >Example change "include" to "display" > >> > > >> >Do you think the record type limiter should be included? > >> >It could be done as radio buttons. > >> > > >> >The fun with spaces might wait until log analysis. > >> > > >> >Gary > >> > > >> >On Tue, 30 Jan 2001, John Pane wrote: > >> > > >> >> Gary, > >> >> > >> >> I have implemented the changes you suggest below. > >> >> > >> >> I think we are converging. Here are some things that aren't done yet: > >> >> * trim leading and trailing spaces > >> >> * replace embedded spaces with dot or semicolon > >> >> * possibly implement year ranges > >> >> * integrate it into the hcibib > >> >> > >> >> John > >> >> > >> >> > >> >> On 1/30/01, Gary PERLMAN wrote: > >> >> >It works for me. > >> >> >I'd drop the numbers. > >> >> >Change "include" to "Display" or "Retrieve" (the latter may be > > > >>too jargony). > >> >> > > >> >> >I find the Help awkward. It does not use the same terminology as > >> >>in the form. > >> >> > For a record to match, ALL rows of search boxes must match. > >> >> > To match a row, ANY of the search boxes in the row can match. > >> >> > Blank boxes and lines are ignored. > >> >> > > >> >> >I'd put the Reset button next to the Search button, and move your > >> >>name over. > >> >> > > >> >> >I'd add a label to the glipse version at the bottom, like: > >> >> > Glimpse search engine syntax: > >> >> > > >> >> >On Tue, 30 Jan 2001, John Pane wrote: > >> >> > > >> >> >> Gary, > >> >> >> > >> >> >> Here is another attempt. > >> >> >> http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ > >> >> >> > >> >> >> John > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> On 1/30/01, Gary PERLMAN wrote: > >> >> >> >I think that is CNF (a conjuct of disjunctions). > >> >> >> > > >> >> >> >I think e.g., would be better than i.e., > >> >> >> >but I am a little wary of the mysterious labels. > >> >> >> >The numbers are clear enough, but what are the parentheses > >> >> >> >and and the commas? Is the first box a name for the line > >> >> >> >and the others are the actual values? > >> >> >> > > >> >> >> >Then, in the instructions, the term "or" might be confusing. > >> >> >> > > >> >> >> >I'd allow for more smaller boxes. You have three size=30 boxes. > >> >> >> >I'd go with four size=15. > >> >> >> > > >> >> >> >The prompt: "Find records that match all of" could be put on > >> >> >> >any search form, so I'd move it closer to the action. > >> >> >> >Maybe somthing like: > >> >> >> > > >> >> >> >match any [__________] [__________] [__________] [__________] > >> >> >> > > >> >> >> > with > >> >> >> > > >> >> >> >match any [__________] [__________] [__________] [__________] > >> >> >> > > >> >> >> > with > >> >> >> > > >> >> >> >match any [__________] [__________] [__________] [__________] > >> >> >> > > >> >> >> > > >> >> >> >Half the screen is help that I doubt users will read. > >> >> >> >I think you can put in one example, such as: > >> >> >> > > >> >> >> >color colour > >> >> >> >coding highlight visual search > >> >> >> >1996 1997 1998 1999 > >> >> >> > > >> >> >> >(actually, parsing NNNN-NNNN and creating a date range > >>would be nice). > >> >> >> > > >> >> >> >I've have printed your papers. > >> >> >> > > >> >> >> >Gary > >> >> >> > > >> >> >> >On Tue, 30 Jan 2001, John Pane wrote: > >> >> >> > > >> >> >> >> On 1/27/01, John Pane wrote: > >> >> >> >> >First, each form is implicitly an abstraction of a record > >> >>(or a page > >> > > >> >> >or a document). Therefore I think people naturally > >>expect that all > >> >> >> >> >the terms on a form must be present in a record for it to > >> >>match. The > >> >> >> >> >words at the top of the form reinforce this. > >> >> >> >> > > >> >> >> >> >Second, the clear boundary between the forms helps > >>people to keep > >> >> >> >> >straight which dimension is conjunction and which dimension is > >> >> >> >> >disjunction. Again, the words on the top help with this. > >> >> >> >> > > >> >> >> >> >I think it would be good to try to preserve these > >> >>features. This may > >> >> >> >> >be challenging if we decide to use conjunctive normal > >> >>form, but I am > >> >> >> >> >open to exploring it. > >> >> >> >> > >> >> >> >> With these points in mind, I have created another > >>design that uses > >> >> >> >> DNF. I'd appreciate your thoughts. I haven't yet > >>implemented some of > >> >> >> >> the other ideas we've been discussing. > >> >> >> > > http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ > >> >> >> >> > >> >> >> >> John > >> >> >> >> > >> >> >> > >> > > > >> > From perlman@turing.acm.org Wed Jan 31 09:55:10 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0VEt9g03230 for ; Wed, 31 Jan 2001 09:55:10 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa00076; 31 Jan 2001 9:55 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Wed, 31 Jan 2001 09:55:11 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 15 Hi Gary, I played around a little: http://www.cs.cmu.edu/~pane/www.hcibib.org/v3/ John On 1/31/01, Gary PERLMAN wrote: >The example search is really cute. I think you have got a great idea there. >I wonder if it can be applied in other systems. > >With no paying customers to complain, release can be independent of testing. >On the other hand, releasing yet another UI to the HCI community with >no usability testing seems undesirable. > >I'll take your word on the lines. One option when it is integrated is to > 1. remove the red "Search" > 2. Move "Search interface by: John Pane" under my "Cobbled" line > possibly with the John Pane link leading to a page specifically > on these efforts, background research, etc (i.e., one link). > >I'm going to a seminar this morning, so I can finish your papers. > >On the type limiter -- I admit to being overly optimistic here -- >the initial prompt could read: > Display [any type of record][v] if it >but I suspect the trickiness might end up confusing. > >One thing to think about is how to integrate two user interfaces. >The current one has the box, but shows a lot of options. >I think it takes up the same space as the matrix. >Perhaps the matrix could be the default, to which I would >add an option to show options, perhaps showing current option >settings (e.g., highlight, whole word). > >There are no interleaved comments below. > >On Wed, 31 Jan 2001, John Pane wrote: > >> On 1/30/01, Gary PERLMAN wrote: >> >I am afraid the "." is a problem. I keep on getting zero hits. >> >So please remove the ".". >> >> Ok, it is done. >> >> >> >I like the date ranges a lot. You could also match: >> > NNNN- >> >and fill in the current year (or 2001 if you are losing steam). >> >> Ok, it is done; and it determines the correct year to use. >> >> >> >For me, the most common reason for not searching from >> >the HCIBIB home page is that it does not have a type limiter. >> >But I am not your average user. I'll check the logs to see >> >if I am the only person in the world to use it. Could be. >> >> Ok, let me know what you determine. >> >> >> >I'd like to pass the design around ot some people here >> >to get comments. And I may run some impromptu usability tests. >> >Is that okay with you? >> >> Sure. Comments and usability testing would be great. Hopefully it >> won't delay the release for too long. >> >> >> >I keep wondering if the example should not be a separate form >> >with the values filled in. It could even work. Then I wonder >> >if the default form should come up with a real query (which >> >would require users to click reset, so it might have problems). >> >> Another possibility is to have an "Example" link, which fills in the >> slots when you click it. I have implemented this for you to try and >> see if you like it. >> >> >> >I'd start "display a record if it" with "Display". >> >> Ok, it is done. >> >> >> >Maybe drop the longer horizontal rules (I am a space fanatic). >> >> I tried it without these horizontal rules and it didn't look as good >> to me. I would prefer to leave them in, if that would be ok with you. >> >> >> >Maybe move the "Simple search by..." up to the top of the form >> >on the same line as Search, but in a cell on he right. >> >Then move the Search+Reset buttons to the left of Help. >> >> Ok, it is done. >> >> >> I am pretty happy with how it is developing, though it is not >> perfect. It is now to the point where I am spending a little too much >> time fiddling around with little html quirks so that everything wil >> display right, which is out of my area of expertise. I should >> probably leave those things to an html wizard. >> >> >> John >> >> >> >> >> > >> >Gary >> > >> >On Tue, 30 Jan 2001, John Pane wrote: >> > >> >> Gary, >> >> >> >> I have implemented all of the following: >> >> >> >> > > * trim leading and trailing spaces >> >> > > * replace embedded spaces with dot or semicolon >> >> replace with dot for now, subject to further discussion >> >> >> >> > > * possibly implement year ranges >> >> string must be exactly NNNN-NNNN, limits range to 50 years > > >> >> >> >Example change "include" to "display" >> >> >> >> >How about dropping the Help to size=2 and slipping it in >>between the slots >> >> >and the Search button? Try the Help label over the Reset, and the text >> >> >under the slots >> >> >> >> >> >> The following is not done yet. If it were up to me, I would not >> >> include it, but feel free to override me: >> >> >Do you think the record type limiter should be included? >> >> >It could be done as radio buttons. >> >> >> >> >> >> John >> >> >> >> >> >> >> >> >> >> On 1/30/01, Gary PERLMAN wrote: >> >> >For implementation, I think I'll probably code it in the form handler, >> >> >but JavaScript is okay for now. >> >> > >> >> >How about dropping the Help to size=2 and slipping it in >>between the slots >> >> >and the Search button? Try the Help label over the Reset, and the text >> >> >under the slots >> >> > >> >> >Example change "include" to "display" >> >> > >> >> >Do you think the record type limiter should be included? >> >> >It could be done as radio buttons. >> >> > >> >> >The fun with spaces might wait until log analysis. >> >> > >> >> >Gary >> >> > >> >> >On Tue, 30 Jan 2001, John Pane wrote: >> >> > >> >> >> Gary, >> >> >> >> >> >> I have implemented the changes you suggest below. >> >> >> >> >> >> I think we are converging. Here are some things that >>aren't done yet: >> >> >> * trim leading and trailing spaces >> >> >> * replace embedded spaces with dot or semicolon >> >> >> * possibly implement year ranges >> >> >> * integrate it into the hcibib >> >> >> >> >> >> John >> >> >> >> >> >> >> >> >> On 1/30/01, Gary PERLMAN wrote: >> >> >> >It works for me. >> >> >> >I'd drop the numbers. >> >> >> >Change "include" to "Display" or "Retrieve" (the latter may be >> > > >>too jargony). >> >> >> > >> >> >> >I find the Help awkward. It does not use the same terminology as >> >> >>in the form. >> >> >> > For a record to match, ALL rows of search boxes must match. >> >> >> > To match a row, ANY of the search boxes in the row can match. >> >> >> > Blank boxes and lines are ignored. >> >> >> > >> >> >> >I'd put the Reset button next to the Search button, and move your >> >> >>name over. >> >> >> > >> >> >> >I'd add a label to the glipse version at the bottom, like: >> >> >> > Glimpse search engine syntax: >> >> >> > >> >> >> >On Tue, 30 Jan 2001, John Pane wrote: >> >> >> > >> >> >> >> Gary, >> >> >> >> >> >> >> >> Here is another attempt. >> >> >> >> http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ >> >> >> >> >> >> >> >> John >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 1/30/01, Gary PERLMAN wrote: >> >> >> >> >I think that is CNF (a conjuct of disjunctions). >> >> >> >> > >> >> >> >> >I think e.g., would be better than i.e., >> >> >> >> >but I am a little wary of the mysterious labels. >> >> >> >> >The numbers are clear enough, but what are the parentheses >> >> >> >> >and and the commas? Is the first box a name for the line >> >> >> >> >and the others are the actual values? >> >> >> >> > >> >> >> >> >Then, in the instructions, the term "or" might be confusing. >> >> >> >> > >> >> >> >> >I'd allow for more smaller boxes. You have three >>size=30 boxes. >> >> >> >> >I'd go with four size=15. >> >> >> >> > >> >> >> >> >The prompt: "Find records that match all of" could be put on >> >> >> >> >any search form, so I'd move it closer to the action. >> >> >> >> >Maybe somthing like: >> >> >> >> > >> >> >> >> >match any [__________] [__________] [__________] [__________] >> >> >> >> > >> >> >> >> > with >> >> >> >> > >> >> >> >> >match any [__________] [__________] [__________] [__________] >> >> >> >> > >> >> >> >> > with >> >> >> >> > >> >> >> >> >match any [__________] [__________] [__________] [__________] >> >> >> >> > >> >> >> >> > >> >> >> >> >Half the screen is help that I doubt users will read. >> >> >> >> >I think you can put in one example, such as: >> >> >> >> > >> >> >> >> >color colour > > >> >> >> >coding highlight visual search >> >> >> >> >1996 1997 1998 1999 >> >> >> >> > >> >> >> >> >(actually, parsing NNNN-NNNN and creating a date range >> >>would be nice). >> >> >> >> > >> >> >> >> >I've have printed your papers. >> >> >> >> > >> >> >> >> >Gary >> >> >> >> > >> >> >> >> >On Tue, 30 Jan 2001, John Pane wrote: >> >> >> >> > >> >> >> >> >> On 1/27/01, John Pane wrote: >> >> >> >> >> >First, each form is implicitly an abstraction of a record >> >> >>(or a page >> >> > > >> >> >or a document). Therefore I think people naturally >> >>expect that all >> >> >> >> >> >the terms on a form must be present in a record for it to >> >> >>match. The >> >> >> >> >> >words at the top of the form reinforce this. >> >> >> >> >> > >> >> >> >> >> >Second, the clear boundary between the forms helps >> >>people to keep >> >> >> >> >> >straight which dimension is conjunction and which >>dimension is >> >> >> >> >> >disjunction. Again, the words on the top help with this. >> >> >> >> >> > >> >> >> >> >> >I think it would be good to try to preserve these >> >> >>features. This may >> >> >> >> >> >be challenging if we decide to use conjunctive normal >> >> >>form, but I am >> >> >> >> >> >open to exploring it. >> >> >> >> >> >> >> >> >> >> With these points in mind, I have created another >> >>design that uses >> >> >> >> >> DNF. I'd appreciate your thoughts. I haven't yet >> >>implemented some of >> >> >> >> >> the other ideas we've been discussing. >> >> >> >> > > http://www.cs.cmu.edu/~pane/www.hcibib.org/v2/ >> >> >> >> >> >> >> >> >> >> John >> >> >> >> >> >> >> >> >> >> >> > > >> >> >> From perlman@turing.acm.org Wed Jan 31 14:33:13 2001 -0500 Return-Path: Received: from localhost (perlman@localhost) by turing.acm.org (8.11.0/8.8.7) with ESMTP id f0VJX7D11228; Wed, 31 Jan 2001 14:33:07 -0500 Date: Wed, 31 Jan 2001 14:33:07 -0500 (EST) From: Gary PERLMAN To: John Pane cc: Gary perlman Subject: Re: Form-based queries for the HCI Bibliography In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 16 Hi John, I am going through the search logs for the HCIBIB. Here are some very basic stats about HCIBIB queries. Pleaase feel free to suggest any analyses. Gary LINES WORDS CHARS 441988 681663 7339471 main file with 441988 searches 10148 20170 402628 curly braces (complex queries) 66383 116325 1623796 ; AND 14720 31641 625195 , OR 139988 379696 3214546 ' ' (space for adjacency) Many "searches" are constructed for the user, such as from a table of contents to a specific article: 105623 105901 1441707 conference paper bookmark "C.*" 48177 48316 683792 journal article bookmark "J.*" So about a third of all searches are for these single items. Only 10K searches out of the 300K others have curly braces, used for grouping. The most frequent are listed here: 440 {{hypertext,hypermedia,{world;wide;web}};{usability,usable}} 362 {software localization,software localisation,internationalization,internationalisation,globalization,globalisation,intercultural} 281 {assistive,disab,impair,handic,special need,accessibility:} 280 {hypertext,hypermedia,{world;wide;web}} 256 {groupware,CSCW,{{cooperative work,collaborative work,collaboration};supported}} 220 {gui,{graphical;interface},WIMP};{guidelines,guideline,standard,standards} 104 {William,Bill};Buxton 93 {library;catalog},{catalog;search},opac,{public access catalog} 79 {Stuart,S\. K\.};Card 74 {keyboard,typing};{performance;skill} 65 {hypertext,hypermedia,{world;wide;web}};http: 64 {Brian,B\. R\.};Gaines 58 {1990,1991};%P 1 56 {Tom,Thomas};Moran 52 {Jim,James,James D\.};Foley 48 {David,Dave};Woods 42 {Bill,William};Hefley 39 {Thomas,T\. K\.};Landauer 38 {Tom,Thomas};Hewett 37 {groupware,CSCW,{{cooperative work,collaborative work,collaboration};supported}};http: 36 Marilyn;{Mantei,Tremaine} 34 {Tom,T\.};Carey 26 {Constantine,C\.};Stephanidis 21 {William,Bill}; Buxton 19 {task analysis} 19 {hypertext,hypermedia,{world;wide;web}};isbn: 19 {documentation,C\.DOC,J\.SIGDOC,technical\ writ,online\ help} 17 {color,colour};{visual search,coding,highlight} 16 {software localization,software localisation,internationalization,internationalisation,globalization,globalisation,intercultural};isbn 16 {learning,teaching,training,tutor,education,instruction};{intelligent,expert,agent};{1995,1996,1997,1998} 15 {Stuart,S\. K\.}; Card 15 {assistive,disab,impair,handic,special need,accessibility:};isbn 12 {{John Pane}} Most are canned searches I put together, and almost all the rest are canned searches for authors (from the authors.html page). There are many searches for categories of internet resources. 841 education:programs 715 hci-sites:people 477 publications:columns 428 publications:acm_sigchi 417 hci-sites:journals 302 hci-sites:resources 230 accessibility:guidelines 221 publications:journals 213 kids: 208 hci-sites:companies 206 intercultural: 185 hci-sites:bibliography 182 publications:digital_library 135 publications:publishers 129 hci-sites:consultants 121 kids:chi_kids_experience 121 education:resources 120 kids:research 111 hci-sites:columns 104 intercultural:books 101 hci-sites:journal 100 hci-sites:laboratories 94 hci-sites:mail 90 kids:organizations 89 hci-sites:people 88 kids:resources 88 intercultural:usability 85 accessibility:papers 84 hci-sites:newsgroups 83 intercultural:resources 82 kids:sigchi_resources 81 kids:sites 80 accessibility:discussion 78 education:acm_sigchi 78 accessibility:resources 77 intercultural:character_set 76 accessibility:organizations 74 intercultural:mail 71 intercultural:translation 71 intercultural:companies 70 intercultural:marketing 70 intercultural:date_format 69 intercultural:standards 68 intercultural:dictionary 66 intercultural:examples 59 hci-sites:indexes 56 education:courses 51 education:mail 49 hci-sites:organizations 45 hci-sites:events 42 http: 41 hci-sites:people;perlman 40 education:general_program_information 39 hci-sites:publishers 17 accessibility: 15 http:;disabilities 14 hci-sites:people/gs.html 13 education:programs/gs.html 11 disabilities:resources 9 accessibility:companies Thousands of searches use more common syntax, for which they get a warning message: LINES WORDS CHARS 1477 4062 46544 parentheses 6436 28400 210151 AND 216 1052 7104 OR 64 303 1892 NOT 1398 2832 28376 + I now see that I did not log the use of the type limiter. :-( From perlman@turing.acm.org Wed Jan 31 15:11:50 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f0VKBog12430 for ; Wed, 31 Jan 2001 15:11:50 -0500 Received: from RUNNER.PC.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa04804; 31 Jan 2001 15:11 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Wed, 31 Jan 2001 15:11:24 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 17 On 1/31/01, Gary PERLMAN wrote: >I am going through the search logs for the HCIBIB. >Here are some very basic stats about HCIBIB queries. >Pleaase feel free to suggest any analyses. Here are few things that come to mind: * can you filter out all of the canned queries, so we can see what users are actually typing into the search dialog box? * if so, can you then count how many have: no operators, semicolon as the outermost operator, and comma as the outermost operator? I'll spend more time looking at this later. Thanks, John From perlman@turing.acm.org Thu Feb 1 22:03:43 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f1233hg31892 for ; Thu, 1 Feb 2001 22:03:43 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa18332; 1 Feb 2001 22:03 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Thu, 1 Feb 2001 22:03:34 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 18 Hi Gary, >I added the logging of the type limiter. >Out of about 500 searches today, 90 had type limits. >Of those, I saw none that did not look like canned queries. >So, it appears that I am the only person who uses them. It is great that you could get the data to answer the question so quickly! Did you have a chance to look at the relative prevalence of CNF vs DNF in the non-canned queries? Both my wife and Brad thought the CNF form was less clear than the DNF one. Of course, all three of us are biased because we became familiar with the earlier match forms. I don't know what your resources are for user-testing, but it would be interesting to compare them head-to-head. Another interesting question is: when the users include a period in a query, do they really want the dot operator? I'll bet that a large portion of these are intended to be literal periods, such as after a person's middle initial. A person unfamiliar with glimpse (or unix-style conventions) would not know to escape the operator with a backslash. I was wondering what would happen if we escaped the periods for them. This would seriously limit the page for those who really want the dot operator, unless we chose a less-common character for this operator. Almost any symbol would be better than a period because they all are less likely to be used accidentally. Of course, this would be a less important issue if the dot operator was not buggy. Also, it occurred to me that the least-frequent queries in the logs may be the most interesting because they are more likely to be user-constructed, and that is also where the buggy queries will probably be found. Another check that could be added to the code: remove the comma & semicolon operators if they appear at the beginning or end of a query string. >On the one-click example: One drawback is that it >clears old values from the screen. One way out is to >show the example when the user hovers over the example >link. Right now, my link opens a new window with the >example query. With the hover solution, they would not be able to submit the query and see the results. For that reason, the separate window may be better. >I am almost done integrating the matrix into the real search. >Most of the time was reorganizing my badly organized code. >Now I am working on figuring out where to put options. >I should have something to show you this weekend >and then can make changes for a release next week. I'm looking forward to seeing it. John >On Wed, 31 Jan 2001, John Pane wrote: > >> On 1/31/01, Gary PERLMAN wrote: >> >I am going through the search logs for the HCIBIB. >> >Here are some very basic stats about HCIBIB queries. >> >Pleaase feel free to suggest any analyses. >> >> Here are few things that come to mind: >> >> * can you filter out all of the canned queries, so we can see what >> users are actually typing into the search dialog box? >> * if so, can you then count how many have: no operators, semicolon >> as the outermost operator, and comma as the outermost operator? >> >> I'll spend more time looking at this later. >> >> Thanks, >> John >> From perlman@turing.acm.org Fri Feb 2 22:28:54 2001 -0500 Return-Path: Received: from localhost (perlman@localhost) by turing.acm.org (8.11.0/8.8.7) with ESMTP id f133Sq712165; Fri, 2 Feb 2001 22:28:52 -0500 Date: Fri, 2 Feb 2001 22:28:52 -0500 (EST) From: Gary PERLMAN To: John Pane cc: Gary perlman Subject: Re: Form-based queries for the HCI Bibliography In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: A X-Keywords: X-UID: 19 On Thu, 1 Feb 2001, John Pane wrote: > Hi Gary, > > >I added the logging of the type limiter. > >Out of about 500 searches today, 90 had type limits. > >Of those, I saw none that did not look like canned queries. > >So, it appears that I am the only person who uses them. > > It is great that you could get the data to answer the question so quickly! > > Did you have a chance to look at the relative prevalence of CNF vs > DNF in the non-canned queries? Both my wife and Brad thought the CNF > form was less clear than the DNF one. Of course, all three of us are > biased because we became familiar with the earlier match forms. I > don't know what your resources are for user-testing, but it would be > interesting to compare them head-to-head. I'll work on that analysis. My intuition is that for searching bibliographic databases, people are focused on (1) known items, and (2) specific topics. For the latter, I think people are interested in the intersection of more general topics, where each topic is represented by the union of the names used for that topic. So if I am interested in expert systems for aiding information retrieval, I would do best to look for all items on expert systems, rule-based systems, ai, etc., and for the intersection with terms like query, search, information retrieval, online public access catalogs (OPACS), etc. Perhaps an intersection of unions would do best for multiple known items, but so would keeping bookmarks. I think you oculd come up with tasks that would favor either, but I suspect that the tasks that would favor DNF would be more artificial that those that would favor CNF. While I think your study in: http://www.cs.cmu.edu/~pane/ftp/PaneMyersTabularTextual.pdf showed benefits of removing syntax and of removing the ambiguities of AND and OR, I do not think the task had much to do with search as much as, say, creating a valid boolean expression in a program. Can you come up with some unions of intersections that would be useful queries on the HCIBIB? Looking through the canned queries (search for u.hcibib), they tended to be big unions, ecept perhaps for the CSCW links for: CSCW or groupware or (computer.supported and (cooperative or collaborative) and work) Looking through the canned queries, even four alternatives may not be enough, but I would be pleased to see some users get into column 2. > Another interesting question is: when the users include a period in a > query, do they really want the dot operator? I'll bet that a large > portion of these are intended to be literal periods, such as after a > person's middle initial. A person unfamiliar with glimpse (or > unix-style conventions) would not know to escape the operator with a > backslash. I was wondering what would happen if we escaped the > periods for them. This would seriously limit the page for those who > really want the dot operator, unless we chose a less-common character > for this operator. Almost any symbol would be better than a period > because they all are less likely to be used accidentally. Of course, > this would be a less important issue if the dot operator was not > buggy. I doubt if many people know that the . means "any char". If they literlly mean ".", then the dot will match it, and generlaly, coming back with too many items is not a problem. I do worry, however, about wildcards causing bugs in glimpse. > Also, it occurred to me that the least-frequent queries in the logs > may be the most interesting because they are more likely to be > user-constructed, and that is also where the buggy queries will > probably be found. I think the medium frequency queries would be the most useful. A single query may be intruiging, but it will not test a theory. It may motivate a test for patterns across all queries. > Another check that could be added to the code: remove the comma & > semicolon operators if they appear at the beginning or end of a query > string. I think I've seen semi-colons at the end of queries, but have not looked for commas. > >On the one-click example: One drawback is that it > >clears old values from the screen. One way out is to > >show the example when the user hovers over the example > >link. Right now, my link opens a new window with the > >example query. > > With the hover solution, they would not be able to submit the query > and see the results. For that reason, the separate window may be > better. Still, I think there is something worth exporing there. > >I am almost done integrating the matrix into the real search. > >Most of the time was reorganizing my badly organized code. > >Now I am working on figuring out where to put options. > >I should have something to show you this weekend > >and then can make changes for a release next week. > > I'm looking forward to seeing it. Me too. I am tracking a bug right now that sends back a blank screen. Clean, but not useful. > John > > > > >On Wed, 31 Jan 2001, John Pane wrote: > > > >> On 1/31/01, Gary PERLMAN wrote: > >> >I am going through the search logs for the HCIBIB. > >> >Here are some very basic stats about HCIBIB queries. > >> >Pleaase feel free to suggest any analyses. > >> > >> Here are few things that come to mind: > >> > >> * can you filter out all of the canned queries, so we can see what > >> users are actually typing into the search dialog box? > >> * if so, can you then count how many have: no operators, semicolon > >> as the outermost operator, and comma as the outermost operator? > >> > >> I'll spend more time looking at this later. > >> > >> Thanks, > >> John > >> > From perlman@turing.acm.org Sat Feb 3 12:08:07 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f13H82g16311 for ; Sat, 3 Feb 2001 12:08:06 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa01101; 3 Feb 2001 12:07 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sat, 3 Feb 2001 12:07:56 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 20 Hi Gary, Responding to both of your recent messages here...it is looking good...see comments below. On 2/2/01, Gary PERLMAN wrote: > > Did you have a chance to look at the relative prevalence of CNF vs >> DNF in the non-canned queries? Both my wife and Brad thought the CNF >> form was less clear than the DNF one. Of course, all three of us are >> biased because we became familiar with the earlier match forms. I >> don't know what your resources are for user-testing, but it would be >> interesting to compare them head-to-head. > >I'll work on that analysis. My intuition is that for searching >bibliographic databases, people are focused on (1) known items, >and (2) specific topics. For the latter, I think people are >interested in the intersection of more general topics, >where each topic is represented by the union of the names >used for that topic. So if I am interested in expert systems >for aiding information retrieval, I would do best to look >for all items on expert systems, rule-based systems, ai, etc., >and for the intersection with terms like query, search, >information retrieval, online public access catalogs (OPACS), etc. >Perhaps an intersection of unions would do best for multiple >known items, but so would keeping bookmarks. I assume you meant union of intersections in that last sentence. A third possibility is that some people just type in keywords and expect them to be intersected. This is the way most web search engines work, and I'd guess many people search the web a lot more frequently than they search bibliographic databases. If a new user comes into the hcibib, they may unconsciously expect that it will work the same as these search engines. For this type of user, the DNF forms may better match their expectations. But I agree completely that CNF is better for experienced searchers, and that may be reason enough to use it. >I think you oculd come up with tasks that would favor either, >but I suspect that the tasks that would favor DNF would be >more artificial that those that would favor CNF. >While I think your study in: > http://www.cs.cmu.edu/~pane/ftp/PaneMyersTabularTextual.pdf >showed benefits of removing syntax and of removing the ambiguities >of AND and OR, I do not think the task had much to do with search >as much as, say, creating a valid boolean expression in a program. Granted. That is one reason why I am excited to be able to apply the ideas here, and to assess their effectiveness on searching tasks. >Can you come up with some unions of intersections that would be >useful queries on the HCIBIB? Looking through the canned queries >(search for u.hcibib), they tended to be big unions, ecept perhaps >for the CSCW links for: > CSCW or groupware or > (computer.supported and (cooperative or collaborative) and work) >Looking through the canned queries, even four alternatives may not >be enough, but I would be pleased to see some users get into column 2. For searches that involve both operators (AND and OR), I trust your arguments and your intuition that DNF is best. The question is: how often do people type in this kind of search, as opposed to using canned queries? I'm thinking about the inexperienced users. For example, will they type their keywords all in one row, get union instead of intersection, and become frustrated because the results are not good matches? >I doubt if many people know that the . means "any char". >If they literlly mean ".", then the dot will match it, >and generlaly, coming back with too many items is not a problem. >I do worry, however, about wildcards causing bugs in glimpse. Until this bug is fixed, I propose that a dot be escaped so it only matches a period, and some other symbol be used to represent "any char". Maybe underscore? > > Also, it occurred to me that the least-frequent queries in the logs >> may be the most interesting because they are more likely to be >> user-constructed, and that is also where the buggy queries will >> probably be found. > >I think the medium frequency queries would be the most useful. >A single query may be intruiging, but it will not test a theory. >It may motivate a test for patterns across all queries. I think unique queries should not be discarded in the analysis. Without having seen the logs, I would guess that most user-generated queries are unique, and examining the patterns in these may be the most genuine way to see how people use the hcibib. > > Another check that could be added to the code: remove the comma & >> semicolon operators if they appear at the beginning or end of a query >> string. > >I think I've seen semi-colons at the end of queries, but have >not looked for commas. May as well trim them out, especially semicolons because they can cause the term to match the empty set if there is another expression after it. There is no valid reason to have them there, right? >The name I am using is "Tabular Form". >I found the name "Simple" non-descriptive and promotional. "Tabular Form" seems like it would be meaningless to most people. "Tabular Search" or "Search Form" are better. Or even just "Search", and call the original search "Advanced Search"? >Here are some problem areas: > >[1] Options: I would like to display options, and I had planned to show >them only if the user clicked an option button, but I ran out of >steam on some bugs in my maintaining state. So there they are. >The option for approximate match, and the . both fail when >combined with boolean logic, so the approximate match option >does not appear when the form is present. I think the options clutter up the page too much, and would prefer that they were not there until the user asked for them. If that is not possible due to bugs, I would just remove them completely from the Tabular Search page. I feel pretty strongly about this. If they must be present, I would make them smaller and put them under the Search and Clear buttons. I think "Whole Word" and "Highlight Terms" should be turned on by default. >[2] Which form to show: It depends on how the user arrives. Seems good. >case 1: Incoming terms=xyzzy > >If a user comes into the search form with a query, >e.g., a canned query, then old search box should appear >(one option is to parse the incoming query and fill >the Tabular Form, which I doubt I'll do; maybe the simple case >of no chars from [{};,] could be copies into the first cell). How about this: if there are no characters from [;,], then strip all characters from [{};,], and put the result into the first cell of the Tabular Search form. >When the old search box is displayed, we can still show the Tabular Form, >but then there is some ambiguity about the meaning of the form >(the way I have it set up, any values in the Tabular Form cause >the search box to be ignored, and the constructed query is >placed into the search box). It could be confusing to have both inputs available at the same time. If both boxes are filled in and the user changes the query in the wrong box, it will have no effect on the submitted query and they might not realize why. It would be nice if there were an easy way to switch back and forth between the two search forms. One idea is to put a tiny link below the form (outside the blue table), or something in the header region. >case 2: Incoming term00 (this is the form variable for the first cell) > >The Tabular Form is displayed. The check should really go through all >the cells. Yes, it would be best if it checked all of the cells. After forming a complicated query, the user should be able to clear the first cell and submit the search without unexpected repercussions. >[3] On-screen help text > >I showed your form to our top usability expert and his comments were: > * change the wording to "matches and of these terms" You actually have "matches any of these:". I think this is excellent. I think the "Tabular Search: Example" should be made much smaller, and moved to the bottom right corner of the form (right of the Search and Clear buttons). For one thing, where it is now it interferes with the flow of the sentence "Find a record if it matches any of these: ..." My wife suggests that "Find a record if it" should end with ellipsis or colon, for the same sentence flow reason. I'm not sure I agree, especially if the example is moved away, but I wanted to pass her comment along anyway. > * drop the Help because (1) users would not understand it, > (2) if they did, it would add nothing to their understanding, > (3) users would ignore it. Ok. In the header region, the Help link goes to a help page for the Advanced Search. Will there be a corresponding Help page for the Tabular Search? >[4] Layout > >It still looks like two designs on one screen. I need to do >some work with the options. The labels are confusing and >poorly aligned. See above: I would like for the options to be removed from the Tabular Search by default. >I think I need a few days away from it, and you might want a >few days with it, and then it's back to the drawing board. > >The URL: > http://www.hcibib.org/newgs.cgi >(The colors change for developoment versions, although I am >getting tired of the khaki and beige). This is going to be great! Thanks for your efforts on this. John From perlman@turing.acm.org Sat Feb 3 20:52:47 2001 -0500 Date: Sat, 3 Feb 2001 20:52:31 -0500 (EST) From: Gary PERLMAN To: John Pane Subject: Re: Form-based queries for the HCI Bibliography In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 21 On Sat, 3 Feb 2001, John Pane wrote: > Hi Gary, > > Responding to both of your recent messages here...it is looking > good...see comments below. > > On 2/2/01, Gary PERLMAN wrote: > > > Did you have a chance to look at the relative prevalence of CNF vs > >> DNF in the non-canned queries? Both my wife and Brad thought the CNF > >> form was less clear than the DNF one. Of course, all three of us are > >> biased because we became familiar with the earlier match forms. I > >> don't know what your resources are for user-testing, but it would be > >> interesting to compare them head-to-head. > > > >I'll work on that analysis. My intuition is that for searching > >bibliographic databases, people are focused on (1) known items, > >and (2) specific topics. For the latter, I think people are > >interested in the intersection of more general topics, > >where each topic is represented by the union of the names > >used for that topic. So if I am interested in expert systems > >for aiding information retrieval, I would do best to look > >for all items on expert systems, rule-based systems, ai, etc., > >and for the intersection with terms like query, search, > >information retrieval, online public access catalogs (OPACS), etc. > >Perhaps an intersection of unions would do best for multiple > >known items, but so would keeping bookmarks. > > I assume you meant union of intersections in that last sentence. Yes, I was thinking about the terms so much I lost all meaning. > A third possibility is that some people just type in keywords and > expect them to be intersected. This is the way most web search > engines work, and I'd guess many people search the web a lot more > frequently than they search bibliographic databases. If a new user > comes into the hcibib, they may unconsciously expect that it will > work the same as these search engines. For this type of user, the DNF > forms may better match their expectations. But I agree completely > that CNF is better for experienced searchers, and that may be reason > enough to use it. I look at summaries of millions of searches a year, and it's sobering. The best strategy I can attach to what users expect is that they will type relatively few terms and the results will be rank ordered by what's important to them (as though the search engine can read minds). But most queries are 1-2 words and match way too many items to review. Then users (again assuming that the search engine is smarter than it is) look through the first page of results, and maybe a second, out of thousands retrieved. I think Google's and Amazon's ranking methods are clever enough that they do read minds, by using usage data. > >I think you oculd come up with tasks that would favor either, > >but I suspect that the tasks that would favor DNF would be > >more artificial that those that would favor CNF. > >While I think your study in: > > http://www.cs.cmu.edu/~pane/ftp/PaneMyersTabularTextual.pdf > >showed benefits of removing syntax and of removing the ambiguities > >of AND and OR, I do not think the task had much to do with search > >as much as, say, creating a valid boolean expression in a program. > > Granted. That is one reason why I am excited to be able to apply the > ideas here, and to assess their effectiveness on searching tasks. > > > >Can you come up with some unions of intersections that would be > >useful queries on the HCIBIB? Looking through the canned queries > >(search for u.hcibib), they tended to be big unions, ecept perhaps > >for the CSCW links for: > > CSCW or groupware or > > (computer.supported and (cooperative or collaborative) and work) > >Looking through the canned queries, even four alternatives may not > >be enough, but I would be pleased to see some users get into column 2. > > For searches that involve both operators (AND and OR), I trust your > arguments and your intuition that DNF is best. The question is: how > often do people type in this kind of search, as opposed to using > canned queries? I'm thinking about the inexperienced users. For > example, will they type their keywords all in one row, get union > instead of intersection, and become frustrated because the results > are not good matches? There is some independence of the layout and the semantics. So, the terms in a column could be ORed, then columns could be ANDed. That would still be CNF, but with a different layout. The tab order could be made to go either way. > >I doubt if many people know that the . means "any char". > >If they literlly mean ".", then the dot will match it, > >and generlaly, coming back with too many items is not a problem. > >I do worry, however, about wildcards causing bugs in glimpse. > > Until this bug is fixed, I propose that a dot be escaped so it only > matches a period, and some other symbol be used to represent "any > char". Maybe underscore? The problem is that glimpse returns no items when combining any wildcards and booleans. It would be nice if glimpse would let me change the wldcard character, but it does not. I am wary of replacing characters, but I think it might be worth escaping the dots in the Tabular Form. TODO: Gary - escape the dots in Tabular Form > > > Also, it occurred to me that the least-frequent queries in the logs > >> may be the most interesting because they are more likely to be > >> user-constructed, and that is also where the buggy queries will > >> probably be found. > > > >I think the medium frequency queries would be the most useful. > >A single query may be intruiging, but it will not test a theory. > >It may motivate a test for patterns across all queries. > > I think unique queries should not be discarded in the analysis. > Without having seen the logs, I would guess that most user-generated > queries are unique, and examining the patterns in these may be the > most genuine way to see how people use the hcibib. The distribution of queries, after you pass the canned queries, is that about half the queries are unique, and you learn plenty from queries in the 2-20 frequency range. Going to the unique queries, by hand, is really tedious (we are talking about over 50,000) unless you run a script looking for something. TODO: Gary - more log analysis > > > Another check that could be added to the code: remove the comma & > >> semicolon operators if they appear at the beginning or end of a query > >> string. > > > >I think I've seen semi-colons at the end of queries, but have > >not looked for commas. > > May as well trim them out, especially semicolons because they can > cause the term to match the empty set if there is another expression > after it. There is no valid reason to have them there, right? TODO: Gary - more cleanup of Tabular form > >The name I am using is "Tabular Form". > >I found the name "Simple" non-descriptive and promotional. > > "Tabular Form" seems like it would be meaningless to most people. > "Tabular Search" or "Search Form" are better. Or even just "Search", > and call the original search "Advanced Search"? In FirstSearch, Basic search is a single box, Advanced search has several slots, and Expert search has a big text area. Most searches in FirstSearch are from Advanced search, and few are from Expert. I'd like a name that was descriptive either of the display (I took Tabular from one of your papers), or of the logic (e.g., Combination search). I do not have stong feelings on this, except I don't want to call it something that makes a claim (e.g., Simple search). TODO: John - new name > >Here are some problem areas: > > > >[1] Options: I would like to display options, and I had planned to show > >them only if the user clicked an option button, but I ran out of > >steam on some bugs in my maintaining state. So there they are. > >The option for approximate match, and the . both fail when > >combined with boolean logic, so the approximate match option > >does not appear when the form is present. > > I think the options clutter up the page too much, and would prefer > that they were not there until the user asked for them. If that is > not possible due to bugs, I would just remove them completely from > the Tabular Search page. I feel pretty strongly about this. > > If they must be present, I would make them smaller and put them under > the Search and Clear buttons. > > I think "Whole Word" and "Highlight Terms" should be turned on by default. I agree about the clutter. I think they can be presented conditionally, but I need to get the bugs out. TODO: Gary - work on optional presetation and layout of options > >[2] Which form to show: It depends on how the user arrives. > > Seems good. > > > >case 1: Incoming terms=xyzzy > > > >If a user comes into the search form with a query, > >e.g., a canned query, then old search box should appear > >(one option is to parse the incoming query and fill > >the Tabular Form, which I doubt I'll do; maybe the simple case > >of no chars from [{};,] could be copies into the first cell). > > How about this: if there are no characters from [;,], then strip all > characters from [{};,], and put the result into the first cell of the > Tabular Search form. That may work. TODO: Gary - work on ways to migrate queries from one box > >When the old search box is displayed, we can still show the Tabular Form, > >but then there is some ambiguity about the meaning of the form > >(the way I have it set up, any values in the Tabular Form cause > >the search box to be ignored, and the constructed query is > >placed into the search box). > > It could be confusing to have both inputs available at the same time. > If both boxes are filled in and the user changes the query in the > wrong box, it will have no effect on the submitted query and they > might not realize why. It would be very confusing. > It would be nice if there were an easy way to switch back and forth > between the two search forms. One idea is to put a tiny link below > the form (outside the blue table), or something in the header region. Without adding a parser, it is very hard to go back and forth. > >case 2: Incoming term00 (this is the form variable for the first cell) > > > >The Tabular Form is displayed. The check should really go through all > >the cells. > > Yes, it would be best if it checked all of the cells. After forming a > complicated query, the user should be able to clear the first cell > and submit the search without unexpected repercussions. TODO: Gary - check all cells > >[3] On-screen help text > > > >I showed your form to our top usability expert and his comments were: > > * change the wording to "matches and of these terms" > > You actually have "matches any of these:". I think this is excellent. adding "terms" made it a little wide, so I dropped it. > I think the "Tabular Search: Example" should be made much smaller, > and moved to the bottom right corner of the form (right of the Search > and Clear buttons). For one thing, where it is now it interferes with > the flow of the sentence "Find a record if it matches any of these: > ..." I have been trying to find a home for the example. I was meandering to having a title for the form along with an example. I suspect that only I would know. TODO: Gary - move the Example > My wife suggests that "Find a record if it" should end with ellipsis > or colon, for the same sentence flow reason. I'm not sure I agree, > especially if the example is moved away, but I wanted to pass her > comment along anyway. TODO: Gary add ellipses to first line of form. > > * drop the Help because (1) users would not understand it, > > (2) if they did, it would add nothing to their understanding, > > (3) users would ignore it. > > Ok. > > In the header region, the Help link goes to a help page for the > Advanced Search. Will there be a corresponding Help page for the > Tabular Search? People do not use it much, but it would make sense to go to a different place. > >[4] Layout > > > >It still looks like two designs on one screen. I need to do > >some work with the options. The labels are confusing and > >poorly aligned. > > See above: I would like for the options to be removed from the > Tabular Search by default. > > > >I think I need a few days away from it, and you might want a > >few days with it, and then it's back to the drawing board. > > > >The URL: > > http://www.hcibib.org/newgs.cgi > >(The colors change for developoment versions, although I am > >getting tired of the khaki and beige). > > This is going to be great! Thanks for your efforts on this. It may be great. I've worked on too many features to be too hopeful, but some sort of attack on the gimpse/boolean syntax seems worthwhile. TODO: Gary - add a marker so we can easily gets stats on which UI is used From perlman@turing.acm.org Sat Feb 3 21:21:28 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f142L6g20590 for ; Sat, 3 Feb 2001 21:21:28 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa03913; 3 Feb 2001 21:20 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sat, 3 Feb 2001 21:20:35 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 22 On 2/3/01, Gary PERLMAN wrote: >I'd like a name that was descriptive either of the display (I took >Tabular from one of your papers), or of the logic (e.g., Combination >search). I do not have stong feelings on this, except I don't want >to call it something that makes a claim (e.g., Simple search). > >TODO: John - new name Ok, how about if we go with "Tabular Search" until one of us comes up with a better idea? > > It would be nice if there were an easy way to switch back and forth >> between the two search forms. One idea is to put a tiny link below >> the form (outside the blue table), or something in the header region. > >Without adding a parser, it is very hard to go back and forth. First, this link could from one search page to the other without filling anything in. But, if we decide it is important to try to copy the query, it is very simple to go from the Tabular Search to the advanced search. Going the other way, we've already discussed the simple case ("if there are no characters from [;,], then strip all characters from [{};,]"). In the more complex cases, we could punt (make the form blank) or put the entire glimpse query into the first slot. > > I think the "Tabular Search: Example" should be made much smaller, >> and moved to the bottom right corner of the form (right of the Search >> and Clear buttons). For one thing, where it is now it interferes with >> the flow of the sentence "Find a record if it matches any of these: >> ..." > >I have been trying to find a home for the example. >I was meandering to having a title for the form >along with an example. I suspect that only I would know. Making a title bar at the top of the form, with "Tabular Search" on the left, and the example to the right, sounds like a reasonable solution. John From perlman@turing.acm.org Sat Feb 3 21:25:45 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f142PNg20644 for ; Sat, 3 Feb 2001 21:25:44 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa03934; 3 Feb 2001 21:25 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sat, 3 Feb 2001 21:25:35 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 23 On 2/3/01, Gary PERLMAN wrote: >The problem is that glimpse returns no items when combining any wildcards >and booleans. It would be nice if glimpse would let me change the >wldcard character, but it does not. I am wary of replacing characters, >but I think it might be worth escaping the dots in the Tabular Form. > >TODO: Gary - escape the dots in Tabular Form There is one unfortunate problem with escaping the dots. The results page gives a diagnostic message about literal spaces and parenthetically suggests that they be replaced with dots. This of course would not work if the dot are escaped. Since dot is buggy, maybe that parenthetical suggestion to use dot should be removed from the diagnostic message? John From perlman@turing.acm.org Sun Feb 4 10:57:42 2001 -0500 Return-Path: Received: from localhost (perlman@localhost) by turing.acm.org (8.11.0/8.8.7) with ESMTP id f14FvfR29552; Sun, 4 Feb 2001 10:57:41 -0500 Date: Sun, 4 Feb 2001 10:57:41 -0500 (EST) From: Gary PERLMAN To: John Pane cc: Gary perlman Subject: Re: Form-based queries for the HCI Bibliography In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 24 As a start, for the tabular search form, I am not reporting glimpse checks in the form. They are sitll reported after the results, so there are still come issues. TODO: Gary - change suggestions for tabular search form On Sat, 3 Feb 2001, John Pane wrote: > On 2/3/01, Gary PERLMAN wrote: > >The problem is that glimpse returns no items when combining any wildcards > >and booleans. It would be nice if glimpse would let me change the > >wldcard character, but it does not. I am wary of replacing characters, > >but I think it might be worth escaping the dots in the Tabular Form. > > > >TODO: Gary - escape the dots in Tabular Form > > There is one unfortunate problem with escaping the dots. The results > page gives a diagnostic message about literal spaces and > parenthetically suggests that they be replaced with dots. This of > course would not work if the dot are escaped. Since dot is buggy, > maybe that parenthetical suggestion to use dot should be removed from > the diagnostic message? > > John > From perlman@turing.acm.org Sun Feb 4 12:07:02 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f14H71g29850 for ; Sun, 4 Feb 2001 12:07:01 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa07763; 4 Feb 2001 12:06 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sun, 4 Feb 2001 12:06:51 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 25 Gary, It is looking very good! >I put the example with the buttons. What do you think? I like it. >I got the options on/off button working, cleaned up the options display. This is much better! Is it possible to eliminate the trailing "|" after the list of options that are set? Did you decide that you do not want to turn on "whole word" and "highlight terms" by default? I have an idea for a slight simplification to your options layout. Please look at this link to see a non-functional illustration of what the two situations might look like: http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ This changes the button into a link and moves it down and renames it to "show/hide options". >As a start, for the tabular search form, I am not reporting glimpse >checks in the form. They are sitll reported after the results, >so there are still come issues. This is much better. John From perlman@turing.acm.org Sun Feb 4 15:30:18 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f14KUHg30983 for ; Sun, 4 Feb 2001 15:30:17 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa09010; 4 Feb 2001 15:30 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sun, 4 Feb 2001 15:30:07 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: X-Keywords: X-UID: 26 > > I have an idea for a slight simplification to your options layout. >> Please look at this link to see a non-functional illustration of what >> the two situations might look like: > > http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ >> This changes the button into a link and moves it down and renames it >> to "show/hide options". > >Putting it on the form submit maintains the data in the form. >I tried putting the sbmit button into the options section, >but it looks odd everyehere. I could do something with JavaScript, >but then it would not maintain data. I think the submit can be done with regular links and maintain the data in the form. See if this does what you need: http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ John From perlman@turing.acm.org Sun Feb 4 15:37:49 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f14Kbmg31013 for ; Sun, 4 Feb 2001 15:37:48 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa09101; 4 Feb 2001 15:37 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sun, 4 Feb 2001 15:37:38 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 27 On 2/4/01, John Pane wrote: >> > I have an idea for a slight simplification to your options layout. >>> Please look at this link to see a non-functional illustration of what >>> the two situations might look like: >> > http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ >>> This changes the button into a link and moves it down and renames it >>> to "show/hide options". >> >>Putting it on the form submit maintains the data in the form. >>I tried putting the sbmit button into the options section, >>but it looks odd everyehere. I could do something with JavaScript, >>but then it would not maintain data. > >I think the submit can be done with regular links and maintain the >data in the form. See if this does what you need: > http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ Also you may be able to put the javascript code into onClick="", so that you can have a url that does something useful in href="" for people who don't have javascript. John From perlman@turing.acm.org Sun Feb 4 17:21:20 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f14MLJg31572 for ; Sun, 4 Feb 2001 17:21:19 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa09760; 4 Feb 2001 17:21 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sun, 4 Feb 2001 17:21:23 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 28 On 2/4/01, Gary PERLMAN wrote: >The links do an okay job but miss any changes in the form. >JavaScript, which covers most users, could cover that case. >I think that right now, I'm too lazy. :-( I understand if you are getting burned out on this. It is very good as it is. Unless I am overlooking something, my test page does indeed preserve any changes that I make to the form before I click the options links. There is no auxiliary javascript code, just what is in the href (or the onSubmit) fields of the . John > >On Sun, 4 Feb 2001, John Pane wrote: > >> On 2/4/01, John Pane wrote: >> >> > I have an idea for a slight simplification to your options layout. >> >>> Please look at this link to see a non-functional illustration of what >> >>> the two situations might look like: >> >> > http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ >> >>> This changes the button into a link and moves it down and renames it >> >>> to "show/hide options". >> >> >> >>Putting it on the form submit maintains the data in the form. >> >>I tried putting the sbmit button into the options section, >> >>but it looks odd everyehere. I could do something with JavaScript, >> >>but then it would not maintain data. >> > >> >I think the submit can be done with regular links and maintain the >> >data in the form. See if this does what you need: >> > http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ >> >> >> Also you may be able to put the javascript code into onClick="", so >> that you can have a url that does something useful in href="" for >> people who don't have javascript. >> >> John >> From perlman@turing.acm.org Sun Feb 4 17:52:51 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f14Mqog31788 for ; Sun, 4 Feb 2001 17:52:50 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa09941; 4 Feb 2001 17:52 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sun, 4 Feb 2001 17:52:53 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 29 On 2/4/01, Gary PERLMAN wrote: >The changes that are not preserved are ones that are made >after the form is displayed. So if the user goes to >a blank form and enters a query, and says "Hey, I'd like >to see more options", clicking the options link will show >the options and lose the query they just entered. This is strange. I have tried this in my browsers (Netscape and Internet Explorer on the Macintosh), and in all cases the changes to the form are shown on the form after I click the "Show Options" or "Hide Options" links. I am using the test page at: http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ >Maybe with the layout work I did yesterday, the options >button could go under the options section. > >But I am running out of steam on this. > >I think I'll circulate it to our UI list at OCLC. >It has about 55 people on it, and sometimes people >give good comments. I am very interested to hear what they have to say. Thank you again for all of your efforts on this! John >On Sun, 4 Feb 2001, John Pane wrote: > >> On 2/4/01, Gary PERLMAN wrote: >> >The links do an okay job but miss any changes in the form. >> >JavaScript, which covers most users, could cover that case. >> >I think that right now, I'm too lazy. :-( >> >> I understand if you are getting burned out on this. It is very >>good as it is. >> >> Unless I am overlooking something, my test page does indeed preserve >> any changes that I make to the form before I click the options links. >> There is no auxiliary javascript code, just what is in the href (or >> the onSubmit) fields of the . >> >> John >> >> >> >> > >> >On Sun, 4 Feb 2001, John Pane wrote: >> > >> >> On 2/4/01, John Pane wrote: >> >> >> > I have an idea for a slight simplification to your options layout. >> >> >>> Please look at this link to see a non-functional >>illustration of what >> >> >>> the two situations might look like: >> >> >> > http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ >> >> >>> This changes the button into a link and moves it down and >>renames it >> >> >>> to "show/hide options". >> >> >> >> >> >>Putting it on the form submit maintains the data in the form. >> >> >>I tried putting the sbmit button into the options section, >> >> >>but it looks odd everyehere. I could do something with JavaScript, >> >> >>but then it would not maintain data. >> >> > >> >> >I think the submit can be done with regular links and maintain the >> >> >data in the form. See if this does what you need: >> >> > http://www.cs.cmu.edu/~pane/www.hcibib.org/test/ >> >> >> >> >> >> Also you may be able to put the javascript code into onClick="", so >> >> that you can have a url that does something useful in href="" for >> >> people who don't have javascript. >> >> >> >> John >> >> >> From perlman@turing.acm.org Sun Feb 4 17:53:05 2001 -0500 Return-Path: Received: from oa1-server.oa.oclc.org (oa1-server.oa.oclc.org [132.174.29.60]) by turing.acm.org (8.11.0/8.8.7) with ESMTP id f14Mr4g31794 for ; Sun, 4 Feb 2001 17:53:05 -0500 Received: from OA3-SERVER (oa3-server.oa.oclc.org [132.174.29.62]) by oa1-server.oa.oclc.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1G2NQ0A6; Sun, 4 Feb 2001 17:53:27 -0500 Received: from OCLC.ORG by OCLC.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 7272 for UI@OCLC.ORG; Sun, 4 Feb 2001 17:53:27 -0500 Received: by oa1-server.oa.oclc.org with Internet Mail Service (5.5.2653.19) id <1G2NQ0AZ>; Sun, 4 Feb 2001 17:53:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Approved-By: "Perlman,Gary" Message-ID: Date: Sun, 4 Feb 2001 17:53:26 -0500 Reply-To: "Perlman,Gary" Sender: OCLC User Interface Announcements and Requests for Comment From: "Perlman,Gary" Subject: tabular search form To: UI@OCLC.ORG Status: RO X-Status: X-Keywords: X-UID: 30 John Pane, a grad student at CMU, proposed a tabular search form for the HCI Bibliography. It can be viewed in an unadvertised URL: http://hcibib.org/newgs.cgi It is supposed to (1) hide the boolean syntax of the glimpse search engine, and (2) help users with confusions of ANDs and ORs in boolean queries, issues FirstSearch users face to some degree. If you have any comments or suggestions, please send them to me. From perlman@turing.acm.org Sun Feb 4 19:37:51 2001 -0500 Return-Path: Received: from run.amulet.cs.cmu.edu (RUN.AMULET.CS.CMU.EDU [128.2.222.38]) by turing.acm.org (8.11.0/8.8.7) with SMTP id f150bpg32340 for ; Sun, 4 Feb 2001 19:37:51 -0500 Received: from DUATHLON.REM.CS.CMU.EDU by run.amulet.cs.cmu.edu id aa10545; 4 Feb 2001 19:38 EST Mime-Version: 1.0 X-Sender: pane@ux6.sp.cs.cmu.edu Message-Id: In-Reply-To: References: X-HomePage: http://www.cs.cmu.edu/~pane/ Date: Sun, 4 Feb 2001 19:38:07 -0500 To: Gary PERLMAN From: John Pane Subject: Re: Form-based queries for the HCI Bibliography Content-Type: text/plain; charset="us-ascii" ; format="flowed" Status: RO X-Status: A X-Keywords: X-UID: 31 On 2/4/01, Gary PERLMAN wrote: >Oh. I see. You are using JavaScript to make the link >act like a form submit. That would work for most users. >So the link could show the options, but be a real link >to use the state when the form was loaded, with an >onClick event handler to do the form submit. >Judging by the decreasing font size of the link, >it seems you are really irriated by the button. >I really don't think it's a big deal, >so I would prefer to wait for comments. >I'm guessing that if it is irritating, someone will comment. I wouldn't say that I am irritated by the button, just that it seems a little misplaced and the labels (on the button and in front of the options themselves) seem redundant. But these are very minor points. Overall, I am very happy with the current version. (One note in case we do re-visit the issue: I could not get the onClick handler to work correctly. I don't know if I was doing something wrong, or if there is a limitation there. Maybe a better solution would be to embed the button in