Optimizing online businesses with InContext Editing

Additional Requirements

Business Catalyst extension for Dreamweaver

• Download

Business Catalyst free Partner account

• Learn more

In this article, you’ll learn best practices for working with InContext Editing. You’ll examine the code that is created when your clients use it, compare the features with the deprecated Business Catalyst editor (SiteWalk), and get tips to help you make the most out of InContext Editing as a site maintenance tool.

This article is divided into the following sections:

• Updating websites with InContext Editing
• Analyzing the code generated by InContext Editing
• Enabling specific CSS rules
• Comparing InContext Editing with SiteWalk
• Tips for configuring and working with InContext Editing

Updating websites with InContext Editing

InContext Editing is now included with Business Catalyst as an added feature to the hosted solution. It is no longer necessary to enroll in a separate service or pay extra fees to use InContext Editing when building Business Catalyst sites. Previously, InContext Editing was an external service hosted on its own server, separate from the data center. As a result, performance was slower. Now, InContext Editing is hosted on the Business Catalyst servers, alongside the Admin Console.

It is an integral part of the administration rights management, because you can control exactly who can edit content and the types of content they can edit. Using roles, you can also enable or disable permissions for your clients to control the capabilities of each team member that works on the site. For example, you can allow some team members to edit pages, while others can only run reports.

Additionally, when you build the site, you have complete control over the areas of the page that are editable, and which editing features are enabled for each editable region.

To discover InContext Editing and learn the basics of using it, see the Guide to incorporating InContext Editing for Business Catalyst administrators.

Back to top

Analyzing the code generated by InContext Editing

InContext Editing generates standards-compliant code. While InContext Editing obviously is much less powerful than the HTML editing capabilities of Dreamweaver, it enables users to edit their sites without any programming knowledge.

When your client updates a page, InContext Editing adds inline styles to apply formatting to content. This is consistent with the editing behavior of SiteWalk. A web page can be edited using both tools; since they add the same code, there are no conflicts with the way the source is formatted.

It is important to understand how the changes made to the page will update the code, so that you can make informed decisions when choosing to enable or disable specific formatting options. The inline styles applied by InContext Editing are shown below:>

If you don't want your clients to add inline styles to the code, you can define CSS classes and disable most of the text formatting options. This strategy ensures that the generated code is as clean as possible, because inline styles are not added.

For example, you could restrict the typography formatting options to bold, italic and CSS styles (see Figure 1).

Clients can use the Style pop-up menu in the InContext Editing interface to apply predefined CSS rules to format the page (see Figure 2).

Note: It is a best practice to add styles with descriptive names, to make it easier for your clients to choose and apply the appropriate style. The style names are displayed in the Style pop-up menu.

To learn more about specifying which CSS styles your clients can apply, see "Enabling specific CSS rules," the next section of this article.

Back to top

Enabling specific CSS rules

You can use the Partner Portal to add the style names of the rules that you want your clients to be able to access while they are editing (assuming that the CSS Styles formatting option is enabled, and they have the necessary permissions to edit the page content).

Follow these steps:

1. Log into the Admin Console, and click the link to access the Partner Portal.
2. Click the Tools tab. Choose the Online Editor Settings option in the left sidebar and then choose your site from the list of sites (see Figure 3).

3. Click the Apply CSS tab. Enter the specific style names that you want users to access as they update site content (see Figure 4).

Note: If you do not specify any CSS styles in this area, then all of the styles applied to the document are enabled. A long list of styles can be daunting to clients, so it is a good idea to define which styles your clients can apply, unless the site only uses a limited number of styles.

If you enter a specific style name, a CSS rule with a matching name must be applied to the page (either in the HTML code in the <head> section of the page or in a linked CSS style sheet). If you enable the style and it exists on the page the user is editing, the style will be listed in the InContext Editing interface and the user can apply it, assuming that they have the necessary permissions.

Be careful to avoid typographical errors when you add the style names in the Apply CSS panel. If you enter classes or style names that do not exist, the Styles menu in the InContext Editing interface will be enabled, but it will display No Style, as shown in Figure 5.

Back to top

Comparing InContext Editing with SiteWalk

If you’ve been a Business Catalyst Partner for awhile, it’s likely you are familiar with SiteWalk, the online editing interface that is replaced by InContext Editing in the Admin Console.

The two features are right next to each other in the Admin Console, in the Website section (see Figure 6).

For now, SiteWalk is still available for use in the Admin Console, although it is recommended to use InContext Editing, as SiteWalk is deprecated. However, you can use both editing interfaces interchangeably on the same site content; if one of your clients prefers to use SiteWalk and a newer team member prefers to use InContext Editing, they can edit the same pages without any conflicts. Also, it is not necessary to create roles specific to the editing tools—if you create a role that includes the ability to edit web pages and add your clients to that role, they will be able to use both SiteWalk and InContext Editing when editing pages.

Table 1 lists the features available in each editor:

Table 1. Features available in SiteWalk and InContext Editing

* In SiteWalk, return to the live site by switching between the live page and the working copy.

**In SiteWalk, discard changes made during the session by clicking Cancel.

InContext Editing introduces the added ability to add links to external documents, such as PDF and Word files (see Figure 7).

InContext Editing does not support the following:

• Paste from Word: This option is not necessary, because Word formatting is automatically removed from text content during the Paste operation.
• Create and Delete folders: This option could lead to major changes in the site’s structure; experienced users can access this feature in the File Manager in the Admin Console.
• Delete images: This option could lead to broken image files in pages and templates. Web team members can access this feature in the File Manager of the Admin Console.
• Print: If printing is needed, choose File > Print to use the browser’s print feature.
• Spell check: If spell-check is needed, use the browser’s spell-checking functionality. Alternatively, spell-check the document in Word before pasting in the text.
• Word count: If word count is needed, use the word count feature in Word.

Back to top

Tips for configuring and working with InContext Editing

InContext Editing is ready to use the moment you create a free Partner account and build your first trial site. Since InContext Editing is an integral part of Business Catalyst, the <div> regions of pages are preset to be editable and the online interface is very easy to use. However, there are some best practices that you can follow to ensure your clients can access the content they need to edit with the editing tools you want them to use. Use the following strategies to control the editability of page elements:

Granting specific permissions for users assigned to roles

You can control the site editing capabilities of your clients by enabling or disabling the features and areas of the site that they can access. By creating roles and assigning your clients to those roles, you can define their ability to perform specific tasks. When you add users to a role, they are automatically granted the permissions that are assigned to that role.

For example, you could create several different roles for your clients and their employees, such as Moderator, Content Contributor, Editor, and Designer. Using the Admin Console (Admin > Manage Roles) you can define the permissions that are available for each role.

The following list illustrates how you could set up a site's roles:

• Moderator: Can delete pages and approve content submitted by visitors
• Content contributor: Can edit and create pages
• Editor: Can edit, create, and delete pages
• Designer: Can edit, create, and delete pages and templates

To test the roles you've created, you can log into the Admin Console with the user’s credentials and use the interface to see which features are available to the users of that role. You can also create a second user account for yourself (using a different email address) and add that user account to the role you want to test.

The InContext Editing functionality respects the permissions assigned to users in specific roles. Roles take precedence over the editable and noneditable regions set on each page. The system follows this order of operations when evaluating whether the current user has the ability to edit content:

1. Does the current user have permissions to edit this content? (Yes/No)

   Even though a template has editable regions defined, these regions will not be editable if the current user does not have permission to edit templates.

2. If Yes, does the site content exist inside an editable region? (Yes/No)

   If No, then the user cannot edit the content, even if they have permissions to edit editable regions in other pages or templates.

3. If Yes, does the page or template use specific CSS styles? (Yes/No)

Based on the Online Editor settings for styles, if CSS styles formatting option is enabled for the user (and if the CSS styles exist in the page or template or a linked style sheet), the user can use the InContext Editing interface to apply CSS styles to page elements.

If the CSS styles formatting option is disabled, the interface will display the message "No Style" and the menu will be inactive (see Figure 8).

To learn more about working with roles, see Creating roles and assigning them to users to add permissions.

Navigating to orphan pages by editing the URL in the address bar

In most cases, your clients can navigate from the home page of the site to the page they want to edit. They can choose Website > InContext Editing > InContext Editing to access the Introduction screen. Once they click the Start Editing button, the InContext Editing session begins, and they can make changes to the home page.

If they wish to edit other pages, they can hover over the links to the desired page and click the Follow Link icon to visit the desired page of the site (see Figure 9).

However, you may have created orphaned pages for marketing campaigns, to prevent a page from being indexed by search engines, or for other purposes. You can’t access orphaned pages by clicking the Follow Link interface, because they aren’t linked from other pages in the site.

To edit orphaned pages, follow these steps:

1. Log into the Admin Console. Choose Website > InContext Editing > InContext Editing.
2. In the Introduction screen, click the Start Editing button (see Figure 10).

3. The home page for the site appears. In the address bar of the browser, it looks something like this:

   http://my-site.businesscatalyst.com/Admin/Editing.aspx#page=%2Fhome

4. Edit the URL in the address bar, replacing the end of the URL by typing the file name and replacing the text after the equal sign to access the About page:

   http://my-site.businesscatalyst.com/Admin/Editing.aspx#page=about.html

5. Refresh the browser window to load the new page. Dashed line borders define the editable regions. Click inside an editable region to begin updating the content. The dashed line borders become solid when you select an editable region (see Figure 11).

Setting pages and templates as uneditable

By default, the <div> tag containers (as well as <td> and <th> table cells) in all pages and templates are set as editable. If you do not want your clients editing a specific page, template, or area of site content, you have several strategies to prevent them from making changes.

As mentioned above, you can create roles with specific permissions, and then add your clients to the roles to grant them access to various areas of the site. If you do not want them editing the templates, then ensure that the roles they are assigned to do not include the ability to add, delete, or edit templates. If your clients do not have permissions to create or modify templates, then you do not need to set the templates as uneditable. (You may wish to create another role in order to set permissions for one of the members of your web team, so that they have the ability to edit and manage templates while using the InContext Editing interface).

But you may encounter situations where you want your clients to edit most web pages, except for a few. In these cases, it is important to understand how to set pages as uneditable.

The backend of the InContext Editing follows these rules:

• If the page contains <div> tag containers, these areas are marked as editable by default.
• However, if you specifically set at least one of these containers as an InContext Editing editable region, then all other <div> tag containers on the page are set as uneditable.

So, while it may seem counterintuitive, the way to make a page non-editable in InContext Editing is to define an editable region on that page. For example, you could create a <div> tag in the footer, or some other inconspicuous area that does not contain any text or image content, and then set that section as editable (using Dreamweaver or by hand-coding the tag). Just ensure that at least one <div> tag has the following syntax:

If you want to restrict the formatting abilities even further, use this syntax:

In the line of code above, only the bold text formatting is enabled for the <div> container.

The <div> tags can still have other attributes; for example, you can set the editable region on a <div> tag that has a CSS style applied, like this:

Adding a single editable region on the page or template causes all of the rest of the <div>, <td> and <th> tags to become uneditable.

Even if your clients have permissions to edit templates and pages, they won’t be able to edit any of the content on a page with a specified InContext Editing editable region, except for that one small area that doesn’t contain any content.

When you train your clients to use InContext Editing, it’s a good idea to alert them that some of the pages may be set as uneditable, so that they will understand this behavior.

To learn more about setting InContext Editing editable regions and specifying the formatting options, see Guide to incorporating InContext Editing for Business Catalyst administrators.

Limiting access to upload image files

When your client uses the image feature and chooses to upload a new image file (with the Media Location: My Computer setting), the file uploads and inserts as expected, but the image file is saved in the root level of the site hierarchy, which is not optimal.

At the moment, there's currently no way to preset where the uploaded image files will go, and your client can't choose the folder destination during the upload process in the InContext interface.

Note: If you later move the image files from the root level to a subfolder in the site, the paths to the image files are broken on pages where they were inserted.

It is a best practice to disable the image upload feature for your clients, because the image files uploaded with the My Computer option are placed at the root level of the site (see Figure 12).

Alternatively, you can optimize and upload the image files in advance, and then enable image editing for your clients, instructing them to choose the My Site option and navigate to the existing image files that they want to insert (see Figure 13).

To prevent your clients from uploading images, you can configure the InContext Editing editable regions to not enable the Image formatting option in Dreamweaver, by deselecting the Image option (see Figure 14).

You can also hand-code the syntax of the editable region’s <div> tag to ensure it does not include the formatting options that you do not want your clients to access. To learn more about setting the formatting options for editable regions, see the guide to incorporating InContext Editing for Business Catalyst administrators.

Using InContext Editing as a production tool for minor content changes

Although InContext Editing was designed as a way for users with no coding experience to edit site content in a browser, it is also a helpful utility for you and members of your web team. You may encounter situations where your client requests an immediate site update. In these cases, you can also log into the Admin Console and access the InContext Editing interface. Since you are logged in with your credentials, you’ll have all the same permissions you normally have when editing the site.

Small text changes, as well as updates to links and images, can be implemented in a matter of minutes, so that changes can be published immediately. When you think of InContext Editing, don’t forget that it is not just a tool for your clients—it is also a quick way for you and your web team to update the site.

Back to top

Where to go from here

As you can see, there are many methods you can use to control the editability of site content with InContext Editing. It is a powerful tool that allows you to define which team members can edit specific content, and specify the formatting options that they can access to make changes. To learn more about configuring InContext Editing for your clients, see the guide to incorporating InContext Editing for Business Catalyst administrators.

Also check out the following knowledgebase articles:

• Migrating an existing site with InContext Editing to the Business Catalyst Platform
• Defining InContext Editing editable regions using Dreamweaver
• Defining InContext Editing editable regions using any code editor

And be sure to visit the Business Catalyst Developer Center, where you’ll find helpful articles and sample projects to help you get up to speed quickly.

Back to top