Curated by: Luigi Canali De Rossi
 


Sunday, January 9, 2005

Accessibility Requirements: Marqui CMS Review - Part IV

Sponsored Links

Marqui is an online-based content management system. I am on paid assignment to review and analyze their technology and this is my fourth article covering it.

fromMaestroCMStoMarqui_350.gif

In my introductory article I have set out the basic requirements that a Web-enabled organization would likely define when needing to tackle the effective selection of their ideal CMS solution.

Today, I am looking at the Marqui CMS from the specific point of view of how well it meets my reference set of CMS accessibility requirements.

As defined in Part I of this article series, these are:

a) Accessibility

b) Cross-browser support

c) Support for client-side functionality

d) Speed

e) Valid HTML

f) Effective navigation

g) Metadata

h) Support for multiple languages

In summary:

Accessibility requirements


Pages generated by the content management system must meet certain design, accessibility, usability, identity and design standards if they are to provide value to your users and profitability to your organization. It is therefore critical that the CMS supports, facilitates and streamlines the integration of such presentation design guidelines while guaranteeing accessibility and browser compatibility out-of-the-box.

Let me review here these accessibility requirements one by one:

a) Accessibility

The content generated by the CMS should be able to conform to one or more accessibility standards such as the W3C Web Accessibility Initiative (WAI).

Content produced by the default Marqui CMS can be made to be compliant with the major accessibility standards. Some features, like the Menu Builder, may facilitate some of this, though in general most of the work to make both navigation and site content compliant with accessibility standards will require custom coding work done on the site page templates.

The Marqui CMS does not output directly its own code but utilizes the code utilized to create the page templates. Therefore the old statement holds true across all of Marqui output related functionalities: garbage in - garbage out. If you place bad or incompatible code inside the page templates that will be utilized by the Marqui CMS so it will be the final output: bad and not compatible.

WAI accessibility cannot be sold as an out-of-the-box, automatic feature. It is achievable through manual customization. Therefore this is not a feature, nor an option for the Marqui CMS. It is simply an extra cost, as it is with many other CMS systems, for the end user.

More important accessibility issues for those who need to use Marqui as editors, writers, contributors.

The Marqui CMS Web-based management system is not friendly to Macintosh users of the system. This is due to the fact that the Marqui CMS uses FRAMES to allow access to specific content management facilities like:


  • Text formatting tool bar (ie. bold, italics, etc.)

  • Send test e-mail window

  • Version Compare window

  • Defining alternate workgroups window


Since Netscape and Internet Explorer for Macs restrict the use of FRAMES such facilities cannot be fully accessed with such browsers/OS combinations.

In the Marqui Help system as well as when accessing the Web-based content management interface, Marqui clearly states:

"For optimal performance, we recommend using a PC with Internet Explorer 5.5 and higher..."

IE_requirement.gif



b) Cross-browser support

Web pages generated by the CMS must be automatically viewable across all major browsers including Internet Explorer, Mozilla/Firefox, Netscape, Safari and Opera.

The Marqui CMS outputs content that is viewable through most browsers including Internet Explorer, Mozilla FireFox and Netscape.

Again, the effective coding of the page templates utilized inside the Marqui CMS is critical in obtaining pages that are more or less compatible with major browsers.

In my personal and small browser compatibility test, run on the Marqui.com site only Opera 6 on the Mac was not able to correctly display the PayBloggers page.

To see detailed screenshots of the test page across seven browsers and three different operating systems, please see this page.

cross_browser_test2.jpg

On the other hand, access to the management and publishing functionalities of the Marqui CMS do require use of Microsoft Internet Explorer. This is something that may create problems for the increasing number of organizations moving away from the IE standard. Access to certain critical functions such as the Menu Builder, cannot be managed effectively if not by utilizing the IE browser.

Today, any effectively accessible web-based application worth of this name needs to acknowledge IE rapid decrease in market share and the significant fast-growing existence of users preferring standards-supporting, non-Microsoft technology, to navigate the Internet.



c) Support for client-side functionality

The CMS should be able to support client-side technologies like Java, JavaScript, Flash as they may be needed.

The Marqui CMS supports Java, JavaScript, Flash and other client-side technologies can all be effectively supported by the Marqui CMS.

Marqui allows use of basically any code inside its page templates and therefore it is completely open to the web designers to identify the most appropriate and effective client-side technology to use for any specific application.

Unfortunately, no specific information addressing these topics can be presently found in the present online documentation and in the other support materials I have received access to.

Due to the Marqui CMS content management engine being based on a Microsoft server technology, Java, PHP and other code will not be displayed when previewing content.



d) Speed

CMS must be able to provide checks and controls that can guarantee maximum page size thresholds and automatic adjustments for where this happens. The CMS may also provide features that provides multiple versions of the a Web site optimized for either dial-up users and high-speed Internet connections.

The Marqui CMS does offer the ability to specify maximum amount of characters to be used for any of its content input fields. This provides a good degree of control in the maintaining editorial consistency and maximum page size within established limits.

tresholds_page_content.gif

On the other hand, there is no explicit feature allowing control of maximum file size for uploaded images, and no other relevant parameters to tightly control page size/weight and page download speed.



e) Valid HTML

The CMS must automatically generate clean HTML adhering to the official specifications. This ensures maximum compatibility across browsers and platforms.

The Marqui CMS, does not seem to be able to guarantee out-of-the-box valid HTML output without some intervention from the user. Once again, Marqui does not take responsibility for the page templates code but only for effectively managing the body content inside each page.

Just out of curiosity I have run a simple validation test on the very Marqui.com site utilizing the official W3C Validator. The results obtained clearly indicate that even at home and with the maximum technical support possibly available taming the content to follow-up established international standards may be indeed an issue.

I have personally submitted the Marqui.com Solutions page to the W3C Validator. And here it is what the Validator reported:

validate_results.gif
Validation results for Marqui.com home page

validate_results2.gif
Validation results for Marqui.com Solutions page



f) Effective navigation

Users must be provided with consistent, comprehensive and usable navigation aids.

The Marqui CMS allows the creation of complex menu systems while maintaining visual consistency across the whole site. The navigation support facilities provided are quite flexible and allow rapid changes, additions, modifications and use of customized menus on any page of a site.

Menu01.gif

What the Marqui CMS does not offer in terms of navigation support is the complement of a few more, much in-demand facilities, which have become staples of much simpler and more (economically) accessible CMS solutions. The most important navigation items that could be added to the present system are:


  • Breadcrumbs - A 'breadcrumb trail' is a row of links that shows, on top of a Web page, where the page is placed in context to the whole site an what is the sequence path required to move to other hierarchically relevant site sections from there. Each page will be more valuable as it becomes more explicitly aware of the context it is part of.

  • Related articles - A simple function allowing editors to associate more related content links to relevant articles (on or off site).

  • Internal search - Ability to search site contents and pick up reference titles and hyperlinks from within the editing/authoring interface of the system

  • Content clusters creation - Facility allowing automatic clustering and display of content based on their association with any of the following:

    • search

    • date range

    • content category

    • author

    • keywords

    • popularity

    • etc.

The Marqui CMS Menu Builder allows a pretty straightforward and simplified creation of complex menus within a rather uncomplicated (though not always intuitive) interface.

menu_builder.gif

With the Menu Builder it is possible to link and un-link pages and folders in any of the site menus and to easily re-arrange their display order. Once a menu item is selected, one can utilize the top and down arrows of the blue navigation gizmo to organize the order in which they will appear.

Menus and nested submenus can be easily generated and the system offers many alternative options affecting the layout (vertical, horizontal) and the formatting of them (text only, text and images, etc.).

menu_builder_automatic_output.gif

To be noted that navigation menus created with the Marqui CMS are output in an HTML table format though without the actual HTML table tags (which need to be added manually in the template). Pure CSS page support is not available.

HTML tables have been recently addressed as an antiquated and inefficient way of laying out Web pages. Here is some supporting reference:



g) Metadata

All pages must provide sufficient metadata to allow effective indexing and searching. This should conform to a standard such as Dublin Core.

Inside the Marqui CMS system it is possible to add metadata information to any content item.

The default set of metadata fields does not conform to the Dublin Core specifications but can be customized in any desired way.

The Marqui CMS offers a Metadata specific field in which the user is invited to type relevant keywords. Unfortunately, the support text next to the input area, appears to be misleading as it suggests that keywords input in this field will be used by search engines to give more relevance to the content inside search engine page results. As I have explained clearly elsewhere this is both untrue and misleading.

There is no other support for Metadata (description, author, copyright, etc.) within the Marqui CMS.



h) Support for multiple languages

If the CMS is to be used by editors working from different parts of the world and in different languages the CMS must easily support localization if not direct multiple language support right out of the box.

The Marqui CMS integrates the ability to add secondary languages rather simply (once you find where the feature is). When this is done a clone of the existing structure of the site is created allowing translators and language editors to start editing the existing content into the new selected language.

The Marqui CMS UI is presently available in both English and German, though some input forms in the content management UI can be localized to almost any language.

language.gif

Unfortunately the procedure and facilities to manage this function are not easy to find or well documented in the Help documentation presently available.

language2.gif

I have not been able to discover what specific languages and international character code sets are actually supported (I am for example interested in Arabic, Chinese, Russian and Thai: are these supported in the Marqui CMS? Where is some online information or examples that support this?)

(Though apparently UTF-8 is supported, while Unicode is not, I have not been able to obtain a final comfirmation from Marqui on this, yet):

No way for now to find out.




In the next Part (V), I will be looking at how well the Marqui online CMS meets the Business requirements set out in Part I.

Stay tuned.

marqui_man.gif

 
 
 
Readers' Comments    
2005-07-20 14:00:58

ian

This is the best (easiest) CMS I have ever saw!
Elixon CMS

Looks great!

ian



2005-01-12 15:51:47

Rok Hrastnik

Robin,

Great article!

But I wouldn't be so hard on Marqui:)

First, I haven't been actively working in the CMS field for about two years now, so I don't know the latest standards and approaches. So it is possible that there have been some drastic changes on the market.

However, I was previously working on the development (as the concept and functionality "designer") of an extremely flexible CMS, capable of powering practically any kinf od web site, with quite advanced features, especially in the field of "template" management.

Anyway, from the perspective of an ex-CMS "developer", I cannot quite agree with your evaluation of Marqui from the accessibility viewpoint.

A CMS usually does not generate HTML code "all by itself", but rather takes the HTML code stored in the various templates and then generates the output based on that code.

However, that code is prepared by designers and HTML coders, and actually has almost nothing to do with the CMS (except of course for the CMS specific tags and that it has to adhere to some of the rules enforced by the individual CMS; but these usually don't have much to do with accessibility, cross-browser support for end-users, valid HTML code etc.).

The "garbage in - garbage out" principle is valid for most CMS solutions, and most especially more advanced ones, since their clients need to have full control over the design, which means that they also have full control over the HTML code.

My point is that many of mentioned accessibility problems shouldn't really be taken as negative against Marqui.

Even more so, I take the fact that Marqui does not enforce HTML code as a positive, since as a client or web developer I want to have the power to develop my own web site in whatever way I want to develop it, which means I want full control over my "templates".

The only thing that Marqui could do in this instance is create better default templates ... but even that wouldn't help much with most clients, since at least in mid-sized businesses they need to create their own design and consequently HTML.

But if the CMS "pushed" its users with some pre-defined HTML code, that would be a drawback and not a positive, at least from my perspective.

Like I said, it's quite possible that some things have changed since I was last active in this market, so if any of the above is off the mark in "now and today", someone please correct me:)

Take care,

Rok



 
posted by Robin Good on Sunday, January 9 2005, updated on Tuesday, May 5 2015


Search this site for more with 

  •  

     

     

     

     

    2684




     




    Curated by


    Publisher

    MasterNewMedia.org
    New media explorer
    Communication designer

     

    POP Newsletter

    Robin Good's Newsletter for Professional Online Publishers  

    Name:
    Email:

     

     
    Real Time Web Analytics