STACK case studies are short, practical accounts of how people are using, developing and contributing to the STACK project. They are intended to share experience with the wider STACK community and to help others learn from what has been tried.
A case study does not need to be a formal academic paper or a polished success story. We are particularly interested in sharing practical experience: what you tried, why you tried it, what happened, what worked, what did not work, and what you would do differently next time.
A good case study should answer some or all of the following questions:
- What was the context?
- What problem or opportunity were you addressing?
- Why was STACK relevant?
- What did you do?
- What was novel, interesting or particularly useful about the approach?
- What did you learn?
- What were the benefits or impacts?
- What challenges did you encounter?
- What would you recommend to other STACK users?
- What happens next?
The emphasis will vary according to the type of case study. The sections below give some suggestions.
These case studies describe something new that has been developed, or an existing STACK feature being used in a new way.
Examples include new question types, new mathematical or technical functionality, new approaches to feedback, integrations with other systems, or novel approaches to assessment.
A useful structure is:
Briefly explain the problem or opportunity.
What was difficult or impossible to do previously? Why was there a need for a new approach?
Explain what you developed or how you used STACK.
Include examples wherever possible. Screenshots, diagrams, example questions and short code fragments can be particularly helpful.
Give enough technical detail that an experienced STACK user can understand the approach and, where appropriate, reproduce or adapt it.
Link to:
- GitHub repositories;
- documentation;
- example questions or question banks;
- demonstration sites;
- relevant STACK documentation; and
- related research or publications.
What worked well? What proved difficult? Were there unexpected issues or limitations?
It is useful to report limitations as well as successes. Sharing things that did not work is valuable to the community because it can save others from repeating the same experiments.
Describe planned developments, possible applications, or questions that remain open.
Meeting reports should do more than simply record that a meeting took place.
The purpose is to tell the wider STACK community what happened and why it mattered.
Useful information includes:
- where and when the meeting took place;
- who participated;
- the purpose of the meeting;
- the main topics discussed;
- significant presentations, demonstrations or activities;
- important discussions or decisions;
- new collaborations that resulted;
- resources or projects that were discussed; and
- agreed next steps.
Photographs are particularly welcome for meetings and conferences.
Where appropriate, include links to:
- the meeting website;
- programme;
- presentations;
- papers or reports;
- repositories;
- related projects; and
- subsequent events.
Try to identify the take-away messages for someone who was not able to attend.
For example, rather than simply listing presentations, explain what participants learned, what problems were identified, and what the community plans to do as a result.
STACK is a community project, and case studies can give interns and students an opportunity to describe their own experience and contribution.
These case studies should, where possible, be written with the intern or student, and ideally give them a direct voice.
Useful topics include:
- What was the project?
- What did you work on?
- What did you learn?
- What STACK skills did you develop?
- What challenges did you encounter?
- What did you contribute to the wider STACK project?
- What did you find particularly interesting?
- What would you recommend to someone considering a similar internship?
- What happened after the internship?
It is often particularly valuable to describe the development process, rather than simply listing the final outputs.
For example, a case study might explain how someone progressed from having no experience of STACK to authoring questions, contributing code, translating materials, supporting users, or participating in the wider community.
This is the most common type of STACK case study.
The purpose is to describe how STACK is actually being used in teaching and assessment, so that other educators can learn from the experience.
A useful structure is:
Describe:
- the institution;
- the course or programme;
- the subject;
- the level of study;
- approximately how many students are involved; and
- whether the course is online, blended or face-to-face.
You do not need to provide extensive institutional background. Include only information that helps readers understand the educational context.
Explain what problem STACK was intended to solve.
For example:
- large numbers of students;
- the need for immediate feedback;
- formative assessment;
- mastery learning;
- diagnostic assessment;
- automated marking;
- randomised questions;
- assessment of symbolic mathematics;
- reduction in marking workload;
- improved student engagement;
- accessibility;
- supporting a particular pedagogical approach; or
- enabling an assessment which was previously difficult to deliver.
Describe the role STACK plays in the course.
Useful information might include:
- the number and type of quizzes;
- the number of STACK questions;
- formative versus summative assessment;
- frequency of assessment;
- how feedback is used;
- how questions are authored and maintained;
- how STACK integrates with Moodle or another learning platform;
- how students are introduced to STACK; and
- how STACK fits alongside other forms of teaching and assessment.
Screenshots and examples of representative questions are strongly encouraged.
Where possible, describe the experience from the students' perspective.
For example:
- How do students respond to STACK?
- What do they find useful or difficult?
- How do they use feedback?
- Has STACK changed how they study?
- Have students become familiar with mathematical input?
- What support do students need?
Student quotations can be particularly effective, provided appropriate permission has been obtained.
Include evidence where it is available.
This might include:
- student numbers;
- usage statistics;
- changes in attainment;
- diagnostic results;
- student feedback;
- changes in marking workload;
- improvements to the course;
- adoption by other courses or institutions; or
- other evidence of impact.
Formal statistical analysis is not required. A case study can still be valuable when the evidence is primarily based on experience.
However, distinguish clearly between evidence and personal impressions. For example, "students reported..." is preferable to making an unsupported claim about what students learned.
This is one of the most useful sections for other educators.
Describe things such as:
- technical difficulties;
- authoring time;
- staff training;
- student preparation;
- limitations of particular question types;
- integration with institutional systems;
- assessment security;
- accessibility;
- maintenance of question banks; or
- aspects of the pedagogy that needed to be changed.
Do not feel that a case study needs to present everything as a success. Honest accounts of difficulties are extremely useful to the community.
Describe planned developments.
This might include:
- extending STACK to other topics or courses;
- developing new question types;
- increasing the number of questions;
- changing the assessment strategy;
- training additional staff;
- evaluating the approach;
- sharing materials; or
- collaborating with other institutions.
Case studies will be published here https://stack-assessment.org/CaseStudies/
Case studies are written in (or converted to) markdown, and follow a template. Either write in markdown, or keep the formatting very simple and we will convert your case study.
The website is automatically re-build when we push to the master branch here: https://github.com/maths/stack-web Pull requests are very welcome!
Assume that readers know broadly what STACK is, but do not assume they know your particular institution, course or project.
A case study should be accessible to:
- new STACK users;
- experienced question authors;
- mathematics educators;
- developers;
- researchers; and
- members of the wider international STACK community.
Explain specialist terminology where necessary.
A strong case study usually has a simple narrative:
We had a problem → we tried something → this is what we did → this is what happened → this is what we learned.
Avoid turning the case study into a long technical description without explaining why the work was undertaken.
Where possible, include concrete examples.
Useful material includes:
- screenshots;
- photographs;
- diagrams;
- example STACK questions;
- sample feedback;
- short videos;
- code snippets;
- links to question banks;
- links to GitHub repositories; and
- student or staff quotations.
A reader should ideally be able to see what is being described.
Case studies should acknowledge the people who contributed to the work.
This might include:
- students;
- interns;
- lecturers;
- question authors;
- developers;
- learning technologists;
- researchers;
- institutional support staff; and
- external collaborators.
Where an intern, student or early-career colleague made a substantial contribution, consider making them a named author and giving them an opportunity to write part of the case study in their own voice.
One of the major benefits of the STACK case-study collection is that it can become a practical resource for the community.
Where possible, link to resources that readers can actually use, adapt or investigate further:
- question banks;
- STACK XML exports;
- GitHub repositories;
- documentation;
- Moodle courses;
- examples;
- papers;
- presentations; and
- demonstration sites.
If the material is open source or openly licensed, say so.
Images are encouraged.
Good images include:
- a representative STACK question;
- an example of student feedback;
- an interactive element;
- a photograph of a workshop or meeting;
- a screenshot of a course;
- a diagram explaining a technical approach; or
- a photograph of the people involved.
Please provide a short caption explaining what the image shows.
Make sure that images do not disclose confidential or personal student information. Obtain appropriate permission before publishing photographs of identifiable people.
There is no rigid word limit, but around 800–2,000 words is a useful target for many case studies.
Shorter pieces are welcome, particularly for a small technical development or a concise meeting report. More substantial projects may warrant a longer article.
The priority is useful content rather than length.
Case studies do not need to follow a formal academic referencing style.
However, cite or link to relevant:
- academic papers;
- project documentation;
- software;
- previous STACK case studies;
- external projects; and
- other sources.
Use hyperlinks where these make it easier for readers to follow up.
If the case study reports formal research results, it may be appropriate to provide conventional academic references.
Please distinguish between:
- what you observed;
- what students or colleagues reported;
- measured results;
- your interpretation; and
- future plans.
For example:
"Students reported that the immediate feedback was useful."
is different from:
"The use of STACK improved student attainment."
The latter requires appropriate evidence.
Case studies are primarily accounts of experience, not peer-reviewed research papers. If you have conducted formal research, however, please link to the relevant publication or report.
STACK is an open-source community project. Case studies should help build and share that community knowledge.
Where possible, authors are encouraged to share materials openly and to explain how other STACK users can benefit from the work.
Case studies are particularly welcome from institutions and communities that are new to STACK, from different geographical regions, and from disciplines beyond mathematics.
We want the collection to reflect the diversity of the STACK community.
Authors may use the following template as a starting point. It is not necessary to use every heading.
Title
A concise title describing the project, course, development or event.
Authors
Names and affiliations.
Abstract
A short summary of what the case study is about and why it is interesting.
What is the context? What problem or opportunity motivated the work?
Why was STACK chosen? What did it make possible?
Describe the implementation, development, event or experience.
Show representative questions, screenshots, diagrams, code or other evidence.
What happened? What did students, staff or participants experience? What evidence is available?
What was difficult? What did not work as expected?
What would you recommend to others? What would you do differently?
What are the next steps?
Links to question banks, GitHub repositories, documentation, papers, demonstrations, etc.
Relevant publications and other sources.
Please check that your case study:
- explains clearly what the case study is about;
- provides enough context for an international reader;
- explains why STACK was relevant;
- gives concrete examples;
- includes images or screenshots where appropriate;
- describes both successes and challenges;
- distinguishes evidence from opinion;
- acknowledges the people who contributed;
- provides links to useful resources;
- has permission to publish photographs, quotations and other material;
- does not disclose confidential or personally identifiable student information; and
- has been checked by the relevant colleagues or institution where appropriate.
A STACK case study should help someone else.
Ask yourself:
If I were another STACK user facing a similar situation, what would I want to know?
That is the most useful content to include.