Content Markup

ThemesWiki.org is a new website designed to provide users with comprehensive, free guides for designing Web Themes and Templates. This site intends to ease the web design process by providing tutorials for a large number of systems at a common location.

To add granularity to the items in a given view that should be shown on a given list, you can either use:

1.  Taxonomy terms - has the disadvantage of being listed in the term listing for that node unless you do extra work to exclude the vocabulary
2. Re-purpose the 'promote to frontpage', or 'Sticky' settings already provide in Drupal - can have side-effects by affecting the promote and sticky features; since this is a 'misuse' of features
3. Views Bookmarks - This module provides the features of the above alternatives without the disadvantages of either option. The module enables the creation of multiple and virtually endless switches that can be restricted by roles allowed to use them, the scope of effect (users can create bookmarks that only affect what they see), and the node-type (CCK) that a tag/switch can affect. Most  importantly, this module closely works with VIEWS, and so the switches can be used to add more granularity to VIEWS queries without unnecessarily clouding Taxonomy or mis-using existing settings (Sticky, Promote)

Are you of the thinking that if something looks good is a respectable web browser such as Firefox, Safari, Opera, or Internet Explorer, then it is satisfactory (especially if the code also validates using the W3C validator)?
Have you ever tried to browse the web using a screen-reader such as JAWS or Opera Browser/Audible?

Building an inaccessible web
Content and application accessibility is not being regarded with as much importance as it deserves. Currently, too much focus is put on the lowest common denominator, and investing time and resources in features and implementation strategies that will get the biggest bang for the money and time is a commonly tolerated compromise. This Web Design and Development strategy is a direct result of letting business interests drive the way of the Internet. It is undeniable that the business community and capitalist market forces are responsible for the growth of the Internet from a scientific experiment, to the previously unimaginable medium that it is today. However, catering only to what will generate high dividends for share-holders can be lack of visions.

An example of this short-sighted drive to cater for the majority at the expense of the non-traditional and minority site visitor became clear to me in two situations where the CEO of a mid-size company asked this question when he was told that web applications built for the federal government had to be Section 508 compliant so that blind members of the public could use them: "Blind people do not read, and should they use the Internet?" In another situation, a senior project manager at another company remarked that to reduce server overhead, a new application would be built so that the last bits of XSLT logic to transform raw XML data to the UI (user interface) markup would be done in the web browser. When told about accessibility, and the use of non-traditional web browsers such as PDAs, text-only, and other browsers that are not able to parse XML/XSLT, he angrily responded that "We are building a rich application that will work with the latest browsers (IE6+, FF, Safari), opening the Web Application to non-traditional browsers is not part of this project and will have to be scoped separately as an enhancement"!!

The above-two are examples of some level of ignorance, disregard for Web Accessibility, and quick frustration with the otherwise meticulous process of making web sites and applications accessible. I cannot deny that it is slow, and anything but easy to attempt to code a site, and as opposed to previewing it in Mozilla Firefox or Internet explorer, to open up JAWS, or turn off the monitor and preview/browse the website/application without any visual information. This is also the biggest reason to make web-sites and applications accessible to blind, low-vision and otherwise disabled users.

No one can deny the the W3C placed and has continued to place importance and dedicate time and resources to developing the necessary techniques and infrastructure for designing and developing accessible websites and applications without compromising the eye-candy that we often rush for at the expense of accessibility. We therefor have very weak, or no reasons at all for not building accessible web applications and sites.

Currently, there may be relatively little motivation for business management to spend the extra time and resources required to make applications accessible. I once worked on a project that was launched despite my protests and warnings that the UI markup was not valid HTML or XHTML. The 'important' thing at that time is that the application was relatively stable and quite usable in Internet Explorer version 6, IE7, and Firefox. My protests seemed to many to be the passion or a lone and narrow-minded purist with little regard for the financial consequences of delaying the project so that the issues could be fixed and bring the web application to scope in terms of accessibility and code validity. The disregard for valid code soon begun to make the applications behaviour unpredictable, unstable, and difficult to quickly update because what initially seemed stable and usable became unstable when small changes were made

Skinning and templating Drupal with themesÂ

Beyond creating a customized Drupal theme or skin that does not look like any of the out-of-the-box themes that are supplied with the application, ideal front-end Web Design and markup aims to create valid, accessible, and semantic markup that is visually pleasing, light on the browser (high content to markup ratio), and is easy for search engines to crawl.

In a related article, I touched on creating a Drupal homepage without the 'Blog look' that had come to be characteristic and typical of dynamic websites created by technologically savvy 'geeks' with little or no motivation and interest to apply equal or at least significant attention to the visual design and SEO viability of the web content. Successful and ideal CMS (Content Management System) implementation is transparent in the front-end. Technology should be an enabler of client-side features as being an impediment and unnecessarily manifesting itself to the user.

Here is an outline of some objectives and important points to consider in order to create A Drupal theme that fills the above needs and objectives

1. Start of by creating a layout in XHTML markup without thinking or taking into consideration any structural limitations of the CMS, and Drupal in this case (Just to clarify, Drupal themes are fully customizable using a rick library of theming functions). Make sure that your markup is not bloated or unnecessarily verbose in elements and attributes because doing so will affect your markup to content ratio which has an effect on SEO and page loading-times
   
2. For Search Engine Optimization (SEO), make sure that you create physical order for your content that will enable the search engine crawler to sequentially find and crawl the page content before it gets to routine and repetitive sections such as static menus, disclaimers, site seals and other content-poor objects and page sections that might distract it or lead it to secondary pages before it gets to crawl the page in question.
3. It goes without saying that table-layout it an accessibility no-no, and it unnecessarily limits flexibility and slows down site evolution and updates. Apply CSS to create a visual layout of your content.
   
4. Once you are satisfied with your static XHTML structure and the tentative or definitive CSS that you have on it, you can add PHP snippets to replace markup region contents with Drupal elements by inserting region snippets in your layout. If you want to add more content regions to place your blocks, menus and other Drupal content items, you can create them in template.php (PHPTemplate Drupal template engine) as explained in a related document.
5. Save the file as page.tpl.php and go on to customise the structure and standard markup of the other template files such as node.tpl.php, box.tpl.php etc
6. The Drupal templating structure allow visually limitless customization of any theming function and feature without touching core or module files - Drupal Theme Developers Guide .

If you need custom assistance and Drupal theme development, please contact us so that we can create a Drupal theme based on your branding and design guidelines and needs