Adapt Learning Community: OpenTextInput Component

We started to work on the open textinput component and wanted to let you know about the progress.

The workflow for the user could look as follows:
1. The user starts the course and types in his answer
2. The user clicks on "save"
3. The user can view his answer and clicks on "edit"
4. The user edits his input and clicks "submit"
5. The user can compare his answer to a model answer

Therefore we have 4 parts/views:
Input View - initial view of the component
View includes: Title, Body, Textarea, Save-Button, Submit-Button

Draft View - is shown when the user clicks on "save"
View includes: Title, Body, Text (not editable), Edit-Button, Submit-Button

Edit View - is shown when the users clicks "edit"
View includes: It's the same as the input view and the previously saved answer is loaded into the textarea

Submitted View - is shown then the users clicks "submit"
View includes: Title, Body, User Answer, Model Answer

Pending questions:

We also thought about leaving off the draft view. If the user clicks on save he gets a notification that the text has been saved but the view stays the same.

One problem where we stuck is the storage of the user answer. We thought about storing it on the server and in the local storage that the user can access his given answer from any device and can work offline

We are not sure about the layout of the submitted view. With all the other question components it's possible to switch between the user answer and the model answer. But we tought about showing both anwers next to each other as it might be easier to compare. On the other hand we would have to force a full layout.

Any suggestions are much appreciated!!

Best regards
Petra

Hi Petra

In terms of where to store the data - how much text are you expecting the user to enter here? just a word or two or could it potentially be paragraphs?

Show parent | Reply

Hi Matt,

it's likely that the length of the text is between some words and several paragraphs.

One use case of the openTextInput component could be to ask the user for a feedback on a course.

Regards,

Petra

Show parent | Reply

Hi Petra,

A thought on your final question.

I completely agree with you - the user answer/model answer wouldn’t work as a toggle view imo. You need to cross compare what is likely to be, at least, a few sentences of content and quite possibly more.

Couldn’t we adopt an approach so they’re two separate but related components (as per a recently developed confidence slider). You just position Part A (user entry) and Part B (model answer) next to each other in the same block. Avoids having to force a full layout.

Thanks,

Paul

Show parent | Reply

Hi,

When we use an open input component on our courses we would tend to follow the example that Paul has given where the user would first type in their answer and then would be shown a model answer alongside the user entry.

In terms of how this would work would there be a function to have the open input component at the top of the page so that the user is asked a question before going through the content, they type their answers and select save. At the end of the page we then present them with their answers in one column alongside the model answer in order for them to compare what they originally thought with what they have now learnt.

Or would this require two components, an open input component and an open input feedback component with some sort of input index in order to link the answers?

Thanks,

Kevin

Show parent | Reply

Hi Kevin,

we still haven't defined the final requirements and just implemented the basic functionality. Your approach sounds very interesting. From a technical point of view we could implement this with related components as Paul said.

This means that you have 2 different components in your JSON file, one for the textinput and one for the "model answer/my answer view" and you just have to link them via the components-id.

Best regards,

Petra

Show parent | Reply

Hi Petra,

As well as 2 different components you'd also need to track the instance id of each of the components for example

OpenInput:1 on Page 1

OpenInputDisplay:1 on Page 4, along with the model answer

OpenInput:2 on Page 5

OpenInputDisplay:2 on Page 8, along with the model answer

It's possible that a course could consist of several OI and OID's

Pending questions:

We also thought about leaving off the draft view. If the user clicks on save he gets a notification that the text has been saved but the view stays the same.

>>Sounds good, can the save message not appear in a popup and act like a status notification, so the user does not have to click something

One problem where we stuck is the storage of the user answer. We thought about storing it on the server and in the local storage that the user can access his given answer from any device and can work offline

>>If the course is SCORMED store the data in the LMS, if not scormed can we store the data in a session?

We are not sure about the layout of the submitted view. With all the other question components it's possible to switch between the user answer and the model answer. But we thought about showing both answers next to each other as it might be easier to compare. On the other hand we would have to force a full layout.

>> Would a tabbed interface work here, once the user has typed their answer and clicked save a tab appears at the top of the Open Input where the user can toggle between their answer and the model. This would have to be configurable. If the OI was setup where the components are split it would be nice to be able to compare the users answer and the model answer side by side, not sure if that's a single components that spans or 2 separate components

Show parent | Reply

Hi Mark,

Thought it would be useful to put up my thoughts on how you might use the Open Input. Don't think we're to far apart. I think your right about using a notification to flag input has been registered rather than tutor as I state. I also think the tab for what I term item 2C is interesting. Works well for mobile doesn't it where, due to limited screen size, you'd have to scroll up and down to see the pre and post user entries. On desktop I think I'd prefer to compare side by side but perhaps the mobile friendly tabbed approach is pay off worth making to ensure consistency.

Cheers,

Paul

Show parent | Reply