dhmit / rereading Goto Github PK

Involves

• factor out various data collection mechanisms already implemented in student_view from the prototype
• make a data format that can be sent via API call to the backend

... plus probably more.

On Catherine-reread-count-frontend, I am integrating my function run_compute_reread_counts(self) which uses the helper function compute_reread_counts(self, question, context) into the frontend. The data returned was originally a dictionary, but there was no sensible manner to display the data on the webapp. We decided to take an average of our data, but now the numbers do not seem to be lining up.

To do:

• Suggestions for new ways to display data from dictionary
• Fix the compute_reread_counts(self, question, context) output to represent correct mean reread count

Some analysis functions are based on the questions asked for the 6 word story, but these are not the only questions that will ever be asked. Try to see if any of the existing functions need to be generalized further.

This view would be presented AFTER the whole reading, and would have prompts and/or questions.

This view could have the whole text presented as well, for review.

Line breaks within a segment aren't showing up -- probably we need to make a <p> element per line.

Work is taking place on evidence-for-questions branch. This is a tracking issue for the things left TODO:

• add field to database models for questions responses for evidence
• send evidence to the backend correctly
• add BooleanField require_evidence for questions
• fix display bug wherein all evidence is a single long string instead of list
• add functionality to remove evidence
• fix bug wherein "tag evidence" affects state of all Questions instead of just the one clicked

• Student segment data -- timestamp when it gets submitted
• Student reading data -- timestamp when it gets init-ed and on last change
• Response models -- timestamp of last edit

We're starting to see some regular patterns in the analysis data formatting -- e.g., a lot of analyses are a single heading + a value. Let's make a React component at least for that. This can be a tracker issue for making these components.

• Single value analysis

Here's the list of sources Sandy would like listed:
SourcesTab_Recitatif1.docx

Sandy suggests that we add questions that are shown on every page of the rereading view, and that these questions keep their state from segment to segment.

We can track what is added/removed to these question responses per segment, which might be very interesting to visualize.

Sandy, via email

I’ve also enclosed some colors that I’d like to be part of the online project’s "color palette.”
If possible, I’d like the background of the site to be that beige/tan/sandy color so that moments of color can actually stand out.

Sandy was interested in a design where we show each segment first just in a plain reading view, and then adorned with questions, prompts, highlighting ability, etc. Let's start hacking that out in the reading view.

Currently in the reading view, a user is allowed to skip through all readings and prompts without submitting any annotations for their reading. We might want to change that in a few ways, depending on how we want to collect the data:

• A user is forced to provide some type of annotation (although this may be suboptimal and provide forced responses)
• After submitting an empty annotation, a prompt appears with questions that will help the user answer questions (i.e. things like "what is this about?", "How did this make you feel?", etc).
• There is some tracking that only allows a few empty responses throughout the reading
• A prompt appears asking if they meant to leave the response blank

The last one may provide the most natural responses, as well as acting as a reminder, but does not entirely fix the case where users click through the reading as described above.

Find some way to color in each section of the Segment Component.
The color of the sections of the segment will be determined by:
number of seconds spent on that section divided by max number of seconds spent on any of the sections of that segment
Using this fraction, find some way to incorporate it into a gradient to determine the color.

List of Qs from Sandy that she'd like presented in the project intro

FurtherQuestions_Recitatif.docx

I think it would be helpful to add a "jump to" option in the reading view so that previous segments can be reread without having to press the back button over and over. I'd be happy to assign myself to this task if no one has any problems with it.

On the branch overview-page-design, I am working on adding a landing page containing:

• One button leading to project overview
• One button to start the experiment
• The designated picture of the two girls eating

The website will redirect to the landing page instead of straight to the reading page.
I finished linking the buttons to the respective pages, but the page still needs the picture and nice formatting.

There seems to be a formatting issue with quotes in paragraphs (as seen in the image below in segment 2). This may be an issue with how the text was loaded into the project, so this would be a simple issue to resolve.

Sandy mentioned that she'd like a view that has some basic information about the story itself. Now that Recitatif is in the system, someone start making a view to show information about it (basic stuff like word count, etc., but also potentially things derived from the analysis functions).

We have a hardcoded list of 'relevant words' from Sandy, and we show how many responses used those words.

We should show the list of words, and which words were used in each question (+ the individual word frequency) to make this much more useful.

When there are a lot of questions, the user needs to scroll down to look at the questions. Instead, we can have a component that holds all of the questions with a scroll feature so that the user can look at the reading while viewing the bottom questions.

Looks like the version of our main font is different on macOS and Windows, so we should use a webfont or host a font for consistency across platforms.

On this branch I'm trying to add the all_contexts_repeated_prompt_words analysis component, but it breaks the page and throws the following error:

Error: Objects are not valid as a React child (found: object with keys {}). If you meant to render a collection of children, use an array instead.

The component is readable for Python but not for React, so I'm starting the following:

• Possibly change how the back-end analysis function returns data to make this easier
• Figure out how to unpack data from dictionaries so it can be shown on front-end (maybe using var mapping / arrow functions)
• Format data (tables?)
• Possibly implement commented out analysis code (edited Oct. 29th, see this comment)

I think there is an inconsistency in some of the formatting that makes the analysis page that presents the results feel a bit disjointed. We can standardize the sizing for our headings and make sure that we have consistent rounding for our data. We can also group together similar categories together. Ex: data on time spent can be all together in one section, and then data on types of responses and feelings in another section.

I feel like it's somewhat confusing for total view time to read "3600 seconds" rather than "1 hour". Would it be worth the effort to change this?

Sandy would like to create a page that introduces the overall project and the purposes and goals of this rereading project. She sent out an email with an idea of the overall content that this page will display. I will create a branch to start working on this.

Tons of design stuff to do in the reading view. I'm going to make this a tracking issue, so we don't scatter these TODOs all over the place.

Biggies:

• Choose a really nice reading font.
• Make the number of words per line deterministic: we want to control the position of lines, so we don't want the text to freely reflow per user, probably

Add more here as you think of it...

This is not so great...

... we need to remove stopwords from this analysis for it to be meaningful. (At which point it's probably awesome!)

Starting this as a tracking issue. @fyang3 will populate this.

See format from comp hist --> add a long and short version.

For example, in student_view.css, running frontend results in a "Compiled with warnings" message, and lines 46, 48, and 49 exceed the maximum line length of 100.

Is there a way to format the code so that readability is improved and this error is resolved?

It can get quite annoying scrolling through all of the other functions to get to the one I'm interested in. Although it's not immediately useful to the project itself, it may make code maintenance easier in the future.

Rather than clicking through all of the different parts of the text, have something to track scrolling.

The document question responses do not carry over to the overview page.

The website currently looks really great on desktop, but several components get smashed together or are inaccessible on mobile views.

I'm self-assigning this, but reach out to me if anyone wants to help.

Ben, Michelle, and I were wondering if there should be an instructions view before the reading view so that readers know what they're expecting and how to interact with the text. The more specific the instructions are the easier it will be for us to analyze their responses/interactions as well. We will also need to know more clearly what data we're collecting from rereading and annotations.

@samimak37 -- assigning this to you as you mentioned interest in it yesterday. @opheeelia and @JasonLin43212 have a prototype reading view going, let's get a serializer etc. going for the db models that can hook into their prototype.

Need to add a <p> element per line break, like the Segment component does.

Sandy thinks that maybe one paragraph per segment is too few -- let's make this a tunable parameter for the system for now (i.e., show more than one segment at a time?) and then see what works.

Tracking issue for myself as we move the site into production:

• Production settings -- read secret key, etc. from environment on startup
• Adjust webpack config so production assets get built to assets/js and assets/css
• Go through Django deployment checklist and make sure I haven't forgotten anything
• Configure gunicorn
• Configure nginx
• Setup SSL
• (optional) tune CONN_MAX_AGE
• (optional/maybe) switch production db backend over to postgres

If anyone's interested in learning some of this deployment stuff, send me a message on Slack and I'll let you know when I'm working on it.

This is follow-on work from #108. Right now, each submission of a StudentSegmentData object creates a brand new StudentReadingData object in the backend.

We need all StudentSegmantDatas for a single reading point to a single StudentReadingData.

The pages in the /project_overview/ section (overview, rereading sample, visuals, values, quantitative questions, sources) are a little cluttered, and could be made easier to read. In addition, the visuals and values pages only have questions on them with no other content.

One last little thing—I think the body text of the reading page is supposed to be in Garamond, but it looks like Times New Roman (maybe we need to import the font?)

Two big things to do here:

• Move sort to the backend -- probably by using order_by in the db query. Right now all of the responses are out of order at the API endpoint, and then sorted in the frontend. This is super duper slow and gums up the loading of the analysis page.
• Collate responses -- right now the table displays a separate row for each response, instead of collating them by question. Makes it much harder to see patterns.