This research project could rapidly get quite large, employing many people, so self-supportive must be feasible. Feasibility of this project must be viewed from the vantage of return on investment.
Either research and knowledge are valuable assets themselves, or they are not—however, money channels through its channels; corporate venture capital may not prove the best method to fund our research, since research must neither be hampered nor influenced by interests to turn a profit. Moreover, private non-profit might seem a favorable financial model for this project—however, we must not be hampered by the possibility that our efforts could prove profitable. Right now, profit is our concern; here the research stops.
Tuesday, April 13, 2010
#16. The Science of Willingness
Before we summarize our work so far, and further build the next logical step in series, we now may be best served to view our project from a few different vantages. We can return to developing human interfaces that front computer data structures later; right now let's regroup for a moment, and consider our own motivations into action.
Since we are usability scientists, and we are interested in human actions and human-computer interactions, we must consider their sources. Since we are largely studying human actions and reactions, we must be clear about the sources of these actions, instead of merely recording what they were, or how they manifested once they have already occured. We know that if we can anticipate likely future actions of end-users, based on their past actions, we can learn from our mistakes; however, we also know that it is best to categorize this behavior before we even get started. Therefore, we can again start with the broadest category, and work down to the minutia.
The Classical Greeks discovered that humans, as well as other organisms, are motivated by only two factors; that is, if all factors that motivate humans can be categorized, they will fall under one of two headings (or a percentage of both of them, in reality). These two factors that motivate actions are Fear and Desire—those are the only two options. People either move away from something, or move toward it. Although people may not act as the result of Fear or Desire, we know action (and sometimes inaction) is motivated by either of those two factors.
If our own desire is to create user-friendly healthcare software, then we can manifest that desire by cultivating the desire of the end-users of this software. This will be a completely different motivation to create software than relying on forcing healthcare workers to learn a faulty system, lest they lose their jobs. Not only would such threats be unfriendly, they would impede our ability to learn from our own mistakes; a user-hostile system would incorporate mistakes, and disallow all user input, except for that which the system channels.
Humans can be motivated by fear, but that is not the basis for the profession of healthcare, in general. The basis for healthcare is the desire to selflessly help others to achieve health. A desire for better health has sent willing patients to healthcare professionals, and these patients have willingly agreed to treatment from willing professionals.
At no point does fear make this system run more efficiently.
As the result, we know that we scientists are best served if we purposefully focus our own efforts toward cultivating willing participation of end-users without instilling any self-willed fear whatsoever, if that is possible. This will afford us the greatest possibility to extract the most accurate information from end-users, and will likely grow the system that mines data.
If user-friendliness is one benefit of user-centered design, then humble willingness will prove more profitable than proud willpower. This leads us to the next topic: We need to determine "profitable".
Since we are usability scientists, and we are interested in human actions and human-computer interactions, we must consider their sources. Since we are largely studying human actions and reactions, we must be clear about the sources of these actions, instead of merely recording what they were, or how they manifested once they have already occured. We know that if we can anticipate likely future actions of end-users, based on their past actions, we can learn from our mistakes; however, we also know that it is best to categorize this behavior before we even get started. Therefore, we can again start with the broadest category, and work down to the minutia.
The Classical Greeks discovered that humans, as well as other organisms, are motivated by only two factors; that is, if all factors that motivate humans can be categorized, they will fall under one of two headings (or a percentage of both of them, in reality). These two factors that motivate actions are Fear and Desire—those are the only two options. People either move away from something, or move toward it. Although people may not act as the result of Fear or Desire, we know action (and sometimes inaction) is motivated by either of those two factors.
If our own desire is to create user-friendly healthcare software, then we can manifest that desire by cultivating the desire of the end-users of this software. This will be a completely different motivation to create software than relying on forcing healthcare workers to learn a faulty system, lest they lose their jobs. Not only would such threats be unfriendly, they would impede our ability to learn from our own mistakes; a user-hostile system would incorporate mistakes, and disallow all user input, except for that which the system channels.
Humans can be motivated by fear, but that is not the basis for the profession of healthcare, in general. The basis for healthcare is the desire to selflessly help others to achieve health. A desire for better health has sent willing patients to healthcare professionals, and these patients have willingly agreed to treatment from willing professionals.
At no point does fear make this system run more efficiently.
As the result, we know that we scientists are best served if we purposefully focus our own efforts toward cultivating willing participation of end-users without instilling any self-willed fear whatsoever, if that is possible. This will afford us the greatest possibility to extract the most accurate information from end-users, and will likely grow the system that mines data.
If user-friendliness is one benefit of user-centered design, then humble willingness will prove more profitable than proud willpower. This leads us to the next topic: We need to determine "profitable".
Monday, April 12, 2010
#15. Crediting Novelty
Thus, we have developed an infrastructure whereby questions submitted on computer interfaces directed to individual healthcare professionals are organized so that organized computer interface answers can later be reflected back by the computer system to these individual healthcare workers. The computer system develops information trails, left by individual end-users, so that the computer system can direct specific communication to each individual end-user along the same trail in reverse.
To review: We know that end-users vary, that their jobs vary, that their patients vary, that symptoms vary, but that those entities can be organized and analyzed if we place them in variables (which themselves can vary, but that's later). Again we cannot make the mistake of limiting the input of information from these end-users, since they are the ones who are building their own system; rather, we know whatever system we create will not be perfect, so we must include the ability for users to amend it. Lastly, we also know that the scientific method asks questions, but answers to those questions actually spur a multitude of new questions.
(We must realize that the difference between a question and an answer becomes rather blurred at this point. Since end-users are submitting accounts of inadequacies within their own system that is presenting them with questions, they are actually questioning the authority of the system—which returns even more questions. We could go 'round and 'round with this debate of what constitutes a question versus an answer, so let's move on.)
Therefore, we must submit to end-users question/answers that are already established (from previously answered question/answers) in a different format from question/answers that are new. When question/answers are submitted to end-users from the computer system, their routine ones must be easily manipulated by clicking buttons, or similar third-key experiences, such as dragging pull-down menus—unless they are new questions/answers to the system—new answers must be typed; it is this ease of manipulation itself, that which differentiates routine from novelty, which can credit users with their own authoring.
For example, say we have created an interface that holds the question, "What is your last name?" However, family names in some cultures precede individual names—so the question does not capture accurate information as it relates to some end-users. We can employ this variance as an opportunity for our own growth, as well as crediting those who grow the research system.
This can be accomplished when some individual may claim the fact that in his culture family name comes first; this can be done by selecting the option, "This Question Does Not Fit," whereby he will be allowed to type information into a field directed to the creation of an entirely new Question Card (Development of these newly added Question Cards may be either reviewed first by authorized researchers, or submitted electronically with no oversight—nevertheless, the new cards are submitted into the system to be reused by others).
Therefore, research credit can be established for individuals as they submit information that finds faults with their system. (External rewards can be linked to this function, but let's just acknowledge its existence for now.)
This system not only allows users to upgrade their own system that they use, similar to the way that Wikipedia allows users to input information for upgrade, it also credits each user with the authoring of each amendment made. However, unlike Wikipedia, which submits one information interface to everyone, no author of novelty need be necessarily constrained to the practice of a preceding individual; each individual person has the ability to add information to this reverse data mine.
We will next investigate just how that individuality is expressed to each human individual.
To review: We know that end-users vary, that their jobs vary, that their patients vary, that symptoms vary, but that those entities can be organized and analyzed if we place them in variables (which themselves can vary, but that's later). Again we cannot make the mistake of limiting the input of information from these end-users, since they are the ones who are building their own system; rather, we know whatever system we create will not be perfect, so we must include the ability for users to amend it. Lastly, we also know that the scientific method asks questions, but answers to those questions actually spur a multitude of new questions.
(We must realize that the difference between a question and an answer becomes rather blurred at this point. Since end-users are submitting accounts of inadequacies within their own system that is presenting them with questions, they are actually questioning the authority of the system—which returns even more questions. We could go 'round and 'round with this debate of what constitutes a question versus an answer, so let's move on.)
Therefore, we must submit to end-users question/answers that are already established (from previously answered question/answers) in a different format from question/answers that are new. When question/answers are submitted to end-users from the computer system, their routine ones must be easily manipulated by clicking buttons, or similar third-key experiences, such as dragging pull-down menus—unless they are new questions/answers to the system—new answers must be typed; it is this ease of manipulation itself, that which differentiates routine from novelty, which can credit users with their own authoring.
For example, say we have created an interface that holds the question, "What is your last name?" However, family names in some cultures precede individual names—so the question does not capture accurate information as it relates to some end-users. We can employ this variance as an opportunity for our own growth, as well as crediting those who grow the research system.
This can be accomplished when some individual may claim the fact that in his culture family name comes first; this can be done by selecting the option, "This Question Does Not Fit," whereby he will be allowed to type information into a field directed to the creation of an entirely new Question Card (Development of these newly added Question Cards may be either reviewed first by authorized researchers, or submitted electronically with no oversight—nevertheless, the new cards are submitted into the system to be reused by others).
Therefore, research credit can be established for individuals as they submit information that finds faults with their system. (External rewards can be linked to this function, but let's just acknowledge its existence for now.)
This system not only allows users to upgrade their own system that they use, similar to the way that Wikipedia allows users to input information for upgrade, it also credits each user with the authoring of each amendment made. However, unlike Wikipedia, which submits one information interface to everyone, no author of novelty need be necessarily constrained to the practice of a preceding individual; each individual person has the ability to add information to this reverse data mine.
We will next investigate just how that individuality is expressed to each human individual.
#14. DNA of End-Use
We have proposed interface Question Cards to be subsequently submitted in series to individual healthcare workers; each Question Card is assigned a unique and invisible serial number, bar code, or other identifier, that a computer can read and process. Further, since initial questions submitted to each end user will be broad in scope, subsequently narrowing to questions regarding minutia, we can begin to organize the questionnaire structure as strings of data associated with individual end-users.
Different users can answer the same questions that other users have answered—that is, they can use the same Question Cards. However, different users are not constrained to using the same cards, or receiving them in the same order. Different users will assemble their questionnaires by using different cards already submitted into the data structure, or may need to create new questions.
In fact, sometimes different cards (with different serial numbers) must interface similar data fields, if we are to unify our research of end-use of varying professionals. For example, one Question Card may read "Please Enter Your Last (family) Name," while another Question Card may read "Пожалуйста впишите ваше последнее имя (семьи)," or "Incorpore por favor su nombre pasado (de la familia)", or "请输入您的前个(系列)名字." Regardless of human interface, our ability to gather similar data fields must be organized and unified for processing.
In essence, we have developed a method that allows healthcare professionals to build an informational genotype, of sorts; this genotype describes their work (which is performed to the class entitled Patients, and others) that can now be presented in the most efficient informational phenotype, if you will.
Rather, we now have strings of data regarding end-use of individual healthcare professionals—these are the interfaced Question Card serial numbers, and the sequences of their series. This information provides accurate data regarding end-use of each healthcare professional that we must attain to analyze the work of each individual. Once this work is accurately accumulated, we can then provide each individual with an accurate individual interface.
We must now submit the most efficient means for these professionals to communicate their jobs to the computer system, so that the computer system can reflect back their jobs, similar to the way that protein is expressed by nucleic acid molecules that have been linked appropriately.
Different users can answer the same questions that other users have answered—that is, they can use the same Question Cards. However, different users are not constrained to using the same cards, or receiving them in the same order. Different users will assemble their questionnaires by using different cards already submitted into the data structure, or may need to create new questions.
In fact, sometimes different cards (with different serial numbers) must interface similar data fields, if we are to unify our research of end-use of varying professionals. For example, one Question Card may read "Please Enter Your Last (family) Name," while another Question Card may read "Пожалуйста впишите ваше последнее имя (семьи)," or "Incorpore por favor su nombre pasado (de la familia)", or "请输入您的前个(系列)名字." Regardless of human interface, our ability to gather similar data fields must be organized and unified for processing.
In essence, we have developed a method that allows healthcare professionals to build an informational genotype, of sorts; this genotype describes their work (which is performed to the class entitled Patients, and others) that can now be presented in the most efficient informational phenotype, if you will.
Rather, we now have strings of data regarding end-use of individual healthcare professionals—these are the interfaced Question Card serial numbers, and the sequences of their series. This information provides accurate data regarding end-use of each healthcare professional that we must attain to analyze the work of each individual. Once this work is accurately accumulated, we can then provide each individual with an accurate individual interface.
We must now submit the most efficient means for these professionals to communicate their jobs to the computer system, so that the computer system can reflect back their jobs, similar to the way that protein is expressed by nucleic acid molecules that have been linked appropriately.
Thursday, April 8, 2010
#13. More About Presenting The Questions.
Human/Computer interaction is soft-coded.
Communication is dynamic. Languages change, word meanings change, people change, and medical practices change. Developing a system that is not preconceived to change must mean that either change has not been considered, or that the system has been preconceived to become outdated. Therefore, the best method for the computer to communicate with end-users is subject to change and advancement, along with technology and research into end-use of the individuals who interact with the system.
Nevertheless, we need to start somewhere, so we can accept our own limitations, while making some assumptions about these first few end-users to be studied:
• That they can read.
• That they can use the English language.
• That they have access to computers that are connected to the World Wide Web.
• That they have basic understanding of how to manipulate a computer, keyboard, and mouse (or other third-key device).
• That they have no handicaps that would compromise the efforts of this study.
So, while these opinionated assumptions are enough to get started, we must keep in mind that our opinions have been presented without an evidence base, so we must return to them. These opinions must simultaneously trigger our responses to further the researches into end-users to develop human/computer communication techniques that are more efficient than our first efforts will allow.
Interface tracking is hard coded.
Yet, we can begin by presenting our first interfaces that include the aforementioned criteria:
• That each individual end-user will be identified and instantiated by the first question (For example, "What is your name?").
• That each subsequent interface will be directed at each individual end-user.
• That each subsequent interface will be will be organized and presented in series for best comprehension.
• That each subsequent interface will be in the form of a question, regardless of communication technique.
• That each individual end-user will be able to change their questions.
• That the computer system will record these changes.
It will be important for us to develop a method to track these interface components as they are selected, compiled, amended and further developed. Not only will these interfaces provide a means for the human end-users to interact with their databases, these interface components themselves will become the objects of research; they must be labeled in such a way that a computer can compile them.
Therefore, these initial questionnaire components (let's refer to them as Question Cards) will have assigned alphanumeric serial numbers which may, or may not be visible to end-users. (I can think of no reason to hide these serial numbers from end-users, except that their visible presence could distract them from focusing their efforts of efficiently interacting with the system. That could change; but for now, let's hide these serial numbers in invisible metadata, off of the viewing screen.)
Communication is dynamic. Languages change, word meanings change, people change, and medical practices change. Developing a system that is not preconceived to change must mean that either change has not been considered, or that the system has been preconceived to become outdated. Therefore, the best method for the computer to communicate with end-users is subject to change and advancement, along with technology and research into end-use of the individuals who interact with the system.
Nevertheless, we need to start somewhere, so we can accept our own limitations, while making some assumptions about these first few end-users to be studied:
• That they can read.
• That they can use the English language.
• That they have access to computers that are connected to the World Wide Web.
• That they have basic understanding of how to manipulate a computer, keyboard, and mouse (or other third-key device).
• That they have no handicaps that would compromise the efforts of this study.
So, while these opinionated assumptions are enough to get started, we must keep in mind that our opinions have been presented without an evidence base, so we must return to them. These opinions must simultaneously trigger our responses to further the researches into end-users to develop human/computer communication techniques that are more efficient than our first efforts will allow.
Interface tracking is hard coded.
Yet, we can begin by presenting our first interfaces that include the aforementioned criteria:
• That each individual end-user will be identified and instantiated by the first question (For example, "What is your name?").
• That each subsequent interface will be directed at each individual end-user.
• That each subsequent interface will be will be organized and presented in series for best comprehension.
• That each subsequent interface will be in the form of a question, regardless of communication technique.
• That each individual end-user will be able to change their questions.
• That the computer system will record these changes.
It will be important for us to develop a method to track these interface components as they are selected, compiled, amended and further developed. Not only will these interfaces provide a means for the human end-users to interact with their databases, these interface components themselves will become the objects of research; they must be labeled in such a way that a computer can compile them.
Therefore, these initial questionnaire components (let's refer to them as Question Cards) will have assigned alphanumeric serial numbers which may, or may not be visible to end-users. (I can think of no reason to hide these serial numbers from end-users, except that their visible presence could distract them from focusing their efforts of efficiently interacting with the system. That could change; but for now, let's hide these serial numbers in invisible metadata, off of the viewing screen.)
Wednesday, April 7, 2010
#12. Data Mining In Reverse
Data mining is the process of extracting patterns from data accumulated; however, I must point out that we are set to reverse that trend. This study is being setup to develop a computerized information management system that studies the functions of end-users so that end-users do not need to study the function of the computerized information management system. Therefore, the computer system will be actually mining data that has not yet been accumulated, and the information resources mined are those of the end-users.
Once this information has been accumulated, it can then be further processed.
Therefore, if the entire effect of this study is to provide criteria to develop user-centered software for healthcare informatics, then that must remain our sole focus. Absolutely nothing must impede the effort of providing a friendly end-user experience, lest it undermine our primary goal of attracting willing users to help us to determine if Healthcare = 1/Crisis.
Once this information has been accumulated, it can then be further processed.
Therefore, if the entire effect of this study is to provide criteria to develop user-centered software for healthcare informatics, then that must remain our sole focus. Absolutely nothing must impede the effort of providing a friendly end-user experience, lest it undermine our primary goal of attracting willing users to help us to determine if Healthcare = 1/Crisis.
#11. Play 20 Questions With Your Interface.
Most who have played the child's game "Twenty Questions" realize that linear organization of questions can efficiently pinpoint answers; by beginning with the broadest possible scope of questions (EG "Are you an animal?") children can isolate objects and their locations in very few questions.
It is possible for computerized interfaces to submit questions to end-users in this fashion. It is possible to submit the correct healthcare practice questions (in an organized fashion) to the correct healthcare individuals, who can then answer them more efficiently than if the users, on their own, were forced to sort through a large list of questions that also contains questions not relevant to their jobs.
Since a format to receive the information has already been established at the database level, we merely continue organizing the questionnaire information—submitted on an interface structure—in the same format, forwarded to the end-users. Like dealing face-up cards to poker players, it is possible to submit appropriate questions to individuals without handing them the entire deck of the whole questionnaire.
For example, since everyone has a name (or an alias) that has instantiated their accounts, "What is your name, or alias?" might likely be the first question on an interface structure received by individual healthcare workers; the submitted name field will be different in every case. However, the second question submitted to individuals might be a job title (doctor, nurse, respiratory therapist, or the like); that job title will be similar to some, different from others. We now begin to find differences and similarities to study for the purpose of mining information about users to extract interface specifications to better serve these individuals when a user-centered informatics system is developed.
It is possible for computerized interfaces to submit questions to end-users in this fashion. It is possible to submit the correct healthcare practice questions (in an organized fashion) to the correct healthcare individuals, who can then answer them more efficiently than if the users, on their own, were forced to sort through a large list of questions that also contains questions not relevant to their jobs.
Since a format to receive the information has already been established at the database level, we merely continue organizing the questionnaire information—submitted on an interface structure—in the same format, forwarded to the end-users. Like dealing face-up cards to poker players, it is possible to submit appropriate questions to individuals without handing them the entire deck of the whole questionnaire.
For example, since everyone has a name (or an alias) that has instantiated their accounts, "What is your name, or alias?" might likely be the first question on an interface structure received by individual healthcare workers; the submitted name field will be different in every case. However, the second question submitted to individuals might be a job title (doctor, nurse, respiratory therapist, or the like); that job title will be similar to some, different from others. We now begin to find differences and similarities to study for the purpose of mining information about users to extract interface specifications to better serve these individuals when a user-centered informatics system is developed.
Subscribe to:
Posts (Atom)
