SiteExecutive Blog

Thoughts, Opinions and Current Trends in Content Management

Posted by: David Schreiber

During a terrific story on NPR the other morning, reporter Christopher Joyce interviewed Ian Tattersall, a curator at the American Museum of Natural History who uttered the phrase, “Novelties happen randomly.”  Tattersall was referring to natural selection – the Darwinian principal behind evolution – but the concept got me thinking about software development.

no, this is not the SE development team, these are hominidsBefore I get started, I assure you, the SiteExecutive development team has a product roadmap that outlines dozens of new features and capabilities. These are mapped to target release dates – the whole thing is very ordered and logical. And, contrary to natural selection, we can and do call things into existence because they are desirable.

On the other hand, we run into situations where clients get ideas for doing things with SiteExecutive which are outside of our frame of reference. A case in point is Geisinger Health System using SiteExecutive to manage policies, procedures and guidelines – all manner of clinical content. Geisinger’s project is outlined in a case study – it was also a finalist for a 2009 KMWorld Reality Award.

To address the clinical content challenge, Geisinger designed and built a custom SiteExecutive module. They could have purchased an off-the-shelf application for this purpose, but they wanted something better. To make it happen, Geisinger developers took SiteExecutive developer and API training. They also had a team of very smart people from across their organization focused on making this project a success.

The policies, procedures and guidelines at Geisinger cover all aspects of their operations – from life-saving procedures to sanitizing floors. As with so many aspects of healthcare, the way Geisinger manages this clinical content is regulated by the state of Pennsylvania and Joint Commission.

 It turns out – no surprise – that other clients, in other industries have similar challenges. Substitute “standard operating procedures” for policies, procedures and guidelines and voila, we have new workflow requirements driven by a client’s “novel” request.

More details about the new SiteExecutive workflow functionality will be disclosed in the near future. BTW, we’ll be sharing a detailed product roadmap with clients at our SiteExecutive user conference – formal save the date announcement coming soon.



Posted by: David Schreiber

Unless you've always used a Mac or are new to Windows PCs, you've probably experienced the infamous Blue Screen of Death (BSoD) more than once. Though annoying (and sometimes extremely aggravating), the BSoD is usually resolved by restarting Windows. Yesterday, thanks to an article in the San Francisco Chronicle, I learned about the Web analog to the BSoD – it's called the White Screen of Death (WSoD).

Unlike the good old BSblue screen-of-deathoD, the WSoD is an open-source affliction, related to PHP programming errors. What makes the WSoD worthy of a mention in the SF Chronicle (and this blog), is the fact it directly effects WordPress – a widely deployed blog engine and light-weight CMS – and Drupal, an equally popular open-source CMS, which competes with SiteExecutive.

When the WSoD occurs, afflicted sites render blank pages. And if I understood the Chronicle article correctly, the problem can also impact the Admin pages in WordPress. Thus, your site visitors get blank pages with NO content and you cannot administer your blog or Website – NICE!

Both WordPress and Drupal are know for making content management easy for end users. This certainly contributes to their popularity, which is also fueled by their cost – they're free (sort of). In actuality, for most organizations, the total cost of ownership (TCO) for these applications is far from free. Factor in the costs (whether you're paying for internal colleagues or third-party consultants) of support, development, add-on modules, integration and downtime and the numbers can add up.

So, if you're considering an open source CMS, please take into account the time, effort and expertise required for managing open source code – and be prepared to contend with the business impact of WSoD.

Alternatively, if you are looking for an affordable, reliable (and easy to use) CMS on which you can dependably run your organization's Website, we suggest SiteExecutive – especially if you choose our SaaS offering, which gets you a fully supported, hosted CMS and Website, with SLAs for performance and availability.



Posted by: Mark Dabrowski

With all the iPhone (and now iPad) fever over the past few years we’re clearly seeing a structural shift from browsing the Web on computers to mobile devices, or more aptly “multimedia devices.” This trend is particularly apparent among 18-24 year olds. Though this is not news to anyone, it's amazing how many college and university Websites are extremely difficult to navigate, if not completely unusable on mobile devices.

Working with higher-ed clients, I have had many occasions to view and assess their Websites’ mobile performance, particularly on my BlackBerry Storm…yes, I know – a weak browser to begin with – but the experience was no better with WebKit-based browsers like on the Apple iPhone or on Google Android devices.

So, why is this important? According to Nielson Research, about 25% of US Internet users regularly access the Internet through mobile devices. Of course that number can vary widely by age demographic among other factors. We also recently conducted a Website visitor survey for one of our customers – a private liberal arts college – and 46% of their target Web audience (prospective students and their parents) indicated they regularly browse the Web via mobile devices. That’s a wake-up call folks.

I’m not suggesting that all of sudden prospective college students will be doing all of their research on their iPhones, Droids or Pres. But if a college or university can answer some of their most common questions – what majors do you offer, how much is tuition; or provide valuable services: a campus map (Google Maps integrated perhaps?) or ability to check admissions status,  via communication mediums that they use most – that's a powerful way to connect with those individuals. The key here is to leverage the mobile Web as yet another tool to drive admissions, yield, giving, alumni involvement and many other goals. We want to be able to connect with our audiences through the various communications mediums they use, and these days they’re increasingly mobile.

What’s holding back mobile site development?

  • Most Websites are optimized for viewing on screen sizes and resolutions common to desktop computers or laptops. As a result, they don’t scale well to the much smaller, much lower resolution screens found on most mobile devices.
  • JavaScript-based navigation and functionality – many Websites leverage it heavily, while many mobile browsers do not support JavaScript, have it disabled by default, or handle it inconsistently. The end result for mobile users is a poor user experience because of a difficult, if not impossible to navigate Website.
  • Flash – many college and university Websites make use of Adobe's Flash technology for content presentation, video and navigation. The problem is that mobile devices based on BlackBerry OS, Windows Mobile, Android and iPhone OS (all the major players in the mobile space) don't support Flash. While Flash support should arrive later this year for BlackBerry OS, Android and Windows Mobile 7, Steve Jobs has famously made it clear that Flash has no place on Apple's iPhone OS (variants of which power the iPhone, iPad and iPod Touch).

Alternative approaches to mobile Web develop

The legacy approach to mobile Web has been to create a separate mobile-optimized Website, e.g. “m.yoursite.edu” vs. www.yoursite.edu. The idea was for users to either know the mobile URL and access it through their handheld or preferably for your Web server to “detect” when a user tried to access your main site through a mobile browser and automatically redirect them to the mobile-optimized URL. Some Websites still do this, but there are flaws with this approach:   

  • Often times two separate content management systems:- one for the main Website and one for the mobile version. This becomes a maintenance headache.
  • Either copying content or making sure it gets properly syndicated from the main site to the mobile site – again more work for content managers.
  • Typically with this approach only a subset of your main Website’s content and functionality is made available via the mobile-optimized site. How useful is that for your visitors?

An alternative approach, and one that I think is far better for your content authors and for site visitors, is a single site which presents content optimized for the device requesting it. In this case, your Web content management system or application server detects whether or not a site visitor is using a mobile browser and then formats the requested Web page accordingly – either optimized for the desktop or for the far smaller screen of a mobile device.

Mobile site development in the real world

To solve this problem, the approach we took with SiteExecutive, our Web content management system (Web CMS), is to provide content authors with the ability to build mobile-optimized Web page templates and then link them to standard desktop browser-optimized templates. So, when a visitor accesses a page on a SiteExecutive-powered Website, SiteExecutive first detects whether or not that visitor is using a mobile browser. If so, the page content is presented through the mobile-optimized “sibling” template the content author had previously associated with the standard desktop template. The end result is one Website, one set of URLs and all of your Website content accessible via mobile devices. No need to manage two systems or maintain content in two locations. This certainly does not solve the Flash issue, but there are other mobile-optimized means to present video and other content traditionally presented through Flash.   

For some examples of how this approach works in the real world, check out the following sites from your desktop and mobile device’s browser:

If you're interested in exploring your options for mobile site development, please give us a call: 1-877-797-2554 or get in touch by email.



Posted by: David Schreiber

Congratulations to Art Lang, Ernest Bourne and the rest of  the Web team at the Salt Lake County Library on the launch of the library's revamped Website. The site serves as an online branch, giving visitors access to virtually all library services, from research to book requests and more. Making these services available through SiteExecutive required some custom development and integration with existing library systems. Fortunately, the SiteExecutive API is easily tapped for custom development, especially by Web developers completing SiteExecutive API and Developer Training, which Art and Ernest did last fall.



Get Started Today!

Follow Us:

  • [f]
  • [t]
  • [in]
  • [>]

Sitemap

  •  
    •  
    •  
.