National Aeronautics and Space Administration Usability Project Update Mark Rose Intelligent Systems Group NASA Ames Research Center

Furthering My PDS Education Dec-Mar: Learning about PDS “skin” Apr-July: Learning about PDS “skeleton” As of last MC meeting, three projects approved for further work: –Site visits and reports to PDS Nodes –Cassini/CIRS product query tool –Propose “standard” UI for browsing volumes, with download improvements Other work added since: –Review of some current designs at the Nodes –Assist with parser for new validation tool

Node Evaluations & Site Visits  By next week, visited all science nodes except PPI Some nodes have already made changes Also reviewed or learned about a variety of search interfaces inside and outside PDS

Evaluation Results Mostly low-severity usability defects Needed finer-grained prioritization (I’m guessing) Most won’t get fixed My usual severity scale: - disaster - high severity - low severity - cosmetic issue Modified scale: - high impact - low impact, persistent - low impact, nonpersistent - cosmetic or very minor

Usability as a Process Number of different interfaces is growing, and will continue to grow Value of interfaces relative to data is growing Importance of good usability engineering will grow with those factors PDS must increase ability to design using good usability principles

Design from Inside Out An honest job of design should flow from the inside out, not from the outside in. – Henry Dreyfuss Reviewing implementations can help, but fixes compete with other tasks and projects. Improving a design prior to implementation is cheaper and usually sees more flaws fixed.

“Standard” View of Volumes Mockups from two datasets Good feedback from very small sample of users Addresses browsing, product search (building on Basic Browser), and download Needs: Feedback, refinement, buy-in to tool development plan

New Volume Validation Tool object_statement : "OBJECT" EQUALS IDENT (COMMENT)? EOL (nongroup_statement)* "END_OBJECT" (EQUALS IDENT)? (COMMENT)? EOL Helped JPL create grammar describing PDS labels. Grammar development unearthed various ambiguities in PDS standard specifications. Lessons: Future standards for formats should be grammar-centric; get a parser expert on board early. Or, save (a lot of) time by using a predefined framework like XML. Rule for an OBJECT statement

CIRS Data Query Tool The bad (my blame): – Not publicized yet – Need more feedback – Retargetability problematic The good: – Tool is working – Some good feedback – Can be retargeted

Applicability of Query Tools Everyone is writing query tools for PDS data: –Nodes: Analyst’s Notebook, Orbital Data Explorer, Image Atlas, SBN, PPI, Rings, etc. –Researchers: Local databases, scripts to pull data from PDS, interfaces to IDL, etc. It would seem that a generalized tool could have wide adoption, but…

Barriers to Tool Adoption Diversity of PDS Node environments –Java, C#, Perl, PHP, databases, etc. Index generation may be data-set specific –Labels may not contain appropriate summary data –Data in product rows may have wrong reference point (date/times, esp.) –Summary or thumbnails may require reading data files and custom processing Data diversity  may need custom search Bottom line: Nodes may not save enough effort to justify adopting a general solution

Observations While working on these tasks, I’ve observed several things that may affect future PDS planning: –Pain point: volume creation –Data usability problems –Growing importance of query interfaces

Volume Creation Creating PDS-format volumes is viewed as time-consuming, painful process –“Is there some way to relax PDS standards to get some of this data in?” (JPL Researcher) Nodes believe better volume creation tools will help both nodes and instrument teams (and tool design is in the pipeline) Proposal: Interview some instrument teams to understand their needs better, to complement knowledge in the nodes

Data Usability Usability problems don’t stop once you find the products –Labels sometimes don’t contain needed index data (e.g., first/last values for time series) –Data distribution among products sometimes not easy to use Data usability guidelines might help

Importance of Query Tools Dataset size is growing –“Download all data,” then analyze won’t work –Online query interfaces more important But, query interfaces don’t have built-in longevity Also, rise of mission-specific sites and interfaces raises longevity concerns

Mission-Specific Interfaces What happens to these long-term? Over time, value of these interfaces is increasing. Two potential problems: 1. Mission-specific 2. Technology-specific Multi-mission interfaces seem to have better long- term prospects.

Summary Nodes have made progress in usability already, and are very receptive to usability info Usability improvement is an ongoing effort (because of new interfaces) Volume generation is bigger pain-point than volume search Increasing dataset size and proliferation of interfaces pose long-term problems

Questions?