User Experience Issues

From Data-gov Wiki

Jump to: navigation, search

Contents

Overview

Making something as complex as this project simplified for a user is a tall order, and the steps that should be taken to achieve this are non-trivial. Below are the specific notes that fall under a few common themes that are generally present in a User Experience revision:

  • Transparency: Making both the internal infrastructure as well as the external expectations clear and apparent from the beginning is essential to maintaining interest in the project.
  • Reduction: Reducing the sheer amount of data, particularly the metadata, is more or less essential to making the project more palatable. In no way does this mean eliminating data, or changing anything in that right; simply, changing the way that the data is presented, and the conditions under which it is presented, is what reduction means.
  • Flow: The moment that a new user lands on the main wiki page, there should be a clear path with steps and tutorials on how to complete those steps all the way through a working demonstration. Implementing this sort of documentation would likely go a long way in generating a larger user base that is more excited about the possibilities of using the semantic web.

Necessarily, all the information on this page hinges on who our target audience is. If we are interested in new growth of users who were previously unaware/had never really used semantic web technologies (proselytizing), then we want to take a vastly different approach than if we just wanted to clearly outline all the work being done and who has done it, and where the project is going (documenting). More likely, we use this site for a combination of the two. Currently, it is heavily in favor of a documentation approach with lack of proselytizing through better user experience.

Transparency

When using the current infrastructure, a user is very confused as to how various components of the Data.gov project (the Data catalog, the SPARQL Proxy, Google Visualizations and Demos, etc) fits together, much less how to use the different components. By making the relationships clear, as well as explaining, in a most general sense, who we are, what the project is, and where the different components are located in a straightforward manner would help.

Specific Examples

If we are aiming for creating the "documentation" wiki, we are relatively fine in terms of transparency; the semantic web is a familiar concept to all involved, and the audience targeted in this approach is aware of who we are and what the aims are. However, there still should be a better organization of the "quick links" section on the main page; perhaps the sparql proxy should be included in that set? Thinking about the steps taken during the process of selecting a data set and finishing a demo, and what links are involved in this process typically, would be instructive.

If we are going to proselytize, however, we should of course take this step, but we should also have a very clear, call to action type of link or Header item on the left column of the main page that serves as a welcome section. This would necessitate the creation of a few pages: First, we would want to explain the Tetherless World Constellation, who is involved, what it is tasked with, and what it has done so far. Second, we would want a hub tutorial page explaining the steps one has to take in learning how to use triples to make amazing work: an overview and explanation of RDF, SPARQL, the SPARQL proxy and how it works, what it's role is in the scheme of things is important. Third, we would want to explain the utility of this technology: now that you have the ability to use SPARQL to generate data sets that are interesting, and convert those data sets into any variety of storage (json, xml, etc), what can you do with it? This is where we would show the demos, along with clear demonstrations of the SPARQL used and datasets involved, and why these decisions were made would provide insight for a new user. These types of revealing explanations and overviews and tutorials are missing from the current implementation of the wiki, and new users would likely benefit greatly from even marginal steps in this direction. It should be noted that the guided tour is serving many of these purposes currently, but at a very low level. Currently, the main attraction is the collection of the demos present on the page with some descriptions as to how they were arrived at; this seems like the wrong direction; there should be a few demos with much more detailed description on the process involved from beginning to end.

Reduction

In a general sense, there is too much data, but not enough information on this wiki right now. Data is necessary, and by no means should anything be eliminated or cut out; what should happen, however, is we should revisit templates and design decisions about what to show on the page and what not to show on the page to make it more reasonable for users.

Specific Examples

The Data.gov Catalog should be more humanized, and columns such as Dcterms:publisher and RDF(enhancement) should either be populated or omitted. When looking at an actual dataset, such as Dataset 34 or the more abrasive Dataset 191, it is clear that there is more data than is really necessary. This is the main problem right now; a potential new user looking at the RDF fact sheet would be easily intimidated by the massive set of information that generally is not essential to using the set in most cases; this should turn into a collapsible window; we can see the specific, point by point breakdown about this particular data set, but from a general user's perspective, its too much even in the strict sense that there's really no practical use case for some of the links more often than not. If something is always clicked, however, such as the URL of the data set on Data.gov, the Agency, Description, and perhaps unit of analysis would be most useful; DCTerms:relation is probably not generally useful. Editing templates like these all around the site would generally help in reducing the wiki to only the most useful information, while allowing people who actually want to look under the hood still have that ability.

Flow

The idea of flow dovetails with many arguments made above in the Transparency section. There should be a detailed way of calling a new user to action; in a few simple sentences, we should be able to motivate people to action, and with two or three links, and a very step-by-step approach, we should be holding the user's hand and showing them how to use this very complex set of data and documentation to their benefit. We should not shy away from explaining things with no assumptions about their experience being made, and the tone for this more public-facing side of the wiki should certainly be more casual.

Personal tools
internal pages