Input Forms in OurApp
Author : csy@ Brainstorm Ideas UX : email@ reviewer@ [ LGTM ]
Updated : 2020.02.14 WIP UX Mocks ENG : email@ reviewer@ [ LGTM ]
The Problem
It’s difficult to collect and store data in OurApp from a wide external audience, without allowing
them to see and edit existing data in the table.
● An adoption blocker for a number of internal and external customer use cases, such as:
expense requests, room requests, incident reports, event suggestions1.
● Lightweight intake form flows accounts for ~X% of use cases for organizing and
tracking data in MS Access or Sheets2.
Google Forms is a product that addresses this need and the plan is to integrate. The lack of an
accessible Forms API and difference in team timelines make this a future project, after we’ve
validated market fit. This document will propose a MVP interim forms experience.
Primary use cases
We will limit use cases to ones explicitly mentioned by our external trusted testers:
● As a program manager for a library, I want to collect event suggestions and vendors to
work with from the public, so that I can improve our programming and plan ahead.
● As an AV Ops manager for a large company, I want to collect equipment and event
space requests from employees, so that I can reassign assets in a timely manner.
● As an operations manager for a tutoring service, I want to survey tutors for their
availability and preferences, so that I can better screen and match them with students.
Current user journeys
Currently there’s no way to support this type of data collection process in a frictionless manner
that doesn’t expose sensitive PII or pose a security issue to the data owner:
● Either: you have to use a Google Form or some other forms product, then regularly
import/diff the data from Sheets and deal with data integrity issues.
● Or: you share the entire table with edit access to a broad Google Group and allow anyone
to join the Google Group, but anyone can go in and modify the data in the table.
Landscape
1 Internal Research Notes, SMB Research Notes, SMB Pilot Test Notes
2 Survey on Lightweight Database Use Cases from State of CO Employees
Google Forms (example)
● Each form is a separate
standalone object in Drive.
● Generally follows Drive ACL
model, except missing
comment permission role.
● Can set form name and
description, question title and
description, data validation,
reorder/require and pre-fill
questions, create sections,
add text/images/videos and
conditional logic.
● Can automatically collect
emails, restrict to domain or
single response, allow editing
submission, create short-urls,
embed form, custom styling.
● Summary charts and reports,
link to Sheets for responses
(loose coupling).
● Can get email notifications
for new responses.
Airtable Form View (example)
● Treated as a type of view, can
have multiple forms per table.
● Follows the Airtable view ACL
model for edit access.
● Can set form name and descr,
separate question title and
descr from column name, or
hide/reorder/require items.
● Data validation is based on
column type settings.
● Link toggle/recreation, form
embedding, custom styling
and theming available, can
share link domain-only, or
make password protected.
● Can get email notifications
for new responses.
ServiceNow Forms (user guide)
● The “form view” is just one
part of the very customizable
UI experience for an “app” in
the ServiceNow platform.
● Similar to Lotus Notes, admin
can create entire “apps” with
their own page nav, “form
views”, workflows, biz logic.
● Advanced role permissions,
configure views users can
see based on role.
● Rich WYSIWYG drag’n’drop
form designer to customize
fields displayed, layout,
sections, labels & help, etc.
● Can set pre-filled values, add
special objects like related
lists, embedded lists, activity
filters (rev history), advanced
conditional logic to hide or
show fields based on role or
field input, customize styles.
● Sharing externally works by
making a page “public”.
Proposed Solution
Implement a barebones MVP solution for input forms that allows users to:
1. Create and publish a form for a table, with a url that external people can access.
2. Create and edit questions, which are coupled with table columns and their types.
3. Hide, reorder, require, and customize label/description for questions.
Goals
● Make it easier for OurApp users to collect data and input from external people at scale.
● Unblock another major segment of use cases to increase customer adoption.
Non-Goals
● Form styling and theme customization, we will iterate on this in the future.
● Summarizing form responses, can be handled by view layouts or export to Sheets.
● Discussing concepts of “apps,” a complex topic that is out of scope for this MVP.
Measurable Outcomes
● Unblock customer adoption from <customer domain> and internal <group>.
● Increased user engagement and retention (current 1-wk retention is ~X%3).
Conceptual Model
An important thing to note is the data structure and hierarchy. For forms, I proposed that they
should be owned at the table level, similar to bots, where you can have multiple forms for a
given table, but each form is owned by one and only one table.
Requirements
Priority criteria
[P0] MVP for customer release
[P1] Important for delightful experience
[P2] Nice-to-have
Forms List
● [P0] Table commenters and editors can view a list of input forms for a table
○ Should show form name, how many responses a form has had, and whether the
form is enabled/disabled.
● [P0] Only table editors can create, delete, and disable/enable forms.
● [P1] Table commenters and editors can copy the public link for a form.
New Project SH
Task Proj Dynamo +
Gro Filte Sort For View Connected forms
Proje Task description Assign Due Status + to
this table
Co Bug reports
1 Fill out this table with your Today In
2 Loren ipsum Tomorr Not
Trig
3 Loren ipsum Loren ipsum
Customer
+
For requests
List of forms
Team
Meeting AIs
overflo
**DIRECTIONAL Easy
+ Add new form to
Form Editing
● [P0] Table commenters and editors can open a form in the form editor.
○ Form editor should have an easy way to get a preview of the published form.
3 As of Feb 18th, 2020.
○ Commenters have a view-only experience in the editor.
● [P0] Table editors can customize the form metadata:
○ Set form name (internal name)
○ Set form title (external title, applies to browser tab title)
○ Set form description
○ Enable or disable public form link
● [P0] Table editors can add, edit, delete, and hide questions. All table columns are shown
as questions in a table form and are tightly coupled.
○ The set of form questions is tied one-to-one with the set of table columns.
○ Hidden questions are not shown in the published form experience.
○ See this mini-PRD for details on what happens when table schema changes
(column is deleted/added), and how it affects the form.
New Project S
Tas Proj Bug Reports
Dynamo + CA S
Gro Filte Sort For Vie Connected
Form + forms
Proj Task description Assig Due Status
Co Bug to this
reports
1 Fill out this table with your
FormFile
Title a bug!
File a bug!
TodayIn table
2 Loren ipsum Tomorr
Please Not
file a bug in Tri
3 Loren ipsum Loren ipsum
Please
Form file a Customer
+
bug in this 2 Describe the bug you requests
For
encountered.
Form Team
Form Meeting AIs
Where did you
experience
Home this bug?
+ Add new form
**DIRECTIONAL
● [P0] Anyone can open the public form link and access the form (if the link is enabled).
● [P0] When a user submits the form, they should get confirmation that it succeeded.
○ If the form is outdated (e.g. modified since they last refreshed the page), then
show an error and tell them they need to refresh the page because a new version
is available.
● [P1] Table editors can customize form questions.
○ Set a different question title and question description per form.
○ Table editor should be able to determine which table column the question is for.
● [P1] Table editors can mark questions as required.
○ A hidden question cannot be required.
○ Required questions won’t allow form submission until filled with non-blank data.
● [P1] Table editors can set a default value for form questions.
○ For all sensical editable column types (e.g. “date created” doesn’t make sense).
○ This default value is separate from the table-level default values.
● [P2] Table editors can customize the question response type:
○ See this mini-PRD for specifics of the options to offer based on the column type.
● [P2] Table editors can reorder questions.
● [P2] Table editors can enable automatic capture of the form submitter’s email.
○ When enabled, will force the submitter to sign-in before submitting form.
○ Published form needs to notify respondents that it will be collecting their name
and email address from their signed-in account.
● [P2] Table editors can limit responses to 1 response per user account.
Appendix
Decision for building our own forms vs integrating with Google Forms
How do we handle linked columns in the form experience?
Edge cases and error states