1. User Experience
Definitions, Guidelines, Evaluation Criteria
Overview
In order to ensure that developers, researchers, evaluators, and businesses can interact with SPARQL Server
in a predictable and positive way, a broad user experience strategy must be adopted that permeates throughout
both our design, and implementation phases of the product lifecycle. In order to make a cohesive strategy, three
aspects of our user experience guidelines must be set. First, the underlying principles of user experience will be
defined. Second, a set of product­specific guidelines must be created that reflects those principles. Third, for
each major feature of our product set, we will set specific technical goals that reflects those product feature
guidelines. Finally, by applying our user experience plans both in the design and implementation stages, we will
ensure that our products will be met with the highest possible outcomes and satisfaction.
Topics Covered
1. Underlying Principles of User Experience
a. The Five Panes of User Experience
b. The Perceptions of User Experience
c. Understanding the User: How and Why Customers Choose a Database
2. SPARQL Server User Experience Strategies / Requirements
a. Overview
3. Strategies by Product Feature
a. Overview
b. Example
1

2. Underlying Principles of User Experience
Our Point of View
The following panes represent the varying categories of responsibility within a product. Each pane is dependent
on the panes beneath it. The further down the list, the more abstract the responsibilities are.
1. Surface:​ the actual user interface
2. Skeleton:​ the arrangement of things so they’re optimally efficient
3. Structure:​ the informational organization or control flow
4. Scope:​ the pieces and features required to achieve those business goals
5. Strategy:​ the business goals that the finished product is trying to achieve
Customer’s Point of View
All businesses have problems they want to solve, and as long as we understand what users want and don’t
want from us is key to being the technology they choose. In the context of SPARQL Server, users of our product
may be concerned with the following big picture criteria:
● Financial Cost:​ “how much will this cost us to buy a full solution stack? what would be the
development cost to do it ourselves?”
● Time Cost:​ “will a full solutions stack solve our specific needs? how long to build a custom solution?”
● Ease of Use:​ “which product will do what we need with the least amount of difficulty?
● Performance:​ “does this really perform at the scale we need to solve our problems? Can it compute
quickly enough to solve my problem?
● Stability:​ “will this technology cause me time and financial loss due to loss of data, loss of
performance, or other problems with the product?”
● Technology:​ “is this really the right technology solution for our problem? does this technology really
solve the problems it claims to?”
● Innovation:​ “is this technology improving, innovating, and expanding such that it will still be the right
choice a year from now?”
Point of Interaction
Managing a user’s perception of our product is incredibly important. Even if a technology or a product is
perfectly reliable and functional, if there are lackluster interactions between the product and the user, the
perception of the product can end up being that the product is flawed. The following characteristics will define
the ​interaction guidelines​ that shape the perceptions of the product:
1. Clear action statuses:​ “your data is currently in the sorting phase, and will take 3 hours to complete”
2. Technical clarity:​ a non­developer could easily understand what is being said
3. Clear controls and escape routes:​ is it clear how to perform or halt a specific action
4. Consistency:​ attention to detail is consistent throughout the application
5. Tenability:​ operations complete in a short enough time frame that the problem is still relevant
6. Error prevention:​ the product design is obvious and performing the wrong action by mistake is
unlikely
7. Recognition vs Recall:​ a user should not have to remember previous steps in order to proceed
8. Ease of use:​ the product recognizes common use cases and improves your workflow
9. Aesthetics:​ design is comfortable and things that are irrelevant to the user are not presented
10. Error recognition and recovery:​ when errors occur, give clear information and a path to success
11. Help and documentation:​ explain how to use our product when intuitive design fails
2

3.
SPARQL Server User Experience Strategies
The following are a generalized set of positions that incorporates the principles of a good user experience,
broken down into major categories.
● Financial & Development Cost:
○ There should not be technical requirements that create an unreasonable cost requirement
○ The product should be built with use cases in mind, minimizing the need to perform difficult and
redundant tasks repeatedly
○ We should be weary of technical designs that could dramatically slow the progress of the
product’s maturation
○ The product should be stable; the user shouldn’t have to waste time “dealing with” our product
● Consistency:
○ The product should be reliable and stable enough to yield consistent quality
○ The product should not going to be the reason why their application doesn’t work
○ The product should be stable; the user shouldn’t have to waste time “dealing with” our
product
● Performance:
○ The capabilities of loading and querying should be in sync with each other
○ The entire process of loading data should happen in a ​reasonable​ amount of time
○ Optimizations and performance that we promise should ​always​ be true
● Expectation:
○ The product should make a strong effort to consistently and clearly communicate with the user
○ The user should never be able to initiate a process in which there are not clear indicators of the
outcome, good or bad
When designing product features or assessing the current state of a feature, it is strongly recommended that
these types of positions are tested against the feature ­­ doing so may identify aspects of the feature that may
have unintended consequences to the user and the over product’s business goals.
3

4. Strategies by Product Feature
For each major product feature, it is possible to apply a interaction guidelines checklist to the feature, identifying
which criteria are currently met, or not met. From that, it may be easier to identify which issues or weaknesses
of a given feature should be addressed next. Additionally, it could also identify which features are more or less
prone to causing perception problems than others, thus aiding in task prioritization.
Product Feature
Data Loader
Evaluation Date
December 4, 2014
Description
It is a custom tool, built into SPARQL Server, that accepts a file containing triples within a ​Load
Query Statement.​ Once that process has begun, it ingests the data into memory, converts the data
into our proprietary data algebra, undergoes a sorting and hashing algorithm, and commits the
processed data to the filesystem.
User Experience Points (bold indicates the condition is met)
❏ Clear action statuses
❏ Technical clarity
❏ Clear controls and escape routes
❏ Consistency
❏ Tenability
❏ Error prevention
❏ Recognition vs Recall
❏ Ease of use
❏ Aesthetics
❏ Error recognition and recovery
❏ Help and documentation
Score: 2/11
Strategic Requirements Issues
Performance: ​Due to loader algorithm limitations, it is currently not possible to load enough data to
reach our maximum query potential. As a result, users are unable to perform tests to validate that
our query performance can meet the limits that we claim.
Technical Clarity, Clear Action Statuses, Clear Controls and Escape Routes:​ when a load is
initiated, the loader goes into a loading state that is indicated by a the absence of the prompt
character “>”. As a result, for loads greater than 1 minute, it is very unclear if any progress is being
made, and whether or not that load command will proceed and succeed. During that loading state,
the only way to stop a load is to kill the database process altogether, which puts the database at risk
of losing any previously built universe data.
[Each unfulfilled point would be explained]
4