Kepler Users

STATUS

The content on this page is outdated. The page is archived for reference only. For more information about current work, please contact the User Representation and Outreach Team.

Who are our users?

To produce the best software we can, we need to understand our target users. These can be divided into two general groups:

• Direct Users - interact with the Kepler user interface to create and execute workflows.
• Indirect Users - do not interact with the Kepler user interface to create and execute workflows.

Direct User categories include:

• Scientists
• Quantitative Analysts
• Workflow Engineers

Indirect User categories include:

• Kepler Developers
• Deployment Engineers/System Administrators
• Scientific Application Developers
• Computer Science Researchers

Direct Kepler Users

Direct Kepler User	Profile	Primary Kepler Tasks	Examples/Mappings from Project Presentations
Scientists	Domain science experts with no programming experience and little or no technical expertise with data types and/or technical processing issues	*Create high level conceptual workflows *Run existing workflows (including changing parameters) *Run existing workfows with minor modifications (substituting different data or actors)	*Geophysicists *Biologists *Ecologists *Domain Experts *End User Scientis
Quantatative Analysts	Quantitatively or computationally oriented scientists with some basic programming skills (e.g., scripting) and some technical understanding of data types and processing issues. Medium to advanced knowledge of statistics and analysis, varied use of scripted analytical environments (e.g., R). Varied modeling experience.	*Run existing workflows (including changing parameters) *Run existing workfows with minor modifications (substituting different data or actors) *Create simple workflows	*Computational Chemists *Computational Systematists *Quantitative Analysts *Modelers *Computations Scientists *Informatics Specialists
Workflow Engineers	None to expert domain science background but medium to expert programming experience and full understanding of data types and technical processing issues.	*Create simple workflows *Create and modify actors *Create complex workflows	*Chemistry Workflow Specialists *Workflow Developers *Actor Developers *Programmers

 

Indirect Kepler Users

Indirect Kepler User	Profile	Primary Kepler Tasks	Examples/Mappings from Project Presentations
Kepler Developers	Software engineer that ddesigns, implements, and tests changes to the core Kepler software. Works in a complete Kepler development environment, typically checks code in and out at the head of CVS, routinely builds Kepler from sources, and tests the entire Kepler system when adding or modifying code.	*Design, create, test Kepler code.	*Developers *Kepler System Developers
Deployment Engineers/System Administrators	Software engineer that is responsible for installing, configuring, and integrating Kepler with existing computing resources in an organization.	*Install and configure Kepler for others.	Deployment Engineers
Scientific Application Developers	Uses Kepler to provide a scientific workflow automation back-end for a higher-level application targeted at a specific research community. Integrates Kepler with application-specific databases, local authentication and authorization services, and other application- or locale-specific resources.	*Use Kepler APIs	*CIPRES Algorithm Designers/Programmers *Applications Developers
Computer Science Researchers	Uses Kepler as a testbed or platform for their research.	*Design, create, test Kepler code *Use Kepler APIs	none

 

Background and Discussion

In general, our original target user group can be defined as:

• scientists trying to answer broad scale questions e.g., continential or global species distribution changes due to a variety of factors, or climate change and its effects due to global warming.

However, Kepler is not a walk up and use interface and constructing complex executable scientific workflows within Kepler currently requires some level of programming that a general scientist often may not possess. Therefore, I've begun to think of our users in terms of how they will use Kepler (perform certain tasks) based on their workflow building experience and technical expertise. For example:

 

1. users that run existing workflows in Kepler (scientists with no programming and minimal workflow building experience)
2. users that run existing workflows with other data (scientists with no programming and minimal workflow building experience)
3. users that make minor modifications to existing workflows then run them, like adjusting a few data types, or substituting a different algorithm (scientists with no programming but some technical knowledge e.g., get the concept of data formats or just hooking up a different algorithm in the middle of a workflow, medium workflow building skills)
4. users that create and run simple workflows (understand the basics of how to put things together but maybe only have minimal programming skills but have medium to heavy workflow building skills)
5. users that create and run complex workflows which can include building custom actors (and these will be the workflow engineers oftentimes working together with a scientist that has extensive workflow building experience).

So in essence we really have three classes of users that will use Kepler to run, modify and create scientific workflows:

• Scientist -- doman science expert with no programming experience and little or no techincal expertise with data types and/or technical processing issues, and varied workflow creation experience (none to expert)
• Workflow Engineer -- no domain science background but medium to expert programming experience and understanding of data types and technical processing issues, and varied workflow creation experience (none to expert)
• Quantative Analyst - a hybrid user we see emerging as a combination of the two (scientist with some programming skills and some technical understanding of data types and processing issues), with varied workflow creation experience

We are gathering data on our user populations when possible, to build a better picture of their modeling expertise, technology usage and expertise, as well as education, training and research interests. See ???? for selected set of descriptive statistics on our domain scientist and informatics scientist groups of user.

 

Involving Scientists in the Development of Kepler

To answer broad scale scientific questions, domain scientists need to model various scenarios to predict outcomes which can then be used to make important decisions and to plan for the future. They might predict the decline of a species and its effect on an ecosystem, or help decision makers determine conservation planning policies . The Kepler software is the technology platform in which domain scientists can create these scientific models.

To better meet the needs of our domain scientist users we are involving them in the Kepler development. Deana Pennington, in the role of scientific liaison and process analyst, is leading a group of scientists in creating two use cases to be carried out within Kepler. This is to demonstrate real world applications of Kepler, to feed user requirements into the development process of Kepler, and to gather user feedback. See: ????

In order to really see where Kepler works and doesn't work for scientists, we usability tested the software with them. To date, we have performed some basic usability testing in a group setting. Results can be reviewed in the followig two reports:

• December 2004 Kepler Usability Report- report on Kepler usability issues from user feedback and group testing of basic operations during BEAM/ENM workshop
• January 2005 Kepler Usability Report - report on Kepler usability issues from user feedback and group testing of basic operations during SEEK Ecoinformatics workshop

 

Involving Quantatative Analysts in the Development of Kepler

We see this kind of user as an emerging user that will increase in general numbers in the scientific community as informatics is more and more incoroporated in the training of scientists. Currently we have team members that represent this user group and they are frequently consulted and asked to provide feedback to inform the design of Kepler.

 

Involving Workflow Engineers in the Development of Kepler

We have several workflow engineers from various organizations collaborating in the development of Kepler from a usage perspective and their feedback and input into tasks such as creating complex workflows, composite actors and atomic actors informs the design of supporting such tasks. The kepler-dev list is a very active discussion list where issues are raised and addressed.

We hope to conduct usability testing with workflow engineers in the future.