e.g. "ere" matching "where" in story 62

The story content is first processed in elm to add emphasis to special words, and then in Javascript to add <span> tags and event handlers around these.

The whole thing could probably be done in Javascript using Regex matches there. Possibly a single regex could be used ORing all the words to use a single pass rather than one per-word.

Apart from the basic story exercises, the site provides small games and puzzles which can be solved to gain extra points (exisiting extras are word-search, building an image from tiles and polls).

This issue is to collect other possible ideas and references.

Interactive stories

Stories that you don't just read, but which you can play through like a game.
http://elmnarrativeengine.com/

Interactive globe

Finding countries on a 3D globe. A globe is good because it gives kids a real view of the scale of planet and the relative size of countries, unlike typical Europe or US centred projections. Finding countries around the globe could be a trail-like exercise, starting with the most common and moving onto rarer countries for more points.

This project from Google data arts has a clickable globe which could be used.

https://www.chromeexperiments.com/experiment/arms-globe
http://mflux.tumblr.com/post/28367579774/armstradeviz
https://github.com/dataarts/armsglobe (Apache 2)
https://github.com/dataarts/webgl-globe

Other globe
http://www.webglearth.org/

Country lookup API
http://www.geonames.org/export/web-services.html#countrycode

Elm Puzzles

https://github.com/robertbasden/elm-concentration
https://github.com/zindel/game2048elm

Other Elm Stuff

https://github.com/stephenbalaban/Gravity
https://github.com/stefankreitmayer/elm-joust
https://github.com/w0rm/elm-flatris
https://github.com/zalando/elm-street-404
https://github.com/irh/circles
https://github.com/innoq/sandwich-delivery-game

When an account is deleted, the hidden status button is still available, but the server returns a 400 when it is pressed.

No stories are shown until login. Something went wrong when switching to postgres.

There are still some stories that have markup in them, e.g. 285 which has font information and paragraph tags.

IE9 compatibility would be nice to have, but isn't a priority. At the moment, the UI loads OK, but JSON decoding fails with an "Invalid char" error. Not sure why.

Allow teachers to create groups of stories, called "trails" in the existing app, for grouping work together. Trails should be specific to a school (perhaps with some global system-defined ones, e.g. for the Tim Peake stories).

We need new 3ml to be mobile friendly.

For example, when a story is missing, the app should check whether no user is logged in and suggest that as an alternative to the "story not available" message.

Only having 10 fields is restrictive for adding lots of students, so we'll use a textarea like the old stystem for now. In the long term we may look at importing CSV files which could include the student levels, for example.

Once a student has completed a story, they may want to see more which are similar if they enjoyed it.

When a student logs in and the stories are loaded, it would make sense to order them with those closest to the student's level shown first.

Creating students and classes works, as well as selecting a subset of students from the search list. As a bare minimum we also need

• Assign students to classes
• Edit student
  • Change name/password
  • Set level
  • Hide
• Delete students - set a flag, allow undeletion
• Edit / delete class

Moving stright to nixos might also be an option.

e.g. Story 127.

The load of the dictionary fails on startup.

Need to work around this issue in elm-export.

The drawer appears on the left so can obscure the buttons if the viewport isn't big enough, forcing the user to use the close button instead. Putting them on the right would solve this.

Allow users to register as teachers with the site and set up their own "school".

Need to store preferences for colour, text size etc. Probably just a single JSON column in the user table.

• Colours
• Font size
• Font

Password and username changes should also go here.

Stories need to be reloaded on login or the user is stuck with the sample stories.

Need to make sure things still work OK with more data.

Separate app to allow editing and uploading of stories.

There's no API or database tables for story answers.

When finding stories, rather than linking directly to the story page, a zipper view of the filtered story list could be displayed in a popup. The user could then move forward or backward through the list and select a story if they liked it. For students, this could mean going to the story page to do the exercises. For teachers, it might be used to accumulate a list of stories for assigning work, building a trail etc.

To avoid teachers creating duplicate student accounts, only some teachers should have admin permissions to do this.

A number of ideas developed for Real Science were left out of the 3ml implementation, to allow the basic idea to be tested in its simplest form. The plan was always to bring them back gradually, as 3ml gained users.

They are listed below.

1. The Real Science rationale is outlined here: http://www.realscience.org.uk/newwhat-its-about.html

2. Discussion topics arising from the interview. Couple of examples:
   http://www.realscience.org.uk/science-discussion-translocation-Gartcosh-newts.html
   http://www.realscience.org.uk/science-discussion-sediment-core-Antarctica.html

3. Colouring activity according to the type of statement. We developed an Android app that accesses an online blog post and displays it to the reader. She then assigns each statement in the story to one of the statement types and submits her answers. The app compares these with those already coded in the blog post, gives marks and displays the story coloured accordingly. All this is an implementation of Step 4 of Item 1 in this list.

4. Method for generating discussion topics is here. This overlaps with Item 3 above. http://www.realscience.org.uk/newgetting-topics-from-the-text.html

5. Lesson plans based on reciprocal reading and cooperative learning. Contains non-online versions of Connect, Question, Summarise and Clarify. Also contains relevant science misconceptions and curriculum links. Couple of examples here:
   http://www.realscience.org.uk/Basic-lesson-plan-GRE-Centre.doc
   http://www.realscience.org.uk/Basic-lesson-plan-Lisa-Ranford-Cartwright.doc

6. Follow-up lesson plan, which goes into the colouring activity in detail, offline. This also contains further ideas, such as Comic Life, for getting the kids actively involved with the science.
   Example:
   http://www.realscience.org.uk/Follow-up-lesson-Lisa-Ranford-Cartwright.doc

7. How to build on all these ideas to get to grips with a scientific research paper, rather than a piece of popular science writing.
   Examples
   http://www.realscience.org.uk/Wellcome-Trust-Centre-for-Molecular-Parasitology-Lisa-Ranford-Cartwright-Out-of-Africa-paper-activity.html
   http://www.realscience.org.uk/Wellcome-Trust-Centre-for-Molecular-Parasitology-Markus-Meissner-Apicoplast-fission-paper-activity.html

Things to look at

• ekg
• prometheus
• Collecting times directly from clients using the Resource Timing API.

There's currently a mix of use of elm-form and the from code from the elm-spa-example. Should standardize on one, probably the elm-spa-example code which is easier to understand.

The unique constraint on the class table should be (name, school_id), rather than (id, school_id), which is redundant anyway since id is the primary key.

Either the api can return a 409 code or the client can check the cached class names when validating the name (or both).

Can we answer some of their questions from time to time. We do not have staff time to answer them all, but it would be nice to answer good ones sometimes.

The token may have expired out or the server key changed. The server should return a 401 and the client should ask the user to log back in, rather than just showing a page load error.

This should be added in the story content post-processing so that the page doesn't load in place of the app.

The student page needs to optionally return a Student from its update function so that the value in the session cache can be updated. Otherwise the changes are not shown when leaving the page.

The table view isn't very interesting so might be better replaced with something similar to the "tiles" view, or a table with image and the initial paragraph.

Something form of incremental scrolling would be nice too.

This will allow a client session to continue with the existing access token, rather than requiring a new login.

When teachers create new student accounts the username and password is initally generated for them. We need a suitable strategy for these. Generated names also have to be unique.

For checking the submitted answers. Difficult to do comprehensively but basic checks are better than nothing.

e.g. Story 117, lookup "pulsar".

All data saving operations need to differentiate between actual server response errors (with status codes) and things like network errors.

Even if it isn't used in production, this would be useful during development to avoid having to log in after reloading the client. Only the user information really needs to be stored.

The answers form isn't shown to teachers, but when they print the story page, it should include
areas for the answers.

The simplest option is probably to add these to the teacher page and use bootstrap print classes to hide them in the browser.

A teacher should be able to create new teacher accounts. Might be best limited to "admin" teacher accounts. We now have these as a result of #40.

Possibly a 409 error could be returned to indicate the conflict.

When we have real accounts with real data, passwords have to be hashed.

These weren't in the original scraped story list and are missing from the stories in the database.