Brilliant Thinking

BBC NEWS | Business | [Protx] Payments service ‘goes offline’

Oops. It just goes to show that despite “test, test, test” even critical systems upgrades don’t always go to plan.

We have a number of clients with Protx integrations and the new payment gateway that was launched today also introduced its own technical issues for developers. Although the original launch was billed as allowing website owners to customise the look of their payment pages “without the aid of a web developer”, the actual reality is very different. The system just launched requires that payment pages are customised using XSLT (eXtensible Stylesheet Language Transformation) - no “user friendly” customisation tools, just hard-core, complicated coding.

According to Protx “You will need to know XSLT, and we cannot help you there. Our support team will ONLY check your pages before uploading, and we CANNOT do your debugging for you. There are plenty of books available on the subject, and your web developers will definitely be able to help you. XSLT is pretty standard these days.”

On a recent straw poll of the WAUK mailing list approx 50% of developers admitted to having some experience with XSLT, but only approx 20% had current experience. Which means approx 80% of developers (based on a sample response of 35 over a 24 hour period) have little or no experience of XSLT.

Fortunately, since Protx do provide the XSLT templates, it is possible for developers to produce branded versions of the payment pages for their clients. The XSLT templates are basically HTML templates with lots of special tags (the XSLT) which tells the Protx server how to display the Protx generated content. The developer (at the bare minimum) need only produce new HTML to display a branded page and re-use the XSLT tags that are already provided. The level of XSLT knowledge required is actually relatively minimal - you just need to be a competent developer to move the XSLT blocks around and drop in a few of your own images or CSS files. It’s the slow and steady approach.

At first glance, the Protx release about producing customised payment pages for their new system is a little scary if you’re not used to XSLT, but the reality is that it’s relatively straightforward - especially if you have also had some experience with Worldpay’s systems (although they don’t use XSLT, they do have a similar tagging engine).

It was inevitable really - Microsoft have finally decoupled Internet Explorer from Microsoft Office.

With the release of Outlook 2007, Internet Explorer will no longer be used as the HTML rendering engine from within Outlook, instead using the Microsoft Word rendering engine within the Office suite. While this more clearly separates the browser from the operating system for anti-trust reasons, it has a negative impact on HTML email newsletters (irrespective of whether you are for or against them).

Outlook has approximately 75% of the corporate email market. As this represents huge volumes of HTML-capable clients, it’s not something that can be ignored given that most HTML email designers have been adopting more standards-based approaches including CSS. The problem is that Outlook 2007 no longer supports much of this. Here’s the headlines:

1. No background images - Background images in divs and table cells are gone, meaning the image replacement technique is out the window.
2. Poor background colour support - Give a div or table cell a background color, add some text to it and the background colour displays fine. Nest another table or div inside though and the background color vanishes.
3. No support for float or position - Completely breaking any CSS based layouts right from the word go. Tables only.
4. Shocking box model support - Very poor support for padding and margin, and you thought IE5 was bad!

Microsoft have released a full run down of what is and isn’t supported, including a downloadable validator that helps you validate your HTML for their engine. Word of warning though, it only works with Microsoft software and Dreamweaver.

This really is a game changer. Previously you could send a HTML email in the comfort that the majority of your recipients would have very good CSS support. Other email clients were also catching up. Thunderbird uses the Firefox rendering engine, the new Yahoo! Mail beta has great CSS support. Things were looking good for us CSS based email designers.

Unfortunately, that no longer applies. In the old days, if your email broke in Notes or Eudora, it was often an acceptable casualty, but if it broke in Outlook you’re more than likely ostracising too many recipients to justify your design approach. This certainly doesn’t spell the end for HTML email, it just takes us back 5 years where tables and nasty inline CSS was the norm.

Imagine for a second that the new version of IE7 killed off the majority of CSS support and only allowed table based layouts. The web design world would be up in arms! Well, that’s exactly what the new version of Outlook does to email designers.

You can read more about this in the original article at Campaign Monitor.

For email designers, there is a useful tool which helps validate HTML emails across the majority of email clients. The tool is called SiteVista and you can read more about it here.

Shoppers are likely to abandon a (shopping) website if it takes longer than four seconds to load, a survey suggests. The research published by Akamai in November 2006 revealed users’ dwindling patience with websites that take time to show up. The time it took a site to appear on screen came second only to high prices and shipping costs in the list of shoppers’ pet-hates.

Akamai consulted those who shop regularly online to find out what they like and dislike about e-tailing sites. About half of mature net-shoppers - who have been buying online for more than two years or who spend more than $1,500 (£788) a year online - ranked page-loading time as a priority.

Of the 1,058 people interviewed in the first 6 months of 2006:

• 75% would not return to websites that took longer than four seconds to load;
• One-third abandon sites that take time to load, are hard to navigate or take too long to handle the checkout process;
• About 30% said they formed a “negative perception” of a company with a badly put-together site and would tell their family and friends about their experiences.

The last finding is important because the research found that the experience shoppers have on a retail site colours their entire view of the company behind it. In other words, if your site is poorly constructed, badly designed and loads slowly, you’ll guarantee yourself less sales and have a hard job convincing people to come back due to the negative PR you’ll generate.

Companies in the UK must include certain regulatory information on their websites and in their email footers before 1 January 2007 or they will breach the Companies Act and risk a fine.

Every company should list its company registration number, place of registration, and registered office address on its website as a result of an update to the legislation of 1985. The information, which must be in legible characters, should also appear on order forms and in emails. Such information is already required on “business letters” but the duty is being extended to websites, order forms and electronic documents.

The change is being made by a Statutory Instrument to implement a European law, the First Company Law Amendment Directive, into UK law. According to a Department of Trade and Industry spokesperson, the law will take effect on 1 January, one day later than the Directive requires.

The information is expected to appear in the footer of every email sent from a company, to avoid having to decide whether each email amounts to a “business letter” or not. Many companies do this already because the term “business letters” was thought likely to include emails even without this new clarification.

For websites, contrary to the fears of some, the specified information does not need to appear on every page. Again, many websites will already list the required information, perhaps on their “About us” or “Legal info” pages.

The Ecommerce Regulations, passed in 2002, require that certain information is listed on a website, including, “where the service provider is registered in a trade or similar register available to the public, details of the register in which the service provider is entered and his registration number, or equivalent means of identification in that register”.

That has been understood as including the company registration number and place of registration. The Ecommerce Regulations also required a note of “the geographic address at which the service provider is established” – which many have taken to mean the registered office address.

However, the wording in the Ecommerce Regulations is ambiguous compared to the new provisions. Further, many organisations’ sites currently omit the information, perhaps making the mistake of thinking that the Ecommerce Regulations do not apply to websites that do not sell online (in fact they apply to almost all websites).

Information that must be on your website
The following is the minimum information that must be on any company’s website (from OUT-LAW’s guide, The UK’s Ecommerce Regulations).

• The name, geographic address and email address of your company.
• The name of the organisation with which the customer is contracting must be given. This might differ from your trading name. Any such difference should be explained – e.g. “XYZ.com is the trading name of XYZ Enterprises Limited.”

It is not sufficient to include a ‘contact us’ form without also providing an email address and geographic address somewhere easily accessible on the site. A PO Box is unlikely to suffice as a geographic address; but a registered office address would. If the business is a company, the registered office address must be included.

• If a company, the company’s registration number should be given and, under the Companies Act, the place of registation should be stated (e.g. “XYZ Enterprises Limited is a company registered in England and Wales with company number 1234567″)
• If the business is a member of a trade or professional association, membership details, including any registration number, should be provided.
• If the business has a VAT number, it should be stated – even if the website is not being used for e-commerce transactions.
• Prices on the website must be clear and unambiguous. Also, state whether prices are inclusive of tax and delivery costs.

Finally, do not forget the Distance Selling Regulations which contain other information requirements for online businesses that sell to consumers (B2C, as opposed to B2B, sales). For details of these requirements, see out-law.com’s guide, The Distance Selling Regulations - An Overview.

For help with email notices, such as disclaimers, see OUT-LAW’s guide on Email notices.

Six months after unleashing its first production version, Zimbra Inc is adding to its Ajax-based email and group collaboration system a WYSIWYG Wiki document editor and threw in the ability to render natively on several major mobile clients.

Full Story - CBR Online.

What is Zimbra? Zimbra is a collaboration suite designed for teams and offers

• Email
• Shared calendar
• Web document authoring and sharing
• “Over the air” sync to mobile devices
• Microsoft Outlook, Apple, and Linux compatibility
• VoIP integration

As a PIM (Personal Information Manager) it covers the bases that Microsoft’s ubiquitous Outlook software does and is server-based, built using Web 2.0 principles. However, it goes much further as it offers true collaboration functions.

The addition of the WYSIWYG Wiki document editor is a significant addition as it allows groups/teams to collaborate on documents securely from anywhere, including many mobile devices. This allows for more virtual team environments, and the inclusion of a security model allows for tighter document control.

For more information on Zimbra, visit their website.