Eureka!

Hasn’t it always bugged you that you could never do a LIKE clause with multiple criteria? I found this very limiting, especially so when dealing with multi-valued parameters in MS Reporting Services. I believe to have found a way around this! (I haven’t seen this method used anywhere yet, but I’m sure many of you may be familiar with it.)

In order to make this work, we need to use some association. You will have to create a (temporary) table in which to store your criteria, complete with wildcards. Each criterion should be a separate record. From there we JOIN our target table, which we are comparing the criterion with. Furthermore, we will place a limiter on the JOIN to only allow the selected criteria. This last step is only necessary if your criteria are based on a lookup table (presumable the same one you are using to JOIN) and of which only a subset is selected (that is my situation in one of my reports in MS Reporting Services).

Note that the items in [table A] must be stored with their wildcards, i.e. ‘%criterion1%’, ‘%criterion2%’, etc.

Let’s pseudo-code this out:

1. CREATE TABLE [table A] with criteria to be used in LIKE clause.
2. JOIN criterion table to main table [table B].
3. Limit JOIN to LIKE clause using field [field B] from [table B] and field [field A] from [table A].

Now for some code:

SELECT *
FROM [table B] AS b
JOIN [table A] AS a ON a.[field A] LIKE b.[field B]

If you are using [table A] as a lookup table to establish criteria on a report, of which only a subset may be selected, do the following:

SELECT *
FROM [table B] AS b
JOIN [table A] AS a ON a.[field A] LIKE b.[field B] AND a.[field A] IN (@report_parameter)

where @report_parameter is the resultset from a query, or a comma-separated list of items that exist in [table A]. This is analogous to:

SELECT *
FROM [table B] AS b
JOIN [table A] AS a ON a.[field A] LIKE b.[field B] AND a.[field A] IN (’%criterion1%’, ‘%criterion2%’, ‘%criterion3%’)

Think of layout as the blueprint of a manufacturing building, where the production lines of each department provide individual products of value. Taking all these products and combining them into a new product produces even greater value than the sum of all the parts (Gestalt theory). Now, if you optimize the layout of the production lines in such a way, that a minimum of effort is needed to derive the end-product from the assembly of the parts, then you have heightened efficiency, decreased time to delivery, and upped your return on investment.

This analogy holds just as true for web sites. Careful and proper placement of page sections (like navigation bar, footer, side-bar, header, etc.) will ensure that the user has a very low click-to-experience ratio, as well as providing high scores in readability, ease-of-use, and conveying the content.

Design Requirements

It is in the designer’s nature to control every aspect of the design. This is to ensure that the feel and flow of the layout is experienced as the designer intended. Often designers will want strict sizing and positioning of page sections and elements. You will see that this is often in direct conflict with the development and even best practice requirements for web sites.

Also, the designer will often want the page to look exactly the same, regardless of browser or operating system it is viewed on. Unfortunately, if this is the case, the designer will most likely not allow for graceful design degradation for non-compliant browsers.

Development Requirements

Ease of maintenance is a top priority for the developer. To this effect they will want to place the layout specification in a separate CSS file. This will ensure that any layout tweaks or complete reorganizations can be done simply by creating a new layout CSS file. Additionally, standards-compliant code is extremely important for maintenance purposes (non-standard-compliant code will not be valid in the future and may break functionality as new browsers emerge) and user experience.

Another important aspect is that the layout specifications should be such that they are applicable to all technologies trying to read it. This means that the layout should apply, or degrade gracefully, in all viewers (like browsers, Palm devices, PDAs, Blackberries, iPhones, etc.) in such a way that will not trigger any errors or impact functionality. If the layout does degrade due to the limitations of the viewer, then it should render page sections in an order that makes sense to the user, and not scramble the copy, or reorganizes it in such a way that makes reading the copy difficult.

Best Practice Solution

Define your target browsers

Before you even start coding, define a set of browsers you want to target. Your goal is to provide a complete experience within these browsers without degradation of layout, design, or functionality. Develop your layout CSS with these browsers in mind, constantly testing in each one to make sure the experience remains constant. Also, don’t be afraid to let the user know which browsers you have optimized for, and what versions thereof you support without degradation.

Be Accessible

Make your layout accessible to impairment-assisting technologies. For the most part this means arranging your layout in such a way that rendering without CSS applied still appears logical and can be understood by someone using a screen-reader or braille-screen.

Purpose-Driven Layout

Create page sections that make sense for the contain they hold. Do not create new page sections for the same type of content that is held elsewhere. In short, this means: do not create two footer sections, for example; consolidate and optimize. Your users will expect each section to have a specific purpose and multiple sections with the same purpose only aid in confusion.

However, if you place individual content items in their own boxes, or areas, that can appear to be separate page sections, style them similarly to each other, and different from other sections. That way your users will immediately identify them with their proper purpose.

Consider Alternative Technologies

Should your design team insist on fixed layout that doesn’t accommodate all technologies that might view it (blackberries, iPhones, zooming, etc.), urge them to consider different technologies that are geared more towards that type of medium. Flash or Silverlight applications for example.

Closing Thoughts

None at this time.

Bibliography

Cederholm, Dan. Bulletproof Web Design: Improving Flexibility And Protecting Against Worst-Case Scenarios With XHTML And CSS. Berkeley: New Riders, 2006.

Usborne, Nick. "Design Choices Can Cripple A Web Site". A List Apart. 8 November 2005. A List Apart Magazine and the authors. 20 February 2008 <http://www.alistapart.com/articles/designcancripple/>.

Koch, Peter-Paul. "Fluid Thinking". Digital Web Magazine. 2 October 2002. Digital Web Magazine and its authors. 20 February 2008 <http://www.digital-web.com/articles/fluid_thinking/>.

Unknown. "Variability In Web Page Displays". Web Developers Notes. Unknown. Web Developers Notes and its authors. 20 February 2008 <http://www.webdevelopersnotes.com/design/variability_in_web_page_displays.php3>.

Unknown. "A Theme For Your Site". Web Developers Notes. Unknown. Web Developers Notes and its authors. 20 February 2008 <http://www.webdevelopersnotes.com/tips/webdesign/a_theme_for_your_site.php3>.

Other References

None at this time.

Document History

[v0.0.1.20FEB2008] - Document created.

[v0.0.1.25FEB2008] - Initial draft and publication.

What’s a site without a page, right? Or, if you are a fan of Gestalt theory, you will know that the whole is greater than the sum of its parts. The same goes for web sites: your site will only be as good as the underlying pages. However, the impact that a single page has on a user is exaggerated by the experience of the site as a whole. Should a mistake on a single page cause the user experience to be affected then this experience is extrapolated to the entire site.

In the overall view of all things web, the page is second important only to the site as a whole. Because of this, pages need to be developed with consistency across the entire site. Common elements (like navigation tools, headers, footers, and side-bars) need to be in the same location and maintain the same appearance and functionality, providing the user with a tangible and familiar interface.

Problem

As web page visitors we all have encountered web pages that did not perform under various circumstances and technologies as intended. These are most often caused by web applications not being developed with W3C standards in mind, however, even if W3C standards are enforced, some browsers just won’t behave and break then as well. Here some tuning is necessary to support these browsers to make the site at least functional.

We often can also see problematic implementation of various features, like frames, pop-up windows, breakage of basic navigation functionality (back- and forward-buttons), loss of session information, and much more.

Other problems also arise when inappropriate delivery methods are used for various media, like embedded media that rely on specific technology or software on the client computer, interactive functionality, poor implementation of design elements, improper form validation, dead links, and JavaScript errors (resulting from JavaScript coded to specific browsers).

Design Requirements

For the designer the web page presents itself as a canvas. It is the area available to them with which they can present content in a manner they deem best for the given circumstances. However, that is much more an issue of Layout & Design, rather than the web page itself.

The designer does not have any inherent requirements of the web page as it is merely a medium. Their sole involvement is creating the overall design for the specific web page.

Development Requirements

On the contrary, the developer will have many requirements in intents with the web page itself, as it is the developer’s role to manage and build the architecture and code behind a web page. For the developer the web page is the user interface for a predetermined purpose.

Developers are responsible for implementing the proposed design in such a manner that it will be accessible, maintainable, extendible, and feasible.

Accessibility

DocType

The DOCTYPE will ensure that browsers interpret a web page in (nearly) the same manner. This provides consistency, and ultimately greater accessibility, to your web site. “But I have a DOCTYPE in all my pages, yet it doesn’t seem to make a difference!” you protest. The absence of a well-formed (that’s the key here: well-formed) DOCTYPE tag will throw browser compatibility out the window without even having parsed the first line of code. If the browser does not encounter the DOCTYPE tag before the HTML tag, it will revert to its bad old quirky self and render content on its proprietary DOM and CSS interpretations. This is especially prevalent with Internet Explorer and Netscape. There are three DOCTYPE declarations that work, at the moment (there may be more in the works, but these are the established ones):

HTML 4.01 Strict, Transitional, Frameset

   1: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>

   2: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>

   3: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Frameset//EN” “http://www.w3.org/TR/html4/frameset.dtd”>

XHTML 1.0 Strict, Transitional, Frameset

   1: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

   2: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

   3: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>

XHTML 1.1 DTD

   1: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>

Adhering to these DOCTYPEs will ensure that your page behaves properly, and most of all, as expected. “Using an incomplete or outdated DOCTYPE—or no DOCTYPE at all—throws these same browsers into “Quirks” mode, where the browser assumes you’ve written old-fashioned, invalid markup and code per the depressing industry norms of the late 1990s.” (Zeldman).

Maintainability

For a web site, or web application even, to be successful, it needs to be easily maintainable. The developer needs to be able to address the issues at hand without having to jump through hoops, and roll them out quickly and easily. At the base of maintainability is clean code. It doesn’t have to be quick, minimalistic power-code that will run a space station; the code can be as efficient or as inefficient as the abilities of the developer(s) permit. The main thing is that it is clean and consistent.

Feasibility

Technical

The most obvious issue here is the lack of technical knowledge by the employed staff. In these cases management will most likely realize the department is lacking in skill-sets and take appropriate measures, such as out-sourcing or hiring contractors to supplement the existing staff.

The second issue is the lack of technical equipment to make the project a success. For instance, if you don’t have web servers to host the web pages on, the feasibility depends on the restrictions of your hosting provider, or on the (non-) ability to hire an appropriate hosting provider.

Resource Availability

Probably the most determining factor as to how well-designed your web application will be are the availability of resources. This means specifically: time and money (anything else is a derivative of the two).

Given that a lack of resources will require constraints on development and implementation, they will most likely be sacrificed in the planning stages. This means that documentation will be greatly reduced, if not eliminated entirely, and development will be off the seat of the pants. This opens huge risks for the following:

• Scope creep, which can turn the project into a never-ending disaster.
• Bad coding, which can manifest itself as spaghetti-code, inefficient functionality, duplicate code, and improper implementation of functionality.
• Unorganized project files, caused by various developer creating and organizing their portions of the project to their own standards.
• Drop in communication levels, causing the various elements of the teams to splinter apart, and start “fighting” for their own needs, instead of working from a common agreement (the documentation).

Any of these items (and there are more, as well) may bring the project’s feasibility into question. However, because shortcuts are being taken, it is highly likely that a feasibility inquiry isn’t even considered.

Extensibility

When developing the web app, careful consideration must be given to extensibility. Despite what is given by the requesting entities as requirements, even if they say it is a one-time effort, it still needs to be managed, updated, and often upgraded with new functionality.

Keeping that in mind and developing for extensibility will also ensure that any updates and tweaks can be performed quickly and efficiently, even if a different team (who have little prior knowledge of the product) is performing these tasks.

Best Practice Solution

Code

Handicap Accessibility

Many viewers user screen readers that product audio (blind) or tactile (deaf and blind) output. These technologies should be supported under all circumstances, and take very little extra effort to implement. The main thing is being aware of the required tags, attributes, and usage conventions that they take advantage of and adhere to.

DocType

Of the various DOCTYPE examples shown earlier, the one that is most robust and should be used is the XHTML 1.1 DTD. This DOCTYPE will require that your code is completely XHTML compliant (yes, this also means that you can / should not use depreciated tags if you want your page to validate). This alone will force cleaner coding, as well as more attention to detail when planning the site.

Conventions

The developer(s) should adhere to a pre-establish set of rules and guidelines that govern the coding conventions. This includes variable naming, upper- or lower-casing, indentation, use of braces, brackets, and parenthesis, and so on. It really isn’t a question of adopting an industry standard (however, it is preferable, as it is more likely to be recognized by new developers coming into the team), the important part is that the entire team adheres to it. This alone will make code easier to read and understand, because consistent conventions are being used.

Layout & Design Implementation

Layout

The layout specifications of a page should be consistent throughout the entire web application. This demands that a common layout specification be made accessible throughout the application. This ensures two things: consistency and one central maintenance point. Layout and design are also to be separated from content and function, again optimizing maintainability. As of the time of this writing CSS is employed both for layout as well as design purposes. However, the layout specifications should be kept in its own CSS file, as this provides versatility by allowing the entire site’s layout to be reconfigured by simply swapping out one file. (Keeping it mingled with the design CSS would obviously complicate things, as you would then also have to redo the site’s design, or theme.

Design

Just like with the layout CSS file, the design CSS file is meant to provide a consistent look and feel to the web site. However, you may very well have different design CSS files for your application, allowing for varying themes (possibly by section of the site, or by user preference). Each unique theme should have its own design CSS file to allow for easy design management. This will also let you test multiple themes side-by-side when developing the site without have to redo the design CSS file every time you make a change.

Content

The page’s content is just that: meaning conveyed through text and imagery. Content is what is left when you strip away all the design, layout, and functionality.

One option to take under consideration is also the implementation of alternative delivery technologies, depending on the requirements for the site. For example, if there are strong design-requirements where the site must look a certain way for all users, regardless of browser and platform, some thought and consideration should be given to using Flash or Silverlight (just two of many emerging alternatives) to serve up the application.

This is because HTML was originally developed to deliver text-based documents over the Internet. This means that it was never designed as a delivery method for graphically intensive sites. This also means that there will be rendering issues with different browsers, as currently each browser adheres with varying success to W3C standards. Often the purpose of the site, as well as the target audience will help in determining the delivery method to be used.

Head

The <head> section of the code contains meta-data about the content and delivery of the page, as well as title and keywords used to identify it and promote it using SEO (Search Engine Optimization) methodologies.

The <head> should also contain any JavaScript includes that are used site-wide (page-specific includes should only be included on the pages in question as this conserves bandwidth). You also need to specify the various style sheets to be used. Typically all style sheets that are used throughout the application should be included (they do not take up much bandwidth).

Body

The <body> tag / section contains the elements that will be rendered to the browser. This means it contains the raw data (formatting occurs via the style sheets) for the content to be displayed on the given page.

Business Rules (Functionality)

Client-Side Processing

Any client-side code should be implemented to fulfill the following criteria:

• Editing form fields (while saving the new values will inevitably be server-side).
• Form validation (as well as server-side).
• Dynamic hiding and showing of page elements.
• Any other dynamic page changes where no database requests are necessary.

Any client-side processing should be implemented to support speed and efficiency, which has a great impact on user experience.

Server-Side Processing

Server-side processing mainly fulfills data interaction functionality, as well as new page requests. You’ll want to place the following functionality in server-side code:

• Form validation (in addition to client-side to prevent hacks).
• Saving form data.
• Processing external information.
• Reading from database and populating page elements.
• AJAX and JSON functionality.

Closing Thoughts

None at this time.

Bibliography

Zeldman, Jeffrey. “Fix Your Site With The Right DOCTYPE!”. A List Apart. 12 April 2002. A List Apart Magazine and the authors. 30 January 2008 <http://www.alistapart.com/articles/doctype/>.

Other References

None at this time.

Document History

[v0.0.1.15FEB2008] - Initial draft and publication.

Over the past several years I have been involved in all aspects of web publishing, both from the design end, as well as the development and database sides. Over time I have recognized methodologies and standards (best practices) that will provide a higher level of functionality, easier maintenance, and cleaner design.

However, there is often a tug-of-war that I have always experienced, where ever I have worked, between design and functionality. Often times the designers are married to their ideas and layout, not realizing that they are compromising functionality, versatility, and extendibility.

My goal with this series of articles on web best practices is to codify a set of best practices that will allow for both maximum functionality, as well as a maximum level of design control. Over the next few weeks I will be writing articles on the various elements of a web page and how best practices can be applied to them. These include (but not limited to) the following:

• The Web Page
• Layout
• Design
• Functionality
• Server- & Client-Side
• Content
• Navigation
• Menus & Trees
• Headers
• Text
• Links
• Tables
• Charts
• Pagination
• Tabs
• Web Forms
• Validation
• Radio Buttons
• Check Boxes
• Text Boxes (and Areas)
• List Boxes
• Select Lists
• Buttons (Text, Image, Submit, Reset)
• Labels
• Dates & Times

Once all these best practices (more will be added should the need arise) are spelled out, one should have a clear set of standards that both design and development teams can adhere to. It should provide an agreeable set of rules, a common link that ensures that both design is not limited by technical constraints, as well as functionality not diminished through design constraints.

Why perilous? Because of the “war” between design and development. If designers had their way, they would control every detail without regard to functionality. Every designer I have met has always wanted to revert back to styling principles used in print. My goal is to show why this is not feasible, nor desirable with web sites, and why a more principled and best practice approach will provide a more appealing design.

While there are countless of extremely well-written and applicable best practice documents available, these all apply in their own right. However, my goal is to develop a comprehensive set of guidelines that will be universally applicable for all aspects of web development: a codified set of principles that will ensure that my web application is the best it can be at all times.

Each Best Practice article will contain the following sections of discussion:

1. Overview
2. Design Requirements
3. Development Requirements
4. Resulting Best Practice
5. Benefits
6. Drawbacks
7. Thoughts
8. Bibliography
9. Other Resources

As each article is published it will also be added to a master document that will be available for download from this article. Additionally, I will update the listing of best practice discussions above to link to the respective articles as they are completed. As I post each article, I will gather and evaluate comments and feedback, as well as my personal thoughts, in the second-to-last section (7) of each article to provide a reference point with common concerns.

One thing that has always bugged me in the past was that Windows Update, Sharepoint intranets, and other Microsoft-specific sites always required IE to run. Technically, it’s because VBScript and WShell scripts are used in those sites (the validity of that is a totally separate topic). However, what to do if you use FireFox as your daily browser, and hate switching over to IE just to browse some fool’s site?

Well, as long as you are running Windows, this solution should work for you: the IE Tab Firefox add-on.

With it you can switch from Firefox to IE mode and back with the click of your mouse. A little Firefox icon is displayed in the lower right corner of the Firefox browser after installing this add-on. Click on that, and it turns into an IE icon, and refreshes your page, running it in IE within Firefox!

Oh! And for those of you running Minefield (Firefox 3.x Alpha), it claims to work in it as well.

This has become one of my FF necessities!

JavaScript,Extending,Objects

How often have you run into the situation where it would be great if you could chain getElement(s)By method calls? Unfortunately JavaScript does not support this out of the box since the getElement(s)By functions return various collection objects.

Thankfully there is a way you can extend JavaScript functions and objects using prototyping. The stub would look somewhat like this, and you would have to include this in whatever pages use the chained calls:

Object.prototype.getElementByID = function(s_id)
{
alert(s_name);

return null;
}

This is just one example. Using this process you can then run effective chaining that could look like this:

document.getElementsByTagName("rule").getElementsByAttribute("format", document.getElementsByAttribute("data_format");

As soon as I have the extended methods completed, I will make them available here for download. Feel free to contribute, if you have any particular ideas on this!

So I’ve come up with this great business idea that will revolutionize the world, abolish hunger, and set in an era of universal peace never seen before. Well, ok, not quite… but almost, I swear!

Now, of course you need the catchy domain name to go with it. Think again, my web-clicking friend! Over 90% of all domain names have been snatched up by so-called domain brokers who make a living off of others wanting to buy a particular name.

Sure, I promote free markets as much (or maybe more) than the next guy, but I actually caught myself thinking “they should have laws against this sort of stuff”. Wow! I actually caught myself thinking in ways that totally contradict my political beliefs (liberty, freedom, and free markets). This caused me to question my presumption: what right do I have to a domain name that someone else purchased legally? Of course I have none! Is it underhanded and nefarious, or enterprising?

Sure, they aim to take advantage of you wanting your domain name, but don’t all businesses do that now-a-days? I mean, really, isn’t advertising doing the same thing: creating a perceived desire so that you go out and buy it from them? OK, so there’s a slight difference in how the company operates: domain brokers take advantage of the shortcomings of existing markets without having to do any campaigning or marketing for their “product”, but other companies do that as well.

On the other hand, it is near impossible for one business to register all business names in a given state and act as a business name broker. Why is that? This is because registering a business name is in most places a legal requirement that mandates paperwork. And quite often lots of it (articles of incorporation, registration application, etc.). Who wants to start up 100 businesses with all the involved paperwork just to get a monopoly on the names in the off-chance that someone will buy it from you? I highly doubt that the effort pays off.

Should similar registration requirements be placed on domain names? I believe they should. Whoa… wait, wait… let me explain! I believe they should … in certain situations and to a certain degree. All top-level domains should be assigned according to their purpose designation (currently it is more hap-hazard than a chicken coop), as described here. Additionally, I would also enforce the following restrictions:

• .com: require that it be registered by a business and that it cannot be resold (instead it must be relinquished to the domain registration authority if the business closes).
• .net: may only be registered by network companies (IT, communications, internet providers, etc.), otherwise same as .com.
• .org: may only be registered by non-profit organizations, otherwise same as .com.
• .edu: may only be registered by educational institutions, otherwise same as .com.

All names used for business purposes should require additional registration requirements (not government controlled!), e.g. the above-mentioned. These requirements should effect a verification procedure that makes sure the information provided is accurate. Now, this would admittedly upset many domain registrants, such as individuals and those that do not fit the mold as described above, but it would accomplish the goals of the top-level domains in the first place: to effectively categorize the internet. In addition it would free up domain names and put an ill-gotten industry out of business without harming the liberties of individuals. Well, that, and of course I would be able to get the domain name I’m looking for.

contribute,adobe,cs3,contribute publishing server

Well, here is the promised follow-up on my evaluation of Contribute and its buddy CPS.

I had some initial trouble getting it configured so that it would tie in to our ActiveDirectory server (that way we don’t need to manage users aside from in ActiveDirectory). The problem was that I couldn’t establish a connection between CPS and AD.

My assumption at this point was that CPS as actually seeing AD, but I was providing incorrect credentials. Well, the CPS documentation states that you need to enter your user DN as follows: uid=username, ou=group, dn=server, dn=com. This never worked for connection to AD using Windows Authentication Method, eventhough I customized it to use our schema (meaning instead of uid I used samAuthentication).

Making a call to Adobe Support also proved fruitless, as they will not support unregistered (speak trial) versions of their software. When I mentioned that I was evaluating the software for a company with the possibility of a future purpose, it didn’t even phase them; *Indian accent* “I’m sorry sir, we can only support registered versions of your software.”

Back to the drawing board. Luckily (after hours of searching) I stumbled accross a post that mentioned that the user was connecting using the folliwng user DN: user@server.com. This worked like a charm!

Now that I was up and running, I ran contribute and began administering the users (I could now search active directory) and was able to establish a writer > publisher > admin workflow process. Exactly what we are looking for.

Contribute really is the optimal solution if you want to give your content writers as little or as much leeway as they need, while not sacrificing versatility (which is often lacking in CRMs with admin modules). Our users can now create whatever content they wish withing the parameters we allow them, without fear of them breaking site funcitonality; all the appropriate checks and balances are in place.

The downside is, that is is divorced from your Microsoft development path that comes with using Visual Studio. In our case that is not a real big deal, as we will simply use Adobe line of software for our public company site, and continue using Microsoft line of software for our intranet. This is a clean division of applications that corresponds to the division of responsibility (meaning that the users creating content for the public site aren’t the users managing the intranet).

What CPS provides is a tie-in to AD (user management), change control (versioning up to 99 changes per page), and mist importantly process workflow.

Where do I start? Well… I guess I could post about the reason behind this post. I am currently evaluating Contribute CS3 as a potential tool for our non-technical staff to assist in maintaining our company we site.

So far I am amazed at the ease of use in Contribute CS3! I played around with it back when Contribute 2 was published (not CS2), and dismissed it as a nifty tool that didn’t have any real value to me at the time. However, it has significantly matured since, and am delighted to find that it recognized my custom install of this WordPress blog on my site with no manual configuratino necessary! (It also recognizes many other blog standards, like Blogger, etc.)

Further testing will determine how viable it is for a medium-sized business that wants to allow content publishing to its web site without necessarily involving the IT department all the time. This means establishing of roles, publishing rights, and chain of events in the publication process. Contribute Publishing Server should allow for all this (and more!).

I’ll break into that next.

[Update: 9/25/2007] At the moment I am still awaiting purchase of Adobe CS3 at my workplace to post more detailed testing results. This post was basically a use-case for connecting to my WordPress blog. Future write-ups will be more detailed.

Well, after installing Ubuntu Feisty Fawn from scratch again, I have lost all my settings. This includes the screen refresh rate settings that are specified in /etc/X11/xorg.conf. If you are experiencing low screen refresh rates (usually 60Hz) and would like to adjust these higher, look for the following section “Monitor”. Adjust the upper limits similar to the following:

Section "Monitor"
Identifier "Generic Monitor"
Option "DPMS"
HorizSync 28-101
VertRefresh 41-160
EndSection

Now, log off (back to the login screen), and press <CTRL>-<ALT>-<BACKSPACE> to restart the X-Server without needing to reboot completely. Proceed to log in, and set your refresh preference.