ImpVis Wiki - User contributions [en-gb]

Module Timetable

2022-12-01T13:07:12Z

Cclewley: /* Intended learning outcomes */

Module Timetable

2022-11-21T15:03:54Z

Cclewley: /* Week 8: Project work - finalising your draft design */

Module Timetable

2022-11-07T15:41:00Z

Cclewley: /* Asynchronous work after the session */

Module Timetable

2022-10-14T15:03:27Z

Cclewley: /* Asynchronous work after the session */

Module Timetable

2022-10-14T14:05:16Z

Cclewley: /* Asynchronous work after the session */

Module Timetable 2021

2022-10-14T12:51:58Z

Cclewley: Created page with "This timetable is intended as a guide only to help you understand the structure of the course and the progress you should be making by different points. Each week includes a..."

This timetable is intended as a guide only to help you understand the structure of the course and the progress you should be making by different points.

Each week includes a description of the timetabled session activities, the intended learning outcomes for that session, a summary of the asynchronous work for you to complete in between the sessions and the recommended progress status of your project. We will post exact details of the asynchronous work, including links and instructions, on the Teams channel.

Note that we will adapt to the cohort's needs throughout the module, which means the schedule may change accordingly. More specific details may be added as the module progresses - keep an eye on the developments of this page (e.g. by clicking 'View history' at the top)!
==Week 1: Introduction to Course==
===Description===
This week we will discuss the aims of the module and how the module will run. We will also take time to get to know each other and explore the platforms we will be using throughout the module. Finally, we will think about how we learn abstract concepts in STEMM and what role visualisation can play to aid understanding.
===Intended learning outcomes===
By the end of this session, you will be able to:
*navigate the module platforms and find relevant information;
*strike up a conversation with your peers and the module team;
*describe the ImpVis project and how this module fits into the overall project;
*discuss how students learn abstract concepts in STEMM and how visualisations can help students gain a deeper understanding.
===Asynchronous work after the session===
*Fill out a short form to help us assign you to a project group.
*Familiarise yourself with the portfolio template and fill out the reflective questions for week 1.
==Week 2: Project Introduction==
===Description===
This week you will find out your project and start working together with your project team. We will also have a guest talk by Dr Freddie Page about his own experiences designing & developing interactive visualisations. We will start thinking about what we think is important for a 'good' design of an interactive visualisation.
===Intended learning outcomes===
By the end of this session, you will be able to:
*explain what the topic is of your project and identify your project team partners;
*start applying the principles of working in partnership in your team work;
*outline the design & development process of an interactive visualisation for education;
*give a rudimentary opinion on what is important for the design of an effective visualisation.
===Asynchronous work after the session===
*Meet your staff partner to discuss your project and decide on how you will work together.
*Research your project topic so you can explain it to your peers.
*Insert (at least) one education resource that you found useful for understanding your project topic into your portfolio.
===Recommended project progress===
By the end of session 2, aim to:
*know what your project topic is and who your project (student) partners are,
*have signed up to your project on the ImpVis website ([https://impvis.co.uk/code Code environment]).
Before the start of session 3, aim to:
*have inserted your name on your project's Wiki page as a contributor and familiarised yourself with the Wiki.
*understand enough of your project topic so you can explain it to your peers.
==Week 3: Educational Design==
===Description===
This week we will have a guest talk by Dr Juan Nunez, who is an instructional designer in Imperial's Interdisciplinary Ed Tech Lab team. We will discuss which educational principles should be foremost in our mind when designing educational learning tools and attempt to apply these to our own projects.
===Intended learning outcomes===
By the end of this session, you will be able to:
*explain the most important educational principles underpinning our visualisation designs;
*evaluate and update the intended learning outcomes of your visualisation project;
*propose a way to create a scaffolded learning journey, tailored to your visualisation's learners' needs.
===Asynchronous work after the session===
*Meet with your staff partner and update your project's learning outcomes, based on what you have learned in session 3.
*Explore two given examples of visualisations and identify the educational principles underpinning its design - note these down in your portfolio.
===Recommended project progress===
By the end of session 3, aim to:
*have evaluated the existing aim & learning outcomes of your project and decided on whether any improvements are needed;
*have a rudimentary idea of how the visualisation's learning journey may be scaffolded.
Before the start of session 4, aim to:
*have updated the aim & learning outcomes of your project on your Wiki page & project Miro board;
*have collated your ideas on how to scaffold the learning journey on your project Miro board.
==Week 4: Graphical Design==
===Description===
This week we will have a guest talk by a graphic designer, explaining the principles of good graphic design. We will also discuss how this applies to your project and what graphical elements you may want to include in your visualisation.
===Intended learning outcomes===
By the end of this session, you will be able to:
*explain the most essential graphic design principles underpinning our visualisation designs;
*propose suitable graphical elements for your visualisation design;
===Asynchronous work after the session===
*Meet with your staff partner and discuss the graphical elements that could be included in your project, based on what you have learned in session 4.
*Find one example of 'good' graphic design (in your opinion) and one example of 'poor' graphic design (in your opinion) - insert and explain these in your portfolio.
===Recommended project progress===
By the end of session 4, aim to:
*have a range of ideas for graphical elements and 'graphical do's & don'ts' for your visualisation.
Before the start of session 5, aim to:
*have collated the most promising ideas for graphical elements + do's & don'ts on you project Miro board.
==Week 5: Interaction Design==
===Description===
This week we will hear from Prof Bob Spence about the fundamentals of human-computer interaction design. We will also experiment with different interactive components that currently are offered in the ImpVis template and discuss what interactive elements could be included in our visualisation designs.
===Intended learning outcomes===
By the end of this session, you will be able to:
*explain the most fundamental human-computer interaction design principles underpinning our visualisation designs;
*propose suitable interactive elements for your visualisation design;
[[File:VisCritique.png|thumb|An example of how students should critique their chosen visualisation.]]
===Asynchronous work after the session===
*Meet with your staff partner and discuss the interactive elements that could be included in your project, based on what you have learned in session 5.
*Choose an interactive visualisation for education and critique it with respect to its education, graphic and interaction design (see example to the right). Insert this into your portfolio.
===Recommended project progress===
By the end of session 5, aim to:
*have a range of ideas for interactive elements and 'interaction do's & don'ts' for your visualisation.
Before the start of session 6, aim to:
*have collated the most promising ideas for interactive elements + do's & don'ts on you project Miro board.
==Week 6: Project work - defining individual responsibilities==
===Description===
This week we will start the visualisation design project work in earnest. We will finalise our thoughts on what makes a 'good' design of an interactive visualisation for education and formulate these, as a cohort, as the assessment criteria for our designs. Each project team will then decide on what needs to be done in order to create a 'good' design (according to these criteria). This will lead to a 'task tree'. Following on from this, you will complete a 'skills matrix' with your team in order to assign responsibilities to each project partner. Based on these responsibilities, you will define your own personal learning goals. This will form the basis of how you will work together as a team.
===Intended learning outcomes===
By the end of this session, you will be able to:
*describe what in our collective opinion constitute the principles of 'good' design of interactive visualisations for education;
*explain what will need to be done for your project to be successful and describe each project partner's responsibilities and relative expertise, including your own;
*identify what you are aiming to learn from your personal contribution to and participation in this visualisation project over the coming weeks.
===Asynchronous work after the session===
*Meet with your staff partner to discuss progress on the project.
*Carry out independent research as decided within your project team.
===Recommended project progress===
By the end of session 6, aim to:
*have a completed task tree and skills matrix, with individual responsibilities assigned to each project partner - ensure these are visible on your project Miro board.
*have identified your personal learning goals and inserted these in your portfolio.
Before the start of session 7, aim to:
*have completed your first tasks and carried out some independent research
*have a range of specific ideas for components or content for your visualisation - these do not yet need to be synthesised into a single design. For example, how will your visualisation be structured (will it be a single page or multi-page visualisation)? What will be your main graphical elements? What, if any, text descriptions should be included? What types of interactivity will you implement?
===Example resources===
Read about the task tree, skills matrix, and personal learning goals [[Tasks Tree|here]]. You can also view examples of these elements on [https://miro.com/app/board/o9J_ls7JFEY=/?invite_link_id=459778164334 this Miro board].
==Week 7: Project work - supporting each other's progress==
===Description===
This week is dedicated to discussing your progress with your project team as well as with peers from other project teams. You will spend about half the session with people from other project teams who are trying to find answers to similar questions as yourself, so you can share findings, tips and expertise. The other half will be with your project team in order to debrief each other on the progress you've made and synthesise your ideas into one coherent design idea.
===Intended learning outcomes===
By the end of this session, you will be able to:
*communicate findings and ideas with others who have a similar interest;
*evaluate input from others in order to help them improve their ideas as well as improve your own ideas;
*collaborate within your project team to combine different perspectives and findings into an effective, coherent design.
===Asynchronous work after the session===
*Continue independent research and work on your project, based on progress made during the session.
*Meet with your staff partner to discuss progress.
===Recommended project status===
[[File:Page1 Revised.png|thumb|An example of a synthesised design presented in rough format, as recommended by the end of session 7.]]By the end of session 7, aim to:
*have a detailed, synthesised idea of how your visualisation will look, what components it will include and what text content it will feature, all presented in a rough format;
*have added information into your Wiki page detailing design decisions and their rationale (i.e. why have you chosen to do it this way?).
Before the start of session 8, aim to:
*have an updated Wiki project page with further individual research findings;
*have prepared individually improved components of the visualisation design, presented in a better format.
==Week 8: Project work - finalising your draft design==
===Description===
This week you and your project team will finalise your project design draft. The entire session will be dedicated to project work, either in your own project team or comparing notes and discussing feedback with other project teams.
===Intended learning outcomes===
By the end of this session, you will be able to:
*Agree on a fully worked-out and synthesised design with your project partners.
===Asynchronous work===
*Meet with your staff partner to discuss the progress of your design.
*By Wednesday end of day: submit fully worked-out draft design with justifications on Wiki project page.
*From Thursday: review two other designs and fill in feedback template.
===Recommended project status===
[[File:Page1 Final.png|thumb|An example of a more polished visualisation design, which you should have in week 8.]]By the end of session 8, aim to:
*have a synthesised, mostly complete visualisation design that is well presented;
*have a clear plan of / template for your submission format (e.g. a Miro board dedicated to the design draft with a clear structure).
By the submission deadline, aim to:
*have an up-to-date Wiki project page with your group's progress a nd design choices, which is mostly complete;
*have your design ready in your submission format, graphics presented to whatever standard is possible with the timeframe and resources (taking into account your project team's skills and software used).
==Week 9: Review session==
===Description===
This session we will undertake a formal review session, where each project team will give specific feedback to two other project teams. The feedback will be prioritised as follows: red - critical issues to be fixed in order to meet the assessment criteria; orange - recommended improvements to make the design better; blue - possible suggestions / inspiration for further work; green - exemplary features in the design that others should implement too.

Following the review, you will discuss the feedback given and received in your project team and decide on final improvements to make to your design before the final submission.
===Intended learning outcomes===
By the end of this session, you will be able to:
*evaluate other teams' designs in order to identify points for improvement as well as exemplary features you can incorporate in your own design;
*communicate feedback to other teams with a clear prioritisation in a constructive manner;
*reflect upon feedback received and agree within your project team whether and how to act upon this feedback in order to improve your design.
===Asynchronous work===
*Implement the final improvements to your design, as agreed with your team during the session.

*Meet with your staff partner in order to all agree on the final design;
*Finalise your submission for the design exhibition, including visual design representation as well as fully worked-out Wiki project page with design justification and ideas for further work.
===Recommended project status===
By the end of session 9 you should aim to:
*have a clearly worked out list of actions to undertake to finalise your submission;
*have agreed exactly who will take responsibility for which actions.
Before session 10 you should aim to:
*have agreed your design with all project partners and indicate this on your [https://wiki.impvis.co.uk/Mana project management environment] on the ImpVis website;
*have submitted your design exhibition submission, together with a fully worked-out Wiki project page with design justification and ideas for further work.
==Week 10: Design exhibition==
This week all project teams will showcase their designs to each other as well as external people who will assess the designs according to the assessment criteria created by the whole module cohort. Afterwards, we will reflect upon what we have learnt throughout the module and discuss how you (or others) can take your design forwards to a fully working visualisation to be implemented within the intended module of the staff partner.
===Intended learning outcomes===
By the end of this session, you will be able to:
*communicate your design and its justifications to both peers and external staff and students;
*reflect upon your learning during the module and the evolution of your relationship with your partners;
*decide whether you would like to stay a member of the ImpVis community and contribute to further visualisation designs or the development (programming phase) of visualisations.
===Asynchronous work===
*Complete the reflection tasks in your portfolio;
*Complete your self-assessment, based on your reflections and your personal learning goals;
*Submit portfolio & self-assessment by a pre-agreed deadline.
Congratulations, you have successfully completed the ImpVis module. We hope you enjoyed the journey and will be able to see your visualisation design in action in its intended module in the next academic year!

Module Team Records

2022-09-12T15:11:42Z

Cclewley: /* 6 ILOs were based on last year’s + a few changes */

[[Category:Records]]
[[Category:Summer 2022]]

== Assessment ==

=== Summary: ===

* 6 ILOs were based on last year’s + a few changes

* Different ways we could assess, or activities related to the ILOs were proposed
* Table was made to vote on what should be assessed in the end or not
* Decision taken on how to distribute the marks

=== Detailed achievements: ===
The learning outcomes of the module were relooked at and changed to allow for the final mark to be equally graded on group and personal involvement. The assessment was also made more wholistic to accommodate for different goals, pace, and paths that individuals and groups may choose. This meant having reflection and output-based assessments which allow for an individual to get a good grade should they not be able to do either of them.

The marking scheme was also done in a way to maximise fairness in the case of group work that has gone badly or in the case of individuals that have done no work.

=== Learning: ===
We learnt that it is important to always go back to decisions made and evaluate whether any change needs to be made. We noticed that we had initially decided asynchronous worked shouldn’t be assessed but then when “mapping out” all the different unfair scenarios that could happen to a group, we realised it would actually be best to assess it.

=== What we didn’t do: ===

* Give a well/exemplary mapped sample of a finished project involving feedback, reflections, thought process, and the journey.
* Yet to finish what to look for when marking a portfolio, how marks are given.

=== Next step: ===
Make clearer criteria for each of the components of the assessment so that whoever will be marking will know what to look for.

=== Progress that has been made so far can be seen here: ===

[https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764527829325574&cot=14 Miro Board Assessment and ILOs]

== Platforms/Software for the Module: ==

=== Summary: ===

* We investigated and researched the best tools for time-management and blended learning, with the aim to promote better group working between students on the module.

(Add to scope at the end).

* Caroline (module lead) explained that she wanted groups to learn to work better together, so we decided that time-management and blended tools would be best placed to allow this.

=== Detailed achievements: ===

* (revisit)

=== Output: ===

* The main software options we researched into and tested are as follows:
* Microsoft Teams
* Discord
* GatherTown

* Miro
* Airtable
* The information we gathered and our opinions on the best possible option can be found at this link: [https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764528600558707&cot=14 Learning Tools Comparison]

=== Items I meant to do but did not do: ===
We investigated Teams ChatBots, such as ScrumGenius and their potential to be integrated into our chosen learning tool/software. However, we did not take this forward due to lack of time, and inability to request access to these.

=== Learning: ===
We realised that certain tools, specifically Miro, are most effective when used synchronously. From this, we gathered that effective scaffolding and prompting is necessary to ensure for equal participation within groups. We were able to demonstrate this within our own meetings as a module team, and when requesting for feedback from our wider Student Shaper group. Using Miro, we were able to receive feedback instantly from all members of our group.

=== What we didn’t do: ===

* Decide on what platform we will be using ie, discord or teams and how will it be monitored.

== Reflections ==

=== Summary: ===

* Two different types of reflections were deemed important: self and group
* Lists of questions were prepared for each
* The group reflections were tested out on the student shapers team

* Dhruv and Dalia tested out the self-reflections
* Templates were made for the group reflections but still debating whether they will be just for TA use or shown to students too

=== Detailed achievements: ===
The reflection component of the module was restructured to go hand in hand with the revised learning outcomes of the module. With students now not giving themselves a grade, we had to design a reflection that allowed examiners to assess the quality of reflections and level of engagement with the module and thus the progress an individual has made during the module. We were able to create templates for group and personal reflections that allowed individuals to set goals for themselves, reflect on the goals, reflect on their group, and give feedback to each other.

=== Output: ===

* Group reflection: 3 times during the entire module
* Self-reflection: Every two weeks
* Final reflection

Most of our reflections were based off the work and journey we had and not an accurate representation of what the students taking up the module would face. A limitation was that we did not have feedback from the people who were taking up the module.

=== Learning: ===
By making the StudentShapers participants take the group reflections, we learnt a lot about what can be improved. We concluded that having the reflection done anonymously would be much more beneficial and effective than doing it on a Miro board while everyone can see. That was because we would be influenced by what others have said.

We also realised that, if taken seriously, the reflection can be really helpful in terms of improving group work and it adds some intentionality into what we are doing.

=== What we didn’t do: ===

* Sample of filled personal reflections?

=== Next step: ===
Making the finalised google doc forms or the alternative way that we will be doing this.

=== Progress that has been made so far can be seen here: ===

* [https://imperiallondon-my.sharepoint.com/personal/dt419_ic_ac_uk/_layouts/15/Doc.aspx?sourcedoc=%7BC628E9A5-2BA5-409F-9225-E69CB7756F6D%7D&file=Self-%20Reflection.docx&action=default&mobileredirect=true Self reflections]
* [https://imperiallondon-my.sharepoint.com/personal/dt419_ic_ac_uk/_layouts/15/Doc.aspx?sourcedoc=%7BC3926CDD-DB22-4D29-8839-488953F62A19%7D&file=Group%20Reflection.docx&action=default&mobileredirect=true Group reflections]

== Visualisation resource scaffolding ==

=== Summary of scope of project area: ===

* We introduced this as a new component of group work, to be assessed as pass/fail (carrying no weighting), to be included in the group portfolio.
* We decided this, after generating our own example projects and realising that a resource was necessary for the visualisation topic to be understood by members of our group who had no prior knowledge of the topic.
* Whilst we did not produce a finalised version of the resource scaffold (partly due to lack of time),
* We think that including a visualisation resource will benefit all students by helping them to better understand their visualisation topics, especially those with less familiarity with it.

* Through the design of our own resources, we identified the following benefits:
** Students gain a more thorough understanding of their topic since they must carefully plan and carry out in-depth background research around it.
** Allows students to design more useful ILOs, due to the thorough research they have carried out.

=== Output: ===

* Visualisation resource for ‘Heat Transport Visualisation’ example:
** Note that this resource does not follow a scaffold, but is an in-depth background research into the topic, including calculations.
** Link to pdf: [https://imperiallondon-my.sharepoint.com/:b:/g/personal/he120_ic_ac_uk/EX-uj1X2I_lPvpZ5TiAFRssBH8pS-cILTib3MHf1fED1wg?e=OYZmhh Heat_Transport_Visualisation_v4.pdf] (link accessible to Imperial students only).

* Visualisation resource for ‘Surfactant Concentration and Surface Tension’ example:
** This resource followed a more scaffolded approach.
** Link to Miro Board: [https://miro.com/app/board/uXjVOkE5LMg=/?share_link_id=285064772345 Surfactant_Conc_Resource] (link accessible to anyone).

=== Learning: ===
A lot of learning happened while making the visualisation resource scaffold, and it is still happening as we have not yet finalised it. It has proved to be quite a challenging task because there are many ways to go about this and we do not want to be hindering the student's creativity, but we also do not want to leave them with too much uncertainty and too many decisions to make that might be a waste of time or deviating from the main project.

* Didn’t have time to meet with Caroline about this – didn’t get further than taking feedback.

== Module Timeline ==

=== Summary: ===

* Rough module timeline was made
* Divided based on the different reflections and feedback sessions

* Didn’t have time to discuss with module team
* All the team contributed to an analogous timeline for the whole process

=== Detailed achievements: ===
The module timeline is vague and not much time was dedicated on perfecting it as other things were more important at the time such as the assessment and reflections.

=== Learning: ===
We learnt that experience and specifically sharing experiences is important in order to get a complete and comprehensive view. This was obvious when creating the timeline of the project as everyone had to pitch in their ideas.

Also learnt that missing the expertise can make it quite difficult to plan what would happen in the sessions.

=== Next step: ===
Still need to think up ideas for workshops and how each session will be run.

Need to contact people who can help lead that and have more expertise in design and coding.

=== Progress that has been made so far can be seen here: ===
[https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764528875305516&cot=14 Timeline of the module]

[https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764529313630859&cot=14 Timeline of the project]

== Group formation: ==

=== Summary: ===

* Two scenarios were proposed: A (groups work on one project from start to end), B (groups can start from the middle of a project or start and finish wherever deemed sensible)
* Pros and cons for each were written out in a table

* Criteria was made based of that and added into a table to vote on which scenario fits it best
* After voting, it was concluded that scenario B was more favourable

=== Detailed achievements: ===
Once it was decided that scenario B would be best, all the cons that it had were evaluated and a table was made with all the issues it has and with ways to mitigate those and action required.

Most of the unfairness was fixed when the assessment was made. However, there still are some things to do.

=== Learning: ===
We learned the significance of thoroughly thinking through different scenarios and evaluating each criterion individually before coming to a unanimous decision on what would be the best thing to do. We also learnt that even once we concluded that scenario B would be better, there still were some cons we had previously mentioned that had to be dealt with.

=== What we didn’t do: ===
- How the groups may be formed? Using the skills matrix?

=== Next step: ===

* Need to create a list of all possible skill sets that students would want to work on, and the list of all the possible projects they can work on.
* Provide a flow chart to help with choosing the topic.
* Making the form that students will need to fill to have fairly distributed groups.

=== Progress that has been made so far can be seen here: ===
[https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764528163586540&cot=14 Miro Board with the tables described above]

Module Team Records

2022-09-12T13:45:58Z

Cclewley: Copied content from Google Doc (and formatted)

[[Category:Records]]
[[Category:Summer 2022]]

== Assessment ==

=== Summary: ===

=== 6 ILOs were based on last year’s + a few changes ===

* Different ways we could assess, or activities related to the ILOs were proposed
* Table was made to vote on what should be assessed in the end or not
* Decision taken on how to distribute the marks

=== Detailed achievements: ===
The learning outcomes of the module were relooked at and changed to allow for the final mark to be equally graded on group and personal involvement. The assessment was also made more wholistic to accommodate for different goals, pace, and paths that individuals and groups may choose. This meant having reflection and output-based assessments which allow for an individual to get a good grade should they not be able to do either of them.

The marking scheme was also done in a way to maximise fairness in the case of group work that has gone badly or in the case of individuals that have done no work.

=== Learning: ===
We learnt that it is important to always go back to decisions made and evaluate whether any change needs to be made. We noticed that we had initially decided asynchronous worked shouldn’t be assessed but then when “mapping out” all the different unfair scenarios that could happen to a group, we realised it would actually be best to assess it.

=== What we didn’t do: ===

* Give a well/exemplary mapped sample of a finished project involving feedback, reflections, thought process, and the journey.
* Yet to finish what to look for when marking a portfolio, how marks are given.

=== Next step: ===
Make clearer criteria for each of the components of the assessment so that whoever will be marking will know what to look for.

=== Progress that has been made so far can be seen here: ===

[https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764527829325574&cot=14 Miro Board Assessment and ILOs]

== Platforms/Software for the Module: ==

=== Summary: ===

* We investigated and researched the best tools for time-management and blended learning, with the aim to promote better group working between students on the module.

(Add to scope at the end).

* Caroline (module lead) explained that she wanted groups to learn to work better together, so we decided that time-management and blended tools would be best placed to allow this.

=== Detailed achievements: ===

* (revisit)

=== Output: ===

* The main software options we researched into and tested are as follows:
* Microsoft Teams
* Discord
* GatherTown

* Miro
* Airtable
* The information we gathered and our opinions on the best possible option can be found at this link: [https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764528600558707&cot=14 Learning Tools Comparison]

=== Items I meant to do but did not do: ===
We investigated Teams ChatBots, such as ScrumGenius and their potential to be integrated into our chosen learning tool/software. However, we did not take this forward due to lack of time, and inability to request access to these.

=== Learning: ===
We realised that certain tools, specifically Miro, are most effective when used synchronously. From this, we gathered that effective scaffolding and prompting is necessary to ensure for equal participation within groups. We were able to demonstrate this within our own meetings as a module team, and when requesting for feedback from our wider Student Shaper group. Using Miro, we were able to receive feedback instantly from all members of our group.

=== What we didn’t do: ===

* Decide on what platform we will be using ie, discord or teams and how will it be monitored.

== Reflections ==

=== Summary: ===

* Two different types of reflections were deemed important: self and group
* Lists of questions were prepared for each
* The group reflections were tested out on the student shapers team

* Dhruv and Dalia tested out the self-reflections
* Templates were made for the group reflections but still debating whether they will be just for TA use or shown to students too

=== Detailed achievements: ===
The reflection component of the module was restructured to go hand in hand with the revised learning outcomes of the module. With students now not giving themselves a grade, we had to design a reflection that allowed examiners to assess the quality of reflections and level of engagement with the module and thus the progress an individual has made during the module. We were able to create templates for group and personal reflections that allowed individuals to set goals for themselves, reflect on the goals, reflect on their group, and give feedback to each other.

=== Output: ===

* Group reflection: 3 times during the entire module
* Self-reflection: Every two weeks
* Final reflection

Most of our reflections were based off the work and journey we had and not an accurate representation of what the students taking up the module would face. A limitation was that we did not have feedback from the people who were taking up the module.

=== Learning: ===
By making the StudentShapers participants take the group reflections, we learnt a lot about what can be improved. We concluded that having the reflection done anonymously would be much more beneficial and effective than doing it on a Miro board while everyone can see. That was because we would be influenced by what others have said.

We also realised that, if taken seriously, the reflection can be really helpful in terms of improving group work and it adds some intentionality into what we are doing.

=== What we didn’t do: ===

* Sample of filled personal reflections?

=== Next step: ===
Making the finalised google doc forms or the alternative way that we will be doing this.

=== Progress that has been made so far can be seen here: ===

* [https://imperiallondon-my.sharepoint.com/personal/dt419_ic_ac_uk/_layouts/15/Doc.aspx?sourcedoc=%7BC628E9A5-2BA5-409F-9225-E69CB7756F6D%7D&file=Self-%20Reflection.docx&action=default&mobileredirect=true Self reflections]
* [https://imperiallondon-my.sharepoint.com/personal/dt419_ic_ac_uk/_layouts/15/Doc.aspx?sourcedoc=%7BC3926CDD-DB22-4D29-8839-488953F62A19%7D&file=Group%20Reflection.docx&action=default&mobileredirect=true Group reflections]

== Visualisation resource scaffolding ==

=== Summary of scope of project area: ===

* We introduced this as a new component of group work, to be assessed as pass/fail (carrying no weighting), to be included in the group portfolio.
* We decided this, after generating our own example projects and realising that a resource was necessary for the visualisation topic to be understood by members of our group who had no prior knowledge of the topic.
* Whilst we did not produce a finalised version of the resource scaffold (partly due to lack of time),
* We think that including a visualisation resource will benefit all students by helping them to better understand their visualisation topics, especially those with less familiarity with it.

* Through the design of our own resources, we identified the following benefits:
** Students gain a more thorough understanding of their topic since they must carefully plan and carry out in-depth background research around it.
** Allows students to design more useful ILOs, due to the thorough research they have carried out.

=== Output: ===

* Visualisation resource for ‘Heat Transport Visualisation’ example:
** Note that this resource does not follow a scaffold, but is an in-depth background research into the topic, including calculations.
** Link to pdf: [https://imperiallondon-my.sharepoint.com/:b:/g/personal/he120_ic_ac_uk/EX-uj1X2I_lPvpZ5TiAFRssBH8pS-cILTib3MHf1fED1wg?e=OYZmhh Heat_Transport_Visualisation_v4.pdf] (link accessible to Imperial students only).

* Visualisation resource for ‘Surfactant Concentration and Surface Tension’ example:
** This resource followed a more scaffolded approach.
** Link to Miro Board: [https://miro.com/app/board/uXjVOkE5LMg=/?share_link_id=285064772345 Surfactant_Conc_Resource] (link accessible to anyone).

=== Learning: ===
A lot of learning happened while making the visualisation resource scaffold, and it is still happening as we have not yet finalised it. It has proved to be quite a challenging task because there are many ways to go about this and we do not want to be hindering the student's creativity, but we also do not want to leave them with too much uncertainty and too many decisions to make that might be a waste of time or deviating from the main project.

* Didn’t have time to meet with Caroline about this – didn’t get further than taking feedback.

== Module Timeline ==

=== Summary: ===

* Rough module timeline was made
* Divided based on the different reflections and feedback sessions

* Didn’t have time to discuss with module team
* All the team contributed to an analogous timeline for the whole process

=== Detailed achievements: ===
The module timeline is vague and not much time was dedicated on perfecting it as other things were more important at the time such as the assessment and reflections.

=== Learning: ===
We learnt that experience and specifically sharing experiences is important in order to get a complete and comprehensive view. This was obvious when creating the timeline of the project as everyone had to pitch in their ideas.

Also learnt that missing the expertise can make it quite difficult to plan what would happen in the sessions.

=== Next step: ===
Still need to think up ideas for workshops and how each session will be run.

Need to contact people who can help lead that and have more expertise in design and coding.

=== Progress that has been made so far can be seen here: ===
[https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764528875305516&cot=14 Timeline of the module]

[https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764529313630859&cot=14 Timeline of the project]

== Group formation: ==

=== Summary: ===

* Two scenarios were proposed: A (groups work on one project from start to end), B (groups can start from the middle of a project or start and finish wherever deemed sensible)
* Pros and cons for each were written out in a table

* Criteria was made based of that and added into a table to vote on which scenario fits it best
* After voting, it was concluded that scenario B was more favourable

=== Detailed achievements: ===
Once it was decided that scenario B would be best, all the cons that it had were evaluated and a table was made with all the issues it has and with ways to mitigate those and action required.

Most of the unfairness was fixed when the assessment was made. However, there still are some things to do.

=== Learning: ===
We learned the significance of thoroughly thinking through different scenarios and evaluating each criterion individually before coming to a unanimous decision on what would be the best thing to do. We also learnt that even once we concluded that scenario B would be better, there still were some cons we had previously mentioned that had to be dealt with.

=== What we didn’t do: ===
- How the groups may be formed? Using the skills matrix?

=== Next step: ===

* Need to create a list of all possible skill sets that students would want to work on, and the list of all the possible projects they can work on.
* Provide a flow chart to help with choosing the topic.
* Making the form that students will need to fill to have fairly distributed groups.

=== Progress that has been made so far can be seen here: ===
[https://miro.com/app/board/uXjVOtQtmVQ=/?moveToWidget=3458764528163586540&cot=14 Miro Board with the tables described above]

Category:Summer 2022

2022-07-22T09:45:26Z

Cclewley: Created category page

[[Category:Records]]

All categories

2022-07-08T10:06:58Z

Cclewley:

<categorytree mode="pages">Everything

</categorytree>
[[Category:Everything]]

Programming languages

2022-03-09T14:18:28Z

Cclewley: /* The tools we use to create visualisations */

== The tools we use to create visualisations ==
Hypertext Markup Language (HTML) is the backbone of any webpage, and this is the case for ImpVis. HTML is less of a language and more of a collection of blocks or ‘elements’ that define what goes on your page. HTML allows us to define everything on our page, but cannot do much else. For the most part, HTML is static and cannot perform complex equations or plotting. This is where JavaScript (JS) comes in. ImpVis visualisations use JS to perform physical/mathematical calculations, plot, and achieve interactivity. These elements can contain anything from text to a slider to a graph plot, and can be styled to your preference! From the size of your element to the text color, this styling can all be specified using another language: Cascading Style Sheet (CSS).

Here are a few links to relevant places on how to do some basic HTML, CSS and JS -
*'''HTML''': https://www.codecademy.com/learn/learn-html https://scrimba.com/learn/htmlcss
*'''CSS''': https://www.codecademy.com/learn/learn-css
*'''JS''': https://www.codecademy.com/learn/introduction-to-javascript and https://scrimba.com/learn/learnjavascript
*'''Vue.js''': https://www.youtube.com/watch?v=ZqgiuPt5QZo
For the HTML course, you will most likely require sections 1. ''Elements and Structure'', and 3. ''Forms''. You may choose to opt-out on learning CSS as we have a set of predefined components, like sliders and buttons, which will be introduced later! If you are interested in customising the components, you may come back and learn CSS. As for JS, sections 2-7 are essential, and sections 8 and 9 are useful for object-oriented programming.

While coding a visualisation, you will inevitably have to use some mathematical functions. ''Math.js'' is an extensive JS math library that provides many useful tools. For more information, https://mathjs.org/.

== Further links ==
Have a look at our [[Help on HTML, CSS, JS and JS libraries]] page for further guidance on these coding languages.
[[Category:Setting Up]]

Help on HTML, CSS, JS and JS libraries

2022-03-09T14:17:32Z

Cclewley: /* Further reading */

== HTML ==

HTML is less of a language and more of a collection of blocks or ‘elements’ that define what goes on your page. These elements are defined using opening and closing tags. For example, if I wanted to have an element displaying “hello world,” I would have an open <code><nowiki><div></nowiki></code> tag, followed by the text, followed by a closing <code><nowiki></div></nowiki></code> tag. So overall, the element looks like:<center><code><nowiki><div>hello world</div></nowiki></code></center>When constructing your own HTML, it is likely to be composed of two sections: a head and a body. In the Head, all of your external packages apart from your JavaScript file(s). For example, if I were using MathJax to write my equations, I would put the MathJax importing script into the Head. The body contains the actual elements that appear on the page. Then, you should import your JavaScript (or JS) files at the end of the body. This is done because if the JS files were in the Head, they might reference things that aren’t defined yet.

For more tutorials on HTML, here are a few useful resources:

* W3 Schools: https://www.w3schools.com/html/html_intro.asp
* CodeAcademy: https://www.codecademy.com/learn/learn-html

== Cascading Style Sheet ==

Cascading Style Sheet, or CSS, is how we style almost everything on a given web page. CSS is a series of properties and their corresponding values describing all the stylistic features of an HTML element. For example, the following piece of code can set the width, height, and text colour of a div: 0<center><code>width:100%; height: 100%; colour: “#003E74”;</code></center>Everything from colour to size to animations is defined using CSS. One way of defining an HTML elements style using CSS is to embed the CSS directly into the element. An example of embedding CSS directly in an HTML element is:<center><code><nowiki><div class = “textbox” id = “theory” style = “width:100%; height: 100%; colour: “#003E74”;”> Hello world! <\div></nowiki></code></center>''Note: If you don’t understand the above code, it may be useful to look at the HTML section in the Functionality Guidelines document!''

Alternatively, an element's style can be inherited from a class or ID, with the actual CSS written in a separate standalone file. An example for the HTML in this case is: <code><nowiki><div class = “textbox” id = “theory”> Hello world! <\div></nowiki></code> With the separate stylesheet containing the following CSS:

* <code>.textbox{</code>
* <code>width: 100%;</code>
* <code>height: 100%;</code>
* <code>}</code>And

* <code>#theory{</code>
* <code>Colour: “#003E74”;</code>
* <code>}</code>

A typical visualisation will have a basic inherited style from one of two global stylesheets: skeleton.css and style.css. Any further detailed styling by a developer is typically done directly in the HTML file. For more on CSS, visit: W3 Schools: <nowiki>https://www.w3schools.com/css/css_intro.asp</nowiki>

'''Note on Sizes:'''When defining a class's dimensions in a CSS file, this can be done using absolute or relative units. Note that in the first line of example code in the document, relative units have been used (height and width defined in percent). Another way of using relative units would be to write height in terms of "vh" (view height) and width in terms of "vw" (view width); e.g.:<code>width:75vw; height: 85vh;</code>. Here, 1vw means 1% of the width of the viewport (the user's visible area of a web page) and the same for vh.

Absolute sizes are generally defined in pixels, e.g.:<code>width:550px; height: 300px;</code>. The disadvantage of this method of defining sizes is that certain elements will end up being different sizes, depending on the user's screen's resolution. For this reason, when defining div sizes, it is strongly recommended you use relative units.

== JavaScript ==
For the most part, JavsScript (JS) is structurally similar to Python; it has functions that take input variables equal to a String, Float, Integer, or Boolean. However, if you are coming from a Python background, there are a few significant differences to note:

* Defining variables for the first time needs to be preceded with either '''Let''', '''Var''', or '''Const'''. For example, the start of your JS code could say const g = 9.8. The difference between these variable declarations is:
** '''Let''' exists in a block-scoped namespace. I.e., if it is defined in a function, then it stays in that function.
** '''Var''' is very wishy-washy. Please do not use it.
** '''Const''' is also block-scoped, but cannot be reassigned.
* Rather than using indentation to define where a for loop/function is, JS uses curly brackets. For example:
** This function returns the square of the input value:<code>function square(x) {return(x*x);};</code>
** This for loop counts from 1 to 10: <code>for (let i=0; i<10; i++ {console.log(i);};</code>
** This if statement prints ‘yay’ if happy is true and ‘aww’ if happy is false:<code>if(happy===true){console.log(“yay”)}else{console.log(“aww”)};</code>Note that although you don't need indentation to write JavaScript code, you are able to indent it however you like. Consistent

== Plotly package ==
Plotly is a plotting package based on the D3 library. Most interactive plots in our visualisations have been made using Plotly, due to its simplicity and great style right out of the box. After including Plotly in your HTML head, you will mostly be dealing with Plotly through three functions:

* <code>plotly.newplot(graph_id,data,layout)</code>This function creates a plot in a previously unoccupied div with id graph_id. The data and layout inputs define what data is plotted and how the plot looks. Use this to initialise your plot.

* <code>plotly.animate(graph_id, frames,animation_attributes)</code>This function updates the data of an already existing plot in the element with id = graph_id. The frame variable defines the new set of data. Use this for animating a constant set of points or a line, for example.

* <code>plotly.react(graph_id, data, layout)</code>This function updates both the data and layout of an existing plot with id=graph_id. Use this if you need to animate axis sizes, for example, or if your new data set has different dimensions to the old one.

Notice how in all three functions, there is either a '''data''' or '''layout''' variable (or both). These are the two most essential variables in Plotly, and have a basic dictionary-like structure that is super intuitive! Let’s take a look at a '''data''' example first:

<code>var data=[{type:"scatter",mode:"lines",x: [0,2,5,7,3],y: [1,6,3,7,8],line:{color:"#960078", width:3, dash: "dashed"}, },];</code>

As you can see, data is a list of dictionaries, where the dictionaries’ entries are properties of a dataset, properties such as x, y, and data label. Data is a list because Plotly allows for the addition of multiple datasets at once onto a plot.

Now let’s look at a '''layout''' example:

<code><nowiki>const layout = {autosize: true,margin: {l:30, r:30, t:30, b:30},hovermode: "closest",showlegend: false,xaxis: {range: [-10,10], zeroline: true, title: "x"},yaxis: {range: [-10,10], zeroline: true, title: "y"},aspectratio: {x:1, y:1}};</nowiki></code>

As you can see, the layout is a single dictionary defining stylistic features of the plot, such as its size and margins. For more on how you should style a Plotly graph, visit the style guidelines page. For more on Plotly, the two most important resources are:

# '''Function reference''' - https://plot.ly/javascript/plotlyjs-function-reference/
# '''Full reference''' -https://plot.ly/javascript/reference/

''Important note: Plotly can often be the reason a given page is slow or unoptimized. Look out for slow ways of updating a graph, such as plotly.purge() and plotly.newplot().''

== Further reading ==
Check out [[JavaScript packages for graphics]] for help on which graphics package to use for your visualisation.

[[Introduction to Vue workshop|Learn about Vue.js]] - the package that the ImpVis template and components are built with.
[[Category:Tips Whilst Coding]]

Knowledgebase

2022-02-16T12:32:37Z

Cclewley: /* Getting started */

This is the ImpVis knowledge base; it contains all of the information ImpVis has accumulated as a community in order to design and develop effective interactive visualisations for education.

The structure of this page follows the steps of [[our design and development process]] closely.

== Getting started ==
These are the suggested steps to take if you wish to know all about how to get involved in the ImpVis project.

# Read a brief overview of [[our design and development process]] (ensure to take the first step: connecting with our community).
# Find out how to [[Getting involved|get involved]] with a visualisation project.
# Understand what it means to [[Working in partnership|work in partnership]].

You can follow the links in the pages above to find out more information. Below are listed all the pages in the 'Getting Started' category in alphabetical order.<categorytree mode="pages">Getting Started
</categorytree>

==Visualisation design guidance==
To create an interactive visualisation for education, you will need to consider the design of your visualisation carefully from several angles. The ImpVis template implements some of our ideas so that you do not need to design your visualisation entirely from scratch. Suggested steps to follow:
# Carefully phrase the visualisation's aim, learning outcomes, and intended implementation. Read [[Scaffolding concepts]] for guidance. Document these in your own project's Wiki page. If you haven't yet created your own project Wiki page, do so now by copying the [[Wiki Template for new project|template Wiki]] and filling in the sections. Have a look at [[Solid Angles Design|this example]] of a finalised design.
# Familiarise yourself with the [https://impvis.co.uk/launch/impvis-layouts-v2/page1.html?collection=39 ImpVis visualisation template] (hosted on the ImpVis website) so you understand how it can support your visualisation design and read the [[ImpVis template description|description of the ImpVis template]].
#Check out the [[Organising content]] page to consider how to populate the visualisation template with your own visualisation's content.
#Decide on what the visualisation will look like and how it will work. Peruse the design guidance documents listed below to help you.
#Insert a design sketch, including the visual and interactive elements of the visualisation, in your visualisation's dedicated Wiki project page. Explain the rationale of your decisions.
#Once all staff partners are happy with the design, they need to formally confirm their agreement on the website to move their project to the development stage (read [[Managing your project on the ImpVis website#Changing the progress status of your project|here]] about how to do this).

Below we list all our design guidance documents alphabetically, split up into three different categories: education, graphic, and interaction design. Note that we have only just started collating our experience in this section, so it is sparsely populated - we aim to incorporate all knowledge generated by the ImpVis module students in this Wiki going forward.<categorytree mode="pages">Design Guidance
</categorytree>

== Guidance for coding up visualisations==

'''Before you start coding, ensure the visualisation design is well documented on your Wiki project page and all partners have agreed on the design!''' If you haven't done this yet, revisit [[Our design and development process#Visualisation design based on aims and learning outcomes|the steps to take in the design process]] to find out how to do this.

The sections below contain technical guidance to support you with the coding side of ImpVis.

=== Setting up===
When starting coding, these are the suggested steps to follow:

# [[Programming languages|Read about our programming languages]] and where to find some training resources.
# [[Tutorial for setting up the coding environment|Follow this tutorial]] to set up your coding environment.
#[[Getting connected on Github|Learn]] about getting started on GitHub.
All our pages with guidance for setting up are listed below in alphabetical order.<categorytree mode="pages">Setting Up</categorytree>
===The ImpVis visualisations template===
Here you can find information about the ImpVis template created in 2020, using vue.js. You should already have familiarised yourself with the ImpVis template during the design phase. However, before you proceed with the coding, make sure you have an in-depth understanding of the template and its components, including how to include the components in your code. Suggested steps to take:

# See the template in action here: [https://impvis.co.uk/launch/impvis-layouts-v2/page1.html?collection=39 ImpVis template].
# Read the [[ImpVis template description]].
#Follow the [[Basic Component Tutorial|basic tutorial]] on how to include components in your code and/or take the [[introduction to Vue workshop]].
# Find technical documentation on all ImpVis [[Vue Components|Vue components]].

Below are all our guidance pages for the ImpVis and the associated components, in alphabetical order.<categorytree mode="pages">ImpVis Template

</categorytree>
===The coding process===
Look here for tips and help on issues that may come up while you're coding. Here are some pages to get your started:

# [[Structuring your code]]
# [[Help on HTML, CSS, JS and JS libraries]]
#[[JavaScript packages for graphics|Javascript packages for graphics]]
#[[Introduction to Vue workshop]]
#[[Tips for the developer]]

All our coding tips pages are listed alphabetically below.<categorytree mode="pages">Tips Whilst Coding
</categorytree>
==Review and publication of your visualisation==
When you have completed coding up your visualisation, it is time to upload it to the ImpVis website. It will then need to be reviewed before it can be published in 'Teach' environment. You should also create a Collection so your intended learners will easily be able to access your visualisation. Suggested reading:

# [[Uploading a new visualisation]]
# [[Managing your visualisation]]
# The [[review]] process
# The [[Visualisation status|status]] of your visualisation
# [[Uploading a new version of your visualisation]]
# [[Creating a Collection]]
# [[Managing your Collection]]

You can find all pages related to the ImpVis website functionality in the [[Knowledgebase#Website guidance|relevant section below]].

== Maintaining ImpVis ==
Maintaining ImpVis involves moving old visualisations to the new template, updating or creating new components, improving the ImpVis CLI, etc.

Below are listed all the pages in this category in alphabetical order.<categorytree mode="pages">Maintaining ImpVis

</categorytree>
== Website guidance ==
Everything about the functionality on the website and its design. Relevant pages listed in alphabetical order below.<categorytree mode="pages">ImpVis Website Guidance

</categorytree>
[[Category:Everything]]

Bloch Sphere

2022-02-16T12:31:55Z

Cclewley:

== Contributors ==

* ''Name and department of each person.''
*''Student or staff partner?''
* ''How is/was each person involved?''
* ''What rough dates did they contribute?''

== Aims & Learning Outcomes ==

* ''Explain the motivation for your visualisation.''
Being able to visualize quantum states and the effects of quantum gates on them gives the learner a visual and intuitive understanding of quantum logic gates (rather than just as mathematical equations) - this is important to then be able to build more complex algorithms and quantum circuits which are the fundamental building blocks of quantum computing
* ''Introduce the subject of your visualisation.''
'''Bloch sphere'''

# What is a qubit? Bit vs qubit - bits are the building blocks of classical computers (only 0s and 1s) whereas the building blocks of quantum computers are qubits (superpositions of the |0> and |1> quantum states)
# What is a Bloch sphere? A way of geometrically representing these quantum states as vectors of a 3d unit sphere, where |0> can be represented by the 0 vector and |1> can be represented by the 1 vector using bra-ket notation
# The general representation of these pure quantum states as α|0>+β|1>
# Pure vs mixed states

where α and β are complex numbers representing the probability amplitudes i.e. the probability of getting |0> is |α|^2.

* How can we represent this general form of the quantum state geometrically? - We need to introduce coordinate parameters such as φ and θ
** Rewrite the general quantum state form in terms of polar coordinates (using Euler's identity)
** Global phase - two quantum states which differ only by a factor of exp(i theta) are considered to be the same
** Normalization constraint (probabilities must sum to 1)
** To get: cos(θ) |0> + e^(iφ)sin(θ) |1>
** θ and φ restrictions means we get cos(θ/2) |0> + e^(iφ)sin(θ/2) |1>
** Pure vs mixed states (pure states on the surface, mixed states within sphere)

'''Quantum gates'''

* A way of manipulating qubits which is useful for creating algorithms/quantum circuits
* Pauli-X gate:
** Matrix representation
** Flipping the state -> corresponds to 180 degree rotation about the x axis on the Bloch sphere
* Likewise for Pauli-Y
* Likewise for Pauli-Z
* Hadamard
** Matrix representation
** 90 degree rotation around Y-axis followed by 180 degree around X axis

* ''Which module and year is it intended for and which setting (lecture or self study)?''

Useful for the Quantum Information course (PHYS97080)

Can also be used for self-study
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''
After using this visualisation, students should be able to:

* Represent states of qubits (pure and mixed) and their dynamics on the Bloch sphere
* Understand the dynamics of single qubits by quantum gates (Pauli X, Pauli Y, Pauli Z and Hadamard)

== Design Overview ==

* ''Once the design is agreed, describe the final outcome, how it looks, how it functions etc.''
* ''Include graphics.''

== Design Justification ==

''Optionally describe any notable decisions made for the design, e.g.''

* ''Educational design: breaking down of concepts (scaffolding)''
* ''How were accessibility issues considered?''
* ''How was space used effectively?''
* ''How is the design intuitive?''
* ''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
== Progress and Future Work ==

* ''Is the design finalised (i.e. agreed by all partners)?''
* ''If applicable, which pages have been uploaded to website?''
* ''Any ideas for future improvements.''

== Links ==
*Link to GitHub repository for code in development:
*Link to visualisation on ImpVis website (when uploaded):
*Link to Collection on ImpVis website (when created):
*Any other links to resources (Miro boards / notes pages / Google Docs etc):
[[Category:Project pages]]

Knowledgebase

2022-02-09T13:58:44Z

Cclewley: /* The coding process */

This is the ImpVis knowledge base; it contains all of the information ImpVis has accumulated as a community in order to design and develop effective interactive visualisations for education.

The structure of this page follows the steps of [[our design and development process]] closely.

== Getting started ==
These are the suggested steps to take if you wish to know all about how to get involved in the ImpVis project.

# Read a brief overview of [[our design and development process]] (ensure to take the first step: connecting with our community).
# Find out how to [[Getting involved|get involved]] with a visualisation project.
# Understand what it means to [[Working in partnership|work in partnership]].

You can follow the links in the pages above to find out more information. Below are listed all the pages in the 'Getting Started' category in alphabetical order.<categorytree mode="pages">Getting Started</categorytree>

==Visualisation design guidance==
To create an interactive visualisation for education, you will need to consider the design of your visualisation carefully from several angles. The ImpVis template implements some of our ideas so that you do not need to design your visualisation entirely from scratch. Suggested steps to follow:
# Carefully phrase the visualisation's aim, learning outcomes, and intended implementation. Read [[Scaffolding concepts]] for guidance. Document these in your own project's Wiki page. If you haven't yet created your own project Wiki page, do so now by copying the [[Wiki Template for new project|template Wiki]] and filling in the sections. Have a look at [[Solid Angles Design|this example]] of a finalised design.
# Familiarise yourself with the [https://impvis.co.uk/launch/impvis-layouts-v2/page1.html?collection=39 ImpVis visualisation template] (hosted on the ImpVis website) so you understand how it can support your visualisation design and read the [[ImpVis template description|description of the ImpVis template]].
#Check out the [[Organising content]] page to consider how to populate the visualisation template with your own visualisation's content.
#Decide on what the visualisation will look like and how it will work. Peruse the design guidance documents listed below to help you.
#Insert a design sketch, including the visual and interactive elements of the visualisation, in your visualisation's dedicated Wiki project page. Explain the rationale of your decisions.
#Once all staff partners are happy with the design, they need to formally confirm their agreement on the website to move their project to the development stage (read [[Managing your project on the ImpVis website#Changing the progress status of your project|here]] about how to do this).

Below we list all our design guidance documents alphabetically, split up into three different categories: education, graphic, and interaction design. Note that we have only just started collating our experience in this section, so it is sparsely populated - we aim to incorporate all knowledge generated by the ImpVis module students in this Wiki going forward.<categorytree mode="pages">Design Guidance
</categorytree>

== Guidance for coding up visualisations==

'''Before you start coding, ensure the visualisation design is well documented on your Wiki project page and all partners have agreed on the design!''' If you haven't done this yet, revisit [[Our design and development process#Visualisation design based on aims and learning outcomes|the steps to take in the design process]] to find out how to do this.

The sections below contain technical guidance to support you with the coding side of ImpVis.

=== Setting up===
When starting coding, these are the suggested steps to follow:

# [[Programming languages|Read about our programming languages]] and where to find some training resources.
# [[Tutorial for setting up the coding environment|Follow this tutorial]] to set up your coding environment.
#[[Getting connected on Github|Learn]] about getting started on GitHub.
All our pages with guidance for setting up are listed below in alphabetical order.<categorytree mode="pages">Setting Up</categorytree>
===The ImpVis visualisations template===
Here you can find information about the ImpVis template created in 2020, using vue.js. You should already have familiarised yourself with the ImpVis template during the design phase. However, before you proceed with the coding, make sure you have an in-depth understanding of the template and its components, including how to include the components in your code. Suggested steps to take:

# See the template in action here: [https://impvis.co.uk/launch/impvis-layouts-v2/page1.html?collection=39 ImpVis template].
# Read the [[ImpVis template description]].
#Follow the [[Basic Component Tutorial|basic tutorial]] on how to include components in your code and/or take the [[introduction to Vue workshop]].
# Find technical documentation on all ImpVis [[Vue Components|Vue components]].

Below are all our guidance pages for the ImpVis and the associated components, in alphabetical order.<categorytree mode="pages">ImpVis Template

</categorytree>
===The coding process===
Look here for tips and help on issues that may come up while you're coding. Here are some pages to get your started:

# [[Structuring your code]]
# [[Help on HTML, CSS, JS and JS libraries]]
#[[JavaScript packages for graphics|Javascript packages for graphics]]
#[[Introduction to Vue workshop]]
#[[Tips for the developer]]

All our coding tips pages are listed alphabetically below.<categorytree mode="pages">Tips Whilst Coding
</categorytree>
==Review and publication of your visualisation==
When you have completed coding up your visualisation, it is time to upload it to the ImpVis website. It will then need to be reviewed before it can be published in 'Teach' environment. You should also create a Collection so your intended learners will easily be able to access your visualisation. Suggested reading:

# [[Uploading a new visualisation]]
# [[Managing your visualisation]]
# The [[review]] process
# The [[Visualisation status|status]] of your visualisation
# [[Uploading a new version of your visualisation]]
# [[Creating a Collection]]
# [[Managing your Collection]]

You can find all pages related to the ImpVis website functionality in the [[Knowledgebase#Website guidance|relevant section below]].

== Maintaining ImpVis ==
Maintaining ImpVis involves moving old visualisations to the new template, updating or creating new components, improving the ImpVis CLI, etc.

Below are listed all the pages in this category in alphabetical order.<categorytree mode="pages">Maintaining ImpVis

</categorytree>
== Website guidance ==
Everything about the functionality on the website and its design. Relevant pages listed in alphabetical order below.<categorytree mode="pages">ImpVis Website Guidance

</categorytree>
[[Category:Everything]]

Knowledgebase

2022-02-09T13:58:00Z

Cclewley: /* The coding process */

This is the ImpVis knowledge base; it contains all of the information ImpVis has accumulated as a community in order to design and develop effective interactive visualisations for education.

The structure of this page follows the steps of [[our design and development process]] closely.

== Getting started ==
These are the suggested steps to take if you wish to know all about how to get involved in the ImpVis project.

# Read a brief overview of [[our design and development process]] (ensure to take the first step: connecting with our community).
# Find out how to [[Getting involved|get involved]] with a visualisation project.
# Understand what it means to [[Working in partnership|work in partnership]].

You can follow the links in the pages above to find out more information. Below are listed all the pages in the 'Getting Started' category in alphabetical order.<categorytree mode="pages">Getting Started</categorytree>

==Visualisation design guidance==
To create an interactive visualisation for education, you will need to consider the design of your visualisation carefully from several angles. The ImpVis template implements some of our ideas so that you do not need to design your visualisation entirely from scratch. Suggested steps to follow:
# Carefully phrase the visualisation's aim, learning outcomes, and intended implementation. Read [[Scaffolding concepts]] for guidance. Document these in your own project's Wiki page. If you haven't yet created your own project Wiki page, do so now by copying the [[Wiki Template for new project|template Wiki]] and filling in the sections. Have a look at [[Solid Angles Design|this example]] of a finalised design.
# Familiarise yourself with the [https://impvis.co.uk/launch/impvis-layouts-v2/page1.html?collection=39 ImpVis visualisation template] (hosted on the ImpVis website) so you understand how it can support your visualisation design and read the [[ImpVis template description|description of the ImpVis template]].
#Check out the [[Organising content]] page to consider how to populate the visualisation template with your own visualisation's content.
#Decide on what the visualisation will look like and how it will work. Peruse the design guidance documents listed below to help you.
#Insert a design sketch, including the visual and interactive elements of the visualisation, in your visualisation's dedicated Wiki project page. Explain the rationale of your decisions.
#Once all staff partners are happy with the design, they need to formally confirm their agreement on the website to move their project to the development stage (read [[Managing your project on the ImpVis website#Changing the progress status of your project|here]] about how to do this).

Below we list all our design guidance documents alphabetically, split up into three different categories: education, graphic, and interaction design. Note that we have only just started collating our experience in this section, so it is sparsely populated - we aim to incorporate all knowledge generated by the ImpVis module students in this Wiki going forward.<categorytree mode="pages">Design Guidance
</categorytree>

== Guidance for coding up visualisations==

'''Before you start coding, ensure the visualisation design is well documented on your Wiki project page and all partners have agreed on the design!''' If you haven't done this yet, revisit [[Our design and development process#Visualisation design based on aims and learning outcomes|the steps to take in the design process]] to find out how to do this.

The sections below contain technical guidance to support you with the coding side of ImpVis.

=== Setting up===
When starting coding, these are the suggested steps to follow:

# [[Programming languages|Read about our programming languages]] and where to find some training resources.
# [[Tutorial for setting up the coding environment|Follow this tutorial]] to set up your coding environment.
#[[Getting connected on Github|Learn]] about getting started on GitHub.
All our pages with guidance for setting up are listed below in alphabetical order.<categorytree mode="pages">Setting Up</categorytree>
===The ImpVis visualisations template===
Here you can find information about the ImpVis template created in 2020, using vue.js. You should already have familiarised yourself with the ImpVis template during the design phase. However, before you proceed with the coding, make sure you have an in-depth understanding of the template and its components, including how to include the components in your code. Suggested steps to take:

# See the template in action here: [https://impvis.co.uk/launch/impvis-layouts-v2/page1.html?collection=39 ImpVis template].
# Read the [[ImpVis template description]].
#Follow the [[Basic Component Tutorial|basic tutorial]] on how to include components in your code and/or take the [[introduction to Vue workshop]].
# Find technical documentation on all ImpVis [[Vue Components|Vue components]].

Below are all our guidance pages for the ImpVis and the associated components, in alphabetical order.<categorytree mode="pages">ImpVis Template

</categorytree>
===The coding process===
Look here for tips and help on issues that may come up while you're coding. Here are some pages to get your started:

# [[Structuring your code]]
# [[Help on HTML, CSS, JS and JS libraries]]
#[[JavaScript packages for graphics|Javascript packages for graphics]]
#[[Index.php?title=Introduction to Vue workshop|Introduction to Vue workshop]]
#[[Tips for the developer]]

All our coding tips pages are listed alphabetically below.<categorytree mode="pages">Tips Whilst Coding
</categorytree>
==Review and publication of your visualisation==
When you have completed coding up your visualisation, it is time to upload it to the ImpVis website. It will then need to be reviewed before it can be published in 'Teach' environment. You should also create a Collection so your intended learners will easily be able to access your visualisation. Suggested reading:

# [[Uploading a new visualisation]]
# [[Managing your visualisation]]
# The [[review]] process
# The [[Visualisation status|status]] of your visualisation
# [[Uploading a new version of your visualisation]]
# [[Creating a Collection]]
# [[Managing your Collection]]

You can find all pages related to the ImpVis website functionality in the [[Knowledgebase#Website guidance|relevant section below]].

== Maintaining ImpVis ==
Maintaining ImpVis involves moving old visualisations to the new template, updating or creating new components, improving the ImpVis CLI, etc.

Below are listed all the pages in this category in alphabetical order.<categorytree mode="pages">Maintaining ImpVis

</categorytree>
== Website guidance ==
Everything about the functionality on the website and its design. Relevant pages listed in alphabetical order below.<categorytree mode="pages">ImpVis Website Guidance

</categorytree>
[[Category:Everything]]

Wiki Template for new project

2022-02-09T13:33:57Z

Cclewley:

''This is a template which you can use to help get you started on a Wiki for a new visualisation project - it serves as a dynamic 'ReadMe' file of your project. The template is just intended as a guide and you may modify the structure to suit your project (all template instructions are in italics and do not need to be saved in your own project page).''

'''''Note: if you are taking part in the I-Explore module, the [[Wiki Submission Template|submission template]] will be better suited to your needs.'''''

''When a new project is started, the 'Contributors' and 'Aims & Learning Outcomes' sections need to be filled out. Aim to include the rest of the information by the time the design is finalised. The page can be updated whenever the visualisation is updated - ensure to credit all contributors!''

''To create your own project page from this template, do the following:''

# ''In a separate browser window / tab, create a new project page with the same title as your project.''
# ''Come back to this template and press 'Edit source' at the top of the page.''
#''Select all the text on this page and copy it.''
#''Click 'Read' at the top of this page (choose 'Discard edits' in the pop up window to avoid saving any accidental edits).''
#''Go to your browser window with your new project page and paste the text you copied.''
#''Make any edits you want on your own project page (e.g. entering your name as a contributor) and press the blue button 'Save page...' at the top right of your page.''
#''Assign your page to the category 'Project pages'. Read '''[[Making Wiki Pages]]' ''for detailed instructions of how to do this. Note that you may need to remove the category 'Getting started'.''

== Contributors ==

* ''Name and department of each person.''
*''Student or staff partner?''
* ''How is/was each person involved?''
* ''What rough dates did they contribute?''

== Aims & Learning Outcomes ==

* ''Explain the motivation for your visualisation.''

* ''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''

== Design Overview ==

* ''Once the design is agreed, describe the final outcome, how it looks, how it functions etc.''
* ''Include graphics.''

== Design Justification ==

''Optionally describe any notable decisions made for the design, e.g.''

* ''Educational design: breaking down of concepts (scaffolding)''
* ''How were accessibility issues considered?''
* ''How was space used effectively?''
* ''How is the design intuitive?''
* ''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
== Progress and Future Work ==

* ''Is the design finalised (i.e. agreed by all partners)?''
* ''If applicable, which pages have been uploaded to website?''
* ''Any ideas for future improvements.''

== Links ==
*Link to GitHub repository for code in development:
*Link to visualisation on ImpVis website (when uploaded):
*Link to Collection on ImpVis website (when created):
*Any other links to resources (Miro boards / notes pages / Google Docs etc):
[[Category:Getting Started]]

Making Wiki Pages

2022-02-09T13:30:25Z

Cclewley: /* Adding a category to your page */

This page explains how to create a new page on the ImpVis Wiki and some common features you may want to use.

==Creating a New Page==
[[File:Screenshot from 2021-06-21 14-22-26.png|thumb]]
To create a new page, use the search bar in the top right, and search for the name of the page you want to create. If the page does not already exist, you should see a link directing you to create that page. Once you click this link you should be able to start editing your new page.

Once you have saved your page, think about how users will access it. '''''Make sure to add at least one category to your page.''''' This will help users find your page. Also think whether it is essential reading, in which case it should be linked to specifically in one of the [[Knowledgebase]] sections.
== Adding a category to your page ==
First consider which category your page falls into. If your page is a visualisation project page (whether from the I-Explore [[Wiki Submission Template|submission template]] or the general [[Wiki Template for new project|Wiki project page template]]), its category should be 'Project pages'. If you include this category, your page will automatically show up on the [[Project pages]] page. If your page is information on anything else, you will need to decide on one or more corresponding categories. Below is the full category tree to help you choose - you only need to assign deepest-level category (e.g. if it is 'Education Design', do not include 'Design Guidance' or any of the categories above).<categorytree mode="categories">Everything

</categorytree>To add the category to your page, if you are in 'Edit' mode, click the 'burger menu' icon at the right of the toolbar at the top of the page and choose 'Categories'. Note that categories are case sensitive. If you are adding an existing category, it should show up in blue underneath the input box once you start typing.

If you are in 'Edit Source' mode, include "''<nowiki>[[Category:Example]]</nowiki>''" at the bottom of the page source.

You may need to edit and save the pages with category trees to get them to update. If the category you select does not already exist then you will need to click through to the category page at the bottom of your new page and create the category, which is essentially the same as creating a new page, but starting the name with 'Category' (i.e. the category 'Example' would be found on a page named 'Category:Example'). If you made a new category make sure to add it to a higher-level category: either the top level 'Everything' of a lower level category. If you do not do this, your category and associated page(s) will not show up anywhere on any category trees, so will not be found by users.

== Common Page Features ==

* You can add images using the interactive editor under the "insert" tab, or by copying an image and pasting it into your page in 'Edit' mode.
* You can add citations using the interactive editor, or by using the <nowiki><cite> tags in the source code.</nowiki>
* You can add formulae using the <nowiki><math> tag, and putting latex between the tags. </nowiki>[[mediawikiwiki:Extension:Math|(We use this extension.)]]
* You can embed Youtube videos (it is recommended to do this rather than upload videos since our server storage space is limited) using the <nowiki><youtube> tags with the youtube link between the tags. </nowiki>[[mediawikiwiki:Extension:EmbedVideo|(We use this extension.)]]
* You can add pages to Categories to keep pages neatly organised! Category pages are automatically updated when new pages are added to the category.

[[Category:Using the Wiki]]

Project pages

2022-02-09T13:27:24Z

Cclewley: /* List of all project pages */

Below are listed, in alphabetical order, all the 'ReadMe' style project pages associated with visualisations.

To create your own visualisation project page, create a new page with the title of your visualisation project and copy the contents of one of the following pages into it:

# [[Wiki Template for new project|Wiki Templage for new project]] (for new projects that are not associated with the ImpVis I-Explore module), or
# [[Wiki Submission Template]] (for new projects associated with the ImpVis I-Explore module).

== List of all project pages ==
<categorytree mode="pages">Project pages</categorytree>
[[Category:Everything]]

Category:Project pages

2022-02-09T13:26:34Z

Cclewley: Created blank page

All categories

2022-02-09T13:25:56Z

Cclewley:

<categorytree mode="pages">Everything

</categorytree>
[[Category:Everything]]

Project pages

2022-02-09T13:25:07Z

Cclewley: /* List of all project pages */

X-ray diffraction

2022-02-09T13:24:48Z

Cclewley:

''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.''

==Contributors==
*Jacob Edginton - Department of Physics (student partner) - Term 1 2021 - Worked on Fourier Transforms
*Hans Lee - Department of Physics (student partner) - Term 1 2021 - Worked on Diffraction Patterns
*Benjamin Smith - Department of Mathematics (student partner) - Term 1 2021 - Worked on Reciprocal Space and Ewald's Sphere
*Ziang Yan - Department of Mathematics (student partner) - Term 1 2021 - Worked on Ewald's sphere in Desmos

* Jonathan Rackham, Department of Materials. Staff partner from October 2021.
*Paul Franklyn, Department of Materials. Staff partner from October 2021.

==Aims & Learning Outcomes==

This visualisation would be used as teaching tools in MATE50005 (Materials Characterisation, second year undergraduate) lectures as well as self-study tools in lab sessions. It will also be useful in the MATE70001 module (MSc Characterisation course).

The students will have knowledge of the following before using this visualisation:

*Single variable calculus, basic multivariable calculus.
*Understanding of Fourier analysis.
*Full module on crystallography and electronic states of matter.
*Full course on characterisation techniques.

After using this visualisation, students will be able to:

*Qualitatively describe the relationship between direct and reciprocal lattices.
*Discuss the features of reciprocal space and how they relate to a crystal’s structure.
*Relate the motion of a diffractometer to that of the scattering vector through reciprocal space.
*Evaluate the effect of experimental conditions on the diffraction patterns obtained.

==Design Overview==
The design was split up into four main parts: Fourier transforms, diffraction patterns, reciprocal space, and the Ewald's sphere. The visualisations are shown graphically on the right, and in video at the bottom of the wiki.

'''Fourier Transforms'''[[File:ImpVis - Copy.png|alt=Fourier Analysis & Transform page|thumb|424x424px|Fourier Analysis & Transform page of the visualisation]]Fourier transform are the key mathematical framework for all of crystal X-ray diffraction theory. The Fourier visualisation shows two graphs: a function in the real domain, and the Fourier Transform of that function in the conjugate domain. The user is given control over an adjustable parameter in the function, for instance, for the Gaussian example, the user can control the width. If the play animation button is pressed, this parameter will be continuously varied such that the two graphs move in real time. The user is also given a rest button to return to the original conditions. A feedback button is available so that the design can be further improved. It can be seen that on the left side of the visualisation, there is written text and mathematical formulae that give an explanation of what the user is seeing graphically.

The main goal of this visualisation was to give the user an intuitive understanding of Fourier transformations, without having to rely on solely mathematics. The functions most relevant to the materials course were created in the visualisation: the Gaussian, the Top Hat function, a sinusoid, the Dirac delta, and the Dirac comb [more images to be added].

'''Diffraction Patterns'''[[File:Diffraction Pattern.png|alt=Diffraction Pattern page of the visualisation.|thumb|Diffraction Pattern page of the visualisation. The lattice in real space is shown on the left, and subsequent diffraction pattern is shown on the right.|426x426px]]This section of the visualisation aims to connect the lattice geometry of a crystal to the expected X-ray diffraction pattern. On the left side, there is text that points out the relation between Fourier transform and diffraction, and prompts the student to try out the visualisation. The screen on the left shows a 2-D projection of the crystal lattice, and the screen on the right shows its X-ray diffraction pattern. The user can choose the lattice type between rock salt, titanium, alumina, and diamond. Each type of lattice will have a different diffraction pattern based on its geometry. The user can choose to show only the basic structure, which consists of only lattice points, or the full structure with the molecular motif.

The user also has control three other parameters: the wavelength and incident angle of X-rays, and a lattice parameter corresponding to how spaced out the lattice is. When these parameters are changed with the corresponding slider, both screens update in real time.

'''Reciprocal Space'''[[File:Real and Reciprocal Space .png|alt=Real and Reciprocal Space |thumb|426x426px|Real and Reciprocal Space ]]One of the main theoretical techniques of X-ray crystal diffraction is to work in the reciprocal space - the conjugate domain and Fourier transform of real space. The real and reciprocal lattices are overlaid onto each other. A unit cell of the real space is shown in blue, and a unit cell of the reciprocal space is shown in green. The user can click the toggle points (labelled x and y) and move around the real lattice unit cell, then see what the subsequent reciprocal lattice unit cell looks like.

[[File:3D Lattice Projections.png|alt=3D Lattice Projections|thumb|427x427px|3D Lattice Projections]]This concept was extended into 3D. A full 3D unit cell can be seen in both real and reciprocal space. As before, by clicking and moving toggle points, the user can change the size and shape of the real space unit cell, then see the resulting reciprocal space lattice cell. Moreover, the user has the ability to see how many vectors are shown: by adding or subtracting on the constructions button, the number of vectors is varied. The student will also have the ability to change their view point in both visualisations, as this is an important feature for being able to perceive depth in three-dimensions. Finally, the user has the ability to rotate and enlarge the unit cell in order to get an intuition for the existence of a centre, or lack there of, in a lattice and how the reciprocal lattice is independent of the chosen centre.

'''Ewald's Sphere'''[[File:Ewald's Sphere.png|alt=Ewald's Sphere|thumb|425x425px|Ewald's Sphere]]The Ewald's sphere is a construction in reciprocal space used to see if the elastic scattering condition of diffraction is met. The sphere is extended from an arbitrary lattice point, and has a radius equal to the magnitude of the wave vector (the reciprocal of wavelength). If two scattering vectors, k<sub>i</sub> and k<sub>f</sub> can connect two lattice points that intersect the sphere, then a diffraction will occur. The user has the option to toggle two different spheres, one of which is intended as an an example of a sphere in a position suitable for diffraction, and the other is intended to be interacted with, letting the student change the wavelength of k<sub>i</sub>, the direction of k<sub>i</sub>, and the direction of k<sub>f</sub> independently.

'''Ewald's Sphere for Long wavelength and short wave length'''
[[File:Sphere-short.png|thumb|425x425px|Ewald's sphere for different wavelength]]
This part of visualization aims to present the different interaction between Ewald's sphere and lattice points. When wavelength is long it gives a wave vector with small wavelength, resulting in small radius of Ewald's sphere. For short wavelength, Ewald's sphere would have large radius. When radius of Ewald's sphere is very large, a short piece of arc is close to linear, and it is possible that it will intersect with several crystallites. In this visualization there are sliders allowing user to change the radius of the Ewald's sphere, the lattice space as well as the crystallite size.

Links:

https://www.geogebra.org/geometry/ky9yvnft (2D Reciprocal Space)

https://www.geogebra.org/3d/jwwfpfjh (3D Reciprocal Space)

https://www.geogebra.org/geometry/hdzuccwh (Ewald's Sphere)

https://www.desmos.com/calculator/biolmyfndj (Short & Long Wavelengths)

https://miro.com/app/board/o9J_lpv6cb8=/ (Miro board)
==Design Justification ==
===Assessment Criteria===
'''Education Design'''

*Target audience and their prior knowledge is clearly identified. This information is applied to decide what the learning outcomes should be.
*Key concepts identified and broken down into several discrete and easily achievable points.

'''Graphical Design'''

*The design is such that the visualization is clear and easily understood; the layout isn't cluttered.
*The choice of font, as well as size and placement of text, makes the information easy to comprehend.
*The colour palette is appropriate and well justified, making it easy to see all text/design elements

'''Interaction Design'''

*The learner should know intuitively what the objectives are of the visualization.
*The user should be able to intuitively understand the function of each interactive element in the visualization.
* There should be immediate visual feedback when a learner interacts with the visualization.

===Education Design===
*To further deepen the idea of how a Fourier transform works, this visualization will be shown for multiple functions. If only one function was shown, the user might not get the full picture. For instance, if we only showed the user a Gaussian and its FT they might think that all Fourier transforms do is shrink and pull without changing the functional form – which is clearly not true. In addition to the Gaussian, there are also visualizations for a top hat function a cos function, and a Dirac delta. To aid with the more mathematical understanding of Fourier, there will be notes (including formulae) on the side. As you scroll through the notes, the relevant visualization will be shown. This helps a clear connection between the visual information and the mathematical information. One aspect we were concerned about was that users would only ‘play’ with the visualization rather than use it as a learning tool. To stop this, the visualization you are on won’t change unless you scroll over the written notes on the left. This forces the user to interact with the mathematical content.
*After the student is introduced to 1-D FT, the next step is for them to build an intuition of how crystal structures correlate to diffraction patterns. By showing a two-dimensional crystal lattice next to the resulting X-ray diffraction pattern, the student can compare the two screens and notice properties such as symmetries. In addition, changing a parameter updates the lattice immediately, so the student can move one slider and see how the diffraction pattern changes with the parameter, providing an intuitive link between the two. Moreover, changing the lattice parameter will cause the diffraction pattern to change inversely, so the student can relate it back to the 1-D FT visualisation previously, and have a better understanding of how Fourier theory describes real X-ray diffraction.
*In order to more easily introduce reciprocal space, the lesson begins with a two-dimensional visualisation. This visualisation is intended to first describe a normal lattice and what it represents, in which the student can then see the corresponding reciprocal lattice, and by interacting with the normal lattice, the student will be able to identify key features of reciprocal space, namely its orthogonality to normal space, and it's reciprocal nature. It is intended to have the specific mathematics described in the left panel. Having now a good understanding in two-dimensions, the student can quickly start to understand the concept in three-dimensions. Although the student may have a good understanding of reciprocal space now, a three-dimensional visual is still much more cluttered. So, the visualisation was limited to only one cell and also introduced each element one by one. As shown on the Miro board, by constructing the visualisation this way, you can highlight the key features, like bringing to attention how a reciprocal lattice vector is at a right-angle to a real lattice plane. A final feature left to bring to light was the lattice's lack of centre, by giving the student to sliders to enlarge and rotate the normal lattice, and see what changes.
*One of the problems in understanding what’s the difference between short/long wavelength is understanding that Ewald’s sphere intersects with very few crystallites when wavelength is large and more crystallite when short. To see this, a good approach would be visualising the Ewald’s sphere for different wavelengths, especially given short wavelength, arcs of the sphere looks like a straight line. This builds up intuition for such phenomenon.
=== Graphical Design===
*A range of shades of blue were implemented. This formed a set of colours that was not visually heavy but was still aesthetically pleasing. Note that the conjugate domain Fourier graph was shown in red. This was gone to give it contrast to the real domain plot: highlighting how the two are different. The text was shown on a light blue pattern with dark text (black).
*The two screens take up most of the top and centre, which draws the student's attention. The sliders and buttons are placed in a regular pattern below the screens so they are still easy to notice and use, and the screens remain the main focus. The incident angle and wavelength sliders are placed in one column, so it is intuitive to group them together i.e. properties of incident X-rays. The crystal lattice has different colours for different types of particles, so the student can distinguish what the crystal structure looks like without much visual clutter.
*For both the reciprocal visualisations, different colours where used to distinguish between real and reciprocal lattices. And in two dimensions, in order to highlight the chosen centre and axes, the grid was dotted, keeping both axes filled. Additionally, the visualisation windows were positioned in the centre of the screen in order to draw the students focus onto them, with sliders and such to the right on the same canvas, so that it is clear the interactive elements are directly related to the visuals.
*It's important to stress the key object in the graphical visualisation, which is the Ewald's sphere. So orange, which is an eye-catching colour is selected for it. Also, thickness of lines(vectors) is chosen to be easily spotted while not blocking too much of crystallite area displayed. It is important that although this is a 2-D visualisation it represents unit cells in 3-D
===Interaction Design===
*The Fourier analysis visualization seeks to be interactive via two sliders. They let you control an adjustable parameter in the function we are examining. For instance, in a Gaussian it lets you control sigma and ‘conjugate sigma’ (rho). This gives the user an interactive input, and helps people make the connection between the two parameters (if one is altered so is the other). To add to this, there is an animate button. When pressed, the range of values of a parameter will be swept over. Whilst this is less interactive than manually adjusting the slider, it gives the user a strong overview how a function and its Fourier Transform will change for many different values of a parameter. ensure the user can return to their original state, a reset button will be implemented. This will set the values of the two parameters back to their starting values. In addition, there will be a feedback button. This allows users to submit input and suggest how the visualization might be improved.
* There are several parameters/options that can be changed by the student. Whenever a parameter/option is changed, the two screens update quickly for the student to see how the patterns change with the parameter. To make the controls obvious, there are sliders for adjustable parameters, the drop-down box is marked by a downward arrow and the word "select" next to it, and there is an empty box that can be clicked on to toggle showing the motif.
* For the reciprocal visualisation, any interactive element was highlighted in blue. In order to not clutter the visualisation, any interactive element that could be interacted with indirectly, was left to sliders and toggles outside the visualisation window. To keep the education design element in mind, some interactive elements are only intended to appear after certain events such as reading past a certain point in the left panel or finishing the construction of the three-dimensional visualisation. A feature intended for the student to be able to use is to be able to change their view of the visualisation, and whilst the draft doesn't bring light to this, it can be done by including some extra buttons next to the visual windows, one with a cursor, meant to toggle the users ability to interact with the blue points, and the other with a scroll icon, meant to toggle the students ability to change their perspective.
*To build up better understanding in how changes in different parameters influences the result it’s better to give more options in changing variables. So, sliders of changing crystal spacing, crystallite radius, wavelength (directly related to radius of Ewald’s sphere) are provided. In designing demo, one variable is included to control the range of graph shown to allow quick display on some computers.
==Progress and Future Work==
*All the Geogebra and Desmos visualisations used in the design have been linked on this page (in design and in links)
* In the software the visualisations were created in, snapping to points (i.e. lattice points) was not possible. Adding this would make the Ewald's sphere visualisation easier to understand.
* It was suggested that the user build on their understanding of Fourier by being able to draw a 2D shape and seeing its Fourier transform. This is simple to do in Python, but may have implementation issues in Java Script
[[File:ReciprocalSpaceClip.mp4|thumb|316x178px|2D Reciprocal Space]][[File:3DReciprocalSpaceClip.mp4|thumb|316x178px|3D Reciprocal Space]][[File:EwaldsSphereClip.mp4|thumb|316x178px|Ewald's Sphere]][[File:X-Ray_Diffraction(LABELS)_-_配置文件_1_-_Microsoft_Edge_2021-12-13_14-01-25.mp4 |thumb|316x178px|Short & Long Wavelengths]]
==Links ==
Please see videos shown on the right, they provide more detail on the visualisations.

https://www.geogebra.org/geometry/ky9yvnft (2D Reciprocal Space)

https://www.geogebra.org/3d/jwwfpfjh (3D Reciprocal Space)

https://www.geogebra.org/geometry/hdzuccwh (Ewald's Sphere)

https://www.desmos.com/calculator/biolmyfndj (Short & Long Wavelengths)

https://miro.com/app/board/o9J_lpv6cb8=/ (Miro board)
[[Category:Project pages]]

Visualising academic integrity research terminology

2022-02-09T13:24:30Z

Cclewley:

''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.''

==Contributors==
*Miko Oberhauser, Department of Physics. Student partner. Focus on Graphic Design, October-December 2021.
*Man Ho Lam, Department of Physics. Student partner. Focus on Education Design, October-December 2021.
*Themis Halka, Department of Biomedicine. Student partner. Focus on Interaction Design, October-December 2021.
*Alexandru-Eduard Danila, Department of Mathematics. Student partner. Focus on the way in which the data from the data set was displayed, October - December 2021.
*Thomas Lancaster, Department of Computing. Staff partner from October 2021.

==Aims & Learning Outcomes==
The visualisation will be used as a supporting activity in the Academic Integrity in STEMM I-Explore module, therefore the intended learners are second or third year Imperial College students in the module. The learners are not expected to know anything about the topic beforehand.

The aim will be to provide an interactive visualisation that shows the type of terminology used in academic integrity research paper titles and shows how this has developed over time. Some examples of the type of data available are given in the 2021 paper “Academic Dishonesty or Academic Integrity? Using Natural Language Processing (NLP) Techniques to Investigate Positive Integrity in Academic Integrity Research” (https://doi.org/10.1007/s10805-021-09422-4).

After using this visualisation, the target audience will be able to achieve the following learning outcomes:

* Discuss the range of research that has been conducted under the academic integrity banner and identify topics of timely and personal interest to them.
* Explore the range of terminology used in academic integrity research and to interpret how the choice of paper titles influences how often papers are cited and the future reach of research
* Contrast the use of positive, neutral and negative language in discussing academic integrity and to show how the messaging used within the field has developed over time

==Design Overview==
[[File:Main Page.png|thumb|350x350px|Figure 1: The home page of the visualisation.]]
[[File:ExamplePage.png|thumb|350x350px|Figure 2: Topic page users are led to after a keyword has been searched for or the "Surprise me" button has been clicked.]]

The final outcome realised over the course of the ImpVis iExplore module was an interactive prototype which displayed information from our staff-partner's research paper.

The overall visualisation was divided into different sections:

* home page (Fig. 1)
* topic page (Fig. 2)
* chart page (not conceptualised)

On the home page users can input keywords of their choice in the search bar or simply click the "Surprise me" button. This will then lead them to the respective (or random) topic page. On these pages multiple charts are displayed supplying the user with key statistics about the search term. Fore more information, the icon in the top right corner of each section can be clicked to expand the respective section and receive further information and clarifications about the data displayed.

The main part on the right of the topic page is a representation of publications that include the search term in their title. They are presented in bubbles with the number of citations dictating their size. The main part has got an extend button which will show more information such as an embedded page of some of the most cited papers. In the side bar on the left there are placed two diagrams, but more can easily be added as the bar is scrollable. The top diagram is a radial graph displaying the sentiment of the language used (i.e. is it positive/neutral/negative?). This page has also got an extend button which will provide more information on how the score was calculated, and the main positive/neutral/negative terms. Finally, the bottom chart contains information about the most commonly used bigrams. By expanding this, users can get more information about the publications making use of these keywords.

On the bottom of the screen, three related topics are listed that take the user to their respective topic pages upon being clicked. Other navigations include the "home"-icon and the ImpVis logo in the navigation bar on top that lead to the home page and the main ImpVis website. Also present on top is the search bar enabling users to look up keywords without having to visit the home page first.

==Design Justification==
===Assessment Criteria===
''List your cohort's assessment criteria. You may want to number the assessment criteria so you can refer to them easily later.''

==== Education Design ====
#Target audience and their prior knowledge is clearly identified. This information is applied to decide what the learning outcomes should be.
#Key concepts identified and broken down into several discrete and easily achievable points.

==== Graphical Design ====
#The design is such that the visualisation is clear and easily understood; the layout isn't cluttered.
#The choice of font, as well as size and placement of text in the visualisation design, makes the information easy to comprehend.
#The colour palette is appropriate and well justified, making it easy to see all text/design elements.

==== Interaction Design ====
#The learner should know intuitively what the objectives are of the visualisation.
#The user should be able to intuitively understand the function of each interactive element in the visualisation.
#There should be immediate visual feedback when a learner interacts with the visualisation.

==== General ====
#The wiki page should give a clear overview of the project, and someone not familiar with the project should be able to understand it - no prior understanding necessary.
#The design choices should be well justified in the Wiki project page.
#Fulfillment of staff partner's brief.
===Education Design===
In the beginning, most of our target audience will only have limited amount of knowledge about academic integrity research, for example, everything about academic integrity is just anti-plagiarism and anti-cheating. Because of that, we want to give them maximum freedom to explore the visualisation in the first instance instead of feeding much information straight away. This is the reason why we decided to make interactions as easy and simple as possible and later came up the idea of 'surprise button'. There will be indications down the bottom of each page to show the progress: home page or a particular topic.

Our project is heavily based on words instead of equations and numbers, but we also want to keep the audience interested and active all the time. We decided to use word bubbles as the main method to present information about research papers and terminology. Showing different sizes and colours of word bubbles may be a relaxing and interesting way to keep learners' attentions.

After learners just finish quickly scanning through the visualisation, they may then wish to further explore more details in the topics they are interested in, so we created a search bar in the home page to accommodate everyone's own preference.

In each topic area, we chose to split the page into three different sections as shown in Figure 2 to present information so that the learners don't suddenly get overwhelmed by loads of materials. The size of each section also intuitively indicates the order of importance. The 3 sections from largest to smallest are: word bubbles containing specific information about papers, radial bar chart representing sentiments of language (positive, neutral and negative) and frequency histogram of different terminology:

# For each paper, the paper title, year of publish and number of citations will be shown in a single word bubble. The bigger the size of bubble, the more citations the paper has. The learners will gain a clear view to contrast how paper titles and year of publish would generally influence the number of citations.
# Radial bar chart was chosen to best present sentiments analysis (positive, neutral and negative) of language in papers' titles change over time. It can show the proportions and different sentiments as different coloured sections at the same time.
# The histogram indicates the frequency of bigrams in the field of academic integrity research. This should give learners a general idea on what the key messages in these papers conveyed and how different terminology evolved.

Researchers in the field of academic integrity and learners with much background knowledge might also be interested in using the visualisation to further investigate around the field. If they click the title of a paper, there will be a link to that particular paper of their interest.

===Graphic Design===
[[File:Design System.png|alt=Typefaces "Lato Thin", "Lato Regular", and "Lato Medium" on a white background. Shades of pink on blue are displayed below.|thumb|Figure 3: Design system of the visualisation. Lato is the typeface with regular being the style of choice. The two main colours are pink and blue. Only the most saturated shades are used for type as the contrast of the less saturated ones is not start enough on white to ensure good readability.]]
The construction of the design system for this visualisation involved creating the visual design language, including the components of colour, typography, size and spacing, along with a UI pattern. As we do not have much imagery, the guidelines for illustrations and icons have not been precisely defined (yet). Colours were selected and their contrast checked using the [https://webaim.org/resources/contrastchecker/ WebAIM online tool] to accommodate users with visual impairments. Furthermore, care was taken to avoid the colours red and green for juxtapositions since about 1 in 12 men and 1 in 200 women suffer from red-green visual impairment<ref>[https://www.nhs.uk/conditions/colour-vision-deficiency/ NHS Colour vision deficiency (colour blindness)]</ref>. Instead, magenta and imperial blue were chosen as contrasting colours to represent negative and positive sentiments, respectively. The shade of blue chosen is also the same as in the ImpVis logo to comply with the branding of the overall website. The sans serif font Lato was chosen as typeface due to its good readability at small sizes and large variety of styles (i.e. thin, regular, medium etc.).

On the topic page the desktop was divided into a side and main column following the rule of thirds. As per request of the staff partner the user should see the key data at a glance which is achieved by placing the primary chart of a topic in the main column and secondary charts in the scrollable side column on the left. For more information, users can expand each infographic by clicking on the icon in the top right corner of each representation. This way, the visualisation does not become cluttered and shows only the necessary information required to get a grasp of the topic. The zoom controls on the right are for magnifying the bubbles in this section to read what publication each one represents without losing the visual element of its size corresponding to the amount of times the paper has been cited. For the home page the background was blurred and the elements the user is meant to interact with are placed in the middle, to direct their attention to it. On both pages a help button was added to the top right or bottom right corner, as this is the location users intuitively look to find more guidance in.

The visualisation was made even more intuitive by using symbols whose function is known to the users. For example, when a user sees a magnifying glass icon in a bar, they know that this is a search bar where they can look up terms.

Throughout the design process, decisions were discussed within our project group and we continually suggested potential enhancements or challenged choices that had previously been made.

'''Next steps:'''

* add scroll bar to the side column
*make bubbles float and maybe even movable
* add expanded views for individual graphs
* embed publications (or their abstracts)
* design more pages displaying different types of charts
* make the design responsive

[https://www.figma.com/proto/SVziYGbNHYZQQue8e1PWQ6/ImpVis?node-id=312%3A3&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=312%3A3 Click here] and take a look at our first prototype! HTML and CSS can be extracted from it to make coding the visualisation easier (need edit permission).

===Interaction Design===
The interaction was designed to make the visualisation as intuitive as possible, with no need to explain the function of each tool. The homepage presents a search bar, which the user can use to input keywords if they have a specific theme they want to explore. The 'surprise me' button has been implemented for users that don't have a precise ideas and just want to explore the visualisation: it takes them randomly to a set of selected keywords. Using each of the two elements will take the user to the 'analysis page', where they will be able to subsequently navigate back to the homepage, to related topics, explore further some analyses by clicking on them.

All the implemented interactive options are intuitive, the user just clicks on the element and a new window, pop up or zoom will appear. e.g. the home button has a house shape: all straightforward.

Design elements

*Question marks pop ups: can click on question marks on the home page: pop up with text explaining general function of interaction + different options. Justification: clear help function, intuitive. User can choose to click on it: if knows how to use the visualisation, no impact on the design, content not overwhelming.
*Search bars and enter button: for learner's input of keywords/filters. Explicit function, similar to google
*Buttons for navigation within platform: return to home page... function indicated on button
*Links enabling user to click on words to either go to another page with this keyword inputted directly in the search bar, or click on paper title and go on page with more information about the paper: intuitive.
*zoom buttons indicated by + and -: function is intuitive. Allow the user to make the titles of some bubbles, that might be too small to read, more readable
We originally decided on putting no indication and let the user find its way through the interaction, but following the feedback process, realised we might want to implement a question mark pop up that provides more information on each page if clicked on.

==Progress and Future Work==
*The design is not finalised. We have done the prototype of the project and the main frame.
*Pages uploaded are: The main page and template pages for positive/neutral/negative terms.
*Main ideas for future improvements are coding the website and making it functional and using a broader data set to get more accurate results. Adding on that, the graphical design could be further improved by adding a scroll bar to the side column, make bubbles float and be movable and adding expanded views for individual graphs.
==Links==
*''Link to GitHub repository for code in development:''
*''Link to visualisation on ImpVis website (when uploaded):''
*ImpVis website (in progress): https://impvis.co.uk/code/projects/7
*''Link to Collection on ImpVis website (when created):''
*''Link to Figma Prototype:'' https://www.figma.com/proto/SVziYGbNHYZQQue8e1PWQ6/ImpVis?node-id=312%3A3&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=312%3A3
*''Project's Miro Board:'' https://miro.com/app/board/o9J_lpvA2FQ=/
*''Staff-partner's Research Paper:'' https://doi.org/10.1007/s10805-021-09422-4
<references />
[[Category:Project pages]]

The wider determinants of health at Imperial's GP practices

2022-02-09T13:24:11Z

Cclewley:

''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.''

==Contributors==
*Justin Lau, Katerina Loupasaki, Regen Petu-Stiles
*Renee Ewe, Faculty of Medicine, School of Public Health. Staff partner from October 2021
* Viral Thakerar, Faculty of Medicine, School of Public Health. Staff partner from October 2021
*''How was each person involved?''
**Regen Petu-Stiles worked on the interactive design draft in the Figma prototype (as well as the general ideation and justification of the idea)
**Katerina Loupasaki worked on the education side of the project (identifying suitable indicators and data in the context of the target audience) as well as the general justification of the interaction and graphic design
**Justin Lau created a prototype of the visualisation which pulls live data from the Fingertips API and allows users to plot graphs on a pre-selected set of indicators and regions corresponding to the relevant location to Imperial GP practices and helped justify part of the education design.
*''What rough dates did they contribute?''
**We each contributed on the Monday of every week from the week beginning Monday 11th October and also worked asynchronously between the live sessions on Mondays.
**The staff-partners contributed on two distinct Wednesdays through a Microsoft Teams meeting (synchronous) as well as asynchronously via the Microsoft Teams channel where they posted feedback, advice and additional resources for the project

==Aims & Learning Outcomes==

* ''Explain the motivation for your visualisation''
** Our Visualisation aims to introduce students to the wider determinants of health and prompt students to think about the association between different indicators and health outcomes in the population.
** This visualisation will be used to help first-year medical students prepare for the GP placements and understand how the health outcomes of the local populations are affected by the wider determinants of health. A visualisation is particularly useful in this context as it can better highlight associations between the different indicators compared to a simple text explanation which wouldn't allow for students to express curiosity and explore further associations depending on their interests.
** Target audience description: first-year medical students preparing for GP placement in the context of the Patients, Communities and Health module of their course. At this stage of their training, the students are being introduced to the wider determinants of health and will need to have a good understanding of how these affect health outcomes.
** Staff-partner brief:
*** the visualisation should allow first-year medical students to become familiar with the wider determinants of health that affect the population in their GP practice areas and express curiosity regarding the associations between different indicators
*** the visualisation will be used in the context of the Patients, Communities and Healthcare module for year 1 (phase 1a) medical students in preparation for the GP placement
*** the visualisation is needed as the existing data base is large and difficult to navigate, existing visualisations are not tailored to the specific locations that the students will be allocated and they also feature a large number of indicators which can be overwhelming for first-year students. Therefore, the staff-partners requested that our visualisation includes a more concise list of indicators that will allow students to explore the wider determinants of health in specific areas as well as evoke their curiosity for further exploration

* ''Introduce the subject of your visualisation''
** We are looking at socio-economic determinants of health and how they relate to overall health outcomes.
** These wider determinants extend beyond non-modifiable factors such as age and sex. They relate to the general social, economic, environmental and cultural aspects of a geographical location which in turn affect the health outcomes of the resident population.
** Examples of such indicators include: air pollution, access to green spaces, unemployment, pupil absence, and income deprivation. In turn, these might affect health outcomes such as: under 75 mortality rate from liver disease, life expectancy, % of diabetes.
* ''This visualisation is meant for use by students during e-learning and blended pre-reading for the Patients, Communities and Health Y1 (1a) Module.''
* Learning outcomes:
** ''After using this visualisation, students should be able to:''
*** Identify the wider determinants of health in specific GP practice areas
*** Relate specific determinants of health to their impact on health outcomes
*** Recognize that different areas in London (and their associated GP practices) have populations that differ in terms of health outcomes

After using this visualisation, students should be able to explain how societal inequity relates to health outcomes as applied to the local area of GP practices.

Useful data sources:

Location of GP practices the students will attend: <nowiki>https://www.google.com/maps/d/u/0/viewer?mid=1ZA9dwGqH3NV-b-syChVyMip13k5ZSMv9&ll=51.554548833368905%2C-0.21984190000002068&z=11</nowiki>

GP-level data: <nowiki>https://fingertips.phe.org.uk/api</nowiki>

R/Python packages for GP-level data: <nowiki>https://fingertips.phe.org.uk/profile/general-practice/data#page/9/gid/2000005/pat/166/par/E38000245/ati/7/are/H85637/iid/639/age/28/sex/4/cat/-1/ctp/-1/cid/4/tbm/1</nowiki>

Wider determinants data (not GP level, but general area): <nowiki>https://fingertips.phe.org.uk/profile/wider-determinants</nowiki>

==Design Overview==
*''What the final outcome was, how it looks, how it functions etc.''
*''Include graphics.''
*Link to prototype: https://www.figma.com/file/vhPMjbpmZ8gvlAMMhqYNu0/Wireframing-(Copy)?node-id=0%3A1
*''Do not include justification or design progression, leave this for later sections.''
==Design Justification==
===Assessment Criteria===
*''Education Design''
**Target audience and their prior knowledge is clearly identified. This information is applied to decide what the learning outcomes should be.
**Key concepts identified and broken down into several discrete and easily achievable points.
*Graphical Design
**The design is such that the visualisation is clear and easily understood; the layout isn't cluttered.
**The choice of font, as well as size and placement of text, makes the information easy to comprehend
**The colour palette is appropriate and well justified, making it easy to see all text/design elements
*Interaction Design
**The learner should know intuitively what the objectives are of the visualisation.
**The user should be able to intuitively understand the function of each interactive element in the visualisation
**There should be immediate visual feedback when a learner interacts with the visualisation
*General
**The wiki page should give a clear overview of the project, and someone not familiar with the project should be able to understand it - no prior understanding necessary.
**The design choices should be well justified in the Wiki project page
**Fulfillment of staff partner's brief
===Education Design===
*''What Methods were considered to convey concepts?''
**Our staff-partners provided us with examples of existing visualisations that they considered suitable and we discussed any modifications that could be made. Following that discussion, we decided to produce scatter plots of the data (similar to existing examples https://fingertips.phe.org.uk/profile/wider-determinants/data#page/10/gid/1938133045/pat/6/par/E12000001/ati/402/are/E06000047/iid/93701/age/169/sex/4/cat/-1/ctp/-1/yrr/1/iid2/90366/age2/1/sex2/1/cat2/-1/ctp2/-1/yrr2/3/cid/4/tbm/1), but tailor the data to the target audience
**To fulfil the staff-partner brief in terms of the education design aspects, we compiled a list of the relevant GP practices and areas and included only those in our visualisation so as to make it relevant and beneficial for the students
** Given that the students are in their first year and have only recently been introduced to the wider determinants of health, we selected indicators that could produce graphs that will depict interesting associations that are useful in a GP setting.
** Bearing in mind that the students may not be comfortable or entirely familiar with the wider determinants of health, we have included definitions of the indicators to help students understand what the variable they are selecting actually mean.
** Scaffolding: we have broken down the overarching concept of the wider determinants of health into distinct indicators that span the socioeconomic and environmental aspects. Having a list of specific indicators will allow the students to explore the wider determinants of health using specific examples, instead of being overwhelmed by the concept as a whole
** Students can also broaden their understanding of the wider determinants of health by selecting indicators that they find interesting. This can generate a number of different graphs while still ensuring that the students are taking away key concepts such as the relationship between indicators and health outcomes. This also means that students are achieving the intended learning outcomes and fulfilling the staff-partner brief: they're expressing curiosity about the wider determinants of health while learning about specific associations between indicators in their chosen area.
**We used the idea of prototyping to create a minimum viable product. In the future, the aim is to incorporate sliders/ other similar features to make the design entirely interactive
**Indicators can be selected allowing for a plot to be generated . This generation is not yet a feature we have integrated.
*How did we tailor the design to our target audience and their prior knowledge?
**As mentioned above, the target audience is first year medicine students at Imperial. Since the target audience consists of medicine students, who are unlikely to have worked with huge datasets before, we picked out the most relevant parts of the data to prevent them from being overwhelmed. From an original list of >1700 indicators, we have hand picked a few (<20 in total) which we believe are illuminating. The correlation matrix of the selected indicators is presented below. We have also narrowed down the choice of locations to 15 so only locations with student placements are included [[File:Correlation Matrix.png|center|thumb|797x797px]]
**It is unlikely that medicine students would have a lot of experience in manipulating complex data visualizations, so we have decided to keep it simple by using a scatter plot with drop-down axis for selecting which indicators to plot against each other
**Even though some of the indicators themselves are related to medical terms, first year medical students may not have experience in analysing real world data, so they may not be familiar with the precise definitions of these terms- for example, 'Under 75 mortality rate from cardiovascular diseases' is one of the indicators. Possible points of confusion may include how to determine whether a death is due to cardiovascular disease- does it have to be a direct cause, or would an indirect one also count? How does one determine what the direct cause of death? It is also unlikely that they would be familiar with the technical definitions of some socio-economic indicators, such as how exactly is income depravation measured? As a result, we would have a wiki page with definitions of such terms and students would be able to look up confusing definitions with ease.
**Since students are only in their first year, they are not expected to be able to give in-depth explanations of how one indicator relates to another (e.g. higher proportion of adults cycling for travel and higher life expectancy). This is because they probably are not equipped with the technical knowledge to do so (in the medical sense). Also, explaining these relations would need a good grasp of correlation/causation between variables, which is not the focus of the medicine course. Instead, they are encouraged to think about the relationships which they found interesting and discuss them on the forum
*How did we come up with our learning outcomes and how do we measure them?
**As mentioned above, the aim of this visualisation is to help students prepare for their GP placements. It is important for them to be aware of the socio-economic background of the area their GP is located at, since different causes leading to the same problem may lead to a different approach of dealing with the problem. They also need to understand that socio-economic backgrounds can differ between different areas. So what they know about a certain area might not be true in another. Hence, we have listed identifying the wider determinants of health in specific GP practice areas, relating specific determinants of health to their impact on health outcomes and recognize that different areas in London (and their associated GP practices) have populations that differ in terms of health outcomes as learning outcomes. To measure the extent to which these outcomes are achieved, there will be a forum where students are encouraged to discuss their findings. For example, students allocated to the same area could talk about how their area differ from other areas- is there anything they should pay attention to in particular? Is there any health risk which they think will be more prominent in their area because of the socio-economic background? Can they verify whether this is true with actual data obtained from the NHS website?
*[[File:Figma.png|center|thumb|312x312px]]''Design Justification:'' ''We went with the idea of an iPhone application for the basis of the platform. This allowed us to create a minimalist design that didn't overwhelm the user with information. It also allowed us to follow with the trend of accessibility, where students can contribute to research and discussions without needing a Personal Computer or laptop to hand. Passive and on-the-go studying is the space we are delving into.''
*The colour pallet is predominantly white to allow for the plots and data visualisations to be clearly distinguished against the background.
*''How has feedback been incorporated: We placed a platform explanation of the first page to allow for a general understanding of the platform. This was part of the iterative improvement process from the feedback.''
===Graphical Design===
*''How were accessibility issues considered?''
**[[File:Landing page.png|left|thumb]]
**We made sure to include large fonts and easily discernible objects
**The colour scheme used in the graphs includes variable and distinct colours to avoid confusion.
**It’s crucial to note that graphical design is inherently emotional. We considered colour theory heavily to make our choices. We used blue for warmer and less abrupt design elements, such as plots of less pressing health aspects.
**Below is the Home screen.
**We also used red for alerts and green for positive signals. We attempted to match tones the information being conveyed. Through the blue coloured landing page, our call to action was clear and inviting.[[File:Home11.png|center|thumb|346x346px]]
**As we were using an iPhone screen primarily, we added widgets and a horizontal scrolling feature for ease of access.[[File:Scroll.png|left|thumb]]
**We also implemented a discussion forum because we, as scientists believe research is collaborative. Here we considered, the flow of information and text, patterns, the 'Rule of Thirds' , a simple font and the left -to-right reading pattern to accommodate for Western Culture(where tis is being implemented)
*''How was space used effectively?''
**Objects of importance occupy the majority of each page and the absence of irrelevant elements or a cluttered design ensure that the visualisation is not overwhelming to navigate
**Key objects (e.g. graphs, indicator drop-down menus) are placed centrally to attract the users' attention
**Important information (e.g. instructions, indicator names) is written in clear, large fonts''.''
*''How has feedback been incorporated: We made the design intuitive ang guided to incorporate feedback''
===Interaction Design===
*''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click)''
**We have placed very large buttons on the bottom ends of the screen to allow a user to return to their original position.
**We have also made indicator choices large to make it easy to discern
**This is an image of the forum feature. The forum title is small as the focus should be on the visualisation
*''Keeping accessibility of interactive elements in mind during design phase''[[File:Choice.png|center|thumb]]
**Interacting with the elements of the visualisation does not require specific technical knowledge and students only need to be able to use the drop-down menu to generate the graphs. The drop down menu is intuitive to use and there is immediate visual feedback upon selection of the indicators i.e. the graph is generated
*''Design progression, With feedback incorporation:''[[File:Back.png|center|thumb|524x524px]] ''We added to the prototype by adding a feedback forum. This highlights the importance of student interaction. We also added a back button, this reset feature is important for understanding different areas of the visualisation.''
[[File:Feedback.png|center|thumb|454x454px]]
[[File:Account.png|left|thumb]]
We also created anonymized accounts for students.

Anonymity allows for concepts of identity protection, sensitive issue discussion and evasion of directed online harassment to be addressed all in one.

Please note that this anonymity is only between users. Each contribution is logged by the platform, for each user.

==Progress and Future Work==
*''Is the design finalised? Yes''
*''Which pages have been uploaded to website?''
*''Any ideas for future improvements''
**Link more data to the visualisation
**Improve the forum element to increase student engagement and increase utility in the context of the Patients, Community and Healthcare module
**Potentially add more opportunities for reflection. For example before the graph is generated, a box could pop-up asking the student to predict what the graph will look like. Alternatively, the same could be done once the graph has been generated and the students could be asked to think of reasons why the association observed exists.
==Links==
*Link to GitHub repository for code in development: https://github.com/n88k/ImpVis-Wider-Determinants
*Link to visualisation on ImpVis website (when uploaded):
*Link to Collection on ImpVis website (when created):
*Any other links to resources (Miro boards / notes pages / Google Docs etc):
**https://miro.com/app/board/o9J_lpvA2Mg=/
[[Category:Project pages]]

Solid Angles Design

2022-02-09T13:23:56Z

Cclewley:

== Contributors ==

* Cianne Park (student partner) 2021 Summer Team - BioEng
*Zhenghe Xuan (student partner) 2021 Summer Team - Physics
* Rishav Chatterjee (student partner) 2021 Summer Team - Computing
* Joshua Cheng (student partner) 2021 Summer Team - MechEng
* Robert Jones (student partner) 2021 Summer Team - Physics

== Aims & Learning Outcomes ==

Solid angles are the 3D variant of a normal angle, commonly associated with the field of view of an observer. In physics, this topic is typically taught with a focus on its uses in Gauss’ law. Whilst the actual concept is not complex, the topic is not covered in as much detail as other areas, due to a lack of time and resources. Whilst resources exist online to improve their understanding, the time required to research and find suitable sources would be better spent on more difficult and vital concepts. For this reason, a visualisation has been designed to improve the conceptual understanding of solid angles along with its applications.

This visualisation is designed for self study use in 2nd year Electromagnetism course in the Physics department.

The intended learning outcomes for the basic concept were:

After using this visualisation, students should be able to explain that:

* Solid angle is a (dimensionless, scalar) measure of '''field of view''' that a given object covers as seen from a particular point, expressed in units of steradians.
* Field of view depends on:
** the size of the object
** the distance of the object
* It can be seen as the surface area of the projection of the object onto a sphere surrounding the observer, at distance r=1. This means:
** the entire sphere would have solid angle 4pi steradians (as surface area of a sphere is 4pi*r^2)
** any size object at any distance has solid angle A/r^2, where A is the surface area of the projection on a sphere at distance r of the object.

And for the use in integration:

After using this visualisation, students should be able to explain that:

* The infinitesimal definition of solid angle is inner product of dS and r, divided by r^2. Here dS is the infinitesimal surface area element of a surface and the inner product is needed to only take into account the projection of the surface area vector along r.
* Integrating over solid angle rather than surface area is the same as the double integral over sin(theta) d(theta) d(phi), i.e. integrating over the surface area of a sphere with radius = 1.
* Infinitesimal definition of dOmega shows that flux from a point source through any surface with the '''same''' solid angle will be the same (basis for Gauss' law).

== Design Overview ==
[[File:Solid Angles Page 1.png|thumb|The first page of the solid angles visualisation design.]]
The first page has a circle showing the definition of an angle, which the students should be very familiar with. On the right hand side, is the three dimensional analogue with solid angles instead of a normal angle. The plot is 3D and made with plotly.js, users are able to pan, rotate and zoom to get a clear idea of what the picture is showing. The green lines in both plots represent the radii of the circle and sphere. As the arc length or area sliders are changed the plots will update to extend the arc length or shaded area in the respective plots. When the radii sliders are updated the radii of the sphere or circle will update in the plot above the slider only. The numbers in the equations will update as the sliders are changed.[[File:Solid Angles Page 2.png|left|thumb|The second page of the solid angles visualisation design.]]In the second page there are two plots which are intended to show the same scenario from different perspectives, as a result, adjusting any sliders will change both plots simultaneously. The plot on the left hand side is two dimensional and shows the view from the observer. The plot on the right hand side shows the three dimensional scenario, where the user can pan, resize and zoom to look around and get a full picture of what is going on. The position of the observer is shown as a person in the right hand side plot, along with their field of view which is shown as a semi-transparent cone.

The third page shows static images to help improve understanding of how to apply the theory to questions. There is one more key equation to learn however no interactive diagrams are provided as they would not provide any benefit. Instead, the page has a toggle which would switch to display some example questions, along with buttons to show the solution.
[[File:Solid Angles Page 3b.png|thumb|An example question on the third page of the solid angles visualisation design.]]
[[File:Solid Angles Page 3a.png|center|thumb|The third page of the solid angles visualisation design.]]

== Design Justification ==

=== Assessment criteria ===
i) Explain the key concepts of the problem through clear and engaging visualisations designed with a target audience in mind, using analogies where appropriate

ii) Create a simple and intuitive design with clear consideration of accessibility issues

iii) Clear design progression with justifications for choices

=== Education Strand ===
The 2D/3D comparison in the first page allows users to see that solid angles are just an extension of something they already know and boosts their confidence in their understanding. This use of analogy satisfies assessment criteria i). The equations for solid angle and angle are displayed and the values in these equations update dynamically with the plots, as the sliders are adjusted; this gives the students another perspective and helps clarify how solid angles work, addressing assessment criteria i).

In the second page, the student’s intuition about solid angles is improved by showing how solid angles are related to the familiar concept of field of view. This again satisfies assessment criteria i) with the analogy to a familiar concept. Allowing the user to move the object in 3D space and see how the solid angle changes introduces the fact that solid angles are dependent on the dot product of the separation vector and the surface vector through an intuitive example, satisfying assessment criteria ii).

Initially, we planned to add an additional section to page two where a flashlight was added and arbitrary shapes could be selected, however we decided that this would add too much complexity and potentially confuse the user so we removed this section. This progression of ideas towards a simplified design satisfies assessment criteria ii) and iii). We also moved from explicitly mentioning that 3D objects have a solid angle to simply using a 3D object in the visualisation and letting the students figure this out by playing around with it themselves since this will give them a more intuitive understanding; this satisfies assessment criteria ii) and iii). We decided to add a static diagram to page 2 which shows clearly how it is the projection of the object which gives the solid angle, as we thought that this effect may be too subtle to notice on the visualisation without prompting. This change towards a design with greater clarity satisfies assessment criteria i) and iii).

The third page shows students how solid angles are relevant to integration and Gauss’s law should motivate how important solid angles are. The integration example also shows how solid angles can be reached using simple trigonometry which the students should be familiar with; this gives an introduction to solid angles from a different perspective, helping the students get a more well rounded understanding. This satisfies assessment criteria i).

=== Graphics Strand ===
The design has used the Imperial Visualisation template due to its effective use of space along with appropriate positioning elements for the application. All of the interactive visualisations could be centred on the page as the main focus, with a clear information panel on the left to guide the user through the visualisation. This follows the Home Office Design recommendations for users with dyslexia, which could form a significant part of the target audience. Whilst there exist many other groups of users with various handicaps, catering to all of them would not be possible therefore efforts were focused on dyslexic users.

For all diagrams where comparison was a key part in understanding, the graphics were displayed side by side horizontally. Whilst this limited the maximum size of the graphics, it allowed the user to more easily recognise similarities and differences; use of a toggle to switch between the images would potentially cause frustration when having to repeatedly change diagrams. The result was a more intuitive design in accordance with criteria ii).

Colour coding the diagrams and sliders used would help to improve the user’s understanding, by improving comparison ability and highlighting key points of the images. On page one, the radius on both diagrams would have the same colour, whilst the arc length and surface area would also have their own colour. This highlights the similarity between the two concepts and aids the user in making this link. Similarly, the sliders corresponding to these variables also have the same respective colour; any use of the variable itself or its numerical value would also follow the same colour scheme as they are the key factors in the equation.

Positioning of the elements on the main area of the visualisation required consideration of the intuitiveness of the design. The diagrams are placed in the most central position as they are the key focus, with their titles just above. The sliders and equation could have been placed in a toggled hotspot however as the focus of the page is to understand the key factors of solid angles, they are positioned directly below the diagrams. Equations relating the variables are situated below the sliders to simulate the natural flow of thought for the user, from the variables and their values to the equation and the result.

Feedback noted the potential to improve the design by considering colourblind users when determining the colour scheme. [do research] Extensions for browsers exist which would automatically convert colours on a page to remove this issue. (<nowiki>https://addons.mozilla.org/en-GB/firefox/addon/axe-devtools/</nowiki>).

=== Interactivity Strand ===
Use of Sliders to adjust the parameters of the 2D and 3D figures [2D - arc length, radius; 3D - area, radius]. In page one the motivation behind using sliders apart from the ease of use was that it was best suited to assist the student to move on to the 3d figure once their intuition about the 2d structure was built (Familiarity would make the transition for the student simpler). In page 2, to adjust the x and z position in 2d and the object size in the 3d figure, sliders were implemented in the design keeping the user’s convenience the first priority.

The camera angles on the 3d figures on page 1 and 2 can be adjusted using a trackpad or mouse which would help the student get a better understanding of solid angles after using the visualisation by aiding the development of intuition regarding the topic.

Accessibility - The use of low contrast coloured sliders in a simple layout makes the visualisation accessible to a large audience. The parameters of the 2d and 3d figures can be adjusted using sliders that can be controlled via touch, mouse, trackpad as well as a keyboard which is another reason behind using sliders.

== Progress & Future Work ==
A final design has been created for this visualisation, but coding has not started.

Future work could include:

* Adding an interactive visualisation for page 3.
*Apply Zhenghe's feedback.
*Make all diagrams in plotly.

== Links ==

* Miro board showing full design process: https://miro.com/app/board/o9J_lsOvu7E=/?invite_link_id=301328771787
* Miro board showing main elements of the design project (task tree, skills matrix, poster): https://miro.com/app/board/o9J_ls7JFEY=/?invite_link_id=3443085594
*Miro board of the example design exhibition poster: https://miro.com/app/board/o9J_lsOvuIs=/?invite_link_id=250551203003
*Link to GitHub repository for code in development: N/A (not yet in development)
*Link to visualisation on ImpVis website (when uploaded): N/A (not yet uploaded)
*Link to Collection on ImpVis website (when created): N/A (not yet created)
[[Category:Project pages]]

Scanning electron microscopy

2022-02-09T13:23:40Z

Cclewley:

''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.''

==Contributors==
*''Name and what department each person was in.''
*''Student or staff partner?''
*''How was each person involved?''
*''What rough dates did they contribute?''

*Jonathan Rackham, Department of Materials. Staff partner from October 2021.
==Aims & Learning Outcomes==
*''Explain the motivation for your visualisation.''

*''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''

This visualisation will be used as a teaching tool in MATE50005 (Materials Characterisation) lectures as well as self-study tools in lab sessions. It will also be useful in the MATE70001 module (MSc Characterisation course) and as a useful teaching tool when training people on the SEM.

Note that this project has crossover with the [[Optical Microscopy|optical microscopy]] project.

After using this visualisation, students will be able to:
*explain the definitions of resolution in the context of a scanning electron microscope.
*qualitatively evaluate the impact of microscope parameters on microscope resolution.
*perform an alignment procedure on a microscope.
==Design Overview==
*''What the final outcome was, how it looks, how it functions etc.''
*''Include graphics.''
*''Do not include justification or design progression, leave this for later sections.''
==Design Justification==
===Assessment Criteria===
*''List your cohort's assessment criteria. You may want to number the assessment criteria so you can refer to them easily later.''
===Education Design===
*''What Methods were considered to convey concepts?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
===Graphical Design===
*''How were accessibility issues considered?''
*''How was space used effectively?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''

*''How is the design intuitive?''
===Interaction Design===
*''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
*''Keeping accessibility of interactive elements in mind during design phase.''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
==Progress and Future Work==
*''Is the design finalised?''
*''Which pages have been uploaded to website?''
*''Any ideas for future improvements.''
==Links==
*''Link to GitHub repository for code in development:''
*''Link to visualisation on ImpVis website (when uploaded):''
*''Link to Collection on ImpVis website (when created):''
*''Any other links to resources (Miro boards / notes pages / Google Docs etc):''
[[Category:Project pages]]

Quantitative PCR

2022-02-09T13:23:17Z

Cclewley:

==Contributors==
'''Students'''
*Jaroslaw Ciba, Department of Physics, creates visual designs
*Thomas Travis, Department of Physics, oversees interactive aspects of design
*Marcus Essam, Department of Medicine, in charge of overall design
*Jacky Zhu, Department of Medicine, edits and updates wiki page
'''Staff Partners'''
*Anabel Varela Carver, Department of Surgery & Cancer. Staff partner from October 2021.
*Joana Dos Santos, Department of Surgery & Cancer. Staff partner from October 2021.
*Jon Krell, Department of Surgery & Cancer. Staff partner from October 2021.
*Robert Kypta, Department of Surgery & Cancer. Staff partner from October 2021.
==Aims & Learning Outcomes==
'''Intended Use and Audience'''

This visualization is intended for self-study to support iBSc Cancer Frontiers Module 1 teaching (q-PCR principles, data analysis and application to an experiment involving cancer cells)

Learners are expected to have an basic understanding of how PCR functions as well as the purposes of using this technology, which are part of the standard A-level Biology curriculum.

'''Topic Background'''

qPCR is a laboratory technique widely employed in life science related subjects. It is build upon the foundation of PCR, a technological innovation allowing exponential amplification of genetic material. qPCR (Quantifying PCR) builds directly upon this concept, while enabling researchers to monitor the quantity of genetic material in real time as they amplify, hence the name qPCR or real-time qPCR. Through the analysis of data generated by qPCR, researchers will be able to conclude the presence or absence of a gene inside samples, as well as comparing their amounts in relative terms. Its most recent usage that gained global attention was its contributions to combating COVID-19 through viral DNA testing, which is considered the most accurate test to discover a current infection even in asymptomatic individuals.

'''Intended Learning Outcome'''

After using this visualization, students should be able to explain how changes in Ct values from a q-PCR experiment relate to changes in the numbers of copies of a gene that a cell contains (for example, a cancer cell upon treatment with a drug).
* Understand how PCR is applied to various biological research
* Describe the workflow of PCR centered protocols
* Explain the roles of different reagents used in PCR
* Provide basic analysis based on qPCR data, such as CT values
==Design Overview==
The overall flow of the visualization are divided into two parts:
# Explanation of the basic principles of PCR, including necessary reagents and what happens within one thermal cycle.
# Explanation of how to interpret PCR results (CT value in particular), as well as what factors may influence the result.
Each of these parts will be explored with multiple slides aiming to introduce material to students in manageable bits. For instance, PCR principles will be dissected down into lab flow, protocols, reagents, etc., whereas PCR results will be explored by taking apart separate data for examination first before bringing them together to form the bigger picture.

The entire project has been put together in a Powerpoint, available [https://imperiallondon-my.sharepoint.com/:p:/g/personal/jwc20_ic_ac_uk/EfWqmugEj01NlH_zrMdI9TgB94U2218wx4Q-P2nf1poV_Q?e=i9euEO&isSPOFile=1 here].

An example mockup animation, for PCR is available [https://imperiallondon-my.sharepoint.com/:p:/g/personal/jwc20_ic_ac_uk/EZAbz8uaTLxLtdJ3uAYK704BnMIbwp2jZ6ynFvNlL0tkQw?e=0v3Zgi here].[[File:PCR Slide 1.png|thumb|Original Design (1)]][[File:PCR Slide 2.png|thumb|Original Design (2)]][[File:Slide 1 2.png|thumb|First two slides of revised design]]
==Design Justification==
===Assessment Criteria===
'''Education Design'''
#Target audience and their prior knowledge is clearly identified. This information is applied to decide what the learning outcomes should be.
#Key concepts identified and broken down into several discrete and easily achievable points.
'''Graphical Design'''
# The design is such that the visualization is clear and easily understood; the layout isn't cluttered.
# The choice of font, as well as size and placement of text, makes the information easy to comprehend.
# The color palette is appropriate and well justified, making it easy to see all text/design elements
'''Interaction Design'''
# The learner should know intuitively what the objectives are of the visualization.
# The user should be able to intuitively understand the function of each interactive element in the visualization.
# There should be immediate visual feedback when a learner interacts with the visualization.
===Education Design===
*Diagrams are used throughout the visualisation as they convey a lot of information without requiring large blocks of text. Their use of colour can make them stand out too, allowing for a better overall learning experience for the learner.
*At the end of each section, we want to include a question testing the learner's knowledge - a mastery learning approach. These are included for the finished sections of the design. They are short questions, as was agreed with our staff partners in discussion, as students at Imperial generally feedback they are not tested enough in the resources provided by the Medicine department.
*The visualisation uses a scaffolding approach, where concepts are built upon through the entire visualisation. We first cover PCR, the technique built upon by qPCR, followed by looking at specific qPCR methods. In the next section, the result of these procedures, a qPCR graph, is discussed in more detail. Its shape is first described in the basics section, followed by methods needed to analyse it. We then finally introduce the factors affecting the Ct value in the graph one by one, before giving the user full access to an interactive graph with all the introduced complexity available (control of starting amount and the effect of a drug).
===Graphical Design===

==== General ====
*Most spaces are filled with custom made diagrams with captions to explain the different elements involved.
*Diagrams are designed or borrowed from biorender.com.
*Pages have a side section explaining concepts in text and a graphical panel on the right.
*Use of [https://www.imperial.ac.uk/brand-style-guide/visual-identity/brand-colours/ Imperial colour scheme] throughout so visualisation clear to see. This is a colour blind friendly palette.

==== PCR and qPCR Reagants ====
===== ''DNA Strands'' =====
* Chose a simple design made of straight lines. A lot of abstraction is allowed, as learners focus is on understanding PCR/qPCR - they already have brilliant grasps on the structure of DNA and other reagants, so do not need the detail. For example, the double helix of structure of DNA is simply reduced to straight lines with bases connecting them. Bases in uniform colour too - we do not need to match complementary bases, learners are more than aware of it. We instead use different colours to signfify areas of interest on the strands.
* Specifically, a simple green (#00FF00) was used to indicate area where the primer attaches, making it stand out. Later, this was changed to Imperials Teal for consistency with the Imperial palette and for contrast with SYBR green, reserving green for fluorescence.
* Different colours for DNA were trialled, with black (#000000) eventually chosen for simplicity.
* The thickness of strands was also played around with. Very thin and very thick designs both look awful, and a midrange thickness was chosen.
* Rounded caps are used at the ends of the strands as they do look better.
===== ''Primers'' =====
* Settled on red for contrasting against the green of area of interest on DNA strands.
* Imperials Red used (#DD2501) in final design, for consistency with the Imperial palette. This still contrasts the teal areas of interest well.
===== ''Polymerase'' =====
* Polymerase simplified to a rounded rectangle, with two ellipses, similar to some designs in research.
* The rectangle is orange from the imperial palette (#D24000), whilst the ellipses are tangerine (#EC7300). The darker colour is used to indicate depth, as the elliptical components of the polymerase "wrap" around a strand.
===== ''Taqman Probe - Body'' =====
* The body of the probe was made in a style consistent with previous visuals - sharp angles, no rounding, mostly straight lines.
* Lemon yellow (#FFDD00) used for the body of the probe, from the Imperial palette. Differentiates the probe from other elements;different colour from thermal cycles elements.
[[File:VD2.png|thumb|Comparison of old and improved design.]]
===== ''Taqman Probe - Quencher and Fluorescent Probe'' =====
*The quencher is a completely passive element, so grey used to not stand out. Different greys from the Imperial palette looked at, and initially settled on dark grey (#373A36). Light grey a bit difficult to see against the white background, whilst dark grey simply stands out better than cool grey - however, when the probe was combined with a DNA strand, it looked better with cool grey. As a result, cool grey (#9D9D9D) used in final design.
*The fluorescent probe emits green light; Imperials dark green used to show that the probe is inactive. When probe is detached off taqman, fluorescene starts. The greens featured on the Imperial colour palette not deemed suitable. A more vibrant light green used (#66ff0a) after playing around with the colours.
===== ''SYBR Green Design'' =====
*An inactive and active version exist; when attached to dsDNA, the dye is active. Inactive otherwise. This is simply shown via colour change.
*The inactive version uses dark grey. As noted in the fluorescent probe section, dark grey looks better than other greys in the Imperial colour paletter when on its own.
*Active version features the same lime green that Taqman used, to indicate fluorescence consistently between the two.
[[File:VD1.png|thumb|Design of probe and SYBR Green]]
===Interaction Design===
*Our first design included a large text box section however with feedback and self reflection we realised this wouldn't be engaging for the user even though it would be an efficient way to display information in a small space
*The final page of the qPCR graph section will allow users to tweak a qPCR curve with PCR parameters to observe how it can affect experimental outcomes.
*On the qPCR basics pages, the user can bring up more information by clicking the show more buttons. The extra information then will fade in, in place of the summary of the specific process. The user can then bring up another slide by clicking a different show more button, or go back to the summary by clicking the red cross.
*On the qPCR basics pages, the learner can play an animated version of the specific step in the qPCR/PCR process. A full animation of the entire process was liked by our peers, but with the change of format between the first draft and the final draft design, this is not included. To compromise, we include smaller pieces, distributed to each process.
*To navigate between the different visualisation pages, the user may scroll or directly click the relevant table of contents title. This flexibility is included as learners on revisits may not necessarilly require visiting all the sections, and may be more interested in a specific one or few.
*Different approaches are used for variety in end of section questions. These include checkboxes for multiple choice questions, draggable boxes for the ordering question for PCR steps and fillable parts for the Delta-Delta method. Prompts included to make sure the learner knows what to do in each section.
*All parts of visualisation include an ImpVis logo, permitting the user to go back to the ImpVis homepage, as direct consequence of feedback from our peers.
[[File:Side 3 4.png|thumb|More slides of the revised visualization]]
==Progress and Future Work==
*The design is not finalised, with the DNA production and qPCR graph subsections not completed.
*Including a home page with an introduction was suggested by our peers, and could be a good starting point for the visualisation.
==Links==
*''Link to GitHub repository for code in development:''
*''Link to visualisation on ImpVis website (when uploaded):''
*''Link to Collection on ImpVis website (when created):''
*https://miro.com/app/board/o9J_lpvA2AE=/?invite_link_id=762082753954
[[Category:Project pages]]

Optical Microscopy

2022-02-09T13:22:58Z

Cclewley:

==Contributors==
Ganel Nallamilli - Student partner from October 2021 - Department of Physics

Malhar Mukne - Student partner from October 2021 - Faculty of Medicine

Michal Horansky - Student partner from October 2021 - Department of Physics

Jeffrey Kahol de Jong - Student partner from October 2021 - Faculty of Medicine

Dr Rackham and Dr Franklyn - Staff partners from October 2021 - Faculty of Engineering, Department of Materials

''Optical Microscopy requires some background knowledge about lenses and light - this led to the two physics students, Ganel and Michal mainly working on education design and explanations of concepts, with Malhar and Jeffrey focusing on the graphic and interaction design of the visualisation. Although each student had a specific role, tasks were often had mixed allocations depending on availability and interest.''

==Aims & Learning Outcomes==
Optical microscopy describes the process of producing a magnified image of a microscopic object using a system of lenses, typically using visible light.

This visualisation will be used as a teaching tool in MATE50005 (Materials Characterisation) lectures as well as self-study tools in lab sessions. It will also be useful in the MATE70001 module (MSc Characterisation course).

Note that this visualisation logically leads onto the [[scanning electron microscopy]] project.

Students are expected to know about basic one lens systems and how they affect incoming light rays. Under the "Image basics" tab in the visualisation, the student should be able to remind themselves of the basics of lenses and how they produce an image. From this basic understanding of lenses, the visualisation will slowly add to their knowledge of ray diagrams and will allow the student to make links to physical components of a microscope and how they affect the image produced.

After using this visualisation, students will be able to (taken from staff partner's brief):
*explain the ray diagram of an optical microscope in reflection and transmission.
*describe the key properties of an optical system and identify the relevant contributing components.
*explain aberrations and its relevance in optical systems.
==Design Overview==
The visualisation is split into four components: "Overview", "Image Basics", "Chromatic Aberrations" and "Electron Microscopes". We expect the student to spend most of their time in the "Overview" section, which explains the key properties of each component in an optical microscope and relates the components to how they affect an image using a ray diagram. The "Image Basics" section is intended to be used as a refresher and is an overview of ray diagrams - this was an important feature to add as most of the project uses ray diagrams to explain the inner workings of a microscope. ''Not all pages are described below as they do not directly correspond to the aims or they mostly explain theory. To view these pages, please visit the Miro page which is linked at the bottom of the page under the heading "Links".''

=== Overview Section ===
In the "Overview" section, the student can select one of the seven basic components of a microscope: body tube, eyepiece lens, objective lens, adjustment wheels, stage, condenser and illuminator. The main components which help the student understand how the optical microscope works using a ray diagram is the eyepiece lens, adjustment wheels and objective lens. For the other remaining components, their key properties are described along with their purpose in the microscope.

==== Eyepiece lens ====
[[File:Eyepiece Lens Slide 2.png|thumb|This is a design of the second slide of the eyepiece lens in the overview section, which describes the features of an optical microscope. This slide shows the interactive feature of this component, which should help the student understand the purpose of the eyepiece lens using a ray diagram. The snapshot shows the screen when the user successfully chooses the correct focus of the eyepiece lens such that the image the eye sees is sharp.]]
The eyepiece lens is used to explain the idea of the focus of a lens. In this section, the student should recognise that the focus of the eyepiece lens has to be in the same plane that the image is formed from the objective lens to produce a clear image when the image reaches the eyes. The student will move the slider to change the focus of the lens in each setup until the image is sharp - this gives the student an intuitive understanding of how the eyepiece lens contributes towards producing a good image and further develops their understanding of a ray diagram which represents an optical microscope. It was important to not overload information to the student during the interactive features as this could confuse them. For this reason, only one element of the ray diagram could be controlled in this section, to help the student become familiar with the setup.
[[File:Adjustment Wheels Slide 2 Updated.png|left|thumb|This design shows the second slide of the adjustment wheel in the over section. This interactive feature allows the student to control two parameters, the coarse adjustment knob and the fine adjustment knob, which changes the position of the object relative to the body of the microscope. This interactive feature aims to bring the image to focus by manipulating the position of the object. The student should find that at high magnifications only the fine adjustment slider needs to be changed, once the coarse adjustment slider is set for smaller magnifications.]]

==== Adjustment Wheels ====
Changing the focus point of an eyepiece lens is not a realistic method to bring an image to focus as it would require multiple eyepiece lenses which isn't cheap and practically would take up a lot of space. In this section, the aim is to allow the student to recognise that changing the object distance to the objective lens changes the position of the plane where the image is formed. The student must use the coarse slider and fine slider to bring the image into focus, similar to the eyepiece section. The coarse slider moves the object closer or further away from the objective lens in big distances. Once the student gets close to the image forming at the focus point of the eyepiece lens, the fine slider is used to move the object in the exact position such that the image formed is at the position of the eyepiece lens focus point. This gives a feel for the practical nature of the adjustment wheels while keeping it in the context of a ray diagram and allows the student to visually see how the thin lens equation works.

==== Objective Lens ====
[[File:Objective Lens Slide 3.png|thumb|This design shows the third slide in the objective lens section in the overview section. The interactive feature allows the student to manipulate all aspects of the ray diagram apart from the eyepiece lens which mimics a typical optical microscope. This interactive feature gives the student an understanding of the magnification power of optical microscopes.]]
The objective lens is the main component which contributes to the magnification power of an optical microscope. The objective lens interactive feature allows the student to change all the individual features in previous sections at once, allowing them to fully explore how changing the objective lens focus point affects the magnification of the image. In this interactive feature, the eyepiece lens focus point is fixed which mimics a typical optical microscope, and changing the objective lens focus point is meant to resemble swapping the objective lenses. The student should intuitively understand why the image needs to be brought into focus every time the objective lens is changed in this interaction. After this interactive feature, the student should be able to explain the main features of a ray diagram of an optical system. Once the student reads the section about the illuminator, they will understand the need for transmission and reflected light microscopy - this doesn't change the understanding of the ray diagrams.

[[File:Chromatic Aberrations slide 2.png|left|thumb|This design is the second slide of the "Chromatic Aberrations" section. It explains how chromatic aberrations can be reduced with the use of a diagram.]]

=== Chromatic Aberrations ===
[[File:Chromatic Aberrations slide 3.png|thumb|This design is the final slide in the "Chromatic Aberrations" section. This slide covers astigmatism and shows visually why it produces a blurry image. The student should be able to recognise why the image is blurry after completing the "Overview" section. ]]
Chromatic aberrations are explained before astigmatism as we thought it would be easier to understand. Chromatic aberrations occur when using a light source composed of multiple colours such as white light. When white light enters a lens, the colours refract differently which means the image forms in different planes depending on the colour. This type of distortion of the image may prevent the user of the microscope from recognising certain elements of the sample as they may be stained, as shown in the slide, a crown and flint glass can be used to correct the dispersion. Astigmatism is then introduced after chromatic aberrations, which is usually caused by defects in the lens. Astigmatism affects all light sources, even monochromatic light sources, as it refracts light differently due to the physical abnormalities of the lens which results in light rays being focused at different points. This causes a blurry image to be seen, which is a critical problem when it comes to identifying features of a specimen in a microscope as the resolution is affected.

[[File:Electron Microscope slide 2.png|left|thumb|This design is the second slide in the "Electron Microscope" section. The interactive feature allows the student to change the current flowing through the electromagnets. By changing the current, the direction of the electron beam will change, which should resemble changing the focus point of a lens in optical microscopes.]]

=== Electron Microscopes ===
Electron Microscopes use electrons to view samples rather than light. This section briefly describes the similarities between optical microscopes and electron microscopes, as the next visualisation the students will view describes electron microscopes. The illuminator and lenses are compared with an electron source and magnetic lenses to show a direct relationship between the two microscopes. To further show the comparison between magnetic lenses and optical lenses, an interactive feature is added which allows the student to control the current flowing through the magnetic lens, which is just two electromagnetics that bends the beam of electrons. This visualisation aims to show that the electron beam can be affected similarly to optical microscopes. In optical systems, the physical properties of the lens affect the direction of light and in electron microscopes, only the current passing through the electromagnetics needs to change which affects the strength of the electromagnetics which in turn changes the direction of the electron beam.

''To view all the design pages, please view our miro board under the "link" section at the bottom of the page. Only the interactive features are included in this page. To achieve all the aims, the key properties of each components must be discussed - this is shown on the miro board.''

==Design Justification==
===Assessment Criteria===
'''General (G):'''

# Fulfilment of staff partner's brief.
# The design choices should be well justified in the Wiki project page.
# The wiki page should give a clear overview of the project, and someone not familiar with the project should be able to understand it - no prior understanding necessary.

'''Education Design (E.D):'''

#Target audience and their prior knowledge is clearly identified. This information is applied to decide what the learning outcomes should be.
#Key concepts identified and broken down into several discrete and easily achievable points.

'''Graphic Design (G.D):'''

# The design is such that the visualisation is clear and easily understood; the layout isn't cluttered.
# The choice of font, as well as size and placement of text, makes the information easy to comprehend.
# The colour palette is appropriate and well justified, making it easy to see all text/design elements.

'''Interaction Design (I.D):'''
#There should be immediate visual feedback when a learner interacts with the visualisation.
#The user should be able to intuitively understand the function of each interactive element in the visualisation.
#The learner should know intuitively what the objectives are of the visualisation.
===Education Design===
We decided to selectively enhance parts of the visualisation to convey details. This happens when the user clicks on/ hovers over a component. When the user hovers over a component it becomes outlined in orange. When the user clicks on a component, the component will be zoomed into and a tab that fades in containing information about the component will appear. This allows the user to focus on one bit of information at a time which improves their understanding and enhances their learning experience, which addresses E.D.2.

The student has been given a lot of control over how they progress through the visualisation so that they can learn at their own pace. They can revisit components or pages whenever they like to consolidate their understanding. The student can progress in any order as they should already know the basics of lenses and how they function, satisfying E.D.1. Sometimes other components may be referenced in the colour blue when describing the function of a component, which refers to other components of the microscope. The user can click on the blue text, and the relevant component will be shown. This allows the student to switch between related components easily.

A section to go over more basic concepts has been included so that the student has sufficient knowledge to understand the rest of the visualisation, in case they forget some fundamentals about ray diagrams. We decided to split the learning process into components, such as "image basics" and "chromatic aberrations" as to not overwhelm the user - different/more challenging concepts are separated so the user can progress onto them as they see fit, making sure E.D.2 is fully met.

With regards to E.D.2, we decided to gradually improve the understanding of the student's intuition of the ray diagram by allowing them to only change specific attributes of the ray diagram. With each step, the students will gain an intuition to how the ray diagram works as a whole, which can be shown when looking at the eyepiece lens, adjustment lens and objective lens interactive features in that order. Each element of the ray diagram is explored and then put together in the objective lens interactive feature allowing the student to fully explore the ray diagram controlling all elements which mimics a typical optical microscopy setup, which is one of our aims.

Initially, we were going to use tabs to explain each component of a microscope, although this would offer a clear structure to the visualisation agreeing with E.D.2, it may have made it more cluttered and the student may not be able to flow between each component as easily as they physically wouldn't know how these components fit together. After further discussions, we agreed that using a diagram of a microscope to explain each feature would be the best way to tie all the components together in a logical way. This allowed us to show the connections between each component in a visual way, which we think improves the learning process.

===Graphical Design===
[[File:Color Palette.png|thumb|The left most colour displays our main colours used in this visualisation. The corresponding columns show how our colour palette will be perceived when a person has protanopia, deuteranopia or tritanopia. In each column, we can see that each colour can be clearly distinguished, which confirms that our colour palette is colour-blind friendly.

Website used: https://davidmathlogic.com/colorblind/#%23D81B60-%231E88E5-%23FFC107-%23004D40]]
Originally we chose a colour palette filled with contrasting primary colours. However, we realised that the colours clashed quite a lot, looked unprofessional and could potentially distract the learner from the information presented to them. We decided to instead use a colour palette composed of black, blue and grey with some bright colours which guide the user. This looks more professional and doesn't distract the user with too many bright colours. Upon consideration of people who are colour-blind, we decided to use shades of blue (#3f4ebb) and orange (#ff7800) as our main colours as it provided us with the most common colour-blind friendly palette (see right), which addresses G.D.3.

Due to our unique design of having a single image, the microscope, as the focus of the visualisation, we decided to design a different template for this visualisation. There is a sharp contrasting border around the edge of the visualisation, clearly setting out the title at the top and topics at the bottom of the page. The border continues along the top and left-hand side of the screen to indicate that there is no element/progression on that side of the visualisation, focusing the user on the visual elements that are there. This is omitted on the right hand side to make way for the progress bar.

Concerning G.D.2, after experimenting with different typefaces, we all agreed that "Arial" was the clearest to read. This is a crucial aspect of the design as the design requires a lot of text to explain the key properties of an optical microscope. To enhance the readability we decided to make the text bold, making the text vivid and clear to read. An advantage of bold text is that it forced us to make our explanations concise as it took more room on the screen. To keep the text consistent throughout the visualisation, we decided to position the text on the left half of the screen at all times, which prevents confusion as information won't seem scattered. To be more consistent, we also kept headers, paragraph text and subheadings the same font size respectively throughout the entire visualisation.

We received feedback that certain sections of our design seemed cluttered such as the adjustment wheels section. Originally, all the information on these slides were on 2 slides. This resulted in cluttered interactive features and made the learning process much harder. To resolve this issue we added two extra slides to the adjustment wheels section and similarly altered other aspects of our design which we thought could be perceived as cluttered. The addition of more vertical white space in our designs made our designs look more professional and improved the readability of the information, satisfying G.D.1.

===Interaction Design===
Regarding I.D.3, a progression bar was included to let the users know how far they had progressed through the visualisation. This means that the users wouldn't miss anything, and gives them more incentive to finish everything on the page that they are on. The addition of a progression bar gives the student an understanding of their progression and meeting objectives in the visualisation.

The opening page is a schematic of a microscope, which users can interact with by clicking on different components. As the user hovers over a component, it becomes outlined in orange, indicating that it can be interacted with, addressing I.D.1. Once the user clicks on a component, the visualisation zooms into that particular component, and information appears relating to it. The user can then read the information and return to the main diagram whenever they wish. As each component is selected, a progress bar on the right-hand side will go up, providing the user with information about how many components they have covered.

Some components/topics have activities for the user - they can adjust the components themselves through the diagrams we have provided. In each interactive feature, a description of what the interactive feature is and the objective of the interactive feature is given. To make the interactive element as intuitive as possible we decided to only include sliders in our visualisation. This allows the student to spend more time learning about the content rather than trying to work out how to interact with the visualisation. By doing this we satisfy I.D.2. and allow the student to consolidate their understanding of optical microscopes.
[[File:Hover Over Tab.png|thumb|This design shows that all components have been viewed. This is shown as all the blue borders around each component and the progress bar is at 100%.]]
A piece of feedback we implemented was to do with the student knowing what components they have viewed. Initially, only the progress bar was updated when a new component was viewed, however, this led to the problem that students may not remember which components they have previously viewed and they are left guessing which components they have left. We fixed this issue by making the components already viewed highlighted in blue - this made it much clear how to progress through the visualisation, which further addresses I.D.1. The components would still turn orange if the user hovered over them with their cursor, indicating that they can revisit that page. To continue addressing this criterion, we decided to actively make sure the cursor changed to the link cursor whenever the cursor hovered over an interactive feature, this makes it explicit whenever the user can interact with a feature.

''Visit our Miro board (Project Blue) to see our designs for each page. The link can be found at the bottom of the page.''

==Progress and Future Work==
The overall layout and design has been created for this visualisation, however certain aspects of the design can still be improved and finalised.

'''Future work to include:'''

* Include more interactive features on transmission and reflected light microscopy. (Although these aspects were discussed in the illumination component section, no interactive features were made)
* Make planar view ray diagrams, or 3D ray diagrams to allow the students to visualise this process more naturally.
* Create interactive features for the different types of aberrations, and how they are dealt with. This would require replacing the "chromatic aberrations" tab for a more general "aberrations" tab. (Static diagrams are used currently)

==Links==
*''Link to GitHub repository for code in development:''
*''Link to visualisation on ImpVis website (when uploaded):''
*''Link to Collection on ImpVis website (when created):''
*''Any other links to resources (Miro boards / notes pages / Google Docs etc) -''
**'''Miro Board:''' https://miro.com/app/board/o9J_lpvA2Dg=/
**'''Animation for Overview page and components:''' https://www.youtube.com/watch?v=DxahOnnmJaA
[[Category:Project pages]]

Mathematical induction games

2022-02-09T13:22:38Z

Cclewley:

==Contributors==
*Zerui Qian, Department of Physics, Student partner from October 2021
*Kelly Chang, Department of Medical Biosciences, Student partner from October 2021
*Max Bingham, Department of Physics, Student partner from October 2021
*Deniz Aydin, Department of Mathematics, Student partner from October 2021

* Mark Wheelhouse, Department of Computing. Staff partner from October 2021.

== Staff Partner's Brief ==
1. Visualising "The Game of Frogs"

This is a thought experiment to get students thinking about Mathematical Induction. We would like to have a visualisation for this little game that will allow the students to experiment with the idea (number of frogs, starting speeds, etc).

The core learning outcome here is that a student should be able to provide an inductive argument to answer why all of the frogs will eventually fall off of the plank.

2. Visualising "The beetle and the cactus".

This is a thought experiment to get students thinking about Mathematical Induction. We would like to have a visualisation for this scenario that will allow the students to experiment with the idea (e.g. initial cactus set-up and beetle's rules). The core learning outcome here is that a student should be able to provide an inductive argument to show why the beetle can (and will) eventually consume the whole cactus. This thought experiment has also been referred to as "Hercules and the Hydra" and has an existing online visualisation. <blockquote>''I'd be happy with the students only tackling one of these two visualisations (not that I would be unhappy if they did both!)''

- Mark </blockquote>

==Aims & Learning Outcomes==
These two game visualisations will be shown during a lecture of COMP400018 - Discrete Mathematics, Logic and Reasoning. They will also be available for self-study so that students can validate what we have discussed in the lecture.

The two thought experiments are intended as playgrounds for developing an intuition for mathematical induction. Mathematical Induction is a technique for proving statements about a class of mathematical objects. The core idea is that if a statement is true for the first object in a sequence, and it being true for one object means that it is true for the next, then the statement must be true for all objects in the sequence. This can later be generalised to "structural induction", where the objects need not form a linear sequence but instead can be a part of any recursively defined structure, such as a tree.

The first thought experiment is "The Game of Frogs", where n frogs slide back and forth on a 1-dimensional frictionless log. If two frogs collide, they bounce off eachother, and if they reach the end of the log they fall into the water and are removed from the game. It seems obvious that each frog must eventually fall into the water, but how can one prove this? After the lecture, the students should be able to provide such an inductive argument.

The second is "The Beetle and the Cactus" (also known as the Kirby-Paris Hydra). A beetle is attempting to eat a cactus which has a tree structure, where every segment can have other segments branching off of it. When it eats one of the outermost "leaf" segments the segment immedietly before it gets duplicated, along with every one of it's descendents. The question is whether or not the beetle can finish off the whole cactus. At first the cactus appears to grow exponentially making the task seem impossible, but the surprising fact is that not only can the beetle eat the whole cactus regardless of the starting configuration, it cannot be avoided so long as it keeps eating. The inductive argument here is more complicated, as the cactus can get bigger before it gets smaller. Because of this a a complete proof is not expected from the students, but it would be nice for them to be able to describe a rough overview of how such an argument would work.

For our visualisation, Mark has stated that it is not strictly necessary for the inductive arguments to be explained within the visualisation for them to be of use in his lecture. The main intent is for the visualisation to make the abstract thought experiments more real for the students to play with and the teaching will be done around them. Our designs will at least have self contained instructions for use, but we may consider including an overview of the inductive arguments.

==Design Overview==
By our staff partner's reccomendation we focused on fleshing out one of the visualisation designs while viewing the other as a bonus task.

We provide:

* A blueprint for a visualisation of "The Game of Frogs", suitable for use in lectures or as a self-contained learning tool. Educational, Graphical, and Interaction design factors have been considered.
*A javascript prototype for "The Beetle and the Cactus" tackling some of the technical problems involved in visualising this thought experiment.

=== The Game of Frogs ===
<blockquote>''In The Game of Frogs, you swim or you die.''</blockquote>
[[File:FrogGameSlide1.jpg|none|frame|Page 1 is an introduction explaining the motiviation of induction in the context of computer science]]
[[File:FrogGameSlide2.jpg|none|frame|Page 2 introduces the setup, explaining the rules. Note: The completed visualisation should display the water the log is floating on]]
[[File:FrogGameSlide3.jpg|none|frame|Clicking the start button begins the animation, which runs until all frogs fall off. The user is then asked to consider whether this happens in general before moving on to the next page.]]
[[File:FrogGameSlide5.jpg|none|frame|Page 3 is the main visualisation. Users can change the number of frogs, the speed and direction of each individual frog and then observe the results.]]
[[File:Beetle and Cactus1.png|thumb|Screenshot of the inital configuration.]]

=== The Beetle and the Cactus ===
[https://editor.p5js.org/denayd/full/NdbfTJNmc '''Link to prototype''']

''(Note: this link is live so functionality may break or change as I work on it. Reported not to work on some (Kelly's) browsers, should be fine on mobile now though)''

Click on the leaf (pink) segments and watch the magic! Code can be seen by clicking the button in the top right.

==Design Justification==
===Education Design===
Though this was not a requirement in the brief, I felt as though it was necessary to provide context for why this topic matters in computer science. The explanation here would have been totally different if this was for a mathematics course, but I thought computing students would like to have the direct connection to computer programs explained. The decisions on what variables the user should control and what should be emphasized was also based on the educational context.

I would not say our visualisation alone fits the learning outcome specified in the brief as we did not get on to explaining the inductive argument, but I think this isn't so bad as it is intended to be a tool used alongside lectures to get the students thinking about how they would construct such an argument themselves. If we straight up told them the answer there wouldn't be much point in the interactive visualisation. However, an extra page detailing the argument is listed in potential future work.

===Graphical Design===
A key goal of the design process was to have the abstract mathematical problem appear more familiar to the user, in order to keep them actively engaged. We chose to implement the conventional icons like the start/stop/pause buttons one would expect in any interactive animation; the user does not need to be reminded what the purpose of these are and so we save clutter on the display by using them. Given the theme of animals we also thought a nice touch would be to include hare/snail symbols to indicate the speeds of the frogs.

We chose also to implement the conventional start/stop/pause buttons one would expect in any interactive animation

The red (wood), green (frog), and blue (water) colour scheme is vibrant and complements Imperial's own colour scheme which we use in our UI. We felt this choice would look engaging and clear in its simplicity, as well as be consistent as an ImpVis visualisation.

We wanted the configuration of the game to be highly interactive for the user; enabling them to customise the speeds of the frogs individually with sliders allows them to get their hands on the problem at hand in an engaging way. By implementing vertical sliders we simultaneously provide this option to the user, and take up dead space caused by the one-dimensional horizontal aspect of the game.

To keep from the visualisation feeling plain, one possible feature of an implementation of this design could be a page transition in which the log, frogs, etc. are dropped onto the screen (featuring water) at the start of a new page, and drift offscreen at the end of one.

In keeping with mathematical conventions, the velocities of the frogs are indicated by vectors to provide feedback for when the user changes them. In an extreme case of many frogs being hard to keep track of, we can employ a colour scheme to indicate the parity (direction) of their motion.

===Interaction Design===
In the main visualisation, buttons that start, pause, and reset the game are located at the upper left corner of the visualisation section. All buttons have icons, and in many cases these are so universal and familiar that text labels are not necessary. Buttons that cannot be interacted with at the current moment are "grayed out". Otherwise all buttons are colour-coded: yellow for pause, red for reset, green and red for adding and removing frogs.

We had much discussion about what parameters the user need to change as being able to control every detail could get overwhelming. We decided on these:

==== Number of Frogs ====
A frog counter is located at the upper left corner of the visualisation section. The number of frogs on the log, and number of frogs fallen off the log are shown, though the latter is greyed out while the simulation is not running as it conveys no useful information at that point. Even though you can infer the number of frogs remaining by looking at the image we still believe it is key information that needs to be emphasized as it is the core of the inductive argument. Users can control the number of frogs by clicking add and remove frog buttons, or typing in a number directly into the box if they wish to save time. A limit on the number of frogs will likely be needed but the exact number will be constrained by technical limitations.

==== Frog Velocities ====
The velocity of each individual frog can be changed by varying the slider above it. Sliders are ideal for this task as they are good for variables where full precision is not necessary. To make the purpose of these sliders intuitive, snail and hare icons are shown and the slider body gets thicker towards the top, indicating a rise in intensity as the slider goes up. With many frogs changing the velocities one by one is annoying so a button is provided to randomize all of them to get a varied spread of speeds without taking too long. In response to feedback we have added the option to select all frogs at once and allow the user to toggle any single slider to change the speeds of all the frogs together.

In addition, clicking on the frog will flip its direction. Hovering over a frog will show a blue circular arrow in order to make this obvious before the user does it.

==== Animation Speed ====
With differing frog numbers, the run time for the game will differ and it may be more ideal if the user can change the animation speed to improve engagement with the game. For example, a simulation with a high frog count would take relatively longer for the game to conclude, so allowing the user to speed up the animation while it is running with a slider will help sustain focus.

=== Beetle and Cactus ===
The Beetle and Cactus prototype is intended more as a technical demonstration than a full design but there are still some design decisions that go into it. The cactus itself is based on the prickly pear plant, as it has the desired node-tree structure. This also makes the colour scheme very contrasting with the green body nodes and the pink clickable edge nodes.

The main thing the prototype does is provide a solution to the problem of displaying the full cactus and animating it's growth. Each of the descendants of a node are evenly spread out (by angle) around it, and when a node is removed the duplication of it's parent is smoothly animated with transparency so the user can clearly see what is being changed. An animation speed slider is provided so they can speed it up if they wish to click through the cactus faster.

The starting cactus is chosen to be large enough for it to grow a fair amount as it gets eaten, but still be relatively quick to beat as slightly larger cacti get out of hand very fast! When there is no more cactus the following message is displayed:<blockquote>The cactus is defeated! But now the beetle will starve - could it have sustained itself forever?</blockquote>This poses an extra (impossible) challenge to the user and attempting it will force them to think about why the cactus will run out rather than just mindlessly clicking through it.

==Progress and Future Work==
We are happy to say we have succeeded in our goal of a complete design for The Game of Frogs. Nevertheless there are opportunities for future work to consider:

* Of course, actually constructing the visualisation in Javascript.
* Creating vector sprites for the components involved.
* Designing slides that go after the visualisation to explain the inductive argument in detail, as well as the broader concept of mathematical induction it is an example of. This would ordinarily be done in the lecture it is shown in, but having this built in to the visualisation would allow it to be used as a learning tool for people outside the course as well.

The prototype Beetle and Cactus game functions and could be used in lectures but is not a complete visualisation design. As such there is a lot of future work that could be done here:

* Making a new wiki page for it, as it will likely be a seperate visualisation entirely from The Game of Frogs.
* Figuring out why it doesn't work on some people's browsers.
* Supplementing the prototype with an educational preamble and an animated explanation of the rules.
* Designing an explanation of the inductive argument which this time is more complicated as it typically uses ordinals, at least in the general case.
* Adding the choice of mutltiple starting cacti, or even custom user-defined ones.
* An "auto-play" feature that just eats away at the cactus without user input.
* Improving visuals, eg making the cactus look more realistic.

== Useful links ==

* [https://www.imperial.ac.uk/brand-style-guide/visual-identity/brand-colours/ The Imperial Brand colours]
* [https://googology.fandom.com/wiki/Kirby-Paris_hydra Googology Wiki article on the Kirby-Paris Hydra]. In the version we implemented, n is always 1.
[[Category:Project pages]]

Constructive alignment in curriculum design

2022-02-09T13:22:12Z

Cclewley:

''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.''

==Contributors==
*''Name and what department each person was in.''
*''Student or staff partner?''
*''How was each person involved?''
*''What rough dates did they contribute?''

* Kirsten Dalrymple, Department of Surgery and Cancer. Staff partner from October 2021

==Aims & Learning Outcomes==
*''Explain the motivation for your visualisation.''

*''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''

This visualisation will be used to support our students' understanding of the concept of constructive alignment and its use in designing curricula. The visualisation will be embedded in an asynchronous session (minilecture, reading, tasks) within a module on Designing and Evaluating Curricula. Learning from this session will feed into coursework and the summative assignment where students are creating a lesson plan for their own surgical teaching. Contextualising this visualisation for surgical and/or medical education will be useful.

After using this visualisation, students will be able to:

* Formulate and choose learning outcomes suitable for planning or developing curricula
* Demonstrate and discuss the importance of constructive alignment in the development of curricula
* Critically discuss and plan a teaching session utilising good practice in learning outcome design and constructive alignment

==Design Overview==
*''What the final outcome was, how it looks, how it functions etc.''
*''Include graphics.''
*''Do not include justification or design progression, leave this for later sections.''
==Design Justification==
===Assessment Criteria===
*''List your cohort's assessment criteria. You may want to number the assessment criteria so you can refer to them easily later.''
===Education Design===
*''What Methods were considered to convey concepts?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
===Graphical Design===
*''How were accessibility issues considered?''
*''How was space used effectively?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''

*''How is the design intuitive?''
===Interaction Design===
*''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
*''Keeping accessibility of interactive elements in mind during design phase.''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
==Progress and Future Work==
*''Is the design finalised?''
*''Which pages have been uploaded to website?''
*''Any ideas for future improvements.''
==Links==
*''Link to GitHub repository for code in development:''
*''Link to visualisation on ImpVis website (when uploaded):''
*''Link to Collection on ImpVis website (when created):''
*''Any other links to resources (Miro boards / notes pages / Google Docs etc):''
[[Category:Project pages]]

Category:Project Pages

2022-02-09T13:21:49Z

Cclewley: Created blank page

Test

2022-02-09T12:56:38Z

Cclewley:

''This is a template which you can use to help get you started on a Wiki for a new visualisation project - it serves as a dynamic 'ReadMe' file of your project. The template is just intended as a guide and you may modify the structure to suit your project (all template instructions are in italics and do not need to be saved in your own project page).''

'''''Note: if you are taking part in the I-Explore module, the [[Wiki Submission Template|submission template]] will be better suited to your needs.'''''

''When a new project is started, the 'Contributors' and 'Aims & Learning Outcomes' sections need to be filled out. Aim to include the rest of the information by the time the design is finalised. The page can be updated whenever the visualisation is updated - ensure to credit all contributors!''

''To create your own project page from this template, do the following:''

# ''In a separate browser window / tab, create a new project page with the same title as your project. Ensure to assign your page to the category 'Project pages'. Read '''[[Making Wiki Pages]]' ''for detailed instructions of how to do this.''
# ''Come back to this template and press 'Edit' at the top of the page.''
#''Select all the text on this page (not the title) and copy it.''
#''Click 'Read' at the top of this page (choose 'Discard edits' in the pop up window to avoid saving any accidental edits).''
#''Go to your browser window with your new project page and paste the text you copied.''
#''Make any edits you want on your own project page (e.g. entering your name as a contributor) and press the blue button 'Save page...' at the top right of your page.''

== Contributors ==

* ''Name and department of each person.''
*''Student or staff partner?''
* ''How is/was each person involved?''
* ''What rough dates did they contribute?''

== Aims & Learning Outcomes ==

* ''Explain the motivation for your visualisation.''

* ''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''

== Design Overview ==

* ''Once the design is agreed, describe the final outcome, how it looks, how it functions etc.''
* ''Include graphics.''

== Design Justification ==

''Optionally describe any notable decisions made for the design, e.g.''

* ''Educational design: breaking down of concepts (scaffolding)''
* ''How were accessibility issues considered?''
* ''How was space used effectively?''
* ''How is the design intuitive?''
* ''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
== Progress and Future Work ==

* ''Is the design finalised (i.e. agreed by all partners)?''
* ''If applicable, which pages have been uploaded to website?''
* ''Any ideas for future improvements.''

== Links ==
*Link to GitHub repository for code in development:
*Link to visualisation on ImpVis website (when uploaded):
*Link to Collection on ImpVis website (when created):
*Any other links to resources (Miro boards / notes pages / Google Docs etc):
[[Category:Project pages]]

Test

2022-02-09T12:54:18Z

Cclewley: Created page with "''This is a template which you can use to help get you started on a Wiki for a new visualisation project - it serves as a dynamic 'ReadMe' file of your project. The template..."

''This is a template which you can use to help get you started on a Wiki for a new visualisation project - it serves as a dynamic 'ReadMe' file of your project. The template is just intended as a guide and you may modify the structure to suit your project (all template instructions are in italics and do not need to be saved in your own project page).''

'''''Note: if you are taking part in the I-Explore module, the [[Wiki Submission Template|submission template]] will be better suited to your needs.'''''

''When a new project is started, the 'Contributors' and 'Aims & Learning Outcomes' sections need to be filled out. Aim to include the rest of the information by the time the design is finalised. The page can be updated whenever the visualisation is updated - ensure to credit all contributors!''

''To create your own project page from this template, do the following:''

# ''In a separate browser window / tab, create a new project page with the same title as your project. Ensure to assign your page to the category 'Project pages'. Read '''[[Making Wiki Pages]]' ''for detailed instructions of how to do this.''
# ''Come back to this template and press 'Edit' at the top of the page.''
#''Select all the text on this page (not the title) and copy it.''
#''Click 'Read' at the top of this page (choose 'Discard edits' in the pop up window to avoid saving any accidental edits).''
#''Go to your browser window with your new project page and paste the text you copied.''
#''Make any edits you want on your own project page (e.g. entering your name as a contributor) and press the blue button 'Save page...' at the top right of your page.''

== Contributors ==

* ''Name and department of each person.''
*''Student or staff partner?''
* ''How is/was each person involved?''
* ''What rough dates did they contribute?''

== Aims & Learning Outcomes ==

* ''Explain the motivation for your visualisation.''

* ''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''

== Design Overview ==

* ''Once the design is agreed, describe the final outcome, how it looks, how it functions etc.''
* ''Include graphics.''

== Design Justification ==

''Optionally describe any notable decisions made for the design, e.g.''

* ''Educational design: breaking down of concepts (scaffolding)''
* ''How were accessibility issues considered?''
* ''How was space used effectively?''
* ''How is the design intuitive?''
* ''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
== Progress and Future Work ==

* ''Is the design finalised (i.e. agreed by all partners)?''
* ''If applicable, which pages have been uploaded to website?''
* ''Any ideas for future improvements.''

== Links ==
*Link to GitHub repository for code in development:
*Link to visualisation on ImpVis website (when uploaded):
*Link to Collection on ImpVis website (when created):
*Any other links to resources (Miro boards / notes pages / Google Docs etc):
[[Category:Getting Started]]

Programming languages

2022-02-02T14:11:07Z

Cclewley: /* The tools we use to create visualisations */

== The tools we use to create visualisations ==
Hypertext Markup Language (HTML) is the backbone of any webpage, and this is the case for ImpVis. HTML is less of a language and more of a collection of blocks or ‘elements’ that define what goes on your page. HTML allows us to define everything on our page, but cannot do much else. For the most part, HTML is static and cannot perform complex equations or plotting. This is where JavaScript (JS) comes in. ImpVis visualisations use JS to perform physical/mathematical calculations, plot, and achieve interactivity. These elements can contain anything from text to a slider to a graph plot, and can be styled to your preference! From the size of your element to the text color, this styling can all be specified using another language: Cascading Style Sheet (CSS).

Here are a few links to relevant places on how to do some basic HTML, CSS and JS -
*'''HTML''': https://www.codecademy.com/learn/learn-html https://scrimba.com/learn/htmlcss
*'''CSS''': https://www.codecademy.com/learn/learn-css
*'''JS''': https://www.codecademy.com/learn/introduction-to-javascript and https://scrimba.com/learn/learnjavascript
For the HTML course, you will most likely require sections 1. ''Elements and Structure'', and 3. ''Forms''. You may choose to opt-out on learning CSS as we have a set of predefined components, like sliders and buttons, which will be introduced later! If you are interested in customising the components, you may come back and learn CSS. As for JS, sections 2-7 are essential, and sections 8 and 9 are useful for object-oriented programming.

While coding a visualisation, you will inevitably have to use some mathematical functions. ''Math.js'' is an extensive JS math library that provides many useful tools. For more information, https://mathjs.org/.

== Further links ==
Have a look at our [[Help on HTML, CSS, JS and JS libraries]] page for further guidance on these coding languages.
[[Category:Setting Up]]

Wiki Template for new project

2022-01-19T16:15:00Z

Cclewley: Italicised instructions

''This is a template which you can use to help get you started on a Wiki for a new visualisation project - it serves as a dynamic 'ReadMe' file of your project. The template is just intended as a guide and you may modify the structure to suit your project (all template instructions are in italics and do not need to be saved in your own project page).''

'''''Note: if you are taking part in the I-Explore module, the [[Wiki Submission Template|submission template]] will be better suited to your needs.'''''

''When a new project is started, the 'Contributors' and 'Aims & Learning Outcomes' sections need to be filled out. Aim to include the rest of the information by the time the design is finalised. The page can be updated whenever the visualisation is updated - ensure to credit all contributors!''

''To create your own project page from this template, do the following:''

# ''In a separate browser window / tab, create a new project page with the same title as your project. Ensure to assign your page to the category 'Project pages'. Read '''[[Making Wiki Pages]]' ''for detailed instructions of how to do this.''
# ''Come back to this template and press 'Edit' at the top of the page.''
#''Select all the text on this page (not the title) and copy it.''
#''Click 'Read' at the top of this page (choose 'Discard edits' in the pop up window to avoid saving any accidental edits).''
#''Go to your browser window with your new project page and paste the text you copied.''
#''Make any edits you want on your own project page (e.g. entering your name as a contributor) and press the blue button 'Save page...' at the top right of your page.''

== Contributors ==

* ''Name and department of each person.''
*''Student or staff partner?''
* ''How is/was each person involved?''
* ''What rough dates did they contribute?''

== Aims & Learning Outcomes ==

* ''Explain the motivation for your visualisation.''

* ''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''

== Design Overview ==

* ''Once the design is agreed, describe the final outcome, how it looks, how it functions etc.''
* ''Include graphics.''

== Design Justification ==

''Optionally describe any notable decisions made for the design, e.g.''

* ''Educational design: breaking down of concepts (scaffolding)''
* ''How were accessibility issues considered?''
* ''How was space used effectively?''
* ''How is the design intuitive?''
* ''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
== Progress and Future Work ==

* ''Is the design finalised (i.e. agreed by all partners)?''
* ''If applicable, which pages have been uploaded to website?''
* ''Any ideas for future improvements.''

== Links ==
*Link to GitHub repository for code in development:
*Link to visualisation on ImpVis website (when uploaded):
*Link to Collection on ImpVis website (when created):
*Any other links to resources (Miro boards / notes pages / Google Docs etc):
[[Category:Getting Started]]

Wiki Template for new project

2022-01-19T16:07:44Z

Cclewley: Added in instructions for creating your own project page

''This is a template which you can use to help get you started on a Wiki for a new visualisation project - it serves as a dynamic 'ReadMe' file of your project. The template is just intended as a guide and you may modify the structure to suit your project.''

'''''Note: if you are taking part in the I-Explore module, the [[Wiki Submission Template|submission template]] will be better suited to your needs.'''''

''When a new project is started, the 'Contributors' and 'Aims & Learning Outcomes' sections need to be filled out. Aim to include the rest of the information by the time the design is finalised. The page can be updated whenever the visualisation is updated - ensure to credit all contributors!''

''To create your own project page from this template, do the following:''

# ''Create a new project page with the same title as your project. Ensure to assign your page to the category 'Project pages'. Read '''[[Making Wiki Pages]]' ''for detailed instructions of how to do this.''
#

== Contributors ==

* Name and department of each person.
*Student or staff partner?
* How is/was each person involved?
* What rough dates did they contribute?

== Aims & Learning Outcomes ==

* Explain the motivation for your visualisation.

* Introduce the subject of your visualisation.
*Which module and year is it intended for and which setting (lecture or self study)?
*List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."

== Design Overview ==

* Once the design is agreed, describe the final outcome, how it looks, how it functions etc.
* Include graphics.

== Design Justification ==

Optionally describe any notable decisions made for the design, e.g.

* Educational design: breaking down of concepts (scaffolding)
* How were accessibility issues considered?
* How was space used effectively?
* How is the design intuitive?
* Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).

== Progress and Future Work ==

* Is the design finalised (i.e. agreed by all partners)?
* If applicable, which pages have been uploaded to website?
* Any ideas for future improvements.

== Links ==
*Link to GitHub repository for code in development:
*Link to visualisation on ImpVis website (when uploaded):
*Link to Collection on ImpVis website (when created):
*Any other links to resources (Miro boards / notes pages / Google Docs etc):
[[Category:Getting Started]]

Knowledgebase

2022-01-19T16:00:14Z

Cclewley:

This is the ImpVis knowledge base; it contains all of the information ImpVis has accumulated as a community in order to design and develop effective interactive visualisations for education.

The structure of this page follows the steps of [[our design and development process]] closely.

== Getting started ==
These are the suggested steps to take if you wish to know all about how to get involved in the ImpVis project.

# Read a brief overview of [[our design and development process]] (ensure to take the first step: connecting with our community).
# Find out how to [[Getting involved|get involved]] with a visualisation project.
# Understand what it means to [[Working in partnership|work in partnership]].

You can follow the links in the pages above to find out more information. Below are listed all the pages in the 'Getting Started' category in alphabetical order.<categorytree mode="pages">Getting Started</categorytree>

==Visualisation design guidance==
To create an interactive visualisation for education, you will need to consider the design of your visualisation carefully from several angles. The ImpVis template implements some of our ideas so that you do not need to design your visualisation entirely from scratch. Suggested steps to follow:
# Carefully phrase the visualisation's aim, learning outcomes, and intended implementation. Read [[Scaffolding concepts]] for guidance. Document these in your own project's Wiki page. If you haven't yet created your own project Wiki page, do so now by copying the [[Wiki Template for new project|template Wiki]] and filling in the sections. Have a look at [[Solid Angles Design|this example]] of a finalised design.
# Familiarise yourself with the [https://impvis.co.uk/launch/impvis-layouts-v2/page1.html?collection=39 ImpVis visualisation template] (hosted on the ImpVis website) so you understand how it can support your visualisation design and read the [[ImpVis template description|description of the ImpVis template]].
#Check out the [[Organising content]] page to consider how to populate the visualisation template with your own visualisation's content.
#Decide on what the visualisation will look like and how it will work. Peruse the design guidance documents listed below to help you.
#Insert a design sketch, including the visual and interactive elements of the visualisation, in your visualisation's dedicated Wiki project page. Explain the rationale of your decisions.
#Once all staff partners are happy with the design, they need to formally confirm their agreement on the website to move their project to the development stage (read [[Managing your project on the ImpVis website#Changing the progress status of your project|here]] about how to do this).

Below we list all our design guidance documents alphabetically, split up into three different categories: education, graphic, and interaction design. Note that we have only just started collating our experience in this section, so it is sparsely populated - we aim to incorporate all knowledge generated by the ImpVis module students in this Wiki going forward.<categorytree mode="pages">Design Guidance
</categorytree>

== Guidance for coding up visualisations==

'''Before you start coding, ensure the visualisation design is well documented on your Wiki project page and all partners have agreed on the design!''' If you haven't done this yet, revisit [[Our design and development process#Visualisation design based on aims and learning outcomes|the steps to take in the design process]] to find out how to do this.

The sections below contain technical guidance to support you with the coding side of ImpVis.

=== Setting up===
When starting coding, these are the suggested steps to follow:

# [[Programming languages|Read about our programming languages]] and where to find some training resources.
# [[Tutorial for setting up the coding environment|Follow this tutorial]] to set up your coding environment.
#[[Getting connected on Github|Learn]] about getting started on GitHub.
All our pages with guidance for setting up are listed below in alphabetical order.<categorytree mode="pages">Setting Up</categorytree>
===The ImpVis visualisations template===
Here you can find information about the ImpVis template created in 2020, using vue.js. You should already have familiarised yourself with the ImpVis template during the design phase. However, before you proceed with the coding, make sure you have an in-depth understanding of the template and its components, including how to include the components in your code. Suggested steps to take:

# See the template in action here: [https://impvis.co.uk/launch/impvis-layouts-v2/page1.html?collection=39 ImpVis template].
# Read the [[ImpVis template description]].
#Follow the [[Basic Component Tutorial|basic tutorial]] on how to include components in your code and/or take the [[introduction to Vue workshop]].
# Find technical documentation on all ImpVis [[Vue Components|Vue components]].

Below are all our guidance pages for the ImpVis and the associated components, in alphabetical order.<categorytree mode="pages">ImpVis Template
</categorytree>
===The coding process===
Look here for tips and help on issues that may come up while you're coding. Here are some pages to get your started:

# [[Structuring your code]]
# [[Help on HTML, CSS, JS and JS libraries]]
#[[JavaScript packages for graphics|Javascript packages for graphics]]
#[[Vue.js guidance]]
#[[Tips for the developer]]

All our coding tips pages are listed alphabetically below.<categorytree mode="pages">Tips Whilst Coding
</categorytree>
==Review and publication of your visualisation==
When you have completed coding up your visualisation, it is time to upload it to the ImpVis website. It will then need to be reviewed before it can be published in 'Teach' environment. You should also create a Collection so your intended learners will easily be able to access your visualisation. Suggested reading:

# [[Uploading a new visualisation]]
# [[Managing your visualisation]]
# The [[review]] process
# The [[Visualisation status|status]] of your visualisation
# [[Uploading a new version of your visualisation]]
# [[Creating a Collection]]
# [[Managing your Collection]]

You can find all pages related to the ImpVis website functionality in the [[Knowledgebase#Website guidance|relevant section below]].

== Maintaining ImpVis ==
Maintaining ImpVis involves moving old visualisations to the new template, updating or creating new components, improving the ImpVis CLI, etc.

Below are listed all the pages in this category in alphabetical order.<categorytree mode="pages">Maintaining ImpVis

</categorytree>
== Website guidance ==
Everything about the functionality on the website and its design. Relevant pages listed in alphabetical order below.<categorytree mode="pages">ImpVis Website Guidance

</categorytree>
[[Category:Everything]]

Module Timetable

2021-11-17T13:37:19Z

Cclewley: /* Asynchronous work after the session */

This timetable is intended as a guide only to help you understand the structure of the course and the progress you should be making by different points.

Each week includes a description of the timetabled session activities, the intended learning outcomes for that session, a summary of the asynchronous work for you to complete in between the sessions and the recommended progress status of your project. We will post exact details of the asynchronous work, including links and instructions, on the Teams channel.

Note that we will adapt to the cohort's needs throughout the module, which means the schedule may change accordingly. More specific details may be added as the module progresses - keep an eye on the developments of this page (e.g. by clicking 'View history' at the top)!
== Week 1: Introduction to Course ==

=== Description ===
This week we will discuss the aims of the module and how the module will run. We will also take time to get to know each other and explore the platforms we will be using throughout the module. Finally, we will think about how we learn abstract concepts in STEMM and what role visualisation can play to aid understanding.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* navigate the module platforms and find relevant information;
* strike up a conversation with your peers and the module team;
* describe the ImpVis project and how this module fits into the overall project;
* discuss how students learn abstract concepts in STEMM and how visualisations can help students gain a deeper understanding.

=== Asynchronous work after the session ===
* Fill out a short form to help us assign you to a project group.
*Familiarise yourself with the portfolio template and fill out the reflective questions for week 1.
== Week 2: Project Introduction ==

=== Description ===
This week you will find out your project and start working together with your project team. We will also have a guest talk by Dr Freddie Page about his own experiences designing & developing interactive visualisations. We will start thinking about what we think is important for a 'good' design of an interactive visualisation.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain what the topic is of your project and identify your project team partners;
* start applying the principles of working in partnership in your team work;
* outline the design & development process of an interactive visualisation for education;
* give a rudimentary opinion on what is important for the design of an effective visualisation.

=== Asynchronous work after the session ===

* Meet your staff partner to discuss your project and decide on how you will work together.
* Research your project topic so you can explain it to your peers.
* Insert (at least) one education resource that you found useful for understanding your project topic into your portfolio.

=== Recommended project progress ===
By the end of session 2, aim to:

* know what your project topic is and who your project (student) partners are,
* have signed up to your project on the ImpVis website ([https://impvis.co.uk/code Code environment]).

Before the start of session 3, aim to:

* have inserted your name on your project's Wiki page as a contributor and familiarised yourself with the Wiki.
* understand enough of your project topic so you can explain it to your peers.

== Week 3: Educational Design ==

=== Description ===
This week we will have a guest talk by Dr Juan Nunez, who is an instructional designer in Imperial's Interdisciplinary Ed Tech Lab team. We will discuss which educational principles should be foremost in our mind when designing educational learning tools and attempt to apply these to our own projects.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain the most important educational principles underpinning our visualisation designs;
* evaluate and update the intended learning outcomes of your visualisation project;
* propose a way to create a scaffolded learning journey, tailored to your visualisation's learners' needs.

=== Asynchronous work after the session ===

* Meet with your staff partner and update your project's learning outcomes, based on what you have learned in session 3.
* Explore two given examples of visualisations and identify the educational principles underpinning its design - note these down in your portfolio.

=== Recommended project progress ===
By the end of session 3, aim to:

* have evaluated the existing aim & learning outcomes of your project and decided on whether any improvements are needed;
* have a rudimentary idea of how the visualisation's learning journey may be scaffolded.

Before the start of session 4, aim to:

* have updated the aim & learning outcomes of your project on your Wiki page & project Miro board;
* have collated your ideas on how to scaffold the learning journey on your project Miro board.

== Week 4: Graphical Design ==

=== Description ===
This week we will have a guest talk by a graphic designer, explaining the principles of good graphic design. We will also discuss how this applies to your project and what graphical elements you may want to include in your visualisation.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain the most essential graphic design principles underpinning our visualisation designs;
* propose suitable graphical elements for your visualisation design;

=== Asynchronous work after the session ===

* Meet with your staff partner and discuss the graphical elements that could be included in your project, based on what you have learned in session 4.
* Find one example of 'good' graphic design (in your opinion) and one example of 'poor' graphic design (in your opinion) - insert and explain these in your portfolio.

=== Recommended project progress ===
By the end of session 4, aim to:

* have a range of ideas for graphical elements and 'graphical do's & don'ts' for your visualisation.

Before the start of session 5, aim to:

* have collated the most promising ideas for graphical elements + do's & don'ts on you project Miro board.

== Week 5: Interaction Design ==

=== Description ===
This week we will hear from Prof Bob Spence about the fundamentals of human-computer interaction design. We will also experiment with different interactive components that currently are offered in the ImpVis template and discuss what interactive elements could be included in our visualisation designs.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain the most fundamental human-computer interaction design principles underpinning our visualisation designs;
* propose suitable interactive elements for your visualisation design;

[[File:VisCritique.png|thumb|An example of how students should critique their chosen visualisation.]]

=== Asynchronous work after the session ===

* Meet with your staff partner and discuss the interactive elements that could be included in your project, based on what you have learned in session 5.
* Choose an interactive visualisation for education and critique it with respect to its education, graphic and interaction design (see example to the right). Insert this into your portfolio.

=== Recommended project progress ===
By the end of session 5, aim to:

* have a range of ideas for interactive elements and 'interaction do's & don'ts' for your visualisation.

Before the start of session 6, aim to:

* have collated the most promising ideas for interactive elements + do's & don'ts on you project Miro board.

== Week 6: Project work - defining individual responsibilities ==

=== Description ===
This week we will start the visualisation design project work in earnest. We will finalise our thoughts on what makes a 'good' design of an interactive visualisation for education and formulate these, as a cohort, as the assessment criteria for our designs. Each project team will then decide on what needs to be done in order to create a 'good' design (according to these criteria). This will lead to a 'task tree'. Following on from this, you will complete a 'skills matrix' with your team in order to assign responsibilities to each project partner. Based on these responsibilities, you will define your own personal learning goals. This will form the basis of how you will work together as a team.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* describe what in our collective opinion constitute the principles of 'good' design of interactive visualisations for education;
* explain what will need to be done for your project to be successful and describe each project partner's responsibilities and relative expertise, including your own;
* identify what you are aiming to learn from your personal contribution to and participation in this visualisation project over the coming weeks.

=== Asynchronous work after the session ===

* Meet with your staff partner to discuss progress on the project.
* Carry out independent research as decided within your project team.

=== Recommended project progress ===
By the end of session 6, aim to:

* have a completed task tree and skills matrix, with individual responsibilities assigned to each project partner - ensure these are visible on your project Miro board.
* have identified your personal learning goals and inserted these in your portfolio.

Before the start of session 7, aim to:

* have completed your first tasks and carried out some independent research
* have a range of specific ideas for components or content for your visualisation - these do not yet need to be synthesised into a single design. For example, how will your visualisation be structured (will it be a single page or multi-page visualisation)? What will be your main graphical elements? What, if any, text descriptions should be included? What types of interactivity will you implement?

=== Example resources ===
Read about the task tree, skills matrix, and personal learning goals [[Tasks Tree|here]]. You can also view examples of these elements on [https://miro.com/app/board/o9J_ls7JFEY=/?invite_link_id=459778164334 this Miro board].

==Week 7: Project work - supporting each other's progress==

=== Description ===
This week is dedicated to discussing your progress with your project team as well as with peers from other project teams. You will spend about half the session with people from other project teams who are trying to find answers to similar questions as yourself, so you can share findings, tips and expertise. The other half will be with your project team in order to debrief each other on the progress you've made and synthesise your ideas into one coherent design idea.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* communicate findings and ideas with others who have a similar interest;
* evaluate input from others in order to help them improve their ideas as well as improve your own ideas;
* collaborate within your project team to combine different perspectives and findings into an effective, coherent design.

=== Asynchronous work after the session ===

* Continue independent research and work on your project, based on progress made during the session.
* Meet with your staff partner to discuss progress.

=== Recommended project status ===
[[File:Page1 Revised.png|thumb|An example of a synthesised design presented in rough format, as recommended by the end of session 7.]]By the end of session 7, aim to:

* have a detailed, synthesised idea of how your visualisation will look, what components it will include and what text content it will feature, all presented in a rough format;
* have added information into your Wiki page detailing design decisions and their rationale (i.e. why have you chosen to do it this way?).

Before the start of session 8, aim to:

* have an updated Wiki project page with further individual research findings;
* have prepared individually improved components of the visualisation design, presented in a better format.

==Week 8: Project work - finalising your draft design==

=== Description ===
This week you and your project team will finalise your project design draft. The entire session will be dedicated to project work, either in your own project team or comparing notes and discussing feedback with other project teams.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* Agree on a fully worked-out and synthesised design with your project partners.

=== Asynchronous work ===

* Meet with your staff partner to discuss the progress of your design.
* By Wednesday end of day: submit fully worked-out draft design with justifications on Wiki project page.
* From Thursday: review two other designs and fill in feedback template.

=== Recommended project status ===
[[File:Page1 Final.png|thumb|An example of a more polished visualisation design, which you should have in week 8.]]By the end of session 8, aim to:

* have a synthesised, mostly complete visualisation design that is well presented;
* have a clear plan of / template for your submission format (e.g. a Miro board dedicated to the design draft with a clear structure).

By the submission deadline, aim to:

* have an up-to-date Wiki project page with your group's progress a nd design choices, which is mostly complete;
* have your design ready in your submission format, graphics presented to whatever standard is possible with the timeframe and resources (taking into account your project team's skills and software used).

==Week 9: Review session==

=== Description ===
This session we will undertake a formal review session, where each project team will give specific feedback to two other project teams. The feedback will be prioritised as follows: red - critical issues to be fixed in order to meet the assessment criteria; orange - recommended improvements to make the design better; blue - possible suggestions / inspiration for further work; green - exemplary features in the design that others should implement too.

Following the review, you will discuss the feedback given and received in your project team and decide on final improvements to make to your design before the final submission.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* evaluate other teams' designs in order to identify points for improvement as well as exemplary features you can incorporate in your own design;
* communicate feedback to other teams with a clear prioritisation in a constructive manner;
* reflect upon feedback received and agree within your project team whether and how to act upon this feedback in order to improve your design.

=== Asynchronous work ===

* Implement the final improvements to your design, as agreed with your team during the session.

* Meet with your staff partner in order to all agree on the final design;
*Finalise your submission for the design exhibition, including visual design representation as well as fully worked-out Wiki project page with design justification and ideas for further work.

=== Recommended project status ===
By the end of session 9 you should aim to:

* have a clearly worked out list of actions to undertake to finalise your submission;
* have agreed exactly who will take responsibility for which actions.

Before session 10 you should aim to:

* have agreed your design with all project partners and indicate this on your [https://wiki.impvis.co.uk/Mana project management environment] on the ImpVis website;
* have submitted your design exhibition submission, together with a fully worked-out Wiki project page with design justification and ideas for further work.

==Week 10: Design exhibition==
This week all project teams will showcase their designs to each other as well as external people who will assess the designs according to the assessment criteria created by the whole module cohort. Afterwards, we will reflect upon what we have learnt throughout the module and discuss how you (or others) can take your design forwards to a fully working visualisation to be implemented within the intended module of the staff partner.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* communicate your design and its justifications to both peers and external staff and students;
* reflect upon your learning during the module and the evolution of your relationship with your partners;
* decide whether you would like to stay a member of the ImpVis community and contribute to further visualisation designs or the development (programming phase) of visualisations.

=== Asynchronous work ===

* Complete the reflection tasks in your portfolio;
* Complete your self-assessment, based on your reflections and your personal learning goals;
* Submit portfolio & self-assessment by a pre-agreed deadline.

Congratulations, you have successfully completed the ImpVis module. We hope you enjoyed the journey and will be able to see your visualisation design in action in its intended module in the next academic year!
[[Category:iExplore Module]]

Design guidance resources

2021-11-09T13:51:30Z

Cclewley:

This page lists useful external resources for design guidance. It is currently a skeleton page - please add resources you come across that you find useful!

=== Links to resources ===

* Comprehensive research (list of publications) on effective simulation design by [https://phet.colorado.edu/ PhET] group. [https://phet.colorado.edu/en/research#design Link].
* Elmqvist, N. et al., 2011. Fluid interaction for information visualization. ''Information Visualization'', ''10''(4), pp.327-340. [https://kops.uni-konstanz.de/bitstream/handle/123456789/18146/Geyer.pdf?sequence=2 Link].
* Chen, Z. and Gladding, G., 2014. How to make a good animation: A grounded cognition model of how visual representation design affects the construction of abstract physics knowledge. ''Physical Review Special Topics-Physics Education Research'', ''10''(1), p.010111. [https://journals.aps.org/prper/pdf/10.1103/PhysRevSTPER.10.010111 Link].
[[Category:Design Guidance]]

Design guidance resources

2021-11-09T13:51:07Z

Cclewley: Created page with "This page lists useful external resources for design guidance. It is currently a skeleton page - please add resources you come across that you find useful! === Links to resou..."

Module Timetable

2021-11-09T13:23:50Z

Cclewley: /* Recommended project progress */

This timetable is intended as a guide only to help you understand the structure of the course and the progress you should be making by different points.

Each week includes a description of the timetabled session activities, the intended learning outcomes for that session, a summary of the asynchronous work for you to complete in between the sessions and the recommended progress status of your project. We will post exact details of the asynchronous work, including links and instructions, on the Teams channel.

Note that we will adapt to the cohort's needs throughout the module, which means the schedule may change accordingly. More specific details may be added as the module progresses - keep an eye on the developments of this page (e.g. by clicking 'View history' at the top)!
== Week 1: Introduction to Course ==

=== Description ===
This week we will discuss the aims of the module and how the module will run. We will also take time to get to know each other and explore the platforms we will be using throughout the module. Finally, we will think about how we learn abstract concepts in STEMM and what role visualisation can play to aid understanding.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* navigate the module platforms and find relevant information;
* strike up a conversation with your peers and the module team;
* describe the ImpVis project and how this module fits into the overall project;
* discuss how students learn abstract concepts in STEMM and how visualisations can help students gain a deeper understanding.

=== Asynchronous work after the session ===
* Fill out a short form to help us assign you to a project group.
*Familiarise yourself with the portfolio template and fill out the reflective questions for week 1.
== Week 2: Project Introduction ==

=== Description ===
This week you will find out your project and start working together with your project team. We will also have a guest talk by Dr Freddie Page about his own experiences designing & developing interactive visualisations. We will start thinking about what we think is important for a 'good' design of an interactive visualisation.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain what the topic is of your project and identify your project team partners;
* start applying the principles of working in partnership in your team work;
* outline the design & development process of an interactive visualisation for education;
* give a rudimentary opinion on what is important for the design of an effective visualisation.

=== Asynchronous work after the session ===

* Meet your staff partner to discuss your project and decide on how you will work together.
* Research your project topic so you can explain it to your peers.
* Insert (at least) one education resource that you found useful for understanding your project topic into your portfolio.

=== Recommended project progress ===
By the end of session 2, aim to:

* know what your project topic is and who your project (student) partners are,
* have signed up to your project on the ImpVis website ([https://impvis.co.uk/code Code environment]).

Before the start of session 3, aim to:

* have inserted your name on your project's Wiki page as a contributor and familiarised yourself with the Wiki.
* understand enough of your project topic so you can explain it to your peers.

== Week 3: Educational Design ==

=== Description ===
This week we will have a guest talk by Dr Juan Nunez, who is an instructional designer in Imperial's Interdisciplinary Ed Tech Lab team. We will discuss which educational principles should be foremost in our mind when designing educational learning tools and attempt to apply these to our own projects.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain the most important educational principles underpinning our visualisation designs;
* evaluate and update the intended learning outcomes of your visualisation project;
* propose a way to create a scaffolded learning journey, tailored to your visualisation's learners' needs.

=== Asynchronous work after the session ===

* Meet with your staff partner and update your project's learning outcomes, based on what you have learned in session 3.
* Explore two given examples of visualisations and identify the educational principles underpinning its design - note these down in your portfolio.

=== Recommended project progress ===
By the end of session 3, aim to:

* have evaluated the existing aim & learning outcomes of your project and decided on whether any improvements are needed;
* have a rudimentary idea of how the visualisation's learning journey may be scaffolded.

Before the start of session 4, aim to:

* have updated the aim & learning outcomes of your project on your Wiki page & project Miro board;
* have collated your ideas on how to scaffold the learning journey on your project Miro board.

== Week 4: Graphical Design ==

=== Description ===
This week we will have a guest talk by a graphic designer, explaining the principles of good graphic design. We will also discuss how this applies to your project and what graphical elements you may want to include in your visualisation.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain the most essential graphic design principles underpinning our visualisation designs;
* propose suitable graphical elements for your visualisation design;

=== Asynchronous work after the session ===

* Meet with your staff partner and discuss the graphical elements that could be included in your project, based on what you have learned in session 4.
* Find one example of 'good' graphic design (in your opinion) and one example of 'poor' graphic design (in your opinion) - insert and explain these in your portfolio.

=== Recommended project progress ===
By the end of session 4, aim to:

* have a range of ideas for graphical elements and 'graphical do's & don'ts' for your visualisation.

Before the start of session 5, aim to:

* have collated the most promising ideas for graphical elements + do's & don'ts on you project Miro board.

== Week 5: Interaction Design ==

=== Description ===
This week we will hear from Prof Bob Spence about the fundamentals of human-computer interaction design. We will also experiment with different interactive components that currently are offered in the ImpVis template and discuss what interactive elements could be included in our visualisation designs.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain the most fundamental human-computer interaction design principles underpinning our visualisation designs;
* propose suitable interactive elements for your visualisation design;

[[File:VisCritique.png|thumb|An example of how students should critique their chosen visualisation.]]

=== Asynchronous work after the session ===

* Meet with your staff partner and discuss the interactive elements that could be included in your project, based on what you have learned in session 5.
* Choose an interactive visualisation for education and critique it with respect to its education, graphic and interaction design (see example to the right). Insert this into your portfolio.

=== Recommended project progress ===
By the end of session 5, aim to:

* have a range of ideas for interactive elements and 'interaction do's & don'ts' for your visualisation.

Before the start of session 6, aim to:

* have collated the most promising ideas for interactive elements + do's & don'ts on you project Miro board.

== Week 6: Project work - defining individual responsibilities ==

=== Description ===
This week we will start the visualisation design project work in earnest. We will finalise our thoughts on what makes a 'good' design of an interactive visualisation for education and formulate these, as a cohort, as the assessment criteria for our designs. Each project team will then decide on what needs to be done in order to create a 'good' design (according to these criteria). This will lead to a 'task tree'. Following on from this, you will complete a 'skills matrix' with your team in order to assign responsibilities to each project partner. Based on these responsibilities, you will define your own personal learning goals. This will form the basis of how you will work together as a team.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* describe what in our collective opinion constitute the principles of 'good' design of interactive visualisations for education;
* explain what will need to be done for your project to be successful and describe each project partner's responsibilities and relative expertise, including your own;
* identify what you are aiming to learn from your personal contribution to and participation in this visualisation project over the coming weeks.

=== Asynchronous work after the session ===

* Meet with your staff partner to discuss progress on the project.
* Carry out independent research as decided within your project team.
* Submit questions that you now have based on your research for discussion with other project teams.

=== Recommended project progress ===
By the end of session 6, aim to:

* have a completed task tree and skills matrix, with individual responsibilities assigned to each project partner - ensure these are visible on your project Miro board.
* have identified your personal learning goals and inserted these in your portfolio.

Before the start of session 7, aim to:

* have completed your first tasks and carried out some independent research
* have a range of specific ideas for components or content for your visualisation - these do not yet need to be synthesised into a single design. For example, how will your visualisation be structured (will it be a single page or multi-page visualisation)? What will be your main graphical elements? What, if any, text descriptions should be included? What types of interactivity will you implement?

=== Example resources ===
Read about the task tree, skills matrix, and personal learning goals [[Tasks Tree|here]]. You can also view examples of these elements on [https://miro.com/app/board/o9J_ls7JFEY=/?invite_link_id=459778164334 this Miro board].

==Week 7: Project work - supporting each other's progress==

=== Description ===
This week is dedicated to discussing your progress with your project team as well as with peers from other project teams. You will spend about half the session with people from other project teams who are trying to find answers to similar questions as yourself, so you can share findings, tips and expertise. The other half will be with your project team in order to debrief each other on the progress you've made and synthesise your ideas into one coherent design idea.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* communicate findings and ideas with others who have a similar interest;
* evaluate input from others in order to help them improve their ideas as well as improve your own ideas;
* collaborate within your project team to combine different perspectives and findings into an effective, coherent design.

=== Asynchronous work after the session ===

* Continue independent research and work on your project, based on progress made during the session.
* Meet with your staff partner to discuss progress.

=== Recommended project status ===
[[File:Page1 Revised.png|thumb|An example of a synthesised design presented in rough format, as recommended by the end of session 7.]]By the end of session 7, aim to:

* have a detailed, synthesised idea of how your visualisation will look, what components it will include and what text content it will feature, all presented in a rough format;
* have added information into your Wiki page detailing design decisions and their rationale (i.e. why have you chosen to do it this way?).

Before the start of session 8, aim to:

* have an updated Wiki project page with further individual research findings;
* have prepared individually improved components of the visualisation design, presented in a better format.

==Week 8: Project work - finalising your draft design==

=== Description ===
This week you and your project team will finalise your project design draft. The entire session will be dedicated to project work, either in your own project team or comparing notes and discussing feedback with other project teams.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* Agree on a fully worked-out and synthesised design with your project partners.

=== Asynchronous work ===

* Meet with your staff partner to discuss the progress of your design.
* By Wednesday end of day: submit fully worked-out draft design with justifications on Wiki project page.
* From Thursday: review two other designs and fill in feedback template.

=== Recommended project status ===
[[File:Page1 Final.png|thumb|An example of a more polished visualisation design, which you should have in week 8.]]By the end of session 8, aim to:

* have a synthesised, mostly complete visualisation design that is well presented;
* have a clear plan of / template for your submission format (e.g. a Miro board dedicated to the design draft with a clear structure).

By the submission deadline, aim to:

* have an up-to-date Wiki project page with your group's progress a nd design choices, which is mostly complete;
* have your design ready in your submission format, graphics presented to whatever standard is possible with the timeframe and resources (taking into account your project team's skills and software used).

==Week 9: Review session==

=== Description ===
This session we will undertake a formal review session, where each project team will give specific feedback to two other project teams. The feedback will be prioritised as follows: red - critical issues to be fixed in order to meet the assessment criteria; orange - recommended improvements to make the design better; blue - possible suggestions / inspiration for further work; green - exemplary features in the design that others should implement too.

Following the review, you will discuss the feedback given and received in your project team and decide on final improvements to make to your design before the final submission.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* evaluate other teams' designs in order to identify points for improvement as well as exemplary features you can incorporate in your own design;
* communicate feedback to other teams with a clear prioritisation in a constructive manner;
* reflect upon feedback received and agree within your project team whether and how to act upon this feedback in order to improve your design.

=== Asynchronous work ===

* Implement the final improvements to your design, as agreed with your team during the session.

* Meet with your staff partner in order to all agree on the final design;
*Finalise your submission for the design exhibition, including visual design representation as well as fully worked-out Wiki project page with design justification and ideas for further work.

=== Recommended project status ===
By the end of session 9 you should aim to:

* have a clearly worked out list of actions to undertake to finalise your submission;
* have agreed exactly who will take responsibility for which actions.

Before session 10 you should aim to:

* have agreed your design with all project partners and indicate this on your [https://wiki.impvis.co.uk/Mana project management environment] on the ImpVis website;
* have submitted your design exhibition submission, together with a fully worked-out Wiki project page with design justification and ideas for further work.

==Week 10: Design exhibition==
This week all project teams will showcase their designs to each other as well as external people who will assess the designs according to the assessment criteria created by the whole module cohort. Afterwards, we will reflect upon what we have learnt throughout the module and discuss how you (or others) can take your design forwards to a fully working visualisation to be implemented within the intended module of the staff partner.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* communicate your design and its justifications to both peers and external staff and students;
* reflect upon your learning during the module and the evolution of your relationship with your partners;
* decide whether you would like to stay a member of the ImpVis community and contribute to further visualisation designs or the development (programming phase) of visualisations.

=== Asynchronous work ===

* Complete the reflection tasks in your portfolio;
* Complete your self-assessment, based on your reflections and your personal learning goals;
* Submit portfolio & self-assessment by a pre-agreed deadline.

Congratulations, you have successfully completed the ImpVis module. We hope you enjoyed the journey and will be able to see your visualisation design in action in its intended module in the next academic year!
[[Category:iExplore Module]]

Module Timetable

2021-11-09T13:19:03Z

Cclewley: /* Recommended project progress */

This timetable is intended as a guide only to help you understand the structure of the course and the progress you should be making by different points.

Each week includes a description of the timetabled session activities, the intended learning outcomes for that session, a summary of the asynchronous work for you to complete in between the sessions and the recommended progress status of your project. We will post exact details of the asynchronous work, including links and instructions, on the Teams channel.

Note that we will adapt to the cohort's needs throughout the module, which means the schedule may change accordingly. More specific details may be added as the module progresses - keep an eye on the developments of this page (e.g. by clicking 'View history' at the top)!
== Week 1: Introduction to Course ==

=== Description ===
This week we will discuss the aims of the module and how the module will run. We will also take time to get to know each other and explore the platforms we will be using throughout the module. Finally, we will think about how we learn abstract concepts in STEMM and what role visualisation can play to aid understanding.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* navigate the module platforms and find relevant information;
* strike up a conversation with your peers and the module team;
* describe the ImpVis project and how this module fits into the overall project;
* discuss how students learn abstract concepts in STEMM and how visualisations can help students gain a deeper understanding.

=== Asynchronous work after the session ===
* Fill out a short form to help us assign you to a project group.
*Familiarise yourself with the portfolio template and fill out the reflective questions for week 1.
== Week 2: Project Introduction ==

=== Description ===
This week you will find out your project and start working together with your project team. We will also have a guest talk by Dr Freddie Page about his own experiences designing & developing interactive visualisations. We will start thinking about what we think is important for a 'good' design of an interactive visualisation.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain what the topic is of your project and identify your project team partners;
* start applying the principles of working in partnership in your team work;
* outline the design & development process of an interactive visualisation for education;
* give a rudimentary opinion on what is important for the design of an effective visualisation.

=== Asynchronous work after the session ===

* Meet your staff partner to discuss your project and decide on how you will work together.
* Research your project topic so you can explain it to your peers.
* Insert (at least) one education resource that you found useful for understanding your project topic into your portfolio.

=== Recommended project progress ===
By the end of session 2, aim to:

* know what your project topic is and who your project (student) partners are,
* have signed up to your project on the ImpVis website ([https://impvis.co.uk/code Code environment]).

Before the start of session 3, aim to:

* have inserted your name on your project's Wiki page as a contributor and familiarised yourself with the Wiki.
* understand enough of your project topic so you can explain it to your peers.

== Week 3: Educational Design ==

=== Description ===
This week we will have a guest talk by Dr Juan Nunez, who is an instructional designer in Imperial's Interdisciplinary Ed Tech Lab team. We will discuss which educational principles should be foremost in our mind when designing educational learning tools and attempt to apply these to our own projects.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain the most important educational principles underpinning our visualisation designs;
* evaluate and update the intended learning outcomes of your visualisation project;
* propose a way to create a scaffolded learning journey, tailored to your visualisation's learners' needs.

=== Asynchronous work after the session ===

* Meet with your staff partner and update your project's learning outcomes, based on what you have learned in session 3.
* Explore two given examples of visualisations and identify the educational principles underpinning its design - note these down in your portfolio.

=== Recommended project progress ===
By the end of session 3, aim to:

* have evaluated the existing aim & learning outcomes of your project and decided on whether any improvements are needed;
* have a rudimentary idea of how the visualisation's learning journey may be scaffolded.

Before the start of session 4, aim to:

* have updated the aim & learning outcomes of your project on your Wiki page & project Miro board;
* have collated your ideas on how to scaffold the learning journey on your project Miro board.

== Week 4: Graphical Design ==

=== Description ===
This week we will have a guest talk by a graphic designer, explaining the principles of good graphic design. We will also discuss how this applies to your project and what graphical elements you may want to include in your visualisation.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain the most essential graphic design principles underpinning our visualisation designs;
* propose suitable graphical elements for your visualisation design;

=== Asynchronous work after the session ===

* Meet with your staff partner and discuss the graphical elements that could be included in your project, based on what you have learned in session 4.
* Find one example of 'good' graphic design (in your opinion) and one example of 'poor' graphic design (in your opinion) - insert and explain these in your portfolio.

=== Recommended project progress ===
By the end of session 4, aim to:

* have a range of ideas for graphical elements and 'graphical do's & don'ts' for your visualisation.

Before the start of session 5, aim to:

* have collated the most promising ideas for graphical elements + do's & don'ts on you project Miro board.

== Week 5: Interaction Design ==

=== Description ===
This week we will hear from Prof Bob Spence about the fundamentals of human-computer interaction design. We will also experiment with different interactive components that currently are offered in the ImpVis template and discuss what interactive elements could be included in our visualisation designs.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* explain the most fundamental human-computer interaction design principles underpinning our visualisation designs;
* propose suitable interactive elements for your visualisation design;

[[File:VisCritique.png|thumb|An example of how students should critique their chosen visualisation.]]

=== Asynchronous work after the session ===

* Meet with your staff partner and discuss the interactive elements that could be included in your project, based on what you have learned in session 5.
* Choose an interactive visualisation for education and critique it with respect to its education, graphic and interaction design (see example to the right). Insert this into your portfolio.

=== Recommended project progress ===
By the end of session 5, aim to:

* have a range of ideas for interactive elements and 'interaction do's & don'ts' for your visualisation.

Before the start of session 6, aim to:

* have collated the most promising ideas for interactive elements + do's & don'ts on you project Miro board.

== Week 6: Project work - defining individual responsibilities ==

=== Description ===
This week we will start the visualisation design project work in earnest. We will finalise our thoughts on what makes a 'good' design of an interactive visualisation for education and formulate these, as a cohort, as the assessment criteria for our designs. Each project team will then decide on what needs to be done in order to create a 'good' design (according to these criteria). This will lead to a 'task tree'. Following on from this, you will complete a 'skills matrix' with your team in order to assign responsibilities to each project partner. Based on these responsibilities, you will define your own personal learning goals. This will form the basis of how you will work together as a team.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* describe what in our collective opinion constitute the principles of 'good' design of interactive visualisations for education;
* explain what will need to be done for your project to be successful and describe each project partner's responsibilities and relative expertise, including your own;
* identify what you are aiming to learn from your personal contribution to and participation in this visualisation project over the coming weeks.

=== Asynchronous work after the session ===

* Meet with your staff partner to discuss progress on the project.
* Carry out independent research as decided within your project team.
* Submit questions that you now have based on your research for discussion with other project teams.

=== Recommended project progress ===
By the end of session 6, aim to:

* have a completed task tree and skills matrix, with individual responsibilities assigned to each project partner - ensure these are visible on your project Miro board.
* have identified your personal learning goals and inserted these in your portfolio.

Before the start of session 7, aim to:

* have completed your first tasks and carried out some independent research
* have a range of specific ideas for components or content for your visualisation - these do not yet need to be synthesised into a single design.

=== Example resources ===
Read about the task tree, skills matrix, and personal learning goals [[Tasks Tree|here]]. You can also view examples of these elements on [https://miro.com/app/board/o9J_ls7JFEY=/?invite_link_id=459778164334 this Miro board].

==Week 7: Project work - supporting each other's progress==

=== Description ===
This week is dedicated to discussing your progress with your project team as well as with peers from other project teams. You will spend about half the session with people from other project teams who are trying to find answers to similar questions as yourself, so you can share findings, tips and expertise. The other half will be with your project team in order to debrief each other on the progress you've made and synthesise your ideas into one coherent design idea.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* communicate findings and ideas with others who have a similar interest;
* evaluate input from others in order to help them improve their ideas as well as improve your own ideas;
* collaborate within your project team to combine different perspectives and findings into an effective, coherent design.

=== Asynchronous work after the session ===

* Continue independent research and work on your project, based on progress made during the session.
* Meet with your staff partner to discuss progress.

=== Recommended project status ===
[[File:Page1 Revised.png|thumb|An example of a synthesised design presented in rough format, as recommended by the end of session 7.]]By the end of session 7, aim to:

* have a detailed, synthesised idea of how your visualisation will look, what components it will include and what text content it will feature, all presented in a rough format;
* have added information into your Wiki page detailing design decisions and their rationale (i.e. why have you chosen to do it this way?).

Before the start of session 8, aim to:

* have an updated Wiki project page with further individual research findings;
* have prepared individually improved components of the visualisation design, presented in a better format.

==Week 8: Project work - finalising your draft design==

=== Description ===
This week you and your project team will finalise your project design draft. The entire session will be dedicated to project work, either in your own project team or comparing notes and discussing feedback with other project teams.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* Agree on a fully worked-out and synthesised design with your project partners.

=== Asynchronous work ===

* Meet with your staff partner to discuss the progress of your design.
* By Wednesday end of day: submit fully worked-out draft design with justifications on Wiki project page.
* From Thursday: review two other designs and fill in feedback template.

=== Recommended project status ===
[[File:Page1 Final.png|thumb|An example of a more polished visualisation design, which you should have in week 8.]]By the end of session 8, aim to:

* have a synthesised, mostly complete visualisation design that is well presented;
* have a clear plan of / template for your submission format (e.g. a Miro board dedicated to the design draft with a clear structure).

By the submission deadline, aim to:

* have an up-to-date Wiki project page with your group's progress a nd design choices, which is mostly complete;
* have your design ready in your submission format, graphics presented to whatever standard is possible with the timeframe and resources (taking into account your project team's skills and software used).

==Week 9: Review session==

=== Description ===
This session we will undertake a formal review session, where each project team will give specific feedback to two other project teams. The feedback will be prioritised as follows: red - critical issues to be fixed in order to meet the assessment criteria; orange - recommended improvements to make the design better; blue - possible suggestions / inspiration for further work; green - exemplary features in the design that others should implement too.

Following the review, you will discuss the feedback given and received in your project team and decide on final improvements to make to your design before the final submission.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* evaluate other teams' designs in order to identify points for improvement as well as exemplary features you can incorporate in your own design;
* communicate feedback to other teams with a clear prioritisation in a constructive manner;
* reflect upon feedback received and agree within your project team whether and how to act upon this feedback in order to improve your design.

=== Asynchronous work ===

* Implement the final improvements to your design, as agreed with your team during the session.

* Meet with your staff partner in order to all agree on the final design;
*Finalise your submission for the design exhibition, including visual design representation as well as fully worked-out Wiki project page with design justification and ideas for further work.

=== Recommended project status ===
By the end of session 9 you should aim to:

* have a clearly worked out list of actions to undertake to finalise your submission;
* have agreed exactly who will take responsibility for which actions.

Before session 10 you should aim to:

* have agreed your design with all project partners and indicate this on your [https://wiki.impvis.co.uk/Mana project management environment] on the ImpVis website;
* have submitted your design exhibition submission, together with a fully worked-out Wiki project page with design justification and ideas for further work.

==Week 10: Design exhibition==
This week all project teams will showcase their designs to each other as well as external people who will assess the designs according to the assessment criteria created by the whole module cohort. Afterwards, we will reflect upon what we have learnt throughout the module and discuss how you (or others) can take your design forwards to a fully working visualisation to be implemented within the intended module of the staff partner.

=== Intended learning outcomes ===
By the end of this session, you will be able to:

* communicate your design and its justifications to both peers and external staff and students;
* reflect upon your learning during the module and the evolution of your relationship with your partners;
* decide whether you would like to stay a member of the ImpVis community and contribute to further visualisation designs or the development (programming phase) of visualisations.

=== Asynchronous work ===

* Complete the reflection tasks in your portfolio;
* Complete your self-assessment, based on your reflections and your personal learning goals;
* Submit portfolio & self-assessment by a pre-agreed deadline.

Congratulations, you have successfully completed the ImpVis module. We hope you enjoyed the journey and will be able to see your visualisation design in action in its intended module in the next academic year!
[[Category:iExplore Module]]

Request additional content

2021-10-18T20:22:58Z

Cclewley:

If you cannot find the information you are looking for on this Wiki, or have suggestions of content to include but don't know where to place it, please add it to the this page.

* Resources from Freddie Page's talk: MDN, Inkscape
*Links to papers from QuVis and PhET

[[Category:Everything]]

Request additional content

2021-10-18T20:19:53Z

Cclewley:

Request additional content

2021-10-18T20:19:34Z

Cclewley:

If you cannot find the information you are looking for on this Wiki, or have suggestions of content to include, please add it to the this page.

* Resources from Freddie Page's talk: MDN, Inkscape

[[Category:Everything]]

Quantitative PCR

2021-10-14T10:49:06Z

Cclewley: Created page with " ''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.'..."

''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.''

==Contributors==
*''Name and what department each person was in.''
*''Student or staff partner?''
*''How was each person involved?''
*''What rough dates did they contribute?''
*Anabel Varela Carver, Department of Surgery & Cancer. Staff partner from October 2021.
*Joana Dos Santos, Department of Surgery & Cancer. Staff partner from October 2021.
*Jon Krell, Department of Surgery & Cancer. Staff partner from October 2021.
*Robert Kypta, Department of Surgery & Cancer. Staff partner from October 2021.
==Aims & Learning Outcomes==
*''Explain the motivation for your visualisation.''

*''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''
This visualisations is intended for self-study to support iBSc Cancer Frontiers Module 1 teaching (q-PCR principles, data analysis and application to an experiment involving cancer cells)

Intended Learning Outcome:

After using this visualisation, students should be able to explain how changes in Ct values from a q-PCR experiment relate to changes in the numbers of copies of a gene that a cell contains (for example, a cancer cell upon treatment with a drug).

==Design Overview==
*''What the final outcome was, how it looks, how it functions etc.''
*''Include graphics.''
*''Do not include justification or design progression, leave this for later sections.''
==Design Justification==
===Assessment Criteria===
*''List your cohort's assessment criteria. You may want to number the assessment criteria so you can refer to them easily later.''
===Education Design===
*''What Methods were considered to convey concepts?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
===Graphical Design===
*''How were accessibility issues considered?''
*''How was space used effectively?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''

*''How is the design intuitive?''
===Interaction Design===
*''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
*''Keeping accessibility of interactive elements in mind during design phase.''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
==Progress and Future Work==
*''Is the design finalised?''
*''Which pages have been uploaded to website?''
*''Any ideas for future improvements.''
==Links==
*''Link to GitHub repository for code in development:''
*''Link to visualisation on ImpVis website (when uploaded):''
*''Link to Collection on ImpVis website (when created):''
*''Any other links to resources (Miro boards / notes pages / Google Docs etc):''
[[Category:Visualisation Project Pages]]

Optical Microscopy

2021-10-13T13:33:40Z

Cclewley:

''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.''

==Contributors==
*''Name and what department each person was in.''
*''Student or staff partner?''
*''How was each person involved?''
*''What rough dates did they contribute?''

*Jonathan Rackham, Department of Materials. Staff partner from October 2021.
==Aims & Learning Outcomes==
*''Explain the motivation for your visualisation.''

*''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''

This visualisation will be used as a teaching tool in MATE50005 (Materials Characterisation) lectures as well as self-study tools in lab sessions. It will also be useful in the MATE70001 module (MSc Characterisation course).

Note that this visualisation logically leads on to the [[scanning electron microscopy]] project.

After using this visualisation, students will be able to:
*explain the ray diagram of an optical microscope in reflection and transmission.
*describe the key properties of an optical system and identify the relevant contributing components.
*explain astigmatism and its relevance in optical systems.
==Design Overview==
*''What the final outcome was, how it looks, how it functions etc.''
*''Include graphics.''
*''Do not include justification or design progression, leave this for later sections.''
==Design Justification==
===Assessment Criteria===
*''List your cohort's assessment criteria. You may want to number the assessment criteria so you can refer to them easily later.''
===Education Design===
*''What Methods were considered to convey concepts?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
===Graphical Design===
*''How were accessibility issues considered?''
*''How was space used effectively?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''

*''How is the design intuitive?''
===Interaction Design===
*''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
*''Keeping accessibility of interactive elements in mind during design phase.''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
==Progress and Future Work==
*''Is the design finalised?''
*''Which pages have been uploaded to website?''
*''Any ideas for future improvements.''
==Links==
*''Link to GitHub repository for code in development:''
*''Link to visualisation on ImpVis website (when uploaded):''
*''Link to Collection on ImpVis website (when created):''
*''Any other links to resources (Miro boards / notes pages / Google Docs etc):''
[[Category:Visualisation Project Pages]]

Scanning electron microscopy

2021-10-13T13:32:43Z

Cclewley:

''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.''

==Contributors==
*''Name and what department each person was in.''
*''Student or staff partner?''
*''How was each person involved?''
*''What rough dates did they contribute?''

*Jonathan Rackham, Department of Materials. Staff partner from October 2021.
==Aims & Learning Outcomes==
*''Explain the motivation for your visualisation.''

*''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''

This visualisation will be used as a teaching tool in MATE50005 (Materials Characterisation) lectures as well as self-study tools in lab sessions. It will also be useful in the MATE70001 module (MSc Characterisation course) and as a useful teaching tool when training people on the SEM.

Note that this project has crossover with the [[Optical Microscopy|optical microscopy]] project.

After using this visualisation, students will be able to:
*explain the definitions of resolution in the context of a scanning electron microscope.
*qualitatively evaluate the impact of microscope parameters on microscope resolution.
*perform an alignment procedure on a microscope.
==Design Overview==
*''What the final outcome was, how it looks, how it functions etc.''
*''Include graphics.''
*''Do not include justification or design progression, leave this for later sections.''
==Design Justification==
===Assessment Criteria===
*''List your cohort's assessment criteria. You may want to number the assessment criteria so you can refer to them easily later.''
===Education Design===
*''What Methods were considered to convey concepts?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
===Graphical Design===
*''How were accessibility issues considered?''
*''How was space used effectively?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''

*''How is the design intuitive?''
===Interaction Design===
*''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
*''Keeping accessibility of interactive elements in mind during design phase.''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
==Progress and Future Work==
*''Is the design finalised?''
*''Which pages have been uploaded to website?''
*''Any ideas for future improvements.''
==Links==
*''Link to GitHub repository for code in development:''
*''Link to visualisation on ImpVis website (when uploaded):''
*''Link to Collection on ImpVis website (when created):''
*''Any other links to resources (Miro boards / notes pages / Google Docs etc):''
[[Category:Visualisation Project Pages]]

Scanning electron microscopy

2021-10-13T13:32:26Z

''This is a template which you can use to help get you started on the wiki submission. It is just intended as a guide and you may modify the structure to suit your project.''

==Contributors==
*''Name and what department each person was in.''
*''Student or staff partner?''
*''How was each person involved?''
*''What rough dates did they contribute?''

*Jonathan Rackham, Department of Materials. Staff partner from October 2021.
==Aims & Learning Outcomes==
*''Explain the motivation for your visualisation.''

*''Introduce the subject of your visualisation.''
*''Which module and year is it intended for and which setting (lecture or self study)?''
*''List learning outcomes. E.g.: "After using this visualisation, students should be able to explain that..."''

This visualisation will be used as a teaching tool in MATE50005 (Materials Characterisation) lectures as well as self-study tools in lab sessions. It will also be useful in the MATE70001 module (MSc Characterisation course) and as a useful teaching tool when training people on the SEM.

Note that this project has crossover with the [[Optical Microscopy|optical microscopy]] project.

After using this visualisation, students will be able to:
*explain the definitions of resolution in the context of a scanning electron microscope.
*qualitatively evaluate the impact of microscope parameters on microscope resolution.
*perform an alignment procedure on a microscope.
==Design Overview==
*''What the final outcome was, how it looks, how it functions etc.''
*''Include graphics.''
*''Do not include justification or design progression, leave this for later sections.''
==Design Justification==
===Assessment Criteria===
*''List your cohort's assessment criteria. You may want to number the assessment criteria so you can refer to them easily later.''
===Education Design===
*''What Methods were considered to convey concepts?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
===Graphical Design===
*''How were accessibility issues considered?''
*''How was space used effectively?''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''

*''How is the design intuitive?''
===Interaction Design===
*''Choice of interactive element(s) that fit in organically with the visualisation [inspiration of choice might be from lecture/in-class activity or other sources] - Sliders/Buttons/Cursor (hover/click).''
*''Keeping accessibility of interactive elements in mind during design phase.''
*''Design progression, key choices with justifications.''
*''How has feedback been incorporated.''
==Progress and Future Work==
*''Is the design finalised?''
*''Which pages have been uploaded to website?''
*''Any ideas for future improvements.''
==Links==
*''Link to GitHub repository for code in development:''
*''Link to visualisation on ImpVis website (when uploaded):''
*''Link to Collection on ImpVis website (when created):''
*''Any other links to resources (Miro boards / notes pages / Google Docs etc):''