Understanding Web Apps

Updated on 20-October-2016 at 10:16 AM

In this article, you'll learn about a powerful feature that allows you to build custom content types (also known as Web Apps) and display the submitted items as a specific type of content on your site. You can think of each Web App as a self-contained database you add to your site, which can contain any number of different value fields that you wish to enter, display, categorize, and search. By incorporating custom content into a site, you have complete flexibility in developing any number of interactive features that fit perfectly with the online business.

Custom content types can be any type of content receptacle that you can imagine. For example, you could create a Web App that is specifically designed to display the members of the company's sales team. In this scenario, a Web App might be called Sales Team Members, and the data that the mini database contains might include the following information:

  • Team Member's Name 
  • Team Member's Title 
  • Team Member's email address
  • Team Member's bio
  • Team Member's photo

And after defining the values listed above, you can then create Web App items, which populate each database record with the data specific to each team member. For example, here's the data for an individual team member item:

  • John Smith
  • Senior Vice President of Sales
  • jsmith@company.com
  • John Smith is passionate about technology and finding the best communication solutions for your business. In 2009, John won the outstanding excellence award for mobile and telecommunication experts.
  •  

Once the Web App is built and the Web App items are entered, there are many ways you can present the data content in a Web App, to enable visitors to navigate the company directory and search to find the team member they need to contact. Typically a Web App contains at least two (or up to four) different "views" of the content. These views are called layouts, which can be completely customized, by controlling the data that's displayed and the way they look.

In the most basic example, the Web App will contain a list view (to itemize the most critical information, such as the team member's name and title) and then a detail view, which might contain the full list of data, to display the team member's photo as well as their email address and bio. This separation of two layouts enables visitors to scroll through a list of linked items, and then click on the item of interest.


 

When they click on a link, a corresponding details page appears (defined by the detail layout) and this displays the full set of data for more information.

This view allows users to drill down to find the specific information they are seeking.

There are two other views that you might also use; the edit layout is used if you want to provide an online interface to let visitors edit their own posts on the site, and the list layout (backup). The backup list layout allows you to have a different way to display the list of Web App items, such as displaying a teaser of content by displaying the top three latest Web App items on the home page, to entice visitors to check out the entire list (or register online to see the full set of content items).

Some Web Apps contain a finite number of items. In addition to the sales team example, imagine a store locator that lists the locations of several stores. In these scenarios, providing visitors with a list view and detail view may be enough for them to access the information efficiently.

Other Web Apps might contain a significant number of items, making the process of scrolling through a list more tedious for visitors. In this case, you can also build a search form that is specific to the Web App. The visitor can enter a few keywords or enter other filter information and see the matching results of Web App items, to quickly find the data they hope to find. For example, a Web App might contain tech tip items for using a specific software program. By searching the Web App database the visitor could find tips related to the topic, such as how to export a file.

Note: For the best experience using Business Catalyst we recommend creating a maximum of 10000 webapp items. For more details please see the Business Catalyst limitations .

Understanding visitor-submitted vs. administrator-submitted Web Apps

One of the first considerations when planning a Web App involves deciding whether the Web App content will be added by administrators with access to the Admin Console, or whether the content will be submitted by the general public using an interface on the site. Assuming the Web App will be enabled for community contributions, you then need to decide if you want the submissions to be immediately published on the site, or if you'd prefer that a team member in the business organization moderates each new submission and either approves and publishes or declines to publish the content that was submitted.

Depending on the business, you'll decide whether new content that is submitted in the Web App is immediately displayed (and in some cases, removed from the live site later, if deemed inappropriate) versus whether it is best to moderate each new submission, to have complete control of the site content.

If you want a business owner (or their employees) to moderate content submitted in the Web App, you create roles that enable the users assigned to the role the ability to approve and publish or delete each post as it is submitted. Set the Web App item submission form to use the content approval workflow, and specify the moderator role (with is linked to the moderator's email addresses). Every submission will send an email notification to the users assigned to the moderator role, and then they can log on to the Admin Console to see the Web App item and decide whether to post it.

List of the available custom field data types

Every Web App comes with two default fields: Name and description. In addition, you can add any number of custom fields to define the custom content.

You can choose from the following different types of custom data fields when building Web Apps:

  • Data Source: Allows the integration of 2 Web Apps (i.e links one Web App to another).
  • DateTime: A calendar widget to choose the day, month and year. (It does not actually display the time).  
  • Image: An interface to select an existing site image or upload an image file.  
  • List (Checkbox List): A series of values with checkboxes for multiple selections.  
  • List (Dropdown List): A drop-down menu that allows a single selection.  
  • List (Listbox List): A series of values for a single or multiple selections.  
  • List (Radio List): A series of values with radio buttons for a single selection.  
  • Number: A numeric value, such as the number of miles, the price of an item, a specific quantity, and other numbers.  
  • Text (Hyperlink):  
  • Text (Multiline): A larger text field to enter a more significant amount of text.  
  • Text (String): A single line text field for a short amount of text, such as a name or place.  
  • True/False (Boolean): A checkbox that when checked, sets the value to True.  

All of these fields can optionally be set as required. A required field displays an asterisk next to its name.

Additionally, when you insert the Web App item submission form on a web page, you see all of the markup code that defines the fields. The form itself can be customized and redesigned to match the appearance of the rest of the site. You could also choose to hide some of the fields using CSS so that they still exist on the page, but visitors don't see them, because the fields are populated with values based on the values of other fields, using a JavaScript function.

Overview of layouts and how they affect the Web Apps appearance

Layouts are used by the system to define the order of Web App items, the desired data items to show, and how they will appear when viewed in a browser.

Many of the modules use these helpful HTML files to define the appearance of the modules, and some (such as an online store) have a significant number of possible layouts you can customize. In the case of Web Apps, there are just four layouts available, and in some cases, you may choose to only use two of these:

  • Detail layout
  • List layout
  • List layout (backup)
  • Edit layout

Accessing layouts

To access the layouts in the Admin Console, select Site Manager > Module Templates, and then click Web App Layouts. 

In Dreamweaver, get the remote site files to copy them to your local machine, and then open the layout files located in the layouts folder at the root level of the site.

The following descriptions provide examples of when each layout is used:

The Detail layout defines the appearance of the way an individual Web App item is displayed. This layout may contain a larger photo of the item, more media (such as video) and a longer description, review, instructions, or other text content.

The List layout defines the appearance of the way the full list of Web App items is displayed. In this layout, you may choose to only show the name and description of the Web App, and you can also define how many (3, 5, 10, etc.) Web App items are listed on the page. You may decide to show the most recently submitted Web Apps, and you can also set the list to display a number alongside each listed item. The List layout allows visitors to quickly scan through the list of Web App items, and then click on the name of the one they want to review in more detail. Clicking the link for a specific item reveals that item's Detail layout.

List layout (backup) is a secondary list layout in the case where you want to display two versions of the list on your site. For example, perhaps you have a secure zone that contains a page with the full list layout, but you also want a shorter, more abbreviated version of the list layout on the home page, to offer a preview of the available content. In this situation, you can optionally use the List layout (backup) to control how the list on the home page (or where ever you'd like to put a secondary version of the list of Web App items) will appear.

The Edit layout is used only when the Web App is configured to enable visitors to submit their own Web App item content. If you have enabled this functionality, you can optionally also allow the visitors to edit the submissions that they've previously posted. (This is a good idea, because otherwise, visitors may start contacting the site owner directly, if they want to edit or delete text that they've posted under their name). By offering the Edit layout on a page, visitors that are logged in can click the Edit button and edit their own submissions, or any submission (if you configure the Web App to allow visitors to edit each other's submissions). Edit layouts are not used with the Administrator-submitted Web Apps, because users with Administrative access will simply use the Admin Console to make these changes. When you are editing Edit layout in the Admin Console, click the button to Reset Original to update the Edit layout with all of the custom fields that you've defined when creating the layout.


 

After updating the fields, you can still customize their appearance as desired; this ensures that visitors can access all of the fields to make changes to their original posts.