zooeymiller / anna-freud-hackday-makatalk Goto Github PK

so that a returning user can use the app

so that I can use the information in my session

so I don't hand the service user the wrong survey

so that their name is displayed correctly within the app

There are two assessments:

• one before the session
• one after the session

We need to come up with a list of assessment questions and a list of possible answers for each question.

so that I can abide by legal obligations around patient consent

so that I am able to correct my mistake in case I've made one

so that I can use the information to inform my next session with the patient

so that the app is effective for people with mild, moderate and severe difficulties

so that it can be used in the questionnaire to personalise it

so that that service users can use the app as independently as possible

so that only the appropriate people can see this information

so that a new patient can start using the app

so that they are able to play again the ones they missed or didn't fully understand

Make a view for the home page with html

relates #27 #8 #22 #21 #20 #18 #17 #13 #12 #11 #9 #8

so that young people with mild learning difficulties can engage with the questions

We need to tidy the screens ahead of presenting.

so that I can keep track of my patients

• Look for makaton videos that are available as they relate to our questions and answers
• If there are not makaton videos available as we need them, try to arrange filming our own videos.

Noga has provided us with designs (to be uploaded). Now we will style the views to look like our new designs.

Following discussions around age, we've realised that diving the app into traditional age sections may not be appropriate because:

We may have some service users who are very young but may function at a very high level and vice versa.

Thus

... we were thinking that it would be great to find one theme that would allow us to target all our service users.

In order to meet this requirement, we need to understand more about designing applications for children with learning difficulties.

Here are the screens, we each worked on them separately so there's 3 slightly distinct styles, but we plan to do the styling "properly" once @nogainbar has had a look at them.

so that I can understand my patient's experience of their week

so that they know what to do once they've finished the survey

goal of spike: to understand how to automatically sequentially play videos in html5

relates #13

so that young people with moderate-severe learning difficulties can engage with the questions

so that my patient's experience of their appointment can inform our next session

so that I'm able to select a different one in case I've made a mistake

So that I don't have to use their name, thus abiding by regulation around data protection

Please thumb up this to indicate you understand. Raise questions in this issue if you run into any problems or come find me.

You can use this repo to copy dwyls labels into your repo: https://github.com/dwyl/labels

1. Create an issue for the task you are working on:

• reference the issue number of the user-story it relates to ("as a... I want... so that...")
• list the technical tasks involved in completing it, either within the issue itself, or as separate issues that refer to the main issue and are given a 'technical' label.

2. Estimate how long it will take you to finish the issue and add the appropriate time label (t1h = 1 hour, t1d = 1 day, etc). If a user-story will take you longer than a day then its too big. Break it down into smaller issues.
3. Give the issue a priority label.
4. Assign yourself to the issue you're working on and add the 'in-progress' label.
5. When you make commits give appropriate descriptions of the technical task it completes and refer to the issue number in the commit message. (e.g. 'related #7'). Aim for small commits that complete a single task.
6. When the PR is ready for review:

• Assign to your team-mates to review and add the label 'in-review' to the PR.

7. When the PR is closed, and once you're satisfied an issue is complete and on the live version of the project, change the label to 'please-test' and assign it to your product owner. This is to indicate to the product owner that they should check if they are satisfied the work is done.

• If they are not satisfied, they should detail in the issue what needs to change. Un-assign them, remove the please-test label, and return to step 2.
• If they are satisfied, they can close the issue.