Here's a summary of the feedback we collected.
Those of you who like Cascade...
- found the dashboard clean and intuitive
- liked the folders and the representation of pages in relation to parent, child, and sibling pages
- liked that it reminded you of Dreamweaver and the current WM Web Templates
- preferred the tree view in searching for links and assets
- found the interface more intuitive
The Cons:
- sunrise/sunset of a page limited to a single cycle
- the need to create folders for "children" pages
- can't preview pages you are linking to within the link management window
cannot upload external graphics “on the fly” (while WYSIWYG editing)(Retraction: You CAN upload graphics while you are editing a page in WYSIWYG)workflow creation required XML with hard-coded users/groups(Retraction: It does not require XML, there is a workflow builder, we did not see this in detail)- aggregating news into lists seems complicated
Those of you who liked RedDot ...
- liked it's image manipulation features
- found it easier to create "children" pages
- liked that you can check visually that a page you want to link to is correct
- preferred the internal search for finding links and assets
- liked the “Keyword linking” for aggregating news into lists
- liked how easy workflow creation seemed
- liked that a page can have infinite relationships (parents)
- found the interface more intuitive
The Cons:
- too many pop-up windows within editing
- no viewable folder structure to see relationships of pages
- requires IE for some administration
As far as the “cons,” we are looking into the implementation options of both products to see what we can address. Both Cascade Server and RedDot have some flexibility including plugins and customization options that we were not shown in these short and specific demonstrations.
Unfortunately, web editors, we still have a tough decision to make, and most unfortunate of all some of you may be disappointed. However, we take some solace in the scores we collected on this statement- “With training I think I can learn this product.” Where 5 = strongly agree, across all three of Thursday's sessions both Cascade Server and RedDot received an average between 4.3 and 4.75! We're convinced either of these products will do what we need and please remember whichever way we go, we intend to give you the training you need. So maybe we will meet after all.
posted by Mark Windley
14 comments:
I would also encourage you to take a look at these sites to learn about some of the features we could not cover in an hour and a half demo
http://www.cmsmatrix.org/ (nice side by side feature set comparison)
http://www.reddot.com/
http://hannonhill.com/
Red Dot's tag system makes it much more powerful I think, and that feature is not available in any other CMS, according to the presentation. I wish I could down-grade my rating for Cascade after the fact, because I strongly preferred Red Dot after I realized the power of the search function. It's especially because it's much easier to manipulate images when you insert them onto the pages in Red Dot.
I did not see the demos, but looking at the homepages above, the menu tab system on http://hannonhill.com/ is unusable in Firefox: The popup menus popup behind the froggy graphic and are therefore not viewable.
Do they use their own CMS to maintain their system? If so, why is there a such a defect on their front page. If not, why don't they use their own system?
Dave,
Sorry you missed the demos. They provided a great deal of useful information.
It's unfortunate that the Hannon Hill page didn't respond correctly in Firefox. Actually, all functionality of the Cascade product (the interface where you edit content) works in Firefox. This must be a CSS problem in the front-end template they designed for their public page.
In fact, you can see a demo of Cascade running on a Mac (with Firefox, I believe) elsewhere on their site: http://hannonhill.com/files/videos/product_demo.html
[Note, this demo begins with the "admin" user. Skip up to just over half-way to see what a content contributer would see under a "simplified" interface.]
Both RedDot and Cascade *can* use web-standards based XHTML and CSS for rendering cross-browser friendly websites. The system admins in RedDot need to use Internet Explorer on a PC for site management. But the average content editor within both systems can use Firefox on any platform to do their jobs.
I'll be posting some elaborations on Beth's comment as well, for those who may not have seen the presentations.
Thanks for reading!
--
Andrew Bauserman
Thanks, Beth, for the comment! I'm glad we have such loyal readers to respond so quickly.
You bring up three interesting features of RedDot and Cascade. I'd like to take the chance to review the differences between the two products, both for those unable to attend, as well as for those who may have been more interested in other features and find these to be less memorable after a week.
The main thing to remember is that of the dozens of products that made our "short list", both of these products can (and do, at other Universities) run university-wide web sites. The way in which each product addresses each CMS function differs; which is what we are currently evaluating for best "fit" for the College.
For a long-winded review of these features, see the articles tagged "CMS" within the re.web blog. For a better idea of all of the features we're looking at, I'll echo Mark in recommending the http://www.cmsmatrix.org/ site.
--
Andrew Bauserman
Hi Dave, I would guess they use their own system, but as far a page defects we can't really blame the product in this case- There are template design considerations and their choice of an external menuing system on the front page is unfortunate. I see many sites with the same problem (cbs.cportsline.com is one that comes and goes) as these external javascript/ajax libraries do have issues with some browsers and within some designs (div layouts, layers, etc.). To play devil's advocate why does RedDot have incorrect links on their Web CMS page (scroll down to the bottom and click on "More about Workflow" or "More about Asset Manager" and you are taken to the Site and Navigation Management page.) That's not a RedDot system problem. I guess it's another example of how much work keeping a large website accurate and error free is even with a powerful CMS
Keyword Tagging
In a previous comment, Beth mentioned RedDot's site-wide keyword tagging system, which is powerful, and different from other systems.
The power of the RedDot tagging system is in pulling tags across all sites. For example, an author in the English department could post an article and tag it as both English and Anthropology and cause it to appear on both the English and Anthropology news aggregation pages without further steps. The keyword system is site-wide, so the College would define the keywords once, and all contributors would be able to post their content under any appropriate keyword.
Cascade also uses taxonomies (defined vocabularies) for tagging content. It is commonly done by template and folder (e.g., within the English department's folders and pages). The Cascade method requires a bit more setup by our implementation team in defining a taxonomy within different sections of the site. But once defined, the end-user would interact with checkboxes next to each term in a very similar manner to RedDot.
It is also possible in Cascade to aggregate a term across multiple sections of the site; but the implementation team would need to define how these aggregations are done. For the example above, Anthropology would need to make a specific request that English stories with the term Anthropology appear within their aggregated lists of stories.
In either system, if a specific item is found to be useful in other places within our site, that content can be deliberately cross-linked, as opposed to being fetched by keyword. In RedDot, it is generally the author that selects where else on the site the item should appear, whereas in Cascade, the owner of the secondary location(s) decides to include within his or her section external items. So, both systems allow content reuse, but implement it differently.
To recap the differences: The "power" of RedDot is in having a single site-wide keyword system prebuilt so that it is easy to build pages that catch any given term(s) with little back-end customization. The "power" of Cascade is in the fact that every template and folder can have it's own data definitions (XML) with extensible metadata, such as keywords. The specifics about who is responsible for making content reuse happen is also a difference.
If you were unable to see the presentations last week, hopefully this explanation will spark some ideas about what will be possible in our new web environment, implementation details aside.
--
Andrew Bauserman
The power of the search function
In a previous comment, Beth raised the issue of Search within the CMS. For those not at the presentations last week, I thought it would be good to explain the different approaches each product uses.
First, we are discussing searching for content within the CMS editing engine itself. This is separate from any search capability that we will deploy for the public web server.
In RedDot, to find a page to edit, you can either search for the page, or navigate to it through a WYSIWYG representation of the site.
In Cascade, to find a page to edit, you can also search for it, or navigate to it through a WYSIWYG representation of the site. But you may be more used to finding pages through a folder structure representing where the page exists in the site (similar to how Dreamweaver shows folders and pages in a side pane).
In RedDot, when you want to add a link to a page, you find the desired linked page using the search tool. You can click next to a search result to popup a window showing that page (to be sure it is the one you intended for linking). Since search is a vital component to linking of content, RedDot has tuned the search function to look in a pre-defined set of fields within each page to find the terms you type. Additionally, there are advanced options to the search to narrow the results further as needed.
In Cascade, when you want to add a link to a page, you are presented the folder-view of the site from which you can select a page. If you do not know the page you want, you have to find it somehow. There are two common methods: You could open another window or tab in your browser and find the page on the live web site. Since the URL mirrors the folder structure, it is trivial to find the page in the system when you know the URL. The other option would be to save the current draft you are typing, and use the search function in Cascade to find the page you are thinking of. Then you have to go back to the page you were editing and add the link.
The Cascade search, while outside of the linking process, is actually somewhat similar to RedDot's. The search box is at the top-right of the user interface, and also returns results from a predefined set of fields of pages within the system. Also like RedDot, the search page has Advanced options for narrowing results by specific terms within specific fields.
To summarize the main differences between RedDot and Cascade:
* RedDot users *must* use the search tool to find pages for linking within the system. A preview of the search result can be popped up in another window for verification.
* Cascade users *must* use the folder structure to find pages for linking within the system. To preview the page, you would need to open another window or tab manually (the URL for the page being it's folder path).
* In both systems, you can use search or WYSIWYG navigation to get to a page you want to edit. In Cascade you can also choose to display the folder view side panel as a method for finding a page to edit.
--
Andrew Bauserman
Red Dot actually looks like they make use of their tagging data in the semantic-web enabling page headers like {meta name="keywords" content="web content management, cms, enterprise content management" /} which is an encouraging sign for a information architect.
I really don't have a dog in the fight about which CMS system to choose, I've worked with web site maintenance since 1996 and agree with many of the concerns expressed on the blog. My skepticism about the re-web process has to do with the 'transience' of the web, how you relate to old content, and how 5 years hence the future http://www.wm.edu/ will relate to the current effort. If the current http://www.wm.edu/ is so poorly designed that it requires a re-web, how are you ensuring that effort put into this reengineering will not become similarly obsolete?
I'm also skeptical about the meaning of WYSIWYG editing in a world with CSS. WYS won't be WYG if anyone makes use of the re-skinning benefits of a CMS.
Aside from those concerns, making it easier for content owners to maintain their own content is a very important feature of a CMS. If it is left to designated web editors rather than the owners, the content quickly grows stale.
Manipulate images
In a previous comment, Beth raised the issue of manipulating images within the CMS. For those not at the presentations last week, I thought it would be good to explain the differences between the products relative to image manipulation.
The Global Image installation of RedDot includes a module called "Asset Manager" which we would likely negotiate into our purchase of the product if we choose to go with RedDot. The asset manager allows you to upload, crop, resize, and otherwise manipulate an image, as well as preview thumbnails of your images as you browse for the right one to place on your page. It isn't intended to replace PhotoShop, but does provides a useful tool as you upload images to your site. [RedDot also provides for users who want to learn to do image manipulation via command line. See: http://www.imagemagick.org/ ]
One other feature of RedDot's Asset Manager module is that it can be popped-up on top of the page editing screen, which means you can upload an image during the page editing process.
Cascade's standard install includes the ability to browse your images by thumbnail. But it does not provide an interface for you to manipulate your images after you upload them. Nor can you upload an image from the page editing screen (you have to save your draft edits, then upload the image, then return to editing the page).
On the other hand, Cascade does have a free plugin that provides for the system to manipulate the image when you upload it (using the Java Imaging API). For instance, there is a sample "asset factory" that allows a user to click "New image with thumbnail". The user chooses a file to upload, and the system saves appropriately sized "large" and "thumbnail" version of the image in the correct folders. The notion of an "Asset Factory" is really something unique to Cascade. It requires the Implementation Team to do more work in creating the "behind the curtain" machinations; but allows the user to create objects that will work within certain templates without user manipulation.
There is a third party add-on for Cascade that allows inline editing of images. Since this is a third party product, we may or may not be able to include it in the price if we purchase Cascade server, and would have to look into it further if we decide to pursue Cascade as an option. But the video demo is available on Cascade's site.
So which system is more "powerful"? Like when we described the "power" of the keyword feature, it depends. They are very different.
I'll sum up the differences again:
*RedDot's "Asset Manager" add-on allows the contributer to perform manual manipulation (crop, resize, etc.) of images after they are uploaded. Images can be uploaded during the editing of a page, without leaving the page.
*Cascade allows the system admins to create "Asset Factories" that do image manipulation (usually resizing and thumbnail creation) during the upload process. The ability for users to manipulate images would require a third-party add-on. Images need to be uploaded separately from the page edit screen before they are placed on a page.
* Both systems (assuming we'd get the RedDot Asset Manager) allow users to select images by thumbnail for placement within a page.
I hope this is helpful. What other features did folks see (or wish they had seen) that you'd like to see addressed in a side-by-side like this?
I see Dave X has raised the issues of Metadata and WYSIWYG - maybe I'll tackle those next :)
[Transience I'll try to address elsewhere, as I don't think either product adds anything over the other to that discussion.]
--
Andrew Bauserman
Corrections:
An Excuse: The RedDot and Cascade CMS products are both really powerful and feature-rich systems each being used by a variety of University sites. Such enterprise systems are complex, and discovering and comparing their features is not always easy...
An Apology: Yesterday I attempted to summarize the differences we saw in the demos of RedDot and Cascade last week. Today I have pie on my face, and need to correct a few points, noted below as [corrected]...
Re: The power of the search function To summarize the main differences between RedDot and Cascade:
* RedDot users *must* use the search tool to find pages for linking within the system. A preview of the search result can be popped up in another window for verification.
* [corrected] Cascade users may use the folder structure OR the search function to find pages for linking within the system. To preview the page, you would need to open another window or tab manually (the URL for the page being it's folder path).
* In both systems, you can use search or WYSIWYG navigation to get to a page you want to edit. In Cascade you can also choose to display the folder view side panel as a method for finding a page to edit.
Re: Manipulate images I'll sum up the differences again:
*RedDot's "Asset Manager" add-on allows the contributer to perform manual manipulation (crop, resize, etc.) of images after they are uploaded. Images can be uploaded during the editing of a page, without leaving the page.
*[corrected] Cascade allows the system admins to create "Asset Factories" that do image manipulation (usually resizing and thumbnail creation) during the upload process. The ability for users to manipulate images requires a FREE add-on which IS available directly from HannonHill. Images CAN be uploaded directly from within the page editing screen without navigating elsewhere.
* Both systems (assuming we'd get the RedDot Asset Manager) allow users to select images by thumbnail for placement within a page.
Sorry for the disinformation yesterday. You can bet that we are redoubling our efforts in questioning everything we have learned about BOTH RedDot and Cascade to make sure that our deliberations are based on reality and not a distorted perception of reality. I'll let you know if we need to make any further corrections...
--
Andrew Bauserman
Hello to Dave X and others who may be reading these comments yet were unable to attend the CMS demos! We'd welcome the chance to talk with you about your ideas for re.web and your thoughts on the two CMS choices. Please send me an email at sevans@wm.edu to set this up. This forum is outstanding and very useful to the re.web project team ... but an in person discussion over coffee is something we'd like to do as well.
Hope we hear from you,
Susan T. Evans
Chair, re.web Project
WYSIWYG
In case anyone is still following this thread, I thought I'd finish out the open topics raised by dave x.
For those who missed the presentations, here's the scoop on WYSIWYG (What you see is what you get) editing within the two CMS products... Both RedDot and Cascade have built-in WYSIWYG Editors that will work in both IE on Windows and Firefox on Windows/Mac/Linux.
Dave X brought up the good question - how WYSIWYG can it be if we are using CSS to separate content from design? The answer is pretty similar for both products. In both RedDot and Cascade, a fully navigable preview of each page is presented to the content contributor prior to editing (this means you can click on links to see other pages in either system).
Both systems also offer 2 methods for editing: Form and Inline editing. (For those who attended the sessions, Kevin demonstrated these a bit differently between sessions, so you may not have seen both ways in both systems, depending on which session you attended.)
Form editing presents all of the content, metadata, etc. for the page in a set of boxes all on one screen where you could edit both the Title and the Body Content at once. In this view (in both products) the WYSIWYG Editor on the Body Content is showing you your content with inline styles (bold, underline, links, etc.) but not the "wrapper" of the template around the content. It is probably less WYSIWYG (not exactly what you will get) and more of an XHTML word processor (you click buttons instead of writing code).
Inline editing differs a bit between RedDot and Cascade. In both systems, you find the content to edit and click a symbol to edit that section (e.g., Body Content).
In RedDot, the symbol is a red circle (dot) that might be next to the content itself, or at the bottom of the page, depending on our choice of implementation. This dot appears after you click the dot to open the page for editing. Clicking the dot for the Body Content pops up another window with just the the Body Content within the WYSIWYG Editor. In this case, you can see what the page will look like in the underlying window, but the new window shows just the content without the "wrapper" of the template and stylesheet. Again, sort of an XHTML word processor. When you save your changes, the popup window goes away, and the underlying window is refreshed to show you the preview as modified.
In Cascade, the functionality is very similar, but the mechanics are a bit different. The symbol to click looks like a small icon of a sheet of paper, and it also takes 2 clicks to get into edit mode (1 click opens a drop-down by the item, with "Edit Inline" as a choice). The page then changes to show a preview of the page (the "wrapper" of the template) except the Body Content area, which is replaced by the WYSIWYG Editor. Again, the actual Body Content inside the WYSIWYG box is not really being shown in it's true font or style - it's again more of an XHTML word processor, only this time the editor is displayed inside the rest of the page where it is being displayed.
In the end, there is little functional difference between the products in this area.
--
Andrew Bauserman
Metadata:
This is (for now) the last of our responses to comments about the RedDot and Cascade CMS demos last month... Unless anyone brings up further suggestions for elaboration - and more excuses for my long-winded writing.
For those who missed the presentations (or those who didn't notice this feature as it flew by), both of the CMS systems under review support the use of metadata.
There are many types of metadata, and a few other bits of page info I'll throw in while we're comparing things.
Titles and DisplayNames: RedDot and Cascade use different terminology, but generally provide for pages to have a set of names - the name that shows up in the top bar of you Browser's window (and in bookmarks, etc.); the name that appears as a headline above the page's content; and the name for the page when it is listed in menus and/or breadcrumbs. The boxes for typing in these values live in various places between the systems, but both have the capability to support these.
Filenames: Both RedDot and Cascade will automatically assign filenames as a page is created - and the editor can override this name in either system by clicking on a tab across the top above the preview portion of the screen. If you choose not to assign a filename, RedDot will assign a numeric identifier (the URL might be: http://www.wm.edu/news/archive/342.html ). Similarly, Cascade will generate a name from the Asset Factory name with a number added to the end (the URL might be: http://www.wm.edu/news/archive/pressrelease42.html ). Of course, we are not stuck with these names, since the user can override it. Also, there may be processes to automate the creation of "pretty" filenames - for instance Cascade provides a free plugin to make a URL-friendly filename from either the Title or the DisplayName of the page.
Description and Keywords: Both systems allow for metadata to be provided in the HTML "description" and "keyword" meta tags. These can be pre-populated by the choice of template, or supplied from CMS metadata when the page is published. This is still considered standard practice on most sites, although the search engines no longer trust them for indexing purposes.
System Keyword metadata: Both systems provide for keyword metadata tagging, as addressed previously. To review, RedDot has a prebuilt system-wide keyword utility where the CMS administrator can easily create the list of keywords. Then each editor simply checks off the appropriate keywords from the list within each page. Cascade opts for defining all metadata (including keywords) in the XML schema at the template or folder level. As an editor, you might still see a list of keywords you can check off for each page - but the list might vary across folders and templates. The "power" of one system is that it is prebuilt and provides a consistent list of words easily pulled across the entire system. The "power" of the other is in having unique keyword lists at the folder and template level which may not be applicable to other departments.
Other metadata and block data: Both systems also allow the definition of certain types of data within each template. For instance, a certain page type may have specific fields for contact name, email, and phone number. In both systems, the editor would fill these data boxes with the appropriate information. If a page needs multiple sets of contact information, both systems handle this, although in their own ways. In RedDot, the template or block definition would be built with the maximum number of repeated items (e.g., name2, email2, phone2, etc.), and be styled to hide empty data blocks. In Cascade, data blocks can be flagged as "repeatable" in the XML schema (with an optional maximum number), which saves a bit of pre-building if we find repeated regions in multiple portions of our site. In any case, both approaches produce the same visual page when rendered to the public web server(s).
Metadata can incorporate many other bits of data, such as:
* dates (created, last-modified)
* users (created by, modified by)
* relationships (folder, parent page)
and just about anything else we want to associate with individual pages.
The serious work for all of this is in the implementation process: creating templates, keyword lists, metadata fields, repeated data blocks, and various other assets and processes.
--
Andrew Bauserman
Post a Comment