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.

← Older revision		Revision as of 16:10, 24 September 2021
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)		\|download = [https://www.mdpi.com/2078-2489/12/8/317/pdf https://www.mdpi.com/2078-2489/12/8/317/pdf] (PDF)
	}}		}}
	~~{{ombox~~
	~~\| type = notice~~
	~~\| image = [[Image:Emblem-important-yellow.svg\|40px]]~~
	~~\| style = width: 500px;~~
	~~\| text = This article should be considered a work in progress and incomplete. Consider this article incomplete until this notice is removed.~~
	}}
	==Abstract==		==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.		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>		<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>

			In the future, we plan to perform formal, empirical evaluations with users comparing ONTSI to other systems. Such evaluations will help generate new insights into features of interface designs and their qualitative and quantitative measures of how search task performances are affected. Beyond that, such evaluation studies may provide prescriptive guidelines for the design of optimal and effective interfaces for health informatics search tasks. In addition, we intend to further investigate how ontologies and machine learning should be integrated into elaborate and challenging search tasks that need domain-specific knowledge for optimal performance.

			===Limitations===
			The first limitation of ONTSI is the scaling of computational resources. ONTSI in its current state provides a plug-and-play experience that can handle the uploading and processing of both document sets and ontology files of large sizes. For instance, ONTSI easily handles HPO and its more than 11,000 ontology terms, alongside an extracted subset of PubMed of more than 10,000 documents. Yet, under the load of large-volume document sets and connected suites of ontology files, ONTSI’s computational systems may provide reduced responsiveness. To deal with such scenarios, further work is needed to solve overhead limitations—strategies such as pre-hosting common ontology files, establishing API connections to access externally hosted document sets, as well as simply expanding the computational power of our systems.

			The second limitation of ONTSI is the support of ontology file formats. ONTSI in its current state can process the core encoded elements within the OWL format, a leading format for encoding ontologies. Yet, the format is quite verbose in its specification, requiring developments beyond the scope of our immediate research objectives. In addition, there are other formats used to encode ontologies that would be valuable to support ontology-supported interfaces for health informatics search tasks.

			===Conclusions===
			In summary, in this paper we began with an examination of the background on the topics of health informatics, machine learning, and ontologies. We then reviewed recent research on health informatics search tasks. Based on this review, we formalized a set of criteria for guiding designers when creating ontology-supported interfaces for health informatics search tasks involving large document sets. We then used these criteria to contrast traditional design strategies for interfaces of search tasks.

			To demonstrate the utility of the criteria in the design process, we applied them to structure the creation of ONTSI (ONTology-supported Search Interface), an ontology-supported interface for health informatics search tasks involving large document sets. ONTSI combines five front-end subviews and two back-end computational systems. With these systems, ONTSI supplies a generalized interface that supports users’ ability to plug-and-play their provided document sets and an ontology file as a mediating resource within the interface when performing their health informatics search tasks.

			The workflow of ONTSI was described and illustrated in a usage scenario. For our scenario, we used the Human Phenotype Ontology to mediate a search task on a subset of the PubMed document set. This usage scenario presented a narrative of a health professional performing a scoping review. Within the scenario, we found that ONTSI allows the user to utilize their ontology resource in a manner that aligns with both the unstructured and structured-like query expansion interface strategy. In the former, the user entered a research question without participating in mediation opportunities. In that case, ONTSI used HPO and WordNet as mediating resources to extend the user’s query within an expansion model to generate the results of a search task. In the latter case, the user took advantage of mediation opportunities during their query building. Although this usage scenario provides a single health informatics narrative, we believe value can be generated from both the criteria and ONTSI for health informatics in a broad sense. In this sense, we envision that our efforts can be further expanded to encompass tasks in informatics such as consumer informatics, nursing informatics, and ontology-supported domains beyond health and medicine, to name but a few.

			In conclusion, in this paper we generated and proposed a set of criteria that can provide guidance to designers in creating ontology-supported interfaces for health informatics search tasks involving large document sets. We illustrated the utility of these criteria in the context of the creation and demonstration of ONTSI. We provided general insight from ongoing, formative, task-driven user evaluations of ONTSI. We hope to continue this research to promote the design of generalized ontology-supported interfaces for health informatics search tasks involving large document sets.

			==Acknowledgements==
			We would like to acknowledge NSERC and its support of our research.

			===Author contributions===
			Conceptualization, J.D. and K.S.; methodology, J.D. and K.S.; software, J.D.; validation, J.D. and K.S.; formal analysis, J.D. and K.S.; investigation, J.D. and K.S.; resources, Insight Lab, J.D. and K.S.; data curation, J.D.; writing—original draft preparation, J.D.; writing—review and editing, J.D. and K.S.; visualization, J.D.; supervision, K.S.; project administration, J.D.; funding acquisition, K.S. Both authors have read and agreed to the published version of the manuscript.

			===Funding===
			We acknowledge the support of the Natural Sciences and Engineering Research Council of Canada (NSERC).

			===Conflicts of interest===
			The authors declare no conflict of interest.

	==References==		==References==

Shawndouglas: Saving and adding more.

2021-09-24T16:02:22Z

Saving and adding more.

← Older revision		Revision as of 16:02, 24 September 2021
Line 421:		Line 421:
	\|}		\|}

			The user uploads their document set and ontology file by clicking the Upload button, activating the Upload subview, as seen in Figure 8. After confirming a selection, the upload process begins.


			[[File:Fig8 Demelo Information21 12-8.png\|800px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="800px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure 8.''' Selecting a document set and ontology file for upload.</blockquote>
			\|-
			\|}
			\|}

			After the upload process is complete, the user begins typing the research question “How does chromosomal instability drive tumor progression?” into the textbox, finishing with a click of the “Run” button. In response, ONTSI provides the results of its computation, as seen in Figure 9. It presents the first page of 500 pages of documents, which totals 20 document entries. There are percentages to the left of each entry that use text and color to annotate the relevance of each document. This scalar is based on the cluster weightings within the dimensional space of the document set, where a 100% would be produced by documents within a cluster that aligns with every input feature. The scalar maintains a color scale between red and green, where red is at the zero point and green at 100%. For instance, at the top of the first page there are five documents that present an orange 45.25% relevance rating. Looking at these documents, the user scans the titles of the documents, where some have terms within their titles that relate to the research question.


			[[File:Fig9 Demelo Information21 12-8.png\|800px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="800px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure 9.''' The results of a search task using the query, “How does chromosomal instability drive tumor progression?”</blockquote>
			\|-
			\|}
			\|}

			Some documents at the top of the results could align with the user’s research question. To explore further, the user selects a few of the top documents, generating additional document information for inspection, as seen in Figure 10. Doing so, the user encounters a summarized version of their selected documents, which provides [[metadata]] and abstracts annotated with words and phrases related to the research question.


			[[File:Fig10 Demelo Information21 12-8.png\|800px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="800px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure 10.''' ONTSI after opening the documents “Cancer morphology, carcinogenesis and genetic instability: A background” and “Kaposi’s sarcoma–associated herpesvirus–encoded latency-associated nuclear antigen induces chromosomal instability through inhibition of p53 function.”</blockquote>
			\|-
			\|}
			\|}

			The user estimates that these top documents may align with their research question. Therefore, they click on the green “pin” button found at the rightmost point of each document to save their reference for future retrieval from the document set. These references are accessible by clicking the green “pin” button found at the top right of ONTSI to open the Saved List subview.

			Although the user has now encountered some documents relevant to their research question, they choose to continue searching. This time, the user decides to take advantage of mediation opportunities when building their query. After closing the Saved List subview, the user begins a new search. After assessing the important words in their research question, the user types in the term “chromosomal.” At the point that they have typed “chromo,” they are presented with mediation opportunities, as seen in Figure 11. They inspect these mediation opportunities and add phenotypic terms that align with their research question.


			[[File:Fig11 Demelo Information21 12-8.png\|800px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="800px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure 11.''' ONTSI while the user is presented with mediating opportunities from the expert–defined Human Phenotype Ontology.</blockquote>
			\|-
			\|}
			\|}

			With the aid of mediation, the user builds a three-item query consisting of “abnormal chromosome morphology,” “chromosomal instability,” and “tumor progression.” After asking ONTSI to run with this query, the user encounters a set of results different from the one produced by their earlier search, as seen in Figure 12. Notably, an increased set of 10 documents at a 48.75% rating is encountered. Looking at these documents, the user notices some that are familiar, such as the saved “Genetic instability in human tumors.”


			[[File:Fig12 Demelo Information21 12-8.png\|800px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="800px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure 12.''' ONTSI after running a new search after the user took advantage of mediation opportunities presented in the generation of the query items.</blockquote>
			\|-
			\|}
			\|}

			From this listing, the user selects two new documents for deeper inspection, as seen in Figure 13. They notice that terms such as “morphology” and “neoplasm” are now being highlighted within the document annotations. The adjusted query based on mediation opportunities has helped promote documents that align with their research question. In this case, the user finds value in the two documents, so they are saved.


			[[File:Fig13 Demelo Information21 12-8.png\|800px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="800px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Figure 13.''' ONTSI after the user has selected new document entries for deeper inspection.</blockquote>
			\|-
			\|}
			\|}

			Before concluding the search task, the user can upload a different ontology file to investigate how alternate vocabularies may bridge them to their document set. Their encounters could have also allowed them to make the assessment that the document set may not be best to help with their research question. If that is the case, they may upload a different document set, performing another scoping review. In any case, ONTSI provides a search task interface that has been generalized to support plug-and-play capabilities for user-provided ontology files and document sets, allowing users to customize the interface to match their search task objectives.

			==Discussion and conclusions==
			===Evaluation of ONTSI===
			We have conducted ongoing, formative, task-driven user evaluations of ONTSI. These evaluations were informally conducted with a few people associated with our research lab; they have provided initial insights into how ontology-supported interfaces for health informatics can support users to perform elaborate search tasks involving large document sets. In these evaluations, we asked the users to perform a targeted set of tasks, such as researching questions outlined in the presented usage scenario. Initial sessions provided general insight into how users search and how ontologies can help mediate such tasks. From these sessions, we have learned a few things:

			* Users are able to quickly transfer their experiences with previous interfaces to use ONTSI (e.g., A, B).
			* Users are capable of utilizing ontology files to align their vocabulary with the vocabulary of the domain, even if they are not initially familiar with the ontology’s domain or its structure and content (e.g., C, D).
			* Users are capable of understanding the requirements of the information-seeking process, expressing their valuation of the support they are provided by the interface as they performed their search tasks (e.g., E, F, G).
			* Users felt that mediating ontologies make search tasks more manageable and easier, and not having them would negatively affect their task performance (e.g., E, F, G).

			The following are some informal excerpts of some of the comments of those who have used ONTSI:

			<blockquote>('''A''') “I think with ONTSI, I can immediately it matches my mental models of how I use search interfaces. I type things in, I click run, I go through pages of results.”</blockquote>

			<blockquote>('''B''') “Once I understood what it was showing me, it helped me. Usually with new tools I tend to read through the documentation or watch videos. And then it still takes me like a while to pick up on them. Like, just running through them and using them a few times. Once you get the hang of it, usually you find success in whatever it’s providing you.”</blockquote>

			<blockquote>('''C''') “But … you can get lost in the information too, right? So, if you have like so much so many things related in that ontology, it’s like, well, it can be useful. But it could also be a distraction for something that you know. There’s this flip side, but I think that’s on the searcher to know what they’re using and why they’re using it. So … for me to complete these tasks, if I hadn’t had the ontologies listed, then I would have had a much more difficult time. It essentially provided guidance … and a structure to something I was unfamiliar with in this case.”</blockquote>

			<blockquote>('''D''') “I wasn’t necessarily intimidated, but I was just like—I don’t know what this is. But the background information for the context helped a little bit. A lot of big words, but they did help me when I was looking at the documents that I had to search for to find out which ones I felt best. So even though I did not have full understanding of the words, having them there in that background provided me a kind of help towards finding myself in the space of the question.”</blockquote>

			<blockquote>('''E''') “I was thinking … where (the ontology) would have been helpful. So … it would have possibly brought up some of those other terms just from searching a few words and they would be able to make some connections between the text that was provided and some of my search terms (to see) … how relevant they were. So, if I was shooting in the dark and hoping for the best, which is what I was kind of doing (without the ontology), at the very least, it would have given you confidence of your actions. Yeah, I think so. A little bit more confidence.”</blockquote>

			<blockquote>('''F''') “I thought it would be like pretty easy because I (am used to) answering … open questions like … find the things most relevant. So, this research question is for me … just an easier thing to do because I have background in doing that kind of stuff. ONTSI kind of functions like … a library tool that is available. This kind of tool felt very familiar to me. I wouldn’t say that I’m an expert when it comes to medical knowledge, but … I understand … basic terminology. So… what the terms meant or what they refer to wasn’t really … an issue. It wasn’t really alienating. I have like some general level of confidence just using the terms and trusting the tool as you went along.”</blockquote>

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

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