The settings required for creating and reading QR codes are documented separately, however there are also some general design principles and techniques which are worth covering separately.

Creating QR Codes

What to encode?

In most cases you are trying to encode a 'fact' of some sort. This will often relate directly to a record in a Table.

Avoid using a recordid as that is easily 'walked' to insert incorrect data. better to use a Hash (ie have a text field on the Table, and set it to have a default value that is Unique alphanumeric)

Then the QR code can encode the Hash value, and users cannot trivially predict what other valid hash values are.

The next issue is whether to encode the hash on its own, or a DirectURL that includes the Hash.

The Hash on its own works well if the user will be using a Data Entry Form to read the QR code, and the Hash then populates a text field. This can then be used in subsequent queries and event actions to join against the table containing the hash.

However if the user is not already using the site, it maybe nicer to provide the a full DirectURL in the QR code. ie the QR code would encode a string such as:

https://www.example.com/GSJ6GKFW

Then you configure a DirectURL View to listen for this hash, and redirect the user as appropriate. This could be to a Page, where the a hash has been decoded to provide a parameter so that a particular record is displayed, or it could be to a Data Entry Form, where the DirectURL view has decoded the hash and provides it as a parameter which is used to populate a hidden Recordlink field.

Expiring QR codes

Note that if the individual QR code is intented to be used once only, you can use an Event Action to change, empty the Hash, thus breaking the DirectURL for subsequent scans. A more nuanced approach would be to add an extra "Valid" checkbox field, and rather than change the Hash field, uncheck the checkbox field. Then set the DirectURL View to have criteria to only include records where the Valid checkbox is true. (Then, another DirectURL could have the inverse criteria, and a different destination, where a page could explain to the user that the QR code has been expired.

Display choices

Choosing where to position QR codes, and how large to make them will be a trade off between design aesthetics and technical effectiveness. Essentially, the QR code needs to be large enough to work, so lots of real-world testing needs to be performed to ensure it is clear enough to work. The inherent 'ugliness' of QR codes can be mitigated by including a logo in the middle, and choosing colors which are attractive or match corporate branding, so long as they retain sufficient contrast to be readable.

It is best to include the text of the QR code immediately below or adjacent to it, both to provide a backup in case the user has to type it in, and also as a comfort to the user to indicate what is hidden within it.

If there are multiple QR codes on the same surface, try to place them away from each other, to avoid a user inadvertently scanning the wrong one.

 

 

Reading QR codes

The Data Entry Form is used to read QR codes.

Theoretically, you could have several text fields on a Data Entry Form, all set to scan QR codes. While this would work, it will likely create a confusing user interface, not least as QR codes are most often read using cellphones, where the screen size is relatively small. Instead, if the process calls for multiple QR codes to be scanned, break the process up so that there is only one per Data Entry From submission.

Where possible, automate the user process. So set the camera to auto start, and, if there are no other fields for the user to complete, get the field to auto submit on scan.

This principle can be extended into a loop. Consider a scanning process akin to a supermarket checkout, where QR codes for different items are scanned in succession. By having a Data Entry Form which auto starts, and auto submits after scanning, and having it redirect after submission back to the data Entry Form for another submission, you can create a zero-click interface where each time the camera sees a QR code a new record is added to the Table underlying the Data Entry Form.

When using such a looping method, take care to avoid duplicate submissions of the same object: for example you can weed out such scans immediately after submission using Event criteria and the Delete record action (checking for the same QR code scan as the predecessor record, occurring within a short timeframe). An alternative approach is to use Validation on the QR code field in the Data Entry Form, to prevent auto submission, but to allow the user to override this by pressing a separate submit button on the form (which does not perform the validation check) if the second scan of the same QR code is actually desired.