Table of Contents

Padoq feed and menus

Kate Santo Updated by Kate Santo

Padoq apps are made of padoqs (also known as groups in customer-facing communication). Padoqs are one of the central and most important features of our platform.

Find out how users interact with padoqs in the user version of this guide.

See for yourself

  • You can download the iOS or Android app on your phone to follow this journey along. And you can also log in or sign up to the web app here
  • You can also follow along by checking out the images or code snippets in this guide
  • And you will find the relevant endpoints linked and explained in this guide, but the full API is documented in Swagger UI

Opening a padoq

When the user opens a padoq they are a member of, the getPadoq endpoint is called. The details returned by this endpoint specify how to display the padoq to the user. A padoq feed can have very different UI views, all defined in this payload. So when the user looks at that main screen in a padoq, they will either see a feed of posts or a tile menu with different options.

The getPadoq endpoint contains 2 main objects that define most of the UI: the displayOptions object and the tileMenu object. We'll look into each of these, and more features of a padoq, in this guide.

Padoq settings

When a user creates a padoq, they can customise a bunch of things: the padoq's colour, the privacy level, the tags members can use, etc. And once the padoq is created, these settings can be edited at any time from My padoqs > Admin > Settings.

All edits to a padoq from this area are done via the updatePadoq endpoint. Find out more in our guide: Create a padoq. And here's how some of these settings look like in a padoq's structure:

{
"title": "My Place",
"colour": "soft_pink",
"description": "A description of this padoq.",
"permittedRichTags": [],
"interests": [
"Music",
"Food & Drink",
"Travel" ],
"permittedPostTypes": [
"BASIC",
"COMMENT" ]
}

Padoq header menu

The items that appears in the menu at the top of a padoq come from one of two places: the displayOptions object in the padoq's model or manual settings from someone at Padoq. Let's explore how each work.

The displayOptions object

The majority of elements in a padoq header is specified in the displayOptions object. This object can be retrieved via the getPadoq endpoint and it might look like this:

"displayOptions": {
"options": [
"HIDE_PADOQ_MENU" ]
}

This object has a very simple structure: one property that contains an array as its value. This array is a list of settings that change the UI. The admin of the padoq can update the content of the array via the web app. And each edit is done by calling the updatePadoq endpoint and sending the updated object in the response. For the admin, it looks like this:

Settings by Padoq

There are items that appear in the header menu in a padoq that are more complex and can't be added or removed by the admin of the padoq unless there has been some work done beforehand. These are things like the button to report issues or book rooms in property apps.

The properties that allow settings like this to be visible in a padoq can be found in the getPadoq endpoint. There are 3 key properties there that allow complex features to appear: official, qrCodesEnabledand bookingInfo.

{
"official": true,
"qrCodesEnabled": true,
"bookingInfo": { }
}

For the feature to report issues to be active, official and qrCodesEnabled need to be true. Only someone at Padoq can do that. However, once they are set to true, the padoq admin can create, update, delete and report on forms, which make up the report issue flow.

On top of that, when there is information inside the bookingInfo object, then users can also book rooms and other things like appointments. Once this is turned on, the admin can set how members of their padoq interact with bookings. This is done via the Super Admin page (Bookings tab). In the example below, members can only book 3 times in 24 hours or 12 times in 28 days.

This object might look like this when it's populated:

{
"bookingInfo": {
"bookingRestrictions": {
"slot": {
"units": "HOURS",
"maxDuration": 1,
"minDuration": 1
},
"quantity": [
{
"period": 24,
"allowance": 3,
"periodUnits": "HOURS",
"allowanceUnit": "HOURS"
},
{
"period": 28,
"allowance": 12,
"periodUnits": "DAYS",
"allowanceUnit": "HOURS"
}
]
},
"appointmentsDisabled": false
},
}

Post feed

A very common way to organise a padoq feed is by presenting the user with a list of posts that have been published in that padoq. The getPosts endpoint is called for this.

This endpoint can take several parameters, although only two are compulsory: name (name of the padoq we're requesting posts for) and Accept (which is a header and simply checks the type of response that the endpoint can handle).

Other parameters, like from and to, allow us to display posts created within a specific period of time. Others, like role, allow us to only display posts created by users with a specific role.

Beyond that, posts themselves have specific parameters and customisation options. Find out more below in Post display options.

Post types

One of the important properties in a post is its type. The post type defines, for example, how the post is displayed, what the user can do with it or how the information is collected. These unique bits of data are captured in a specific property in the post object: structuredContent.

There are 17 types of posts. Here's a summary of what they are, but read more about these in our Post types guide.

  1. BASIC: a post with no data beyond what's present in all posts
  2. COMMENT: a comment to a post
  3. VOTE: a post with structured content that includes a specific payload requiring and returning key information like checklist (to allow users to update their response to the poll at any time) or voteTrigger (which allows the author of the post to define an action they want to trigger when a user submits their response to the poll)
  4. VOTE_RS: a response to a vote post
  5. SURVEY: a post with structured content that includes information like questions (which defines what the survey is made of and requires each question to be unique and at least one question to be answered before the survey is submitted)
  6. SURVEY_RS: a response to a survey post
  7. TEMPLATE: a post with structured content that allows things like issue reporting. Find out more in this separate guide about forms and templates
  8. FORM: a post that works with templates and allows for detailed and trackable information collection. Find out more in Create and Manage Forms (Information Collection)
  9. FORM_RS: a response to a form post
  10. EVENT: a post with structured content that includes information like amount (if the event is paid), frequency (if the event is recurrent) or maxAttendees (to limit how many people can attend the event)

  1. EVENT_RS: a response to a form post
  2. PAYMENT_RQ: a post with structured content that includes information like maxQuantity (to establish the maximum number of items that can be purchased, in a shop-style app) or productCode (which specifies the vendor's code or ID for the product)
  3. PAYMENT_RS: a response to a payment post
  4. NOTE: a post with structured content linked to the pinboard. It includes information like type (which can be basic, pin or reminder) or expires (which has a date-time string as its value and is relevant for reminders). A basic note is created from scratch by the user, a pin is a saved post from a padoq and a reminder is like the basic type, but with date and time added to it
  5. REMINDER: one of the 3 types of note mentioned above
  6. OFFER: a post with structured content that includes information like termsAndConditions (which specifies the terms of the offer), merchantInformation (which tells the user about the merchant making the offer) or previousAmount (which specifies, optionally, the old price of the product on offer, relevant if the offer is a discount)
  7. OFFER_RS: a response to an offer post.

Post display options

All posts returned by the getPosts endpoint returns the feed for a padoq. All posts have the same structure underneath: same properties, but with different values in each case.

Here's a very common display for a basic post:

In this post, some of the properties we can spot are (see code snippet at the bottom):

  • Text: it's the content of the post
  • Type: this is a basic post. Other types of post might be vote, or survey. Those have different content in their structure
  • Public: specifies whether users who aren't registered in the app can see it. The default value is false (meaning that only logged in users can see posts)
  • canLike, canDislike and canComment: these properties set whether users can do each of those things for a post, in the example above, all 3 properties are set to true. If the value was false in any of them, the relevant icon would disappear from the post footer. Both admins and members can choose to turn these on or off when they post something
  • recipients: if the user selects a number of users to share the post with, their names would appear here. If the value is null, as it is in our example, it means that all members of that padoq can see the post
  • likeCount, dislikeCount and commentCount: these properties have numbers as values. Each count appears next to the relevant icon in the post footer, unless the count is "0", in which case there will be nothing next to the icon. In our example, there are 0 likes, 0 dislikes and 2 comments
  • Here's how a part of the payload would look like for our example post:
{
"text": "Any updates on the internet? Mines down",
"type": "BASIC",
"public": false,
"canLike": true,
"canDislike": false,
"canComment": true,
"recipients": [
"null"
],
"display": {
"hideDisplayHeader": false,
"hideDisplayFooter": false
},
"likeCount": 20,
"dislikeCount": 0,
"commentCount": 10
}

Tile menu

The tileMenu object we mentioned in Opening a padoq above defines how this type of menu should behave and how it should be displayed. This tile menu is only for mobile devices -if the user opens a padoq in a web browser, they will always see a post feed like the one described above.

A tileMenu object sits inside the response for the getPadoq endpoint and it might look like this:

"tileMenu": {
"label": "string",
"height": 1,
"width": 4,
"disabled": false,
"tiles": [
{
"action": {
"type": "PADOQ_FEED",
"params": {}
},
"title": "Group activity",
"showTitle": true,
"subtitle": "string",
"foregroundColour": "#090908",
"backgroundColour": "#4eb943",
"height": 2,
"width": 2,
"imageUri": "string",
"iconUri": "string",
"position": 1
},
{
"action": {
"type": "CREATE_POST",
"params": {}
},
"title": "Post something",
"showTitle": true,
"subtitle": "string",
"foregroundColour": "#090908",
"backgroundColour": "#e9d909",
"height": 2,
"width": 2,
"imageUri": "string",
"iconUri": "string",
"position": 2
}
]
}

So there is a parent tileMenu object with some properties. One of those properties contains an array of objects defining tiles. Each of the values for these properties can be edited by the admin of the padoq in the web app. The UI for the admin looks like this:

In that code example above, lots of properties define how the tile is going to look and where it will be placed (backgroundColour, height, width, position) but there is one property that defines the action that the tile will trigger when it's tapped: action.

There are 20 types of action. Some of them have required parameters, others have optional parameters and others have no parameters at all. Here are some tile action examples:

  • The PADOQ_FEED action shows the user the feed of posts. The padoq admin can add details like tags (to only show posts under a specific tag), but this is not required. So they can save the tile just like that
  • The URI action, however, takes the user to an external website. The user needs to specify the website the tile should fetch, otherwise it won't be possible to save the tile
  • The CATEGORY_FILTER action has no parameters at all. It offers the user a list of types of posts to filter by: most popular, admin posts, file posts, etc.

How did we do?

The homefeed

Post types

Contact