Using wget and google to download and translate websites

There is a website for the neighborhood I live in that is all in Spanish (cuartonparque.com).  So that's useful if your Spanish is good, which mine isn't.  Google's translate function is great, but I wanted an archive of the site both in Spanish and English in case the site disappeared or was substantially altered.

wget is a great command line *nix utility to recursively download a website providing the links are statically constructed.  I use wget on OS X (install xcode and macports to enable installation of wget if you don't have it).

For cuartonparque.com, the wget command is straight-forward and well documented.  The site uses simple static links and only has a few levels of linking. To download the site, I used:

wget -rpkv -e "robots=off" 'http://cuartonparque.com' 2>&1 | tee cuartonparque.com.wget.log

This command creates a cuartonparque.com directory with a browsable website.

To download a translate.google.com version of the site was trickier.  Although various googled pages helped a bit, I couldn't find find an example that actually worked.  After some hacking about, I uncovered the required tricks to make this work:

• Google appears to only process requests from browsers it's familiar with (use -U Mozilla)
• Google uses frames and changes it's domain name a bit as it translates (find out the final URL of interest by digging around in the page source)
• Safari really likes a .html extension on files it opens (use --html-extension)

My pain is your gain.  Here is the wget command that downloads the translated version of the website:

wget -rpkv -e "robots=off" -U Mozilla --html-extension 'http://translate.googleusercontent.com/translate_c?hl=en&sl=es&tl=en&u=http://cuartonparque.com/&rurl=translate.google.com&twu=1&usg=ALkJrhjabXZlzJpBCZeWpsmLaKss09lCuQ' 2>&1 | tee -a cuartonparque.com.En.wget.log

wget creates a translate.googleusercontent.com directory with a browsable website, localized from Spanish to English with a horrific URL for the index.html page:

file:///Users/xyz/Downloads/Web%20Sites/cuartonparque.com.En.Google.Trans/translate.googleusercontent.com/translate_c%3Fhl=en&sl=es&tl=en&u=http:%252F%252Fcuartonparque.com%252F&rurl=translate.google.com&twu=1&usg=ALkJrhjabXZlzJpBCZeWpsmLaKss09lCuQ.html

A quick browse around on the downloaded version suggests everything came through, nicely translated to English with wholly-formed pages.  Enjoy!

Spectrums of website control - from tech to non-tech

Sometimes it's not clear to a non-technical consumer of a web site what is involved to change content, style, layout, and functionality that make up the website.  In particular you're interested in enabling websites to be built, updated and extended by non-technical staff.  This entry is about explaining the spectrum of possibilities  in change in each of these areas for non-technical users, for example a non-technical website product manager.

Static Content

The static content of the website is all the text and graphics you see on a page.  It is not about functionality (e.g., customer registration), navigating between pages, or other browser-user interactions.  "Static" is a bit of a misnomer in that the text can be changed using the two methods below.  However, it is not about dynamic content that changes on a page without you requesting it to change.

At a basic level, content can be inserted directly into a web page that sits in a file on a filesystem.  To make these types of content changes, one must know at least some basic HTML and maybe CSS.  These types of content changes are typically done by a website "designer", more aptly called an HTML/CSS author.  Many, many websites start out with this approach - it's easy if you know how to do it.  There are no special costs for purchasing, integrating, and/or learning specialized content administration tools.  This could be considered a "technical" activity as it's generally not simple enough for someone without some basic HTML/CSS and related tools training to do.

At a more advanced level, there is some types of forms based interface that allows a non-technical user to make content and image changes on the website.  There are many levels of variation and complexity at this level.  Workflow, publication control, localization flow, version control and security become differentiating features.

Website Design - Style

The design style of a webpage is typically brand and "look and feel" attributes of the page.  At a simple level, this is colors and type/size/modifications of fonts.  The goal is to have a common style and brand feel across all pages of a website.

At a basic level, design may simply not exist, using browser page rendering defaults to style pages.  This is quite common early on in website/page development as you want to focus on other factors and not design.

As the design approach matures, style may initially be embedded directly in a webpage and closely associated with (located with) the content the design is being applied to.

The next level of maturity is to separate style from what is being styled.  One style view, as defined in a globally used CSS definition, is used for all pages in the website.

For all of the above, it is a technical activity with an HTML/CSS author working with files at a filesystem level.

As with static content, the jump is then made to having a forms based interface to change style dynamically.  The syntax of CSS is somewhat hidden away and simplified by the forms and fields a non-technical user interacts with.

Website Design - Layout

Separate from website style is website layout.  Layout is about how the various blocks of information on a webpage are placed on a page.  The goal here is to balance a uniform customer experience across all pages of the website versus contextually unique information and functionality that appears on specific pages.  For example, all pages of a website may have the same top bar, left navigation, and bottom set of links, but then have significant variation of information and functionality in the other parts of the page.

As above, layout can be done by hand by a HTML/CSS author for each page in a website.

As the manual process matures typically driven by a growing number of web pages, some type of organizational framework is implemented so that a uniform layout is used for all web pages.  Developers who implement the framework start working with the HTML/CSS authors to support them when implementing the framework.

The solutions complexity then jumps up significantly to enable a backoffice to manage layout of web pages.  There are basically two varieties of these currently available:

• Technical staff create a page template where the blocks of content and functionality on the page have a fixed layout.  Non-technical users can create new pages using the template as a base, but can't otherwise change the layout.  This is like working with MS-Powerpoint master templates.  
• A little more advanced is creating a fixed layout of "containers" of functionality on a web page where subordinate blocks of functionality are contained in a larger "container" block.  Popular blogging software such as Wordpress take this approach.  You can't change the overall layout, but you can pick the type and order of functional blocks within the container.  The blocks require technical work to create, typically developer and designer.  Nicer interfaces allow a drag-and-drop placement of the blocks.
• The most advanced layout approach is to allow full construction of a page or parts of a page by drag-and-drop from a toolbox of functional blocks.  The blocks may be placed, sized, and configured via a forms based interface by a non-technical user.  The page may have a completely free-form layout, or inherit certain fixed attributes (e.g., to enforce a common header and navigation at the top of all pages of a website).  A non-technical user may define a "template" layout then used by actual website pages, again like a Powerpoint slide master.  This approach may enable non-techs to create and manage pages, but uses very complex technology underneath to support this capability.  Google Sites is an example of this layout approach.

You can see from the above that layout starts technically easy to implement but doesn't enable non-tech users to manage layout.  At the most advanced, there is a lot of complex technology required, but non-tech users can control the layout of web pages.

Note that sites built using the more advanced tools tend to be blocky, linear, and very functional looking.  This is because a good designer isn't working on the layout, only a limited layout software and non-techincal (non-designer) is building the pages.

Website Functionality

We've covered the non-interactive attributes of constructing websites - content, design, and layout.  We've noticed that layout can place functional blocks, and we'll now take a closer look at them.

Functionality must be built by technologists.  As we've seen above, it's possible to enable a non-tech user to drag and drop functionality into a web page layout, but non-tech users can't create new functionality.  You want to register, login, conduct a transaction, or display dynamically updated content on a website?  Technologists will build that.  Yes, there are interesting projects like Yahoo Pipes, but they're more of a toy, very cool, but not fit for small business or little less enterprise level websites.

Given that functionality must be built by technologists, what are the various ways to build that functionality?

At a basic level, a lot of website functionality can be built directly in a web page.  This is a simple and quick way to introduce many classes of new functionality, but is quite limiting when extending and maintaining the functionality.

A much better practice is to reference functional requirements in a page, but implement the functionality completely separately.

In order to support a "page made up component blocks" for example as required by advanced page layout tools for non-technical users, functionality must be constructed in a very specific way that will play nice with the layout and design frameworks in use.

The Spectrum from and end user perspective

With all the hype around what was user generated content and what is social media (user generated content within defined networks of consumers), what are some practical implications of enabling non-technical user outside the business to manage their own pages and content within the business' website?

The first thing to think about is delegation of control.  For example, how much control do you want to pass on from the technology team to internal non-technical users?  One typical consequence when this happens is that site quality drops as the QA process is decreased but the increased flexibility and scale is deemed to be worth it.

The next step of delegation of control is to trusted external partners and suppliers outside the business.  "Trusted" is no doubt a stretch when describing some of them.

The final step of delegation is to pass control to end users.

For all of these steps of delegation, you have to decide what you can "safely" delegate, balancing scale and customer control versus internal governance and quality controls.  And of course your ability to delegate safely is based on how you've implemented the functional blocks you have to work with.

Let's take a look at a specific end user example.  In the beginning of a website/service, everything is controlled by the business - the user journey, what they see on each page, the functions they have available to them and how they are visually organized.  They interact with the site only to submit information and see results.

The next step is user generated content such as a user homepage with simple "about me", a photo, and blog/status functionality in a fixed format.  Then some user interaction functionality is added like forums and chat.

Then one or both of the following happen.

Path #1: As the site evolves and more functionality and content becomes available the customer really wants to control what they see and do.  The site's one-size-fits-all approach is breaking down.  The only thing left to do is to enable the user to create and manage their own experience by selecting functionality and content important to them, organized in a way that makes most sense to them.

Path #2: The website product manager, realizing the site can't be all things to all people, can't be another Facebook, separates out and emphasizes the core business proposition functionality from all the non-core me-too "extraneous" functionality they've worked so hard to create.  They have a Starbucks moment and realize that they need to be where their customer is and not make the customer come to them.  Enter web services into Facebook and the like and exit stand-alone business websites.

Summary

Websites are made up of content, style, layout, and functionality.

The technology exists today to empower non-technical users to create and manage websites.  There are limitations to this, and some of the underpinning technology is complex, immature, and proprietary.

Like with most technology areas, the more you want to simplify technology so that technology specialists are not required to operate the technology after implementation, the complexity and cost for the project increases.

Portal/CMS selection, some alternative criteria

When selecting a portal/CMS, there are business standard ways to select one:

• Formal RFI, RFP processes
• Formal reports from the likes of Butler and Garter
• Mesh requirements to features
• Cost
• Installation consultancy, on-going support provisions
• Top level Company/IT strategy considerations:
• In-house versus outsource
• Open-source vs commercial vs hybrid
• Technology stack (production support) and language (development)

What is one key flaw with the above list?

You don't actually know if the solution will *work for you*.

The above approach is primarily business oriented and only superficially technology oriented. It is sales and marketing information used by non-technical decision makers. It is information contrived to make a sale. I really believe this is one key reason why so many IT projects fail. Products such as CMS software is selected with only light technology considerations.

And when I write "work", it's more than just the pure technology itself. It's also about integration into your existing environment, IT team adoption, bugs specific to your use of the product, and fit for purpose with respect to your requirements. It's about de-risking the technical side in parallel with the business side.

Don't get me wrong. The above list is important. It primarily provides information to help you sell the proposal with non-technical bosses, stakeholders, and downstream customers. It helps you learn about the partner and your requirements. But if you want to enable a successful project, you should be de-risking deeper technical aspects as well.

It's also important to maintain a commercial view, for example:

• TTM (Time To Market) requirements
• Off-paper requirements (e.g., common shareholders between your and the other business; individual relationships)
• Forecasted revenue benefit to project (i.e., how much can you afford to vet)

Given all this, there is a lighter (higher risk, less work) and heavier (lower risk, more work) investment approaches to software selection.

Light weight investments that can be done relatively quickly (in a week or so) and at lower cost:

• Check in with colleagues that have been involved with portal/CMS creation, selection, and deployment. Similarly, if you can, determine what your competition is using.
• Research forums. This is particularly useful for open source or mixed open/commercial source solutions. Look for use of the product that mirrors your intended use - what issues are people reporting? How do the issues change over time?
• If available, review product case studies. Do the case studies reflect your intended use of the application? For example with portal/CMS, are you trying to build a b2c customer facing website and the case studies are all about ECMs (Enterprise (Intranet) Content Management)?
• Where is the company based? What is their primary language and how does that compare to the project's primary language? Cross-cultural issues to consider?
• Use google to look for your proposed CMS - how many pages come up?
• Go to a recruitment/jobs site like jobserve - can you hire developers and systems administrators that have experience with the CMS?
• Use google to look for consultancies - on-shore, offshore, outsource - that specialize in the software you're considering
• Similarly, talk to recruitment agency contacts and ask them what CMS experience they have on CVs and job placements they're working on
• Perform a more detailed analysis of the system architecture and compare to your own competencies

Let's consider a practical example of the lightweight approach. We are considering two possible portal/CMS/website technologies, Day Communique CQ5 and Alfresco. From a non-technical perspective, we're favoring CQ5.

Checking in with colleagues and in the industry:

• Most sites have a hand made portal and CMS for their core customer system. This isn't surprising for igaming as most sites are transactional/functional (not content) oriented.
• Some PHP portal/CMSs are in use. Again, not surprising as PHP was and continues to be the techies choice of underpinning CMS language.

Forums: TBD

Case Studies:

• Communique/CQ5 had eleven case studies, one of which looked like what we need to do
• Alfresco had 24 case studies, not yet reviewed.

(Aside: note how Alfresco uses "case studies" in the URL and Day does not. I'm might think that Alfresco has people involved that understand SEO and Day does not. Or it could be a language thing.)

Location and Language:

• Alfresco is UK/English
• Day is Swiss/German

Google basic search results:

• "CMS Communique" yields 323,000
• "CMS CQ5" yields 11,800
• "CMS Alfresco" yields 961,000

(Aside: Day has made search/SEO particularly hard on themselves as they appear to be moving from "Communique" to just "CQ5" and also sometimes including the "Day" company name prefix rather than just a name. Compare that to Alfresco which goes by... Alfresco.)

Jobserve results:

• Communique or CQ5 yields 2 job postings
• Alfresco yields 10 job postings

Google results for consultancy: TBD

Google results looking for outsourcing and offshoring:

• "CMS alfresco outsource" yields 17,600
• "CMS alfresco offshore" yields 5,130
• "CMS communique outsource" yields 6,470 (CQ5 is 384)
• "CMS communique offshore" yields 12,900 (CQ5 is 2,040)

I also had one colleague report pain dealing with Alfresco consultancy and support.

System architecture review: TBD

(NB: the TBDs here are due to a time limited review and some prior knowledge of both systems.)

I'll let you draw your own conclusion for the lightweight approach.

Heavier cost and lower risk approach is to do two or more Proof of Concepts (POCs). Create an end to end working system that demonstrates some difficult (high risk) functionality. Determine if the system actually works to the hardest bits of your unique requirements. This can be done independently (cheaper, higher risk) or in collaboration with a vendor or consultancy (more expensive, lower risk).

A practical example of the heavier approach? As you might guess, it's TBD!

In conclusion, you'll have some variable amount of time to evaluate portal/CMS choices. Be very wary of a selection driven only by business and not technical reasons. While it might be a commercial reality that you're forced to not technically qualify a choice, you can now at least quantify what should be done and some consequences if you don't do it.

Portal Versus Content Management Systems (CMS) Versus Web Pages

Introduction

There is a lot of difference of opinion on what a portal is.  This is down to several common, conflicting definitions of portals, thinking that portals and CMSs are the same thing, and many different ways to actually build a web page.

Closely related technology and terms will also be covered, along with some practical best practice recommendations.

History

In the mid to late 90s, the first phase of web applications were the same as websites.    Portal and CMS concerns blended together.  Website developers recognized the need for a control panel to control the customer facing part of their site, to which they added some content controls.  They controlled the whole delivery stack.

By the late 90s to maybe 2004, a number of CMSs became available.  This was the second phase of website construction.  You “had to have” a CMS.  These CMSs blended together portal and CMS concerns.  The CMS was the website – pages, content on pages, how pages linked together.  Great for content sites, but building a transactional, functionality oriented site was painful and expensive as the CMS had to be extended.

Also during this time some very clever people working on Java standards recognized the difference between portal, portlet, and content services and wrote JSR-168 (later 286) and 170.  They got it, but practice was well behind theory.

Starting as early as 2001, but really more by 2005, AJAX and web services were catching hold.  The idea that you didn’t need to control the whole delivery stack became clearer.  The first mash-ups started to appear – pulling in services from one website (service) into another.

Also at the same time, an older concept finally caught, which was the separation of content and business logic.  This was the old MVC (Model-View-Controller) approach, but people finally rallied around it.

This leads to the third phase, which we’ve been in for maybe 3-4 years now.  People began to realize that a website is really a container that can draw services from anywhere.  They also refined the MVC approach to separate content-with-format into content and presentation of that content.  They also took a more granular view of web page construction, effectively creating an MVC for each component on a page rather than treating whole pages at a time.

As a result, a portal became a "container of containers" that pulls in and visually organizes content and functionality from wherever it can, but isn’t otherwise primarily concerned with content itself.

Today (mid 2009)

Which takes us to today.  In a nutshell, if a site is very content oriented (not function/transaction oriented) and the content is self-contained, one of those big CMSs may still be appropriate. 

If a site is quite mixed (content, functionality) and has small volumes, little revenue, you still just hack everything together like you would in the 90s.  Same for those that haven’t made the jump in understanding the differences of concern between portal and CMS, don’t require multi-service integration, or “control everything”. 

For everyone else, content and portal are being treated as separate areas of concern.

Making things more complex is that all the terminology and definitions are evolving, quite variable and/or misunderstood.

Portal

A portal is not a CMS!

A portal unifies together one or more service providers into a unified user interface for an information and service consumer.

Examples of service providers and services used by a portal:

• Customer handling system – create and manage customers
• Payment system – debit and credit a customer’s credit card
• Mash-up classics: flickr photos, google maps and news, youtube video
• Content Management System (CMS) – manage content

The service providers may be based on different technology stacks.  In some fashion (there are various) they need to export (make visible) the services they offer.

A service provider, particularly a legacy system or one that is difficult to change, may not use web services or may not be able to easily change the web services it has.  In this case it is common to create some middleware to form a bridge between the legacy system and portal.  The middleware speaks “legacy interface” on one side, and provides a set of modern web services on the other.

The service providers do not need to know about or interact with each other to provide their services (not coupled).  The connection between the portal and the service providers is flexible (loosely coupled).

Assuming the service provider interface remains the same or is backwards compatible, it may evolve independently of the portal consuming that service and other service providers in use by the portal.

Web based solutions are typically a website as displayed in a browser or a rich Internet client (e.g., an MMRPG client).  A rich client stands alone, a website requires a browser.

Choice of portal means choice of technology.  The most common models are the "P" family (PHP, Perl, Python that sit on the front of a LAMP stack), ASP/.Net, and Java.  There are others growing in popularity like Ruby.  Choice of technology will drive the portlet approach which is covered next.

Portlets

Portlets are also called fragments, widgets, blocks, or CMSlets.

A portlet is used to encapsulate a service provider’s service or combination of provider services.

A portlet provides a uniform interface used by web page authors to construct web pages.

It is possible that a service provider might provide a portlet directly rather than a service that the portal encapsulates as a portlet.  This is dangerous because it creates a greater degree of coupling between website construction and an underlying service.  Conversely, it might be faster as web service and portlet are collapsed into one (less code, simpler, less fragile).  Note that this is only possible if the service provider uses roughly the same technology as the portal.

Aside: A rich client may have an equivalent to a portlet, a way to encapsulate a service or combined set of services in a uniform way for the client.

Content Management System (CMS)

Sometimes a CMS is a portal!  But it shouldn’t be.

A CMS is an optional services that a portal can draw on to manage content.

A portal encapsulates CMS services into portlets so a website author can dynamically mange website content.

A CMS should contain all site content – both text and images.

A CMS supports localization of its content.

A CMS will have a backoffice interface to manage the content.  A content administrator can preview content updates in a pre-production (staging) environment prior to live publication.  Content is under version control - who/when is recorded when content is created and changed.  Other typical backoffice functions are present: workflow, audit trail, role based access controls, reports.

A portal may pull text from the CMS and mix it with transactional functionality from a service to create a customer solution.  For example a portal might have a portlet for a registration page that pulls all the field prompts from the CMS but creates the customer in the customer management system.

Historically CMSs owned both blocks of content on a webpage and the webpage itself.  They mixed together portal and CMS concerns.  This is bad for transactional sites as it makes it more expensive to evolve website functionality.

CMSs have many other feature considerations, this is only a high level view of them when positioned in the delivery stack as a service and relevant to portal integration.

A few best practices when working with CMSs:

• Content seen by a customer is never written into a web page.  The web page author requests content from the CMS.  The author knows the context on the webpage and brings in content appropriate for that context.
• A CMS should never be able to publish Javascript.  Javascript should be considered as application code and flow through a control/QA process before live site publication.  Javascript should be encapsulated in tags, not be present in the web page itself.
• A CMS should only publish content with a limited and well-defined set of safe HTML tags around the content.
• Sometimes content and functionality is interdependent.  For example, a new promotions page with some user interaction (e.g., enter a mobile # to access a promotion) needs to go live at the same time as updated (e.g., T&Cs and various links to the new promo page).  To support this, a number of related content changes can be grouped as a change set, and only published all at once when the new functionality is deployed to the production environment.
• In a shared services environment (one infrastructure and software stack running many different websites), the CMS will require strong RBACs to prevent partners seeing or accessing each other’s content.
• Only bring in the CMS you need.  When you only need content control over a few areas, its a viable option to leverage simple tools or just roll your own CMS.  This is where many companies make the mistake of bringing in an expensive CMS package and customize it versus just having a couple of web page authors making updates and handing the business a simple backoffice interface to update a few portlet's content.
• Ideally a CMS contains all service messaging, including error messages.  A service passes along a code for what information to display, the portlet looks up the information in the CMS using the code as a lookup key.

Web Pages

One thing that might feel uncomfortable with the above CMS definition is that the CMS only controls content as displayed in portlets rather than whole web pages.  It's ok, this should feel uncomfortable to some of you.  If you must enable end users to quickly and non-technically create and deploy new web pages to your site, your only choice is to look at a more traditional big boys CMS and hand your soul (and wallet) to the consultants to tailor the CMS to your business.  It means you're going to have to write a set of customized plug-ins for the CMS in the CMS's terms, usually something proprietary.  You may be able to hybridize your approach as well, and I'll cover that below.

However, if the view of CMS as a supplier of CMS oriented components/portlets and not necessarily whole pages is making sense to you so far, let's move into what that means for constructing web pages.

Web pages are requested by a browser.  The browser may pass in a number of parameters when requesting a web page to achieve an affect such as moving through a workflow.  Web page requests are received by the server.  The server identifies the correct page and processes it.  The pages are then handed to a customer’s browser, and processed further by the browser.

The server processes the web page by substituting custom tags with HTML and Javascript.  The custom tag methodology is provided by a custom tag framework as specified by the portal technology choices.

Web pages executing within a client contain a well defined and consistent interface to access dynamic functionality on the server.

Web pages are written by web page authors (aka designers) who specialize in HTML and CSS.  Custom tags aren't a big stretch for them but complex Javascript might be (they typically aren't programmers).  The closer these tags look to conventional HTML, the more effective the HTML/CSS web page authors are when using them.

A few best practices when considering web pages:

• Web pages typically contain Javascript.  A lot of Javascript in more advanced, interactive, dynamic web pages.  The Javascript should be encapsulated in custom tags or portlet and server side substituted into the web page definition using a custom tag interface.  Javascript should not be added to pages directly.
• Web page authors are most comfortable working with a whole web page inside an HTML editor as stored on a filesystem.  Submitting web pages into a database (that is, web pages pulled from DB, not served from filesystem) is painful.  Reformatting XML data extracts via XSLT is painful.  This is why web pages best live at the filesystem level and not inside of a CMS.
• Web pages are under version control and must be checked in and out.  
• New and updated web pages must be tested on a pre-production (test) environment prior to being placed in a production environment.  
• Web pages should be published to production in a controlled and audited way.  There should be a toolset that supports this activity to make a web page author’s life easier.  You might almost consider this a webpage level CMS, but with a different users and tighter production release style controls.
• The CSS is a web page concern.  Designers own the specification of what the CSS markup should do.  Portlet and custom tag developers own insertion of the CSS markup itself.  Developers and designers must work together via a "CSS Contract".
• The portal must force subordinate services to use a well-defined namespace for CSS use.

A Hybrid view of CMS and Web pages

If for whatever reason an expensive enterprise grade CMS with a recognizable brand is a hard requirement for your website, you have two choices:

• Write custom CMS plug-ins to integrate all the server side functionality you require to build the solution.  Be aware:
• What you build will most likely be non-portable to other CMSs in the future
• You've achieved vendor lock-in.  Vendors like this - you may not in the future.
• You're likely going to have to (re)train a group of developers to write the plug-ins for the CMS.  The big boys CMSs are big and complex and you're going to have to develop a lot of vertical knowledge to make them successful.
• Be prepared to bring in consultants specializing in the CMS to help your delivery team and operational support team.  Vendors also like this - your CFO won't.
• Be prepared to closely risk manage the new CMS technology risks (like any new, big, complex technology introduction) across your IT team and into the business
• The CMS controls the whole website page.  Designers must work with the CMS to create and update whole page designs using a proprietary approach.  Designers will be creating page "templates" which are then throw into a stable of templates that non-technical users access to create new pages on the site.
• Look at a hybrid view

What is the hybrid view?  Assuming you have the staff and dosh to make this happen, create two parallel delivery tracks.

Track 1 is about delivering a site using the way I've described above, with strong separation of concerns between services and portal, treating the CMS as a service.  The portal owns the web pages, specifies the technologies to be used to construct pages and support client/browser and server interaction.  Assuming you have a team of people that have done this before, risks are low, productivity is good, and the website comes into being rapidly.  Keep Track 1 focused on the core user journeys web pages and lightly stub all other pages.

Track 2 is about deploying the CMS, building up an understanding of it, and seeing what you can do with it while Track 1 is building the website.  To start with, Track 2 should focus on delivering content heavy and frequent content changes pages into the solution.  Track 2 pages should be covering off all those lightly stubbed pages you're creating in Track 1.

You then bring these two tracks together.  Ideally you can get to the point where the Track 2 CMS controls the content heavy, functionality light sections of your website, while the Track 1 website focuses on functionality heavy portions of the site.

To accomplish this, you'll at least have to write CMS plug-ins to functionally provide login, session, logged-in status, and one or more navigation blocks.  This will allow you to maintain the customer's login state as they move between Track 1 and Track 2 pages.

What are the benefits of the hybrid approach?

• Primarily, it's risk management.  The approach de-risks the use of a new, big, complex technology.
• Can get a basic up and running quickly, assuming you are building websites in a standardized way, using the separation of concerns as outlined in this blog.
• You can incrementally shift functionality from Track 1 to Track 2 based on growing depth of knowledge of both approaches.
• But you don't have to shift everything from Track 1 to Track 2 - you can take a balanced priorities, efficiency, cost view of how to evolve the two tracks.

Conclusion

Portal, CMS, and web pages are not the same thing.  Each has its own concerns.

Portals mix together various types of functionality to enable an end-user facing solution.

CMSs manage content and provide services to the portal to access content.

Web pages are the practical implementation of portal provided functionality.

If you architecturally mix the three together, perhaps to save initial coding time, you are creating extensibility and team scaling limitations for yourself later.  There is potentially nothing wrong with that - just go into it with your eyes open.