A quick overview of the field types available in a microapp - note: this is currently incomplete as field types and options are constantly evolving and changing.
What it says on the tin. Text field allowing input of plain text - it can be multiline (it will resize itself as user types). Links within the text are automatically parsed on submit (but are clickable only in readonly version ie by users without edit rights). Options include specifying whether it should be a text field, a url, email or phone number (on mobile devices this will open the relevant keyboard type).
TIP: An additional option is to make the field hidden - this is useful only for advanced use-cases where the value may be automatically set by a rule or action; making this field mandatory without auto-populating it will prevent your form from ever being submitted (since validation will error out and the submit button will remain disabled)!
This is a single-line numeric input. Has (legacy) option of specifying it to be a phone number (makes it clickable to dial/call when on mobile phone/device), but this has been superceded by the phone option on a text field (above).
A date/time field - can be a single date/time or a duration (ie with start and end date/time). User can specify as 'all day' (enter date only, no time). Can also limit field to allow time/day/month or year selection only.
An address field - opens a map view.
This is an on/off switch control that renders as a single checkbox with an optional label. Use this when you only need the user to set a single value to true/false or on/off.
A list of checkboxes with a labels allowing user to select either none, one or multiple options.
A 'todo' or task list widget that renders as a series of checkboxes with a 'percentage complete' progress bar - as items are checked off, the progress bar/percentage adjusts. You can specify default items and/or allow users to add/edit/remove their own.
A single dropdown selectbox field allowing user to select only a single option out of a list.
A rating out of 5 selection that includes half measures - can specify from a choice of icons eg stars or hearts etc.
An attachment field that allows users to attach one or more files (including images). Attached files render as a list, with each item clickable (depends on file type and device/browser whether click triggers view or download).
Similar to the Attachments field, but limited to images - these render in a gallery view when clicked.
A signature/drawing field allowing user to sign via mouse/screen touch and save their signature.
Audio Recording (device only)
Allows user to record an audio snippet (with optional speech-to-text conversion) - only works on mobile devices.
Renders as a text input allowing a user to add a url/link. This then displays as a clickable card with title, image and description from the link (if available). User can also manually enter information for that card (eg title or description) if the link doesn't automatically provide it.
Renders a button on the microapp form. You can enter the text to be used on the button, as well as specifying who can view the button analytics (who clicked the button and when). The button options/type include:
- Click button: default, action needs to be specified via rules in the microapp advanced settings (Settings modal > Advance tab > Rules tab)
- Toggle button: similar to click button, actions need to be defined in advanced settings. In this case the button has 2 states (ie on/off), and each state can have custom button text.
- Link button: can specify a link to open on button click (this can include an email address).
- Call (Post/Get) button: assign a post/get call to the button. Avoid: Deprecated legacy option - generally better to just use a Click button as per above
Freeze (BETA/DEMO only)
Allows you to 'freeze' a microapp row on press - ie making it no longer editable by anyone. An owner/author can 'unfreeze' it to make changes, but all actions are logged.
Notification Button (BETA/DEMO only)
Allows you to specify a 'notification' action on a button.
An event widget that includes a title (text input), start and end date/time and location (opens map view). When viewed in results, includes 'add to calendar' button which triggers an email notification with calendar link in it. Also have option to include an RSVP response - if checked, can add/edit custom responses (eg 'Yes - alone', 'Yes - with partner', 'Not going' etc). Can also specify which users/participants can view RSVP responses.
Payment button (Legacy field type: avoid)
This creates a payment button within a result row (not in the microapp submit form itself) - button configuration is done only on a result/row level. This means it's not suited to a form/data gathering use-case (ie where you create a form for users to submit data). It would be used in a scenario where you create a form via a microapp in a Buzz, then use that microapp form to create one or more result rows, each of which includes a payment button. You would then edit the payment button settings in each result row, and your end-users/audience would then view these rows and click the payment button in this result view to make a payment. They would not submit new results via the microapp form themselves.
**Recommend avoiding unless you really know what you're doing with this:** A simpler option in most cases would be to just add a payment button as a standalone resource (ie not as part of a microapp) to the Buzz.
Allows you to render a value via a calculation eg based on values entered in other fields within the same form (for instance, a tally or total).
User Vote (BETA/DEMO only)
Similar to the Payment button (above) in that it intended for end-users viewing pre-existing result rows only. This field type creates a survey - users can select from one of a series of options (which can render as checkboxes or buttons) (multi-select not possible). It is intended to collate the choices of multiple users and is thus redundant with a normal submit form use case (since only the user submitting the form would make a choice - in which case a Checkboxes or Select field would be better suited). You would use this to create an preexisting microapp result row, which your users/audience in turn would then view - and each make a selection/vote. As per other 'result gathering' fields, you can specify who can view the results/analytics.
**Recommend avoiding unless you really know what you're doing with this:** Field options and behaviour are liable to change.
Advanced option to include values from a field in another app within Buzzy.
Super Hero (Demo only field: do not use!)
**This is a demo field only** It was created for a specific proof-of-concept and requires a specific set of microapp fields to be set up; on submit, it then inserts that data into an `svg` superhero card image and renders that in the result view.
Teams (BETA/DEMO only)
These are static text or display elements that don't gather data themselves but are rendered in the microapp submit form or result details view.
A text heading used to group fields into sections.
Static text - for instance help text or instructions you may want to render on your form. Links are parsed and become clickable when viewed in the microapp form or result detail view.
A static divider (horizontal rule) element used to provide a separation between fields and/or form sections.
These are complex controls useful only for specific use cases.
Offline Map (BETA/DEMO only)
**This is a demo field only** Allows use of pre-loaded offline map data. Requires app-level config.
Box File (BETA/DEMO only)
Field which allows user to insert/attach files from Box cloud storage service. Requires app-level config.
IBM Connections File (CUSTOM INSTALL only)
**Only for use where Buzzy is installed within an IBM Connections environment.** Allows use of links to attachments added directly to Connections. Requires app-level config.
These are fields which we added for developer access or specific demos only - they may break at any time.
IBM Watson Personality Viewer
**This is a demo field only** This is a result-level field only - it compiles data from other fields (eg Twitter Feed - see below) within a submitted result row and renders an IBM Watson Personality Insights graph. Requires a twitter feed or text field with 'Personality Profile' checked.
**This is a demo field only** Used as a data input for the IBM Watson Personality Viewer field above.
**This is a demo field only** Displays OpenWeather weather forecast in a result view only based on the first available location field in the microapp (requires a location field with valid location data in the microapp result row to render).