Feasibility Review: wins form entry edit feature

[ExperimentsInHonesty]

Overview

Users would like the opportunity to be able to edit their wins after it is submitted so that they can have more control over their submitted info. For this issue, as a developer, we will determine

1. the feasibility of allowing users to edit their wins submissions, and
2. then how to identify a changed win on the spreadsheet so that its status is switched to Display:False and then a new issue is opened in the repo notifying project managers to re-review.

Details

Currently, we already have a spreadsheet with existing data from Wins form submissions by users. From Wins form research conducted by UX Researcher Vivian, it was determined that users would like the ability to edit their Wins entries after submitting them. Thus, we (developers) need to determine the feasibility of allowing editing after submission.

Action Items

• Read about the Wins page in the wiki
• In order to understand how our Wins form and response spreadsheet are set up, you can request "Viewer" access to the "Wins-form", "Wins-form (Responses)", and the Apps Script associated with the "Wins-form (Responses)" files in the "HfLA website Admin" Google Drive from a Merge Team member or Tech Lead. See Meet the Team wiki page for their contact info.
  • Then, you need to re-create the "Wins-form" and "Wins-form (Responses)" within your own Google Drive, including copying and pasting any Google Apps Script into your own Google Drive.
  • You will also need to set up your own Personal Access Token to use with the Google Apps Script in your own Google Drive. (Note: Personal Access Tokens are like passwords, so be very careful with them.)
    • Request 1Password account (from Bonnie at team meeting or through your lead, or via Admin slack channel by referencing this issue as a link), so that you can store your own personal access tokens for this project in your private vault.
  • Test out how allowing users to edit their submissions will work in your own Google Drive and GitHub
• Determine the feasibility of allowing editing after a Wins form submission. As a starting point for your feasibility assessment, consider the following questions:
  • If editing is enabled, how would we determine if an entry was edited by the user in order to re-review their edits before it is updated on the site?
  • What happens when editing is enabled and someone edits their submission? Does it change the timestamp on the form? Does it have some other indication it was changed?
  • Is there a way to check the spreadsheet with Google AppScript that a submission was edited by the user? For example, can the status for the entry be switched to Display:False?
  • Can a new issue be opened in the repo notifying project manager(s) to re-review a Wins submission? How would they know which Wins submission to re-review?
  • Be sure to include anything else you find as part of your assessment/research
• Write up a feasibility report in a Google Doc in the "HackforLA.org website" Google Drive and add a link to it in the Resources/Instructions section below
• Go over your feasibility report with the tech lead(s) and PM(s), including possibly demoing what happens when a user edits their submission. Also, discuss with tech lead(s) and PM(s) what the next steps are.
• Merge Team member or Tech Lead: After closing this issue, if the assignee is not a member of Merge Team nor a Tech Lead, please remove the assignee's access to the "Wins-form" and "Wins-form (Responses)" files in the "HfLA website Admin" Google Drive.

Resources/Instructions

• Tracked in issue Add editing feature for win submission form #3143
• Meet the Team wiki page
• Wins webpage
• Wins wiki page
• Link to feasibility report: [INSERT LINK TO FEASIBILITY REPORT HERE]

[7kram]

@JessicaLucindaCheng @ExperimentsInHonesty No dependency. Maybe add a link to "Wins research presentation deck" under the Resources/Instructions section. Otherwise, it's ready for a milestone.

[steven-positive-tran]

My copy of the spreadsheet with google script:
https://docs.google.com/spreadsheets/d/1eFa-r0WD7xtOC4xedIdVpDVz2PwchSaxmkmEgF714wU/edit#gid=1306132589

[roslynwythe]

Hi @steven-positive-tran is it correct to state that if we don't make "backup" Review and Response Sheets, then if PMs don't approve of the edited form values, we won't have any way of reverting form data to their original values?

[steven-positive-tran]

Yeah I believe we need a backup review and response sheet to reference any old submissions.

[roslynwythe]

@steven-positive-tran - the PM and dev leads discussed this issue, and we need to ask you to clarify the report and revise the summary so that it clearly summarizes the main challenges with the proposal and describes briefly the extent of the code changes required to address those challenges.

But also please expand your discussion about the Response sheet entry. You had mentioned that this new Review sheet entry is incomplete, yet it is the display columns in this new Review sheet row that determine whether a WINS entry is displayed on the website. Would you recommend that we retain the newly created Response row, and write code to fill in the missing pieces of data; in that case, would we retain the older outdated Review row? Is there a risk of the Response and Review rows becoming "out of sync" without a clear means to link them? Would we have to adopt a new means of connecting the corresponding Review and Response rows?

I'm moving the issue back to "In Progress". When you are ready for re-review, please put it back in "Questions/In Review" and let me know. Also please note, that you should not be taking on any other issues until this one is closed. Thank you!

[steven-positive-tran]

Sorry I've been busy the last two weeks.

ETA 6/2/2023

[steven-positive-tran]

I've edited the report to be more descriptive about the problems that need to be addressed and a potential implementation from me.

I don't think any of the fields are incomplete I suggest adding some fields to the review such as row number to say that this row is being edited and needs to be re-reviewed.

My suggestion is making another sheet similar to the one Form Responses that just have all the the previous wins along with a row field so that we can link it to the original Form Response and use that row number as a way to sync what is being edited.

[ExperimentsInHonesty]

After @hackforla/website-merge reviews, then product looks forward to a presentation.

[roslynwythe]

Hi @steven-positive-tran - the PMs would like to see a report/presentation that summarizes the major challenges with the proposal, and for each challenge, present a possible solution for review along with an estimate of how extensive the coding requirements would be.

One major challenge is the presentation of WINS data to PMs following an edit. In your report you wrote "In the Review sheet, the display review puts in a new Review but only fills the display review column with values that were edited otherwise it those fills becomes blank." So after a WINS submission is edited, there will remain only one Response row (with updated data that overwrites the original data), but a new Review Row will be created that is incomplete (because it contains only the edited fields). So data pertinent to reviewing a WINS submission will exist partly in the original Review row, and partly in a new Review Row. Would we retain both of those Review Rows? How do you propose that we provide a usable UI for PMs looking to review edited WINS submissions and indicate whether or not the WINS submission should be displayed? And how extensive will the code changes be?

Will it be necessary for the PM to know which Response Row was updated? Although the script can determine that row, the code currently does not have parameters to place that information into the GitHub issue that triggers the PM review. If that is a requirement, we will require changes not just to the code behind the wins-form (Responses) spreadsheet, but also to the gh-requests library, so that the createIssue function can send row information in the GitHub issue.

Thank you !

[steven-positive-tran]

Is this a seperate report and make another google doc?

[steven-positive-tran]

I think the only major challange is just being able to present the edited change to the PMs in regards to the Review Sheet.

Code changes will be extensive as it requires reading data from a new sheet.

In my report and presentation before I suggested making a new sheet that store all the previous wins so that we can refer to them for edits. ( I'll just call this old responses)

In the old responses sheet it will be exactly the same as the form response sheet but with another column for the row. When the user makes edits their win it makes a Review Row that is incomplete. My suggestion is we use that old response sheet to sync up the data and possibly delete the old Review Row that previous was correlated to that win so that it is presentable to the PM.

[steven-positive-tran]

Will it be necessary for the PM to know which Response Row was updated?

I don't think they necessary need to know which row was updated but it might just be helpful having that info for debugging. I could see them using that row to look at the old reponse sheet to see what changed from the previous win.

I'm not informed much about the gh library but I don't think its a hard requrement if it just makes a github issue saying some wins need to be approved and the PM will just go to the Review Sheet and review the wins that need to be approved.

[ExperimentsInHonesty]

@steven-positive-tran you are correct, as a pm I do want to see the before. So on the review page (or another review page, for changed reviews), I want to see both the old and the new, side by side if possible.

[roslynwythe]

@steven-positive-tran You mention that you would "possibly delete the old Review Row". Please expand on that: do you think there is any risk that if we delete Review rows, we could lose sync between the Response and Review Rows, and we would have to add an additional column to associate the Response and Review Rows? How extensive would that change be?

[steven-positive-tran]

There is a risk where if we delete the Review Row we could lose sync between the response and review spreadsheet.

From insertLatestFormSubmitIntoReviewSheet whenever it makes a new win it syncs the response row display and homepage column with A2 and B2 which is the corresponding review as it is the first review in the sheet with regards to the header. I'm assuming once more wins are added the the A2 and B2 from the previous wins gets synced by google so for example if there was 5 more wins the new win from before the display and homepage column should be A7, B7.

If we delete the new review row and add a new one we have to update the response row columns (display and homepage).

I think having a column for the correspoding row in the response sheet is a good idea because it gives us a way to easily find the review in that spreadsheet, delete it, and add a new one. Then for the response replace the out of sync display and homepage columns with A2 and B2 respectively.

[roslynwythe]

Thank you @steven-positive-tran for that information. I'm starting to think that these changes are feasible only if we establish a WINS ID and use that to connect data in the Response, Review and History sheets. Does that sound feasible?

Regarding Bonnie's #3223 (comment) is it feasible to provide a side by side comparison of the old and new form data? Would that be done using a new column in the Review sheet or in the existing (post-edit) Review row ? What if there were multiple edits?

[steven-positive-tran]

Establishing a wins id sounds feasible, we could use the row id as an id or some other way.

For side by side comparision I don't really want to make a new column but that could be an option. I was thinking more of if the wins was an edited submission it would be at the the note below the edited field such as

email: new response
old email: old response

For multiple edits it would be tricky since every single form update will just give the updated fields but leave nonupdated fields blank. I think the solution is compare since each edit response will update the response sheet we compare the contrast the fields individually and if they are different we add the note about the field in the review row.

[roslynwythe]

Thank you @steven-positive-tran

• Suppose we were to allow response editing. Are you saying that we have to limit devs to making 1 response, and require sign-in, otherwise people won't be given the option to edit their previous responses?

• If we do set "Limit to 1 Response", and require sign-in, are you saying that people who have already submitted WINS forms would now be able to browse to the WINS form on the HfLA website and they will be given the option to edit their previous submission? Or will this option only be given to future submitters, after we have enabled the require sign-in and "limit to 1 response" settings?

[steven-positive-tran]

If you limit to one response you have to log in to google to do the form. Then you can edit your response at any time instead of needing that specific URL for that certain response

I think if you limit to one response you just need to go to the same win form submission on the site. It will give you that error where you can't make another one and give you the option to edit that particular response.

I'm not to sure about previous submittals since they didn't logged in or logging in wasn't a requirement so it won't sync and receive that prompt.

[roslynwythe]

Hi @steven-positive-tran I think PMs will be asking about whether the proposed solution will allow for edits to previous submittals. I think it is important to clarify that point. I agree that it might not work because logging in wasn't a requirement, but would it be possible to do testing or research to confirm?

[steven-positive-tran]

I don't think it will be possible for them to edit their previous submittals because they do not have the URL of that submittal and I don't think it is possible to get that URL. The only way to get that URL is if they asked for a copy of their response when response editing is enabled. Since it was not enabled at the time of their submittals their copy will only just provide the receipt of what they input in the form.

Turning on the option for 1 submittal only didn't work as since they didn't log in before it won't sync and will just be prompted with an empty form.

[roslynwythe]

Thank you very much @steven-positive-tran. That is an important point about the previous submittals and honestly I'm not sure if given that information, the PM will want to proceed with the proposed solution. I suggest that you edit your summary to make the main points clearer and to include the information about previous submittals. This is just a suggestion, please don't feel obligated to use it:

I believe it is possible to allow participants to edit their wins but there are challenges to the proposal which will require extensive script changes: primarily a way to have access to the old wins before they are edited and a way to provide a user-friendly display of "before" and "after" responses for PMs reviewing edits. To maintain the "before" responses, one possible solution is to add a separate "backup" sheet along with an ID to associate form submissions in the Response, Review and Backup sheets. Further code changes will be required to provide information in the GitHub "review" issue specifying which WINS submission was edited.

The proposal will depend on changing several form settings: turning on response editing, requiring sign-in and limiting users to a single response. Therefore, existing WINS submissions (which were created without signin) would not be editable, nor would it be possible in the future for a member to submit multiple WINS submissions, rather they could only edit prevoius submissions.

[steven-positive-tran]

Thank you Roslyn I have updated the summary in the report.

[roslynwythe]

Thank you @steven-positive-tran for your work on this issue. Your report is very helpful.

[roslynwythe]

DR: Add editing feature for wins submission form

Issue

#3223

Problem Statement

Users would like to be able to edit their wins after it is submitted so that they can have more control over the displayed info.

Potential Solution

The proposal is to enable the "allow response editing" feature of the wins google form and to update the wins-form (response) spreadsheet to allow review and display of the edited responses.

Feasibility Determination

This potential solution is not feasible due to the extensive code and data structure changes that would be required, and because it would not be possible to allow editing of existing wins submissions, only future ones, and because adopting the proposal would require limiting members to a single wins submission.