Dynamic Data Infographics Tool for Designers
Project Description for NCSU User Experience Team
Like many other terms in the tech industry, infographics is at risk of becoming a buzzword that really just means data visualization. What originally set it apart though was that it referred to generally hand crafted graphics (in the poster/graphic design sense) that conveyed information and data concisely to the user. The infographic might contain pie charts, bar chart, or other highly decorated versions of well-known data visualizations, but individually they aren’t infographics.
Infographics, for this project, is a graphical representation made up of several visual elements such as graphs, images, and text, put together to tell a specific story presented with contextual references to the data. We look at infographics as primarily a presentation method.
Static infographics are often created in graphics programs such as Adobe Illustrator or PowerPoint. If we were targeting a static graphic, having a plugin for Illustrator that allows the content of a SAS report to be placed and sized before being rendered as fully editable vector shapes would get us most of the way there.
However, we are focused more on the dynamic and interactive infographics similar to those created by the NY Times and other publications. We are already capable of creating dynamic/interactive dashboards, but our current report building tools fall short of some of the customizability a designer wants to really make the document tailored to the message they want to convey. To see our current report builder in action you can use the trial server:
One of the key abilities of SAS reports is to operate on dynamic data. A lot of infographic designs can be fragile where the data the visual was initially designed for fits nicely, but changing the data would break the design. If we can provide constructs that support dynamic data while maintaining the customized design of infographics then we will have given report authors something they can’t easily achieve through other means.
So, coming to the design problem: Conceptualize a tool that can build visual representations of data and allow users to insert context into the visual, while ensuring the data for the visual can change without requiring the author to redesign the report. The deliverable will be the design spec for the tool and a prototype to show basic functionality.
Note that although your work may result in new visualization suggestions, this is not a project to create new types of visualizations. You may use traditional graphs and allow the user to augment it in some manner.
Dr. Watson’s class will be held Tuesday and Thursday at 9:30 in EBI 1005. Three teams of five students will work on the SAS project with participation from on the SAS side from on of the UX managers and three designers:
Rajiv Ramarajan (Rajiv.Ramarajan@sas.com)
Riley Benson (Riley.Benson@sas.com)
Lisa Everdyke (Lisa.Everdyke@sas.com)
Brandi Gull (Brandi.Gull@sas.com)
NC State students are divided into three teams:
Team 1
Bastikar, Shreya (sbastik@ncsu.edu)
Desai, Juhi Devang (jddesai@ncsu.edu)
Dhruve, Ravina Rajesh (rrdhruve@ncsu.edu)
Nisher, Ronak Pravin (rpnisher@ncsu.edu)
Seth, Vedika (vseth@ncsu.edu)
Team 2
Gopalan, Sharan (sgopala6@ncsu.edu)
Nallabothu, Yashwanth (sgopala6@ncsu.edu)
Pandey, Nitish (sgopala6@ncsu.edu)
Pise, Ankita Arun (aapise@ncsu.edu)
Taylor, Jesseca Rosanne (jrisrael@ncsu.edu) (primary contact)
Team 3
Ganesh, Sushil (sganesh4@ncsu.edu) (primary contact)
Gupta, Prashant (pgupta7@ncsu.edu)
Mirajkar, Sayali Achyut (samirajk@ncsu.edu)
Naik, Shraddha Anil (sanaik2@ncsu.edu)
Roychoudhury, Ritwika (rroycho@ncsu.edu)
The target audience for the tool will be report designers using a SAS provided web client for creating dynamic documents for their company or organization. The knowledge domain for the reports can vary from designers who are creating highly secure reports just for executives of a large company to a publicly viewable report on the operations of government bodies. Report author education will likely be in some form of Communications or Business and will often have some basic statistical knowledge but will not be an expert in SAS, advanced analytics, or programming languages.
However, report authors will posses domain knowledge and context. For example if they are creating a report on the distribution of students in the public schools for a county then they are probably aware of the typical norms for classroom sizes and some of the flags to look for to find issues.
There are no technology constraints on the prototype as it is not planned for direct inclusion in a SAS product. Whatever supports the fastest iteration for you and allows you to best communicate your design ideas is perfectly fine.
We are open to any testing data that you would like to use. Preferably it would provide enough data variety to let you consider showing comparisons, trends, and geographic type visualization. A possible suggestion is the Raleigh Fire Incident dataset which goes all the way to 2007. There is even a public API that can be used to query and aggregate data which should save them some development time:
https://data.raleighnc.gov/Fire/Fire-Incident-Data-January-1-2007-to-Most-Current-/g69m-36bw
You could test the dynamic data issues by selectively filtering out certain time ranges or fire stations to simulate the addition of new rows to the data.
The SAS team can help with finding a story to tell in this data if needed, but as long as you have the time to examine it I think it would be good if each team devised a story as it will force you to undergo part of the process the end user of the tool you are designing will have to use. The story doesn’t need to be correct or compelling really, as long as it is a story. So if you want to communicate that less than 2 fires handled by a fire station per month is unacceptable that would be valid.
For a smaller set of data for a few months these seem to already be saved out as separate tables and so would be good for testing against the API as calls won’t take as long to run I expect:
https://data.raleighnc.gov/Fire/Fire-Incident-Data-January-2014/sa5a-jxyi
https://data.raleighnc.gov/Fire/Fire-Incident-Data-February-2014/vbex-j7zh
https://data.raleighnc.gov/Fire/Fire-Incident-Data-March-2014/seq8-f7ev
https://data.raleighnc.gov/Fire/Fire-Incident-Data-April-2014/hty5-cdw8
The precise feature set for the tool being created is not strictly defined. Instead several use cases for features of the infographics being created are provided with examples. Any feature set for the tool that allows the report author to include these features in their infographic is acceptable.
Terms
Annotations of data shown in a visualization (link, link, link).
2) Block of text with dynamic values, links, or controls inside body (link, link, link).
3) Replace elements in a visualization (bar/marker) with an image. (link, link, link, link, link)
4) Connect an image or other visualization to a element in a visualization (link, link).
5) Customized visualization, images, and text in tooltips (link).
6) Attach/overlay image or custom content to entire visualization (link, link).
7) Use overlayed or masking images to provide decoration or context (link, link).
13) Sparkline graphics in tables and text blocks (link, link).
8) Setup disclosure timings and transitions to provide story guidance through report (link, link, link).
9) Setup disclosure timings and transitions based on scrolling/navigation (link).
10) Choose your own path or cumulative result through a report (link).
11) Anchored view responding to focus in a visualization (link).
12) Link data ranges across incongruous visualization types (link).
14) Setup animation transitions between visualization presentation states (link, link).
15) Images and custom content in filtering controls (link).
16) Custom illustrated legend (link).