Journal:Design of generalized search interfaces for health informatics - Revision history

Shawndouglas: Fixed deprecated parameters

2021-10-06T18:30:42Z

Fixed deprecated parameters

← Older revision		Revision as of 18:30, 6 October 2021
Line 134:		Line 134:
	Harvey ''et al.''<ref name=":18" /> show that in domains with complex vocabularies, such as health and medicine, the disparity of potential users’ prior knowledge is extreme. They find that non-expert users routinely do not possess enough domain knowledge to address their information-seeking needs. This can cause significant issues during query formulation. As a result, non-expert users must first step away from their tool to learn specialized vocabulary before they can begin query building. Both Soldaini ''et al.''<ref>{{Cite journal \|last=Soldaini \|first=Luca \|last2=Yates \|first2=Andrew \|last3=Yom-Tov \|first3=Elad \|last4=Frieder \|first4=Ophir \|last5=Goharian \|first5=Nazli \|date=2015-07-16 \|title=Enhancing web search in the medical domain via query clarification \|url=https://doi.org/10.1007/s10791-015-9258-y \|journal=Information Retrieval Journal \|language=en \|volume=19 \|issue=1-2 \|pages=149–173 \|doi=10.1007/s10791-015-9258-y \|issn=1386-4564}}</ref> and Anderson and Wischgoll<ref>{{Cite journal \|last=Anderson \|first=James D \|last2=Wischgoll \|first2=Thomas \|date=2020-01-26 \|title=Visualization of Search Results of Large Document Sets \|url=https://www.ingentaconnect.com/content/ist/ei/2020/00002020/00000001/art00006;jsessionid=1ui77rulkmwwg.x-ic-live-03 \|journal=Electronic Imaging \|volume=2020 \|issue=1 \|pages=388–1–388-7 \|doi=10.2352/ISSN.2470-1173.2020.1.VDA-388}}</ref> describe that this issue can still affect even experts. This is because experts often must make assumptions when attuning to their tool.		Harvey ''et al.''<ref name=":18" /> show that in domains with complex vocabularies, such as health and medicine, the disparity of potential users’ prior knowledge is extreme. They find that non-expert users routinely do not possess enough domain knowledge to address their information-seeking needs. This can cause significant issues during query formulation. As a result, non-expert users must first step away from their tool to learn specialized vocabulary before they can begin query building. Both Soldaini ''et al.''<ref>{{Cite journal \|last=Soldaini \|first=Luca \|last2=Yates \|first2=Andrew \|last3=Yom-Tov \|first3=Elad \|last4=Frieder \|first4=Ophir \|last5=Goharian \|first5=Nazli \|date=2015-07-16 \|title=Enhancing web search in the medical domain via query clarification \|url=https://doi.org/10.1007/s10791-015-9258-y \|journal=Information Retrieval Journal \|language=en \|volume=19 \|issue=1-2 \|pages=149–173 \|doi=10.1007/s10791-015-9258-y \|issn=1386-4564}}</ref> and Anderson and Wischgoll<ref>{{Cite journal \|last=Anderson \|first=James D \|last2=Wischgoll \|first2=Thomas \|date=2020-01-26 \|title=Visualization of Search Results of Large Document Sets \|url=https://www.ingentaconnect.com/content/ist/ei/2020/00002020/00000001/art00006;jsessionid=1ui77rulkmwwg.x-ic-live-03 \|journal=Electronic Imaging \|volume=2020 \|issue=1 \|pages=388–1–388-7 \|doi=10.2352/ISSN.2470-1173.2020.1.VDA-388}}</ref> describe that this issue can still affect even experts. This is because experts often must make assumptions when attuning to their tool.

	There is growing research targeting the generation and application of mediation resources to help reduce the communication gap while using health informatics tools. Zeng ''et al.''<ref name=":14" /> investigate the development of consumer health vocabularies for reducing the discourse gap between lay people and medical information document sets. Furthermore, Soldaini ''et al.''<ref>{{Citation \|last=Soldaini \|first=Luca \|last2=Cohan \|first2=Arman \|last3=Yates \|first3=Andrew \|last4=Goharian \|first4=Nazli \|last5=Frieder \|first5=Ophir \|date=2015 \|editor-last=Hanbury \|editor-first=Allan \|editor2-last=Kazai \|editor2-first=Gabriella \|editor3-last=Rauber \|editor3-first=Andreas \|editor4-last=Fuhr \|editor4-first=Norbert \|title=Retrieving Medical Literature for Clinical Decision Support \|url=http://link.springer.com/10.1007/978-3-319-16354-3_59 \|work=Advances in Information Retrieval \|language=en \|publisher=Springer International Publishing \|place=Cham \|volume=9022 \|pages=538–549 \|doi=10.1007/978-3-319-16354-3_59 \|isbn=978-3-319-16353-6 \|~~access-date~~=2021-09-23}}</ref> explore the use of novel query computation strategies to improve the quality of medical literature retrieval during search tasks. In their quantitative study, they contrast models generated using combinations of algorithms, vocabularies, and feature weights, assessing the computational performance of different query reformulation techniques. The results of their study suggest “greatly improved retrieval performance” when utilizing combined machine learning and bridged vocabularies. More so, they provide insight regarding the quality of options that can support computational systems for health informatics search tasks.		There is growing research targeting the generation and application of mediation resources to help reduce the communication gap while using health informatics tools. Zeng ''et al.''<ref name=":14" /> investigate the development of consumer health vocabularies for reducing the discourse gap between lay people and medical information document sets. Furthermore, Soldaini ''et al.''<ref>{{Citation \|last=Soldaini \|first=Luca \|last2=Cohan \|first2=Arman \|last3=Yates \|first3=Andrew \|last4=Goharian \|first4=Nazli \|last5=Frieder \|first5=Ophir \|date=2015 \|editor-last=Hanbury \|editor-first=Allan \|editor2-last=Kazai \|editor2-first=Gabriella \|editor3-last=Rauber \|editor3-first=Andreas \|editor4-last=Fuhr \|editor4-first=Norbert \|title=Retrieving Medical Literature for Clinical Decision Support \|url=http://link.springer.com/10.1007/978-3-319-16354-3_59 \|work=Advances in Information Retrieval \|language=en \|publisher=Springer International Publishing \|place=Cham \|volume=9022 \|pages=538–549 \|doi=10.1007/978-3-319-16354-3_59 \|isbn=978-3-319-16353-6 \|accessdate=2021-09-23}}</ref> explore the use of novel query computation strategies to improve the quality of medical literature retrieval during search tasks. In their quantitative study, they contrast models generated using combinations of algorithms, vocabularies, and feature weights, assessing the computational performance of different query reformulation techniques. The results of their study suggest “greatly improved retrieval performance” when utilizing combined machine learning and bridged vocabularies. More so, they provide insight regarding the quality of options that can support computational systems for health informatics search tasks.

	From the above research, we can distill two criteria. First, designs should provide interactions that allow users to efficiently prepare, perform, assess, and adjust their machine learning to align with information-seeking objectives of search tasks. Second, designs should provide mediation opportunities that assist users in communicating information-seeking objectives into the domain-specific vocabulary of the document set.		From the above research, we can distill two criteria. First, designs should provide interactions that allow users to efficiently prepare, perform, assess, and adjust their machine learning to align with information-seeking objectives of search tasks. Second, designs should provide mediation opportunities that assist users in communicating information-seeking objectives into the domain-specific vocabulary of the document set.
Line 242:		Line 242:
	\|}		\|}

	A strength of the unstructured interface strategy is that it supports the use of any vocabulary during query building, allowing for the natural activation of common vocabulary during task performance, in alignment with DC4. Additionally, this removes the requirement for users to possess input expertise and control profiles that typically come with a structured interface strategy, per DC1 and DC4. Designers can still implement prompt and effective feedback during task performance, thereby supporting DC2. If the constraints, processes, and results of their task performance are effectively communicated in result representations, DC3 and DC4 can be well supported. However, by allowing for the direct use of common vocabulary in lieu of a presupposed controlled vocabulary, the unstructured interface strategy suffers where the structured interface strategy excels. That is, poor implementations of the unstructured interface strategy can produce interfaces that do not provide mediation for users to translate their common vocabulary into the domain-specific vocabulary. In doing so, users are not being helped in understanding how their query building has impacted their search performance. For example, these poorly implemented interfaces may take input literally and bring users directly to a result page without providing context as to how the results were found, negatively affecting DC1 and DC5. This potential for promoting weak alignment between user and information source can lead to a significant drop in the quality of search performance. This can be an especially important requirement to address for health informatics interfaces, as it has been found that users routinely struggle to craft effective query terms during their health-related search tasks.<ref name=":21">{{Citation \|last=Jimmy \|last2=Zuccon \|first2=Guido \|last3=Koopman \|first3=Bevan \|date=2018 \|editor-last=Pasi \|editor-first=Gabriella \|editor2-last=Piwowarski \|editor2-first=Benjamin \|editor3-last=Azzopardi \|editor3-first=Leif \|editor4-last=Hanbury \|editor4-first=Allan \|title=Choices in Knowledge-Base Retrieval for Consumer Health Search \|url=http://link.springer.com/10.1007/978-3-319-76941-7_6 \|work=Advances in Information Retrieval \|publisher=Springer International Publishing \|place=Cham \|volume=10772 \|pages=72–85 \|doi=10.1007/978-3-319-76941-7_6 \|isbn=978-3-319-76940-0 \|~~access-date~~=2021-09-23}}</ref>		A strength of the unstructured interface strategy is that it supports the use of any vocabulary during query building, allowing for the natural activation of common vocabulary during task performance, in alignment with DC4. Additionally, this removes the requirement for users to possess input expertise and control profiles that typically come with a structured interface strategy, per DC1 and DC4. Designers can still implement prompt and effective feedback during task performance, thereby supporting DC2. If the constraints, processes, and results of their task performance are effectively communicated in result representations, DC3 and DC4 can be well supported. However, by allowing for the direct use of common vocabulary in lieu of a presupposed controlled vocabulary, the unstructured interface strategy suffers where the structured interface strategy excels. That is, poor implementations of the unstructured interface strategy can produce interfaces that do not provide mediation for users to translate their common vocabulary into the domain-specific vocabulary. In doing so, users are not being helped in understanding how their query building has impacted their search performance. For example, these poorly implemented interfaces may take input literally and bring users directly to a result page without providing context as to how the results were found, negatively affecting DC1 and DC5. This potential for promoting weak alignment between user and information source can lead to a significant drop in the quality of search performance. This can be an especially important requirement to address for health informatics interfaces, as it has been found that users routinely struggle to craft effective query terms during their health-related search tasks.<ref name=":21">{{Citation \|last=Jimmy \|last2=Zuccon \|first2=Guido \|last3=Koopman \|first3=Bevan \|date=2018 \|editor-last=Pasi \|editor-first=Gabriella \|editor2-last=Piwowarski \|editor2-first=Benjamin \|editor3-last=Azzopardi \|editor3-first=Leif \|editor4-last=Hanbury \|editor4-first=Allan \|title=Choices in Knowledge-Base Retrieval for Consumer Health Search \|url=http://link.springer.com/10.1007/978-3-319-76941-7_6 \|work=Advances in Information Retrieval \|publisher=Springer International Publishing \|place=Cham \|volume=10772 \|pages=72–85 \|doi=10.1007/978-3-319-76941-7_6 \|isbn=978-3-319-76940-0 \|accessdate=2021-09-23}}</ref>

	====Query expansion interface strategy====		====Query expansion interface strategy====
Line 259:		Line 259:
	\|}		\|}

	A strength of the combined approach of the query expansion interface strategy is its strong efforts to eliminate the weaknesses associated with the structured and unstructured interface strategies while still maintaining their strengths. That is, by allowing the continued use of common vocabulary during the process of query building, users can have higher confidence about what the interface is asking of them, and what they are telling the interface to do, helping with DC4 and DC5. Furthermore, by integrating the use of mediating resources like ontologies, designers can demonstrate to users the quality of their query building and how their vocabulary decisions affect the performance of their search tasks, supporting DC2 and DC3.<ref>{{Citation \|last=Lüke \|first=Thomas \|last2=Schaer \|first2=Philipp \|last3=Mayr \|first3=Philipp \|date=2012 \|editor-last=Zaphiris \|editor-first=Panayiotis \|editor2-last=Buchanan \|editor2-first=George \|editor3-last=Rasmussen \|editor3-first=Edie \|editor4-last=Loizides \|editor4-first=Fernando \|title=Improving Retrieval Results with Discipline-Specific Query Expansion \|url=http://link.springer.com/10.1007/978-3-642-33290-6_44 \|work=Theory and Practice of Digital Libraries \|publisher=Springer Berlin Heidelberg \|place=Berlin, Heidelberg \|volume=7489 \|pages=408–413 \|doi=10.1007/978-3-642-33290-6_44 \|isbn=978-3-642-33289-0 \|~~access-date~~=2021-09-23}}</ref> Yet, with the added complexities of query expansion, computational systems may be required to perform more work before arriving at a final set of search results. Therefore, designers of systems taking advantage of query expansion should consider the impact on performance and responsiveness and counteract them to maintain alignment with DC2. For the query expansion interface strategy to be successful, designers must clearly communicate to users how exactly their query building has affected their search. If this communication is not provided, it can leave users confused regarding how their decisions have affected their search and can make it challenging for them to assess task performance, negatively affecting DC2. Such limitations may not provide optimal alignment in communication between the system, the user, and the information resource.<ref name=":21" />] That is, if a selected mediating resource does not provide an effective mapping between vocabularies, then query expansion can weaken the quality of search tasks. To address this challenge, designers can utilize user-supplied ontologies, as per DC1. This provides users the freedom to select mediating resources that they believe can best support their task performance, rather than being restricted to a tool-provided mediating resource. A user study by Jay ''et al.''<ref>{{Cite journal \|last=Jay \|first=Caroline \|last2=Harper \|first2=Simon \|last3=Dunlop \|first3=Ian \|last4=Smith \|first4=Sam \|last5=Sufi \|first5=Shoaib \|last6=Goble \|first6=Carole \|last7=Buchan \|first7=Iain \|date=2016-01-14 \|title=Natural Language Search Interfaces: Health Data Needs Single-Field Variable Search \|url=https://www.jmir.org/2016/1/e13 \|journal=Journal of Medical Internet Research \|language=EN \|volume=18 \|issue=1 \|pages=e4912 \|doi=10.2196/jmir.4912 \|pmc=PMC4731680 \|pmid=26769334}}</ref> compares users as they perform the same task set using two interfaces, one with a structured multiple variable input profile, the other with an unstructured single variable input profile. In this study, they find that users felt their needs and expectations were better fulfilled using the single-input profile, performing their tasks quicker, with more ease of use and learnability, and with a higher appraisal of results. Designers must carefully select how they activate query expansion such that it addresses the needs of the task, the information, and the user.		A strength of the combined approach of the query expansion interface strategy is its strong efforts to eliminate the weaknesses associated with the structured and unstructured interface strategies while still maintaining their strengths. That is, by allowing the continued use of common vocabulary during the process of query building, users can have higher confidence about what the interface is asking of them, and what they are telling the interface to do, helping with DC4 and DC5. Furthermore, by integrating the use of mediating resources like ontologies, designers can demonstrate to users the quality of their query building and how their vocabulary decisions affect the performance of their search tasks, supporting DC2 and DC3.<ref>{{Citation \|last=Lüke \|first=Thomas \|last2=Schaer \|first2=Philipp \|last3=Mayr \|first3=Philipp \|date=2012 \|editor-last=Zaphiris \|editor-first=Panayiotis \|editor2-last=Buchanan \|editor2-first=George \|editor3-last=Rasmussen \|editor3-first=Edie \|editor4-last=Loizides \|editor4-first=Fernando \|title=Improving Retrieval Results with Discipline-Specific Query Expansion \|url=http://link.springer.com/10.1007/978-3-642-33290-6_44 \|work=Theory and Practice of Digital Libraries \|publisher=Springer Berlin Heidelberg \|place=Berlin, Heidelberg \|volume=7489 \|pages=408–413 \|doi=10.1007/978-3-642-33290-6_44 \|isbn=978-3-642-33289-0 \|accessdate=2021-09-23}}</ref> Yet, with the added complexities of query expansion, computational systems may be required to perform more work before arriving at a final set of search results. Therefore, designers of systems taking advantage of query expansion should consider the impact on performance and responsiveness and counteract them to maintain alignment with DC2. For the query expansion interface strategy to be successful, designers must clearly communicate to users how exactly their query building has affected their search. If this communication is not provided, it can leave users confused regarding how their decisions have affected their search and can make it challenging for them to assess task performance, negatively affecting DC2. Such limitations may not provide optimal alignment in communication between the system, the user, and the information resource.<ref name=":21" />] That is, if a selected mediating resource does not provide an effective mapping between vocabularies, then query expansion can weaken the quality of search tasks. To address this challenge, designers can utilize user-supplied ontologies, as per DC1. This provides users the freedom to select mediating resources that they believe can best support their task performance, rather than being restricted to a tool-provided mediating resource. A user study by Jay ''et al.''<ref>{{Cite journal \|last=Jay \|first=Caroline \|last2=Harper \|first2=Simon \|last3=Dunlop \|first3=Ian \|last4=Smith \|first4=Sam \|last5=Sufi \|first5=Shoaib \|last6=Goble \|first6=Carole \|last7=Buchan \|first7=Iain \|date=2016-01-14 \|title=Natural Language Search Interfaces: Health Data Needs Single-Field Variable Search \|url=https://www.jmir.org/2016/1/e13 \|journal=Journal of Medical Internet Research \|language=EN \|volume=18 \|issue=1 \|pages=e4912 \|doi=10.2196/jmir.4912 \|pmc=PMC4731680 \|pmid=26769334}}</ref> compares users as they perform the same task set using two interfaces, one with a structured multiple variable input profile, the other with an unstructured single variable input profile. In this study, they find that users felt their needs and expectations were better fulfilled using the single-input profile, performing their tasks quicker, with more ease of use and learnability, and with a higher appraisal of results. Designers must carefully select how they activate query expansion such that it addresses the needs of the task, the information, and the user.

	==Results==		==Results==

Shawndouglas: Finished adding rest of content.

2021-09-24T16:10:54Z

Finished adding rest of content.

@@ Line 19: / Line 19: @@
 |download     = [https://www.mdpi.com/2078-2489/12/8/317/pdf https://www.mdpi.com/2078-2489/12/8/317/pdf] (PDF)
 }}
-{{ombox
 ==Abstract==
 In this paper, we investigate [[Ontology (information science)|ontology]]-supported interfaces for [[health informatics]] search tasks involving large document sets. We begin by providing background on health informatics, [[machine learning]], and ontologies. We review leading research on health informatics search tasks to help formulate high-level design criteria. We then use these criteria to examine traditional design strategies for search interfaces. To demonstrate the utility of the criteria, we apply them to the design of the ONTology-supported Search Interface (ONTSI), a demonstrative, prototype system. ONTSI allows users to plug-and-play document sets and expert-defined domain ontologies through a generalized search interface. ONTSI’s goal is to help align users’ common vocabulary with the domain-specific vocabulary of the plug-and-play document set. We describe the functioning and utility of ONTSI in health informatics search tasks through a [[workflow]] and a scenario. We conclude with a summary of ongoing evaluations, limitations, and future research.
@@ Line 534: / Line 529: @@
 <blockquote>('''G''') “Yeah, this (ontology) would have helped because I can find the things that … share in common, and that can make it probably much easier to find the relevant documents. Yeah, being able to see the things that certain phrases … or words share in common. You can find that common link … that can find you the relevant documents.”</blockquote>
 ==References==

Shawndouglas: Saving and adding more.

2021-09-24T16:02:22Z

Saving and adding more.

Show changes

Shawndouglas: Saving and adding more.

2021-09-23T23:49:14Z

Saving and adding more.

Show changes

Shawndouglas: Saving and adding more.

2021-09-23T23:11:41Z

Saving and adding more.

← Older revision		Revision as of 23:11, 23 September 2021
Line 267:		Line 267:

	==Results==		==Results==
			In this section we describe ONTSI, a generalized ontology-supported interface for health informatics search tasks involving large document sets created using the above-discussed criteria. We outline how the criteria were used to structure ONTSI’s design. We then discuss the technical scope of ONTSI, concluding with ONTSI’s functional workflow.

			===Design scope===
			Table 3 highlights the role of each criterion in the design of ONTSI.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="2" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 3.''' The role of each criterion within the design of ONTSI. The incorporation of these criteria in ONTSI’s implementation is discussed within the workflow and usage scenario.
			\|-
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|DC#
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|ONTSI implementation
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC1
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|ONTSI leverages powerful third-party computational technology. Specifically, pre-built machine learning packages like SciKit-Learn are integrated within ONTSI, and highly optimized indexing is provided by The Apache Software Foundation’s Solr product.<ref name="Solr">{{cite web \|url=https://solr.apache.org/ \|title=Apache Solr \|publisher=Apache Software Foundation \|accessdate=18 January 2021}}</ref> Additionally, ONTSI’s interface provides users with clear text-based alerts, which reflect their current performance status.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC2
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|ONTSI supports an iterative interaction loop to allow users perform repeated sets of search tasks. That is, within iterative interactions, users can save the results they regard relevant in a persistent location within the tool, while still allowing further performances to occur.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC3
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|ONTSI provides visual representations to help analyze and judge the relevance of search results.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC4
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|ONTSI utilizes modern visualization and computational technologies like D3.js to provide powerful interaction opportunities.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC5
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|ONTSI supports the use of a common vocabulary during query building using the query expansion strategy. Specifically, when using ONTSI, users upload both a document set and an ontology file, which are then integrated into the workflow of the computational systems of ONTSI. Users can interact with a search textbox that allows for unstructured text input. ONTSI provides domain-specific vocabulary suggestions that can assist users in guiding their performance and promote alignment between their vocabulary and domain-specific vocabulary.
			\|-
			\|}
			\|}

			===Technical scope===
			ONTSI is developed as a web-based tool that provides a generalized, plug-and-play support of user-supplied ontology files and document sets. That is, ONTSI allows for the uploading of ontology files, either individually or within a .zip compressed file, as well as any compressed document set in the .zip format. ONTSI then processes and indexes their contents for use within the interface. ONTSI’s front end uses the latest HTML5, CSS, and JavaScript technologies, allowing for cross-browser (i.e., Firefox, Chrome, Opera) and cross-platform support. The D3.js JavaScript library is used to create the visualization and interaction experiences found throughout the front end of ONTSI.<ref name="BostockD3js">{{cite web \|url=https://d3js.org/ \|title=D3.js \|author=Bostock, M. \|accessdate=18 January 2021}}</ref> ONTSI’s back-end technology is developed using a custom Python-based computational server that maintains data transfer and machine learning APIs, and with the use of Apache’s Solr system as the search indexer and engine.<ref name="Solr" /> The current ONTSI system maintains support for the live uploading of well-formed ontologies in the Ontology Web Language (OWL) format.

			===Functional workflow of ONTSI===
			ONTSI encompasses several subsystems and subviews within its workflow. Recalling the workflow description of a machine learning-integrated search tool, ONTSI allows:

			* users to communicate their task requirements as a query within its Upload and Search subview;
			* users to ask their tool to apply that query as input within its computational system within its Search Subview;
			* the tool to perform its computation, mapping the features against the document set within its ONTSI server and Solr server;
			* the tool to represent the results of the computation in its interface within its Result List and Result Item subviews;
			* users to assess whether they are or are not satisfied with the results within its Result List, Result Item, and Saved List subview; and
			* users to restart the interaction loop with adjustments within the Upload and Search subviews or conclude their use of the tool.

			The overall functional workflow of ONTSI and its parts are described now, as depicted in Figure 4.


			[[File:Fig4 Demelo Information21 12-8.png\|900px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="900px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure 4.''' Depiction of the functional workflow of ONTSI. Labelled arrows reflect the steps of the interaction loop. Brown boxes represent the processes performed within the back-end computation systems. Blue boxes represent the object types that persist within the browser and external index database storage. Pink boxes represent the back-end computational systems of ONTSI. Yellow boxes represent the various subviews within the front end of ONTSI. The green box represents the types of interactions that can be conducted with the system.</blockquote>
			\|-
			\|}
			\|}

Shawndouglas: Saving and adding more.

2021-09-23T22:55:41Z

Saving and adding more.

Show changes

Shawndouglas: Saving and adding more.

2021-09-23T22:25:08Z

Saving and adding more.

← Older revision		Revision as of 22:25, 23 September 2021
Line 216:		Line 216:

	====Structured interface strategy====		====Structured interface strategy====
			The structured interface strategy creates designs that regulate input during query building. This is achieved by maintaining heavily restricted input control profiles. Designers who implement the structured interface strategy into their interfaces presuppose a search task with specific expectations for input, bounding queries to a limited input profile. One common bounding technique is to constrain query lengths and limiting query content to a controlled set of terms.<ref>{{Cite journal \|last=Zielstorff, R.D. \|date= \|year=2003 \|title=Controlled vocabularies for consumer health \|url=https://www.sciencedirect.com/science/article/pii/S1532046403000960 \|journal=Journal of Biomedical Informatics \|language=en \|volume=36 \|issue=4-5 \|pages=326–333 \|doi=10.1016/j.jbi.2003.09.015 \|issn=1532-0464}}</ref> This restricted scope is considered the sole acceptable input profile, and thus it allows designers to generate interfaces that limit the possible range of inputs and restrict all inputs that fall outside of that range. Designers typically achieve this by using interface elements like dropdowns, checkboxes, and radio buttons instead of elements like text boxes with free typing. For example, Figure 1 depicts the PubMed Advance Search Builder, which implements the structured interface strategy in its design. This interface requires users to select specific query term types from a restricted list, which then guides user input.<ref>{{Cite web \|last=National Center for Biotechnology Information \|title=PubMed.gov \|url=https://pubmed.ncbi.nlm.nih.gov/ \|publisher=National Institutes of Health \|accessdate=18 January 2021}}</ref>


			[[File:Fig1 Demelo Information21 12-8.png\|900px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="900px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure 1.''' An example of a structured interface strategy for a search task in PubMed Advanced Search Builder. In this use case, a query item was generated for a MeSH term for heart abnormalities, a completion date after August 8, 2015, and in the English language, with the publisher of Oxford University Press soon to be added. Source: Image generated on 18 January 2021, using the [https://pubmed.ncbi.nlm.nih.gov/advanced/ public web portal] provided by the National Center for Biotechnical Information.</blockquote>
			\|-
			\|}
			\|}

			Since input control is restricted, a strength of the structured interface strategy is that designers can use information characteristics to prescribe the full range of query formulations. This allows for the use of representational and computational designs that optimize for the expected characteristics of the restricted input profiles, per DC2. This strategy provides a designer-friendly environment that is hardened against unwanted queries, which, if effectively communicated in the design of result representations, could allow for alignment with DC3 and DC4. Yet, it can be challenging to designers to use structured interface strategies in a generalized setting. This is because when a document set is swapped, hardened approaches may not align with the information characteristics of the new document set. This negatively affects the flexibility of the interface, and in turn alignment with DC1. A potential weakness of the structured interface strategy is that it requires users to possess expertise on both the controlled vocabulary of the interface as well as the vocabulary of the document set being searched. If this is not known, user experience can suffer, drastically affecting alignment with DC5. Within the context of health informatics, such weaknesses reduce the users’ ability to effectively perform search tasks. This is because the controlled vocabularies within the health and medical domains demand significant expertise and result in numerous points of failure during the query formation process.<ref>{{Cite journal \|last=McCray \|first=Alexa T. \|last2=Tse \|first2=Tony \|date=2003 \|title=Understanding Search Failures in Consumer Health Information Systems \|url=https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1479930/ \|journal=AMIA Annual Symposium Proceedings \|volume=2003 \|pages=430–434 \|issn=1942-597X \|pmc=1479930 \|pmid=14728209}}</ref><ref>{{Cite journal \|last=Keselman \|first=Alla \|last2=Browne \|first2=Allen C. \|last3=Kaufman \|first3=David R. \|date=2008-07-01 \|title=Consumer Health Information Seeking as Hypothesis Testing \|url=https://doi.org/10.1197/jamia.M2449 \|journal=Journal of the American Medical Informatics Association \|volume=15 \|issue=4 \|pages=484–495 \|doi=10.1197/jamia.M2449 \|issn=1067-5027 \|pmc=PMC2442260 \|pmid=18436912}}</ref>

			====Unstructured interface strategy====
			The unstructured interface strategy creates designs that provide limited input regulation. Unlike the structured interface strategy, it provides an open input control that accepts most input profiles during query building. Designers who implement the unstructured interface strategy do so without presupposing particular input, only accounting for general user error. That is, this input can originate from anywhere, such as common vocabulary, rather than from a pre-determined set of terms provided by the designer. Often, this input is directed to a single interface element. Implementations of the unstructured interface strategy typically present a text box that allows users to freely type their own text into the interface. These implementations will perform some input processing prior to use; however, the presentation of this processing to users is usually limited to correcting typographical errors rather than semantic ones. For example, the interface of Google aligns with the unstructured interface strategy, presenting users with an open, text-box input control without domain-specific assumptions or requirements. Of course, Google’s computational systems use extensive processing between receiving input from users and presenting the results of computation back to users.<ref>{{Cite journal \|last=Luo \|first=Jake \|last2=Wu \|first2=Min \|last3=Gopukumar \|first3=Deepika \|last4=Zhao \|first4=Yiqing \|date=2016-01-01 \|title=Big Data Application in Biomedical Research and Health Care: A Literature Review \|url=https://doi.org/10.4137/BII.S31559 \|journal=Biomedical Informatics Insights \|language=en \|volume=8 \|pages=BII.S31559 \|doi=10.4137/BII.S31559 \|issn=1178-2226 \|pmc=PMC4720168 \|pmid=26843812}}</ref> Yet, users themselves are not informed of how their results came to be, even after changing to Google Instant.<ref>{{Cite journal \|last=Qvarfordt \|first=Pernilla \|last2=Golovchinsky \|first2=Gene \|last3=Dunnigan \|first3=Tony \|last4=Agapie \|first4=Elena \|date=2013-07-28 \|title=Looking ahead: query preview in exploratory search \|url=https://dl.acm.org/doi/10.1145/2484028.2484084 \|journal=Proceedings of the 36th international ACM SIGIR conference on Research and development in information retrieval \|language=en \|publisher=ACM \|place=Dublin Ireland \|pages=243–252 \|doi=10.1145/2484028.2484084 \|isbn=978-1-4503-2034-4}}</ref> Another example of an implementation of the unstructured interface strategy is WebMD’s search interface. This interface processes a free-text input with basic sanitization techniques before generating features for its search engine system, as depicted in Figure 2.

Shawndouglas: Saving and adding more.

2021-09-23T20:00:22Z

Saving and adding more.

← Older revision		Revision as of 20:00, 23 September 2021
Line 144:		Line 144:

	===High-level criteria===		===High-level criteria===
			In Table 1, we provide five criteria based on the above review.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="2" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 1.''' The criteria for guiding the design of interfaces for health informatics search tasks involving large document sets. For abbreviation purposes, design criteria will be referenced in the text as DC#, where # is its assigned number.
			\|-
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|DC#
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|Design criteria
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC1
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide an information-centric interface that shows flexibility towards the evolving needs of users and the dynamic requirements of search tasks like the veracity of data sources and variety of information types.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC2
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide interaction loops that supply prompt and effective feedback for users during the performance of search tasks.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC3
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide natural and consistent representations that allow users to understand the constraints, processes, and results provided by the interface.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC4
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide interactions that allow users to efficiently prepare, perform, assess, and adjust their machine learning to align with the information-seeking objectives of search tasks.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC5
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide mediation opportunities that assist users in communicating and bridge their information-seeking objectives into the vocabulary of the document set.
			\|-
			\|}
			\|}

			===Analysis of traditional interface strategies for health informatics search tasks===
			We now assess the traditional design strategies for interfaces for health informatics search tasks. Wilson’s comprehensive Search User Interface Design<ref>{{Cite book \|last=Wilson \|first=Max L. \|date=2012 \|title=Search user interface design \|url=https://www.worldcat.org/title/mediawiki/oclc/780340844 \|series=Synthesis lectures on information concepts, retrieval, and services \|publisher=Morgan & Claypool \|place=San Rafael, Calif. \|isbn=978-1-60845-689-5 \|oclc=780340844}}</ref> provides a complete survey of the history and current state of search interfaces. Based on their survey, and in particular their discussion of input and control features within the modern search user interfaces, two base strategies and one extension strategy for search interfaces are realized: “structured” interfaces, “unstructured” interfaces, and, in extension, “query expansion” interfaces. Table 2 provides a summary of how the above criteria align with each interface strategy.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="4" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 2.''' A summary matrix of alignment between the criteria and interface strategies. Full descriptions are found within their respective sections. “Strong” is assigned if a characteristic of the interface strategy promotes alignment with the requirements of the design criterion. “Weak” is assigned if a characteristic of the strategy does not promote alignment with the requirements of the design criterion. “Variable” is assigned if the interface strategy has the potential to align with the criterion; however, such an alignment is not innate and must be actively pursued.
			\|-
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|DC#
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|Structured
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|Unstructured
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|Query expansion
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC1
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Weak
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC2
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC3
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC4
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC5
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Weak
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Weak
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\|-
			\|}
			\|}

			====Structured interface strategy====

Shawndouglas: Saving and adding more.

2021-09-23T19:51:29Z

Saving and adding more.

← Older revision		Revision as of 19:51, 23 September 2021
Line 130:		Line 130:

	====Aligning vocabularies for health informatics search tasks====		====Aligning vocabularies for health informatics search tasks====
			When considering interfaces for health informatics search tasks, a major challenge for users is the need to overcome problem formulation deficiencies when encountering unfamiliar domains. This is because, according to Harvey ''et al.''<ref name=":18">{{Cite journal \|last=Harvey \|first=Morgan \|last2=Hauff \|first2=Claudia \|last3=Elsweiler \|first3=David \|date=2015-08-09 \|title=Learning by Example: Training Users with High-quality Query Suggestions \|url=https://dl.acm.org/doi/10.1145/2766462.2767731 \|journal=Proceedings of the 38th International ACM SIGIR Conference on Research and Development in Information Retrieval \|language=en \|publisher=ACM \|place=Santiago Chile \|pages=133–142 \|doi=10.1145/2766462.2767731 \|isbn=978-1-4503-3621-5}}</ref>, users have been found to consistently suffer from four major issues during the performance of search tasks:

			*difficulty understanding the domain being searched;
			*an inability to apply their domain expertise;
			*lacking the capacity to formulate an effective search query within the interface that accurately reflects their information-seeking objective; and
			*deficient understanding of how to assess results produced by search, to decide whether the search has or has not satisfied their objective.

			Harvey ''et al.''<ref name=":18" /> show that in domains with complex vocabularies, such as health and medicine, the disparity of potential users’ prior knowledge is extreme. They find that non-expert users routinely do not possess enough domain knowledge to address their information-seeking needs. This can cause significant issues during query formulation. As a result, non-expert users must first step away from their tool to learn specialized vocabulary before they can begin query building. Both Soldaini ''et al.''<ref>{{Cite journal \|last=Soldaini \|first=Luca \|last2=Yates \|first2=Andrew \|last3=Yom-Tov \|first3=Elad \|last4=Frieder \|first4=Ophir \|last5=Goharian \|first5=Nazli \|date=2015-07-16 \|title=Enhancing web search in the medical domain via query clarification \|url=https://doi.org/10.1007/s10791-015-9258-y \|journal=Information Retrieval Journal \|language=en \|volume=19 \|issue=1-2 \|pages=149–173 \|doi=10.1007/s10791-015-9258-y \|issn=1386-4564}}</ref> and Anderson and Wischgoll<ref>{{Cite journal \|last=Anderson \|first=James D \|last2=Wischgoll \|first2=Thomas \|date=2020-01-26 \|title=Visualization of Search Results of Large Document Sets \|url=https://www.ingentaconnect.com/content/ist/ei/2020/00002020/00000001/art00006;jsessionid=1ui77rulkmwwg.x-ic-live-03 \|journal=Electronic Imaging \|volume=2020 \|issue=1 \|pages=388–1–388-7 \|doi=10.2352/ISSN.2470-1173.2020.1.VDA-388}}</ref> describe that this issue can still affect even experts. This is because experts often must make assumptions when attuning to their tool.

			There is growing research targeting the generation and application of mediation resources to help reduce the communication gap while using health informatics tools. Zeng ''et al.''<ref name=":14" /> investigate the development of consumer health vocabularies for reducing the discourse gap between lay people and medical information document sets. Furthermore, Soldaini ''et al.''<ref>{{Citation \|last=Soldaini \|first=Luca \|last2=Cohan \|first2=Arman \|last3=Yates \|first3=Andrew \|last4=Goharian \|first4=Nazli \|last5=Frieder \|first5=Ophir \|date=2015 \|editor-last=Hanbury \|editor-first=Allan \|editor2-last=Kazai \|editor2-first=Gabriella \|editor3-last=Rauber \|editor3-first=Andreas \|editor4-last=Fuhr \|editor4-first=Norbert \|title=Retrieving Medical Literature for Clinical Decision Support \|url=http://link.springer.com/10.1007/978-3-319-16354-3_59 \|work=Advances in Information Retrieval \|language=en \|publisher=Springer International Publishing \|place=Cham \|volume=9022 \|pages=538–549 \|doi=10.1007/978-3-319-16354-3_59 \|isbn=978-3-319-16353-6 \|access-date=2021-09-23}}</ref> explore the use of novel query computation strategies to improve the quality of medical literature retrieval during search tasks. In their quantitative study, they contrast models generated using combinations of algorithms, vocabularies, and feature weights, assessing the computational performance of different query reformulation techniques. The results of their study suggest “greatly improved retrieval performance” when utilizing combined machine learning and bridged vocabularies. More so, they provide insight regarding the quality of options that can support computational systems for health informatics search tasks.

			From the above research, we can distill two criteria. First, designs should provide interactions that allow users to efficiently prepare, perform, assess, and adjust their machine learning to align with information-seeking objectives of search tasks. Second, designs should provide mediation opportunities that assist users in communicating information-seeking objectives into the domain-specific vocabulary of the document set.

			===High-level criteria===

Shawndouglas: Saving and adding more.

2021-09-23T19:35:06Z

Saving and adding more.

Show changes

← Older revision		Revision as of 20:00, 23 September 2021
Line 144:		Line 144:

	===High-level criteria===		===High-level criteria===
			In Table 1, we provide five criteria based on the above review.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="2" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 1.''' The criteria for guiding the design of interfaces for health informatics search tasks involving large document sets. For abbreviation purposes, design criteria will be referenced in the text as DC#, where # is its assigned number.
			\|-
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|DC#
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|Design criteria
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC1
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide an information-centric interface that shows flexibility towards the evolving needs of users and the dynamic requirements of search tasks like the veracity of data sources and variety of information types.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC2
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide interaction loops that supply prompt and effective feedback for users during the performance of search tasks.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC3
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide natural and consistent representations that allow users to understand the constraints, processes, and results provided by the interface.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC4
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide interactions that allow users to efficiently prepare, perform, assess, and adjust their machine learning to align with the information-seeking objectives of search tasks.
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC5
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Provide mediation opportunities that assist users in communicating and bridge their information-seeking objectives into the vocabulary of the document set.
			\|-
			\|}
			\|}

			===Analysis of traditional interface strategies for health informatics search tasks===
			We now assess the traditional design strategies for interfaces for health informatics search tasks. Wilson’s comprehensive Search User Interface Design<ref>{{Cite book \|last=Wilson \|first=Max L. \|date=2012 \|title=Search user interface design \|url=https://www.worldcat.org/title/mediawiki/oclc/780340844 \|series=Synthesis lectures on information concepts, retrieval, and services \|publisher=Morgan & Claypool \|place=San Rafael, Calif. \|isbn=978-1-60845-689-5 \|oclc=780340844}}</ref> provides a complete survey of the history and current state of search interfaces. Based on their survey, and in particular their discussion of input and control features within the modern search user interfaces, two base strategies and one extension strategy for search interfaces are realized: “structured” interfaces, “unstructured” interfaces, and, in extension, “query expansion” interfaces. Table 2 provides a summary of how the above criteria align with each interface strategy.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="4" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 2.''' A summary matrix of alignment between the criteria and interface strategies. Full descriptions are found within their respective sections. “Strong” is assigned if a characteristic of the interface strategy promotes alignment with the requirements of the design criterion. “Weak” is assigned if a characteristic of the strategy does not promote alignment with the requirements of the design criterion. “Variable” is assigned if the interface strategy has the potential to align with the criterion; however, such an alignment is not innate and must be actively pursued.
			\|-
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|DC#
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|Structured
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|Unstructured
			! style="background-color:#dddddd; padding-left:10px; padding-right:10px;" \|Query expansion
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC1
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Weak
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC2
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC3
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC4
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Variable
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|DC5
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Weak
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Weak
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Strong
			\|-
			\|}
			\|}

			====Structured interface strategy====