# Declarative User Interface: Forms and Apps in RDF

Tim BL, <timbl@w3.org>
Hit the space bar or swipe left for next slide

# Declarative User Interface: Forms and Apps in RDF

- Declarative design is good.
- The Principle of Least Power
- Compose apps and parts of apps out of components
- High-level design allows multiple compatible implementations
- In Solid, data is in Linked Data graphs
- Why not use that for User Interface?

# What would that look like?

      # A simple group with two fields

      ex:form a ui:Group;
        ui:parts (ex:part1 ex:part2).

            ex:part1 a ui:SingleLineTextField ;
            ui:property vcard:fn;
            ui:label "name" .

            ex:part2 a ui:EmailField ;
            ui:property vcard:hasEmail;
            ui:label "email" .

# Components are form Fields or structures

### Fields

###

- BooleanField
- TriStateField
- IntegerField
- DecimalField
- FloatField

- ColorField
- DateField
- DateTimeField
- PhoneField
- EmailField
- SingleLineTextField
- MultiLineTextField
- Autocomplete

### Structures

###

- Group
- Choice
- Multiple
- Classifier
- Options

### Documentation components

###

- Heading
- Comment

# Single Line Text field

Form fields are set up to write linked data into Solid pods.

Each one adds (typically) a new edge to the data graph at run time

So We give the predicate which will be used in the instance of the field.

    # A simple form with one boolean field
    ex:form
    a ui:BooleanField ;
    ui:property ex:allDay .

# Examples of other form fields

1. Examples of individual Form Fields
2. Examples of structures in forms: Groups
3. Selection, Options, Autocomplete
4. Examples of a Solid profile editing form

# Common properties of form fields

label | String | A label for the form field, prompt for the user.
property | rdf:Property | Data it is stored in the web as a triple with this property as its predicate.
default | [according to field type] Optional | The input control is set to this value by default. It is easiest for the user to enter this value. (This value is not automatically stored by the form system if the user does not select or enter it in some way.
suppressEmptyUneditable | Boolean | When the user is just reading the data, not editing it, the fields with blank data will be hidden.

# The Autocomplete field

This form field allows users to select things from lists in public databases, things like Languages, Organizations, Occupations, and Skills

This is not covered in detail in this talk.

(There is a blog Building Solid Apps which use Public Data, about this which I could run though for those interested)

# Code: Render a form

To put a form in your UI

    const element = UI.widgets.appendForm(dom, null, {}, subject, form, doc, callback)

dom | is the DOM HTMLDocument object, a/k/a document
null | used to be the is a DOM element to contain the form. If given, the form will be appended to it. This use is deprecated.
{} | are unused at present
subject | is the RDF thing about which data will be stored
form | is the RDF object in the store for the form
doc | is the RDF document on the web where the data will be stored. Often, `subject.doc()`
callback | is a function taking an error flag and a message (if the error flag is true). Called when the form field has been set to a new value.

# Going meta -- designing forms using the form of forms 1

Here is a form for editing a form

Users and developers should be able to design and adapt their forms

The Form Form

# Going meta -- Editing forms using the form of forms 2

Here we are editing the really small form we started with.

- Editing a simple form using the Form Form

Here we edit the FormForm with itself.

- Editing the Form Form

# Forms and Classes

    export function formsFor (subject) {
      const kb = store

      log.debug('formsFor: subject=' + subject)
      const t = kb.findTypeURIs(subject)
      let t1
      for (t1 in t) {
        log.debug('   type: ' + t1)
      }
      const bottom = kb.bottomTypeURIs(t) // most specific
      let candidates = []
      for (const b in bottom) {
        // Find the most specific
        log.debug('candidatesFor: trying bottom type =' + b)
        candidates = candidates.concat(
          findClosest(kb, b, ns.ui('creationForm'))
        )
        candidates = candidates.concat(
          findClosest(kb, b, ns.ui('annotationForm'))
        )
      }
      return candidates
    }

# The Form Pane

The Form Pane

      icon: UI.icons.iconBase + 'noun_122196.svg',

      name: 'form',

      audience: [ns.solid('PowerUser')],

      // Does the subject deserve this pane?
      label: function (subject) {
        const n = UI.widgets.formsFor(subject).length
        UI.log.debug('Form pane: forms for ' + subject + ': ' + n)
        if (!n) return null
        return '' + n + ' forms'
      },

      render: function (subject, context) {
      ...
      }

# Future: A Form registry?

A place to list forms for each class. (by Shape?)
- Global one could be say `https://solidos.solidcommunity.net/reg/form`
- Users and Communities could have their own, linked from type index
- Idea: Things like global registries are linked from a global community, The Public which is just like a user and controlled by Solid Project

# Future

- Implementations in other platforms - MechanicalUI etc, Native mobile...
- Add new form features -- what can you think of? Things we have code for:
  - Matrix, Tables
  - Image gallery, collections
  - Drawers, sidebars
- Allow entire App top be build from RDF-based declarative components a la JeffZ
  - The App
  - Navigation
  - Menus
  - HTML templates
  - Style themes
  - etc.

Integrate with Ontologies
- Design/Edit Ontologies with forms
- Browse and pick for existing ontologies when building a form

# Questions?

Reference

- Manual: The Form Ecosystem
- Manual: Intro to forms
- The UI ontology (source)