Hannon Hill Corporation
Blog Archives
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
Blogs - March 2011
Below are the blog entries for March 2011
Best Practices Webinar Series on Index Blocks
By Joel Dixon, Amy Liu
Wednesday, March 30th, 2011 at 3:00pm
In a recent blog posting on page rendering times, one of our support engineers looked at several key areas that impact optimal performance when publishing with Cascade Server. Among these topics we found one particular area seems to significantly impact a majority of client sites, call it the 800-pound gorilla in the room, Index Blocks.
Although Cascade Server Index Blocks unlock great flexibility and functionality for content reuse, their misuse can also be one of the common factors that can affect performance. Examples abound but here are some things to consider:
- Look before you leap. Some common areas where Index Blocks are most frequently used and/or abused include the Homepage, the Sitemap, Newsrooms, and dynamically managed navigation elements.
- Different strokes for different folks. For existing users of Cascade Server, it is already clear that almost any dynamic functionality can be implemented in the system through a combination of Index Blocks and Formats. However, like most scenarios in life, there are multiple ways to accomplish the same solution so it is essential that we consider all of the possible options to make sure it will optimize your Cascade Server performance and experience, even if that solution takes more time up front to plan and implement.
- Inspect what you Expect. Even if your current implementation is working, consider revisiting the implementation methods of certain areas to ensure that they are scalable solutions which can handle the anticipated amount of new content that will undoubtedly be created by users of Cascade Server. Oftentimes, the initial environment in which the Index Blocks and Formats were created does not accurately reflect the same environment once the system is in production.
Since our team understands the good, the bad and the ugly that can arise with the use of Index Blocks and other Cascade Server functionality, we decided to start a scheduled webinar series on “Cascade Server Best Practices”. Through these topic-focused webinars we hope to present a variety of functionality available within Cascade Server, highlight new features that clients may not be utilizing, discuss implementation best practices, showcase many different use cases, and provide opportunities for clients to ask additional questions on each webinar topic.
We will host the first webinar in this series on Tuesday, April 12, 2011 at 2PM EDT and will focus on the use of Index Blocks. Included in this webinar will be more detail about the implementation suggestions mentioned earlier in this blog. We will also look through some examples using Index Blocks, including Navigations and News Sections.
Like all our webinars, this is a free event. A member of the Hannon Hill team will be leading this presentation and available to answer questions related to this topic as well. We hope you’ll make plans to attend. Please sign up to reserve your spot!
Update: Please see the video of this webinar here!
Category
- News
Cascade Server Case Study: Northwestern University
By Chris Armistead
Monday, March 28th, 2011 at 10:32am
We're excited to announce that our latest case study, which features Cascade client Northwestern University, is now up on our site. A big thanks goes out to Northwestern Senior Web Developer Lee Roberson as well as the entire Northwestern team for their work on this valuable piece of content. We hope you'll take a few minutes to read the Northwestern case study along with all of our client case studies. If you're a customer who'd like to be the subject of a case study or host a webinar spotlighting your usage of Cascade, please contact me directly at chris.armistead@hannonhill.com
Category
- Product Upgrades
Don't Surrender to the Render
By Tim Reilly
Thursday, March 24th, 2011 at 2:00pm
As a support engineer, one of the most common questions I receive from customers is, "Why are my Pages taking so long to load?" A typical investigation into the matter first includes verifying that the application has enough resources allocated for optimal performance. Once I'm able to confirm that the system is configured properly, the next step includes a deeper look into the way the customer has integrated his or her site(s).
The first things I look for are any slow loading regions in the Page. This involves taking a look at each individual page region -- sometimes even removing Blocks and Formats one-by-one until the Page loads in an acceptable amount of time. Once this happens, it is easy to identify the problem Block and Format. So, why do very large Index Blocks cause Pages to load slowly? Consider this: have you ever tried opening a large XML document in a browser outside of Cascade Server? I've seen some XML files take upwards of 15 seconds to load while other (larger files) have caused the browser to crash. When you combine this with the fact that most pages consist of multiple Index Blocks (which also have to be transformed via XSLT or Velocity), it is easy to see how quickly a very large Index Block can hinder performance.
With the 6.8 release of Cascade Server we've made it easy to spot problem areas in Pages using Metrics. Now, when a Page is rendered in the system, the processing time for each Page region is measured and displayed in a new 'Metrics' menu which is available on the layout pane of the View tab. Clicking this item will show you the total render time for the Page along with a summary of how long each region took to render. Users can then click on the region name for a breakdown of how long the corresponding Block and/or Format took to render.
Rendering metrics preview
So, rather than having to remove Blocks and Formats from regions one at a time in order to isolate issues, users can now get a quick overview of how long each section of their page is taking to load. From there, steps can be taken to reduce the size of the offending Index Blocks and/or tune-up the Formats assigned to certain regions.
When limiting Index Block content, one approach is to look at the number of assets being indexed. Do you really need the Index Block to return data for assets that are 2-3 years old? If not, archive old assets in a separate Folder and/or make them non-indexed such that they won’t appear in the Index Block (thus reducing the size of the index). Another step would be to re-evaluate your Index Block settings to see if you are including page XML and/or Block XML inline. Whenever possible, un-checking these options will make for Index Blocks which are much smaller in size. Some may argue that they must have the page XML and/or Block XML setting enabled in order to retrieve data from the structured data content of their Pages. In these cases it makes sense to take a closer look at the implementation to see if any of those structured data fields can be converted into Metadata fields.
Formats can also be a source of additional rendering time. When using XSLT or Velocity, XPath is utilized to determine which XML nodes are used for transformation of content. Some methods within XPath are more efficient than others. One common instance of this is the use of “//” to search for specific content nodes within an XML structure. This often works but is generally not the most efficient way of getting specific content. The “//” is the shorthand of using the “descendant” axis which returns the XML node from anywhere within the XML structure. When getting the current page from an index block with current page appended, selecting “//system-page” seems a lot shorter than putting “/system-index-block/calling-page/system-page” but really the first way will render results a lot slower than the more specific path. This is because the “//” or “descendant” axis will traverse the entire XML node structure even if the XML node has already been found. It will even go within the “system-page” node checking to see if any of its nodes match the call. Meanwhile, the more specific path will only check the nodes and levels specified within the path.
This feature is a great help not only to our own support team but also to customers looking for answers as to why some of their Pages take more time to render. Metrics provide users with the tools they need to continually monitor how certain page configurations affect load times. From there, they can proactively address Index Block and/or Format issues to increase the performance of their site(s) within Cascade Server.
Category
- Product Upgrades
Hawaii Pacific University Webinar Now Available
By Chris Armistead
Wednesday, March 23rd, 2011 at 11:00am
We hope that you were able to attend our recent webinar presented by Cascade Server customer Hawaii Pacific Univeristy on their use of Structured Data in Cascade Server. If you weren't able to make it, however, you can view it below or access it anytime from the Demos page on our site. This page is where you can view all past and future webinars presented by Hannon Hill staff, partners, and customers. We are always looking for folks who would like to host webinars, so please contact me directly at chris.armistead@hannonhill.com if you're interested. Big thanks to Hawaii Pacific University for presenting such a valuable webinar.
Category
- News
Designing A Page Output For Mobile Devices
By Rahul Bhagnari
Thursday, March 17th, 2011 at 10:00am
With the ever-increasing popularity of mobile devices, many of our clients have already implemented or are designing mobile outputs of their websites. Creating the additional output within Cascade Server is very easy and is based off a template designed specifically for mobile devices. Therefore, the majority of the work lies in the actual design of the template prior to the integration into Cascade. I thought this might be a good time to talk about some of the design considerations when creating a mobile output.
When designing your mobile site, it’s important to note the functionality and purpose of the template. Simplicity is key. Keep in mind the following when creating your template:
- Available real estate - mobile sites have a limited display to show all content
- Slower download speed
- Use of images - you could keep the types of images restricted to jpgs and gifs or remove them altogether
- The Flash, JavaScript, or other “special” sections of your page as not all mobile devices support these types of functionality (and are therefore, unnecessary).
- This includes all flyover and popout menus and tags.
- User experience - including “home”, “back” and other links to various points of interests on your page
- While the mobile site offers a simplified version of your current site, an option to view your actual site on a mobile device would also be useful.
Keep in mind the following when implementing the mobile site version of your page:
- The content should be straightforward
- Try replacing text fields, such as radio buttons and checkboxes, whenever possible.
- All of the content on your main page doesn’t necessarily have to display on your mobile site. You want the most important pages and the most crucial information from those pages.
- The content and structure should be restricted in width size so as to avoid horizontal scrolling
- This is especially true for a navigation menu. Personally, I would recommend a maximum of four fields in the navigation and to keep its placement either at the top or bottom of the display.
- The domain name for your mobile site should be relevant and simplified
- For example, useful examples would be maindomain-mobile.com, m.maindomain.com, or maindomain.mobi. Owning all possible domains could also hep in redirecting users to the original site.
Here are some examples that show very effective designs for mobile devices
http://m.cnn.com/
http://m.espn.com
http://iphone.facebook.com/
http://m.alistapart.com
http://m.google.com
http://m.flickr.com
If you have any questions or if you’re interested in engaging our Services Team, please feel free to contact us.
Category
- News
Webinar On Structured Data To Be Hosted By HPU
By Chris Armistead
Wednesday, March 16th, 2011 at 2:00pm
Hannon Hill is excited to announce the next webinar in our series of webinars hosted by Cascade Server clients and Hannon Hill partner companies. Next Tuesday, March 22, 2011 at 2PM EDT Hawaii Pacific University will be presenting a webinar focusing on their use of Structured Data. Topics included in this webinar will be defining what a Structured Data Block is, and explaining how to set one up through examples in HPU’s instance. Also covered will be HPU's motivations for using Structured Data and the benefits they have seen as a result.
Like all our webinars, this is a free event that will feature a time for Q&A after the presentation portion. A member of the Hannon Hill team will be on hand to answer questions related to this topic as well, so we hope you’ll make plans to attend. Please sign up to reserve your spot!
Category
- News
Beacon Redesign Webinar Now Available
By Chris Armistead
Friday, March 11th, 2011 at 11:00am
We hope that you were able to attend our recent webinar presented by our partner company Beacon Technologies on how they undertake the process of a site redesign, but in case you weren't, we invite you to view the video of the presentation below. It was a great event, and we hope this webinar will continue to be a valuable resource for our customers moving forward.
Category
- News