Table of Contents Main Objective of the assessment 1 Description of the Assessment 1 Learning Outcomes and Marking Criteria. 4 Format of the Assessment 6 Submission Instructions. 7 Avoiding Plagiarism... 8 Late Coursework. 8

Assessment Title	Visualisation Design Task
Module Leader	Dr Timothy Cribbin
Distribution Date	10/01/2022
Submission Deadline	25/04/2022 (Final Report and Implementation)
Feedback by	27/05/2022 (Final Report and Implementation)
Contribution to overall module assessment	100%
Indicative student time working on assessment	60 Hours
Word or Page Limit (if applicable)	Maximum of 3000 Words and 20 pages for Report (not including references)
Assessment Type (individual or group)	Individual (see below for a description of the group aspect)

Main Objective of the assessment In this assessment you will develop an interactive data visualisation, using a Tableau, to derive useful insight from a dataset. A successful approach will depend on the nature of your chosen data and the types of questions you set out to answer. For instance, your visualisation might be an information graphic designed for publication on a popular website that tells a factual story around a topic (e.g. changes in third world prosperity over the last decade). Alternatively, your visualisation might be more business-oriented, such as a dashboard designed to help a manager monitor current departmental performance or an analytics tool that helps to inform a key strategic decision. In any case, your final design and implementation will be a composition of multiple views (charts/graphs) presented within a single screen that follows theory and best practice in terms of visual representation, presentation and interaction, as taught in the CS5703/MA5673 classes. You will demonstrate both module learning outcomes through this assessment. To pass these learning outcomes you need to design and implement an interactive data visualisation using data from a specified domain (e.g. social, business, scientific), which communicates some relevant and non-trivial insight to the user (LO1). You should then critically reflect on the issues faced throughout the process and explaining how you applied theory and technical knowledge to resolve these during design and implementation (LO2). You will start the task by working in a small group where you will discover your data and discuss possible questions around this data. However, the final solution and report should be an individual effort. Description of the Assessment task This task involves the development and submission of a Final Report and Implementation that meets the objectives described above. This task contributes 100% to your final grade and you must pass (C- or higher) this part to pass the module overall. Be sure to read and understand the marking criteria, particularly those required for a pass, before proceeding with this part of the task. The report will demonstrate how you have selected a non-trivial dataset, formulated one/two relevant questions and attempted to answer those questions using interactive data visualisation created in Tableau (the implementation). Additional credit will be given for useful and critical reflection on your final solution and general experience of the task process. Task process/timeline You should take a structured approach to the task following the following steps:

• Group Formation (Optional but recommended; by week 21)
• Data selection (Group/individual; by week 24)
• User type/persona specification (Group/individual to create candidates, then individual choice; by week 26)
• Question formulation (Group/individual to pool possible questions for each persona. Individual chooses unique questions; by week 26)
• User requirements specification (Individual; by week 26)
• Prototype design (Individual; preliminary ideas by week 26/27)
• Implementation (Individual; by submission deadline)
• Walkthrough (Individual; by submission deadline)
• Reflective Discussion (Individual; by submission deadline)

Group Formation In the first few weeks of Term 2, you should try to form a group of two or three students. You will support each other in the early stages of the task i.e. data selection and question formulation. You will work together to choose and prepare a suitable dataset (that is compatible with Tableau) and to brainstorm some personas and relevant questions. Being in a group is particularly recommended if you are unfamiliar with working with quantitative data as it will give you a chance to work with and learn from a classmate who is competent in this area (i.e. a DS&A or AI student). If you have not formed or joined a group by week 20, you may ask the module leader to allocate you to a group. You must inform the module leader of your group membership by Week 21 at the latest. All students who are not registered in a group by the end of week 21 will be assumed to be working individually. Data Selection In your group, you will select an appropriate dataset that is both interesting and comprehensible to all members. These data should exist (or be transformable into) a table comprising at least 10 columns (variables) and at least 500 rows (cases) and be in a format that can be downloaded and saved locally (e.g. as an Excel, CSV or SQLite file). If you wish to use a table that you feel is suitable but does not meet these criteria, please discuss with the module leader prior by week 24. Once you begin working individually (i.e. after question formulation step), you are free to extend or adapt the datatable(s) to suit your requirements (e.g. by joining, adding or deriving new columns). However normally, members of your group should all work on the same base dataset. Try to avoid very large datasets that consume excessive system RAM or ones that require complex, dynamic multi-table joins which may significantly impair the run-time responsiveness of your solution. For instance, if you need to perform lots of joins between multiple source tables, consider merging the required data into a single/smaller number of de-normalised tables. If your source dataset is very big (i.e. >50 MB), think about how you can reduce its size by sampling rows and/or pruning unnecessary columns. The data should also come with sufficient metadata and documentation to enable you to formulate valid questions and draw credible conclusions from your analysis. A data dictionary (i.e. a table listing variable names, descriptions and domains) of all variables relevant to your analysis should be included in your report. User type/Persona specification Youll find it easier to formulate interesting and useful questions if you have a specific user type or persona in mind. For instance, if your data relates to crime statistics, you could apply the persona of a house-buyer who is moving to a new town or region and wants to find a safe area to live that is also close to their workplace. An alternative persona might be a senior police officer who wants to monitor current status and changes of crime levels across their jurisdiction. Taking a specific user perspective should make it relatively easy to think of valid questions along with other requirements that would be relevant to such a person. You can brainstorm personas as a group, but normally a specific persona should only be adopted by one member, unless you are able to think of a large number of relevant and distinct questions. If you experience difficulty thinking up sufficient personas or questions you may need to change or modify your dataset. Question formulation You must come up with either one or two distinct questions that your persona might ask. Setting and answering two questions will make it easier to achieve a B grade (see marking scheme below). These should be relevant (to your persona), feasible (using your data) and non-trivial in nature. Most importantly, they should be the kinds of question that are arguably easier to answer using a good visualisation as opposed to standard quantitative analysis method. For instance: Were average house prices in 2014 higher in London or in Birmingham? or Are most violent crimes committed at night? are poor examples because they can both be answered simply by computing and comparing two numbers. On the other hand: How has the ratio of house-prices to median income changed across regions of the UK in the last 10 years? or Which crimes are more common at night and does this vary by season? are better examples because they are open (exploratory) questions that require the analyst to perceive and interpret complex and possibly subtle spatial and temporal patterns in the data. Remember, you can set up to two questions. The second question should be distinct from the first such that it requires a different view (or combination of views) of the dataset to answer. At least one of the questions should be sufficiently complex to require the use of filtering and/or view coordination. This could be cases where the number of variables exceeds three (the limit of the single, efficient image), where there is an excessive number of categories within a dimension, not all of which are relevant to the answer, or multiple dependent measures (i.e. multi-variate analysis). Some examples:

• Which crimes are more common at night and how does this vary by season and location? involves one measure and three different dimensions (time of day, season and location).
• Which UK towns have the highest rate of car theft and which areas within those towns have the highest/lowest rates?, would require a step-wise filtering approach that first narrows down to say the top five towns so that the selection and ranking of areas within those towns can be tractably presented and interpreted.
• Which combination [of five possible] quantitative factors are most predictive of the quality of a wine? has more factors than can be represented in a single chart and a much larger number of possible interactions. It might therefore be necessary to coordinate multiple views, using brushing and linking or possibly dynamic filters, to pin down the optimal combination of factors.

Most importantly, each question should be different from those proposed by other group (and class) members and thus require a different solution. Try to set your questions as early as possible. If you are struggling to formulate suitable, clearly worded questions help will be on hand in the open labs scheduled for weeks 26 and 27. User requirements specification When designing a data visualisation it is important to consider the user requirements (see lecture/lab weeks 23 and lab week 24). These relate to the functional behaviours (e.g. visual encodings, representations and interactions) and other, non-functional qualities or criteria (e.g. data/hardware requirements, look and feel) that your final solution must satisfy to create a good user experience. From a functional perspective, it is essential that the views convey the relationships in the data (see Lecture 3: Representation) that are implied by the question. For instance, the question: Are taller people generally heavier? implies the need to visualise correlation which, in turn, suggests using something like a scatter chart or maybe a regression line chart. On the other hand, the question: Are men heavier than women? implies a comparison between two groups of people (nominal comparison) which would therefore suggest the use of something like a bar chart or possibly box-plots. A more complex question that involves three or more variables will generally need to employ retinal (non-spatial) variables to encode the data and/or the use of interactivity (e.g. a filter widget) to dynamically transform the view based on one or more variables. Specify your requirements as a numbered list (R1, R2 etc). As a minimum, you need one item for each question that you intend to answer. Within each item remember to reference the question number, variables names, and the relationship(s) that need to be represented. As a toy example: Q1: Are taller people heavier? R1: To answer Q1, the user needs to visualise the variables height and weight in a way that conveys the correlation between them. A good view would be a scatter-plot with height on the y-axis and weight on the x-axis. A more complex question might be handled this way: Q2: Which crimes are more common at night and how does this vary by season and location? R2: To answer Q2, we need to visualise the deviation between night and day rates by crime type and rank crime by deviation. A good view would be a bar chart with crime type on the x-axis and deviation on the y-axis. A filter could be used to select different seasons. A map could be used to select different locations. Non-functional requirements might relate to relevant aspects of the users background (e.g. experience using statistical graphics), context of use (e.g. indoors/outdoors, private/public) and the specifications of the device (e.g. screen resolution, mode of interaction) through which they will interact with your visualisation. Aim to produce between three and six distinct requirements and present them in your report as a numbered list (R1, R2, etc). When presenting both your prototype design and final implementation you should make explicit reference to each requirement, explaining how it has been met. Prototype Design You will then take your data, questions and user requirements into account and sketch a prototype design (using the Paper Landscapes or similar prototyping method) to illustrate how your intended solution will look and function. This should be relatively straightforward if you have specified requirements clearly, as described above. Your sketch should be an ideational design created before you have attempted any kind of implementation i.e. your design at this stage should be your ideal solution, guided only by the theory and best practice that you have learnt during the course, not constrained by the limitations (perceived or actual) of Tableau. Pay careful consideration to representation (e.g. visual encodings, chart choice), presentation (e.g. view/axis arrangement, colour schemes) and interaction (e.g. view coordination, brushing and filtering) choices throughout the design and implementation process to ensure you meet your prior requirements (see above). When you design your views, you should pay close attention to the basic principles of good data visualisation as taught in the lectures relating to visual encoding, representation and presentation. This includes (but is not limited to) Bertins theory and Mackinlays guidance on choosing the correct visual encodings and also Fews guidance on choosing the correct representation for the relationship (e.g. comparison, part-whole, correlation etc.) implied by the question. Remember, the view created for question one must be static so the required answer must be evident without the need for any interaction or animation. As a minimum, your design solution should contain at least two different types of chart (e.g. bar, line, choropleth map, Treemap etc.) and at least two separate views (charts) of the data that are composed neatly and coherently into a single screen overview. It is acceptable to re-use the views for question one when answering question two but not necessary. During both design and implementation, you can assume a maximum resolution of 1080p but smaller is permitted, for instance if your intended display medium is a mobile device. You will refine your design, in response to any feedback received and any known constraints or useful functionality imposed by the Tableau software. You should present both the original (pre-implementation) prototype and an annotated screenshot of the final implementation in the report, explaining how and why the design evolved during the implementation process (see below). For a higher grade (DSD students especially) you might also devote some space to discussing how HCI/UCD/UX theory, principles or methods were (or could potentially) be applied to improve the design process and overall user experience. Any discussion of this kind must be properly evidenced with relevant references. Implementation You will implement your original prototype design, as accurately as you can, using Tableau but are free to make justified changes in the process, as described above. In the final report you should describe, clearly and concisely, how you implemented your solution, discussing any significant issues faced during the process and how you overcame them (or not). You do not need to explain every minute step of the implementation process but there must be enough detail to allow a reasonably competent Tableau user (i.e. Tim or Alaa) to replicate your work. You must submit all files required to run your final implementation together with the report. For a higher grade, you can attempt a second implementation using a different tool or language (e.g. Power BI, Vega or Shiny). You are free to use whichever platform you prefer but think about ease of access and use when making your choice. A solution that runs as a stand-alone app (on the desktop or browser) or a Power BI project is ideal. Avoid solutions that require the installation of paid-for software or non-trivial configuration on the part of the marker. If in any doubt, please check with Dr Cribbin before you proceed. You are not required to describe the implementation at the same level of detail as the Tableau solution but you should submit all required files and, at the end of the Implementation section of the report, present a screenshot of the visualisation along with a few sentences (100-200 words) explaining key issues encountered and where/why/how this differs from the proposed design and/or Tableau solution. Walkthrough At the end of the final report, you should evaluate how successful your implementation(s) was in answering your questions. The process of answering your questions and what relevant answers were achieved should be clearly (but concisely) described, using screenshots where helpful. These walkthroughs should be sufficiently detailed to allow a competent third-party (i.e. the marker) to repeat the process using the submitted project. Any answers achieved should be stated explicitly and be consistent with the walkthrough description. Reflective Discussion Finally, you should provide a reflective discussion on the overall success of the project. This should include some justified, project-specific critique of the strengths and weaknesses of Tableau, either by itself or relative to any second platform used. You should also include some considered reflection on your overall learning experience during the module and at least one justified personal learning objective you want to achieve in the near future. Learning Outcomes and Marking Criteria

Learning outcomes for the assessment	Assessment
LO1: Design and implement appropriate visualisation methods/techniques/algorithms for generating value and insight from the processing of heterogeneous data	100% coursework (final report and implementation)
LO2: Critically reflect on data visualisation and the ability of various methods and techniques to effectively present value and insight	100% coursework (final report and implementation)

Marking Scheme for Final Report and Implementation (100%)
Grade	Marking Criteria
A Met the requirements for B+ grade. Also met, to a good standard: A* - all five of these criteria A+ - at least four of these criteria A at least three of these criteria A- at least two of these criteria	An accurate porting of the same design to a different visualisation tool or programming language (e.g. MS Power BI, Shiny or D3/Vega). Views and functionality are generally very similar to those in the Tableau design/implementation. A screenshot is included and briefly described in the report and all files needed to run the solution have been submitted. A critical comparative evaluation of the two tools used to implement the design. The discussion focuses on the task in hand rather than being generic in nature. Note this criterion can be passed even if the second implementation is not successful. Substantive application of advanced and relevant Tableau skills or data visualisation knowledge that significantly exceed those taught on this module. A useful attempt to apply relevant statistical modelling into some part of the visualisation pipeline (e.g. visualising the results of a clustering or factor analysis in some useful way) A reasonable explanation of how HCI/UCD theory, principles or methods were (or could be) applied to evaluate and/or improve the utility, usability or user experience of the solution. References to any theory or methods applied are cited.
B Met the requirements for C+ grade. Also met, to a good* standard: B+ - at least five of these criteria B at least four of these criteria B- - at least three of these criteria. * criteria marked as acceptable (partially met) will count as a half mark. For instance if two criteria are good and two are only acceptable then you will achieve a B- (1+1+0.5+0.5=3) rather than a B.	A coherent and justified discussion of how the design was refined between the prototype design and implementation stages. This can include explicit consideration of constraints imposed by Tableau and/or new ideas that occurred during the implementation process. There is an annotated screenshot of the final Tableau dashboard that is accompanied by a clear explanation of how views are presented in a manner that facilitates question answering (e.g. appropriate sorting of category axes, following conventions relating to colour choice and ordering, views located/aligned to facilitate salient comparisons) and that generally follows good visualisation design practice. A repeatable walkthrough explaining how one of the questions was satisfactorily answered using your implementation (if two tools used, choose the better solution) A repeatable, walkthrough explaining how both questions were satisfactorily answered using your implementation (if two tools used, choose the better solution in each case) Implementation of an interactive filter that that demonstrably supports the answering of a question. Implementation of view coordination (between at least two views) using either brushing and linking or at least one interactive filter shared between multiple views that demonstrably supports the answering of a question. A final reflective discussion that demonstrates significant insight into personal learning on the module along with the identification of at least one future learning objective relating to data visualisation and how this will be achieved
C C- - All criteria met to at least an acceptable standard C As C-, plus at least eight criteria met to a good standard C+ - As above, plus at least fifteen criteria have been met to a good standard Criteria will be assessed and marked as meeting one of the following thresholds: Good clearly meets all aspects of the criterion Acceptable a reasonable if flawed attempt to meet most aspects of the criterion Fail no or very weak attempt made to meet this criterion	Implementation (LO1) An interactive Tableau dashboard that fits into a single screen of resolution 1080p. All views, filters and legends are visible without scrolling, resizing, or rearranging the dashboard. All project and data files required to run the solution are included in the submitted zip file. The project loads and runs without any remedial action required by the user. Comprises at least two different chart types and three separate views and Is consistent with the design work and requirements specified in the report Generally correct choice of encoding of data to visual variables Generally correct/effective implementation of views The Report contains (LO2) A clear introduction to the dataset and its domain (including a clear reference or link to a primary source) A data dictionary that clearly describes all variables relevant to the final solution. One or two clearly defined question(s) that can be feasibly answered using the available data A set of design requirements, specifying the key relationships to be visualised along with any presentational and/or interactive considerations, that are consistent with both the data and questions(s). A clearly annotated Paper Landscape of a preliminary design, which reflects an ideal solution that is independent of the capabilities of Tableau and that is consistent with the stated requirements and could feasibly be used to answer the planned questions. A clearly annotated screenshot of the final dashboard as implemented in Tableau that is consistent with the stated requirements and could feasibly be used to answer the planned questions. A reflective discussion that provides a balanced and critical evaluation the overall success of the final design and implementation At least five relevant references cited, using the Harvard style, in both the body of the report and the bibliography. No more than 3000 words and 20 pages within the main report (excluding references). The correct section structure as advised in the Format of the Assessment below.
D	Fails to meet at least one C grade criterion within either LO1 or LO2
E	Fails to meet at least two C grade criteria across both LO1 and LO2
F	Fails to meet at least six C grade criteria in total (any LO)

Format of the Assessment This submission will comprise all files required to run your implementation, including all required data, along with your final report. All these files should be collated into a single Zip archive file. Please do not submit in any other compression format. The report should be prepared as a Word file (doc or docx) and included in the zip file in its original format. Wiseflow requires a PDF version of the report as the main submission. However, you will be assessed on the Word file that is contained in your zip and submitted as an appendix to the main PDF submission. Both the main project file (e.g. twb or twbx) and all data files required to load and run this project should be included in the zip archive. For Tableau solutions, we strongly recommend saving your final project in packaged (twbx) format, as this generally prevents problems relating to missing data or broken file paths. In any event, prior to submission, you are advised to test your zip file by extracting to a different PC and making sure your project opens and runs as expected. The marker will always try their best, but if they are unable to run your solution without errors your work may be failed on learning outcome one. Following the task description above, the final report should contain this section structure:

• Introduction: A description of the dataset (including source URL) and data dictionary for all variables used, user persona, planned questions and relevant requirements (use the format provided in the Design Exercise in Week 23):
  • Data
  • Persona and questions
  • Requirements
• Design: You should include both the original prototype design (Paper Landscape) and an annotated screenshot of the final implementation. If there are differences between the prototype and the implementation, explain these and their rationale.
• Implementation: Describe how you implemented your design using Tableau. This should not be an exhaustive click-by-click tutorial but should be sufficiently detailed to allow a competent user to replicate your solution. If you did a second implementation, the description can be brief (
• Walkthrough: This should be an illustrated walkthrough that demonstrates the process you followed to arrive at your final answers and, most importantly, what those answers were.
• Reflective Discussion: that critically evaluates the project as a whole including reflections on your personal learning (to date and looking forward) and the relative strengths and limitations of the visualisation tools used.
• References, a list of sources that you cited throughout the report. This should be presented in Harvard format.

Use single line spacing and font size of 10. You are free to add sub-sections within these sections, to improve readability, but do not omit, rename, or change the order of these sections. The main body (excluding cover page and references) of the report should contain no more than 3000 words and 20 pages in length. It is important that you adhere to these limits as any significant excess will result in failure on learning outcome two. Note that your work will be assessed according to the marking scheme by applying the C grade criteria first, followed by the B criteria and then the A criteria. If you fail any of the C grade criteria you will fail the assessment, regardless of whether your work meets any higher criteria. Therefore, please make sure every C grade criterion has been met before submitting your work. Submission Instructions The submission deadlines are detailed at the beginning of this document. You must submit your final report onWiseflowbefore 11:00 (GMT/BST) on the indicated date. You can follow the link toWiseflowthrough the modules section onBlackboard Learnor login in directly athttps://uk.wiseflow.net/brunel. You need to submit two files to Wiseflow for your final report. The first is a PDF of your report document. The second is a Zip file of all supporting project and data files which you will submit as an appendix. The name of both files should contain your student ID number and, optionally, the module code. For instance, you might submit your appendix file as 0123456.zip or CS5803_0123456.zip. Avoiding Academic Misconduct Before working on and then submitting your coursework, please ensure that you understand the meaning ofplagiarism, collusion, and cheating (includingcontract cheating) and the seriousness of these offences. Academic misconduct is serious and being found guilty of it results in penalties that can reduce the class of your degree and may lead to you being expelled from the University. Information on what constitutes academic misconduct and the potential consequences for students can be found inSenate Regulation 6. You may also find it useful to read thisPowerPoint presentationwhich explains, in plain English, the different kinds of misconduct, how to avoid (even accidently) committing them, how we detect misconduct, and the common reasons that students give for engaging in such activities. If you are experiencing difficulties with any part of your studies, remember there is always help available:

• Speak to your personal tutor. If youre not sure who your tutor is, please ask the Taught Programmes Office (TPOcomputerscience@brunel.ac.uk).
• Alternatively, if you prefer to speak to someone outside of the Department you can contact theStudent Support and Welfareteam.

Late Coursework

The clear expectation is that you will submit your coursework by the submission deadline stated in the study guide. In line with the Universitys policy on the late submission of coursework (revised in July 2016), coursework submitted up to 48 hours late will be accepted, but capped at a threshold pass (D- for undergraduate or C- for postgraduate). Work submitted over 48 hours after the stated deadline will automatically be given a fail grade (F). Please refer to the Computer Science student information pages and the Coursework Submission Procedure pages for information on submitting late work, penalties applied and procedures in the case of Extenuating circumstances.

Attachments:

cs5803-course....docx