They said that they wanted to use Google Sites to host a web site, but their organization's systems administrator said that Google is quite experimental and they frequently ditch services (such as iGoogle and Google Buzz).. the administrator recommended that alternative hosting solutions should be considered instead.
This person was curious to know if these statements were true or not and whether or not Google Sites was a long-term viable hosting solution.
Google Sites has been around since 2006 when it was purchased from JotSpot. As of August 2012, Google has owned what is referred to as Google Sites for six years. To put that in perspective, Twitter was created in 2006; JotSpot (now Google Sites) was bought by Google in 2006. That is, the service known as Google Sites is older than Twitter. Personally, I haven't heard many people advising against the use of Twitter on account of the fact that it may go away soon or that it's immature technology.
Since it's acquisition in 2006, Google Sites has seen a variety of updates and revisions, including at least seven in the first half of 2012.
A significant example of a recent update is from March of 2012 with the inclusion of HTML Boxes. HTML Boxes are tools that allow you to include arbitrary HTML, CSS, and JavaScript. This represents a major leap forward because previously, web content editors could either stick with a pre-built theme, customize the colors, fonts, and images of an existing theme, or edit the underlying HTML of a page to include inline CSS directives.
Using inline CSS gave web content editors a lot of room to work, but they would have to edit the HTML offline and apply the necessary CSS to each element via the 'style' attribute. There were some tools to automate this process, but it was still time-consuming and highly inconvenient.
HTML Boxes allow web content editors to <link> their own stylesheets or use <style> blocks to specify custom CSS using traditional CSS selectors to manipulate the presentation of pages stored in Google Sites. Moreover, web content editors could include <script> blocks to bring in their own JavaScript to make pages more interactive than ever before.
However, there are several restrictions to HTML Boxes:
- you can not use HTML Boxes to create iframes; however, if you specify an iframe in the HTML content of the page (i.e. not through HTML Boxes), Google Sites will translate the iframe into an equivalent Google Gadget on your behalf
- your JavaScript code can not create any image, link, or script tags; you can, however, specify <img>, <script>, or <link> tags in HTML Boxes just like normal. You just can't use JavaScript in an HTML Box to create them.
- your JavaScript can not use document or window onLoad or onReady events. Google recommends that the closest you can get is to create an HTML Box at the bottom of the page to approximate that functionality
For more information on HTML Boxes, go to Google's help page:
As for the objection that Google is experimental in their launching and subsequent support of various applications, consider that iGoogle, formerly known as Google Personalized Homepage, was launched in 2005. As a result, iGoogle, as of August 2012, is more than 7 years old.
In recent years, the popularity of iGoogle has declined. In 2011, Google announced they would be removing iGoogle's social features in an attempt to focus their social efforts on Google+.
Much of the personalization functionality of iGoogle is through the inclusion of portlets, otherwise known as Google Gadgets. Google Gadgets offer the capacity to provide some piece of functionality such as to render an RSS feed or display a calendar.
Google Gadgets can be rendered through a variety of Google Apps, including Google Mail (Gmail), Google Calendar, and Google Sites. That is, it's possible to create a "homepage" through Google Sites that approximates the look and functionality of an iGoogle page.
Google Sites is a core part of Google Apps. Google Drive / Google Docs represents a component of Google Apps allowing users to create, store, edit, and maintain content that's primarily directed inward -- toward the user; Google Sites, on the other hand, is primarily directed outward toward other users, groups, and the public in general. It's certainly possible to use Google Drive / Google Docs to publicly publish content and it's certainly possible to use Google Sites to maintain private pieces of content. Google Drive / Google Docs and Google Sites primarily serve reciprocal purposes.
With that in mind, it's unlikely that Google Sites or Google Drive / Google Docs will be retired any time soon, especially with Google's investment in Google Drive which became publicly available in April of 2012 and the current trend of technology service / cloud providers (such as Microsoft, Amazon, Apple, and others) offering storage capacity to consumers.
It's certainly possible -- and probable -- that Google Sites will eventually be retired. However, there are no indications that this will happen any time in the near future, particularly since Google Sites provides a key service that is used by many individuals and organizations.
There are a number of reasons to consider using Google Sites to host web content.
First and foremost, if your organization already has Google Apps, using Google Sites to host web content is free. In fact, it's "more free" than using many Free / Open Source Software solutions to host web content. For example, consider Drupal, a popular Free / Open Source Software Content Management System (CMS). In order to host a web site in Drupal, you have to have a web server that's running Drupal. This means your organization will either have to either allocate financial resources (e.g. a web hosting solution) or allocate technical and personnel resources to installing and maintaining the software and the system (e.g. patching, cleaning up logs, adding users, etc.). Either way, it ultimately costs money -- money that can be better spent engaging in activities that differentiate your organization (having a web site is no longer a point of differentiation; they're now commodities).
Second, if your organization already has Google Apps, then user management becomes a non-issue with Google Sites. Users and groups that are in your organization's Google Apps domain can be granted access without having to be created solely for the purpose of supporting the web site. Moreover, security, password management, and Single Sign-On (SSO) all come bundled with your organization's Google Apps domain.
Third, the administrative overhead associated with providing Google Sites is trivial compared to using a 3rd party hosting solution. There are no computers to purchase, not virtual machines to spin up, no LDAP synchronization bridges to configure. All the domain administrator needs to do is click on "Enable" once to enable Google Sites and create the occasional mapping of hostnames to Google Sites. Otherwise, much of the effort associated with administering web sites can be delegated to web content editors.
Fourth, Google Sites provides a very user-friendly Content Management System (CMS) that is very similar to Google Drive / Google Docs (which is, itself, similar to a simplified version of Microsoft Word). In fact, if you can edit a document in a word processor, you can edit a web page in Google Sites.
Moreover, there are a variety of integration points between Google Sites and data stored in the various component services of Google Apps. For example, inserting a video stored in Google Drive can be accomplished by clicking on Insert, then Google Docs Video, then selecting the video that you would like to insert from the list of videos in your Google Drive / Google Docs file storage. Similarly, embedding documents, forms, spreadsheets, YouTube Videos, calendars, and more can be accomplished with only a few clicks.
Also, you can setup templates that include HTML Boxes that include the presentation stuff (HTML, CSS, etc.) for each page. Then, when web content editors create pages using those templates, they'll see the familiar editing interface, but with an additional gray box (the HTML Box) that contains all of the "technical stuff." You can instruct your web content editors not to touch the gray HTML Boxes and to otherwise edit the content as usual. That way, even complex web pages can be made user-friendly to edit and maintain.
Fifth, Google fully supports Google Sites. If your organization is a customer of Google Apps for Business, for Education, or for Government, there are phone numbers that you can call to get immediate support for Google Sites. Similarly, Google Sites is administered and maintained by a group of dedicated technologists who make sure your web site is up and running 24/7. There's even a 99.9% Service Level Agreement (SLA) guaranteeing the availability of your web site. Furthermore, Google Apps is run on top of hundreds of thousands of identical, redundant servers in data centers all over the globe.
Sixth, Google secures and backs up your data. Google's data centers are protected by armed guards around the clock and every line of code that makes up "Google Sites" has been reviewed by recognized industry leaders in information security.
Google Apps has SAS 70 (type 1 and 2) and well as FISMA certifications. That is, their code is audited at least every 6 - 12 months and their security is sufficiently strong to allow them to host US federal government data.
Lastly, Google Sites is extensible through the use of HTML Boxes, Google Gadgets, and Google Apps Script. That is, even if Google Sites doesn't support the exact functionality or integration piece your organization needs, the required customization can be constructed using standards-compliant tools and technologies.
Moreover, Google provides APIs for access data in Google Sites. These APIs allow for the creation, modification, and maintenance of web content through third party tools. For example, an organization can use their own CMS to allow users to edit content and then use a script to synchronize their CMS with Google Sites. This gives you all of the availability, redundancy, security, and simplicity of hosting advantages of Google Sites with the familiarity, integration, and control advantages of your organization's CMS.
Other tools, such as Drupal, Joomla, Xoops, Wordpress, etc. are all great tools and they have their place and none of this should be construed as an attack on these or any other packages, nor on their talented and dedicated developers. However, Google Sites is an excellent tool that is worthy of consideration for hosting your organization's web site(s). Also, it's certainly possible to host different parts of your organization's web site using different services. For example, an organization may need to host heavily data-driven web applications that are incompatible with Google Sites on one hostname while their homepage could work very well with Google Sites.
To sum up it's advantages, Google Sites is a free, secure, well-supported, well-documented tool that is easy to use, administer, integrate, and customize. Google Sites has been around for a long time (in terms of the history of the world wide web), and there are no indications that it will be going away any time soon.
Fantastic Article ..great insight!
ReplyDeleteGoogle Docs and Google Apps Script are far more practical than Microsoft Office ever was? Free access and free technical updates also helps a lot:)