Jep's blog

Business Intelligence Software as-a-Platform

2010-07-19T20:29:00.001-07:00

The latest trend in software is "Platform as a Service". This is a software package delivered as-a-Service (SaaS), on which third parties can also develop their solutions. Salesforce.com is the best example of PaaS, because hundreds of companies have posted their solutions on the AppExchange. The base software package is very useful by itself, but you can easily add functionality through 3rd party extensions.

To make PaaS successful it should be easy for partners to extend your software. You need to have a good API and an active developer community (and often also a support desk).

The last company that announced a PaaS strategy is GoodData, a company that provides business intelligence software. They have a cloud-based analytics solution based on Amazon Web Services. The last release of their software has made it really easy for developers to tie their software into the GoodData platform. Because the pricing is affordable, many more companies can now use advanced analytics (it's not a 6-figure project anymore!).

Considering that many companies have reporting challenges, and considering that many SaaS vendors have a very basic reporting system built in, I'd say there is room in the market for GoodData's solution. The trick is to get enough developers excited to build on top of GoodData rather than building it on their own.

Getting "Jep" on Page 1

2010-02-11T21:03:00.000-08:00

I have a fairly unique first name: "Jep". I think I know 2 people in the entire world with the same first name, one in Denmark and one in the US. So it would be cool if my site popped up if you search for "Jep": a little bit of personal branding :-)

I was interested in the Internet pretty early on, so I tried to register domain names with my name in it, which is a good start for personal branding. Unfortunately I was too late to register jep.com, but I could claim castelein.net and jepcastelein.com.

In the past years I learned a fair bit about Search Engine Optimization. If you Google "Jep Castelein", you find pretty-much all my sites, and even if you Google "Castelein" I show up in 4 out of 10 spots.

However, if you Google "Jep", my sites on are page 2. I find it a personal challenge to get on the first page of the Google search results. I recently registered the domain jep.name, which uses one of the new top-level domains. It may not be as good as jep.com, but it should definitely help.

On jep.name I've created a personal profile page using a service called Retaggr. I've added all my social networking sites, and several options to get in touch with me.

On all my other websites I have created links to this new profile page, using "Jep" as the link text. This tells Google that the site is about Jep (see also the miserable failure story). Hopefully we'll see some results in a couple of weeks!

Phone.com VoIP Call Quality Problem - Solved

2009-12-22T19:19:00.000-08:00

For my company I was looking for a small business phone system with a virtual PBX, an efax and a VoIP handset, all for a reasonable price. I've looked at Grasshopper, Ringcentral and 8x8, but Phone.com was the only provider that could offer the full functionality for a pretty low price. But unfortunately I ran into some call quality issues, which were actually not so hard to solve.

The complete small business phone system

I've set the phone system up as follows:

toll-free number as the central phone line
local alternative number
local fax number (efax, send and receive)
a Polycom VoIP handset
Forward to my cell phone if I'm not at my desk
600 minutes per month, shared among all above
Monthly cost of $35 plus taxes and fees

VoIP Quality Problems

I was pretty excited when the handset arrived, but I was only a minute into my first call when the person at the other end said: "do you have a VoIP phone, you're cutting out all the time". I called Phone.com support, but they couldn't really help me.

I have cable Internet, and a wireless router hooked up to the cable modem. The router is a Linksys WRT54G2, which has reasonably good reviews at Amazon.com. However, with the Phone.com VoIP test tool I could see that the line quality wasn't good enough: too much jitter and packet loss.

Router with Quality of Service (QoS) support

Through research on the Internet I found out that some of the more professional routers have Quality of Service support, which allows you to give higher priority to VoIP calls compared to other internet traffic (like watching a movie on your computer). I ordered the D-Link GamerLounge router (DGL-4100) for an amazingly low price of $74 (after mail-in rebate). It was pretty easy to set up and - while I haven't made a ton of calls yet - it seems that the quality problems have been solved!

My Setup

I have Time Warner cable Internet, with 10+Mbps download speed and 500kbs upload speed. In the old setup I had only a cable modem and my Linksys wireless router: my computers were connected via wifi, and the VoIP phone was plugged into one of the router's Ethernet ports.

The old situation

In the new setup, the D-Link router is put in between the cable modem and the wireless router: the phone is now plugged into the D-Link, just like the wireless router, but the phone gets higher priority.

The new situation

Technical Details

The D-Link router worked out of the box: there were some minor setup tasks, but the only main configuration work was to add the QoS rule for VoIP (see screenshot).

The D-Link was now taking care of Network Address Translation (NAT) and DHCP, which was previously done by the Linksys wireless router. Therefore I had to reconfigure the Linksys router to function as 'Router' rather than 'Gateway' (in Setup > Advanced Routing, set Operating Mode to "Router").

In the D-Link configuration I had to assign a static IP address to the router, otherwise it would be really hard to access the Linksys configuration page (the IP address would change when the DHCP lease expires). This is done in Basic > Network Settings. In the Linksys Basic Setup I had to enter this IP address.

Conclusion

Even though I'm cheap and want to get a great phone system for a low price, it's good to invest in call quality. A $74 investment paid off really well. Phone.com should almost offer this router as part of the package.

Let me know if you have any questions or suggestions.

Disruptive Change in Business Intelligence

2009-07-08T11:23:00.000-07:00

In the past weeks I've worked with Good Data as a marketing consultant. I've spent a lot of time studying their value proposition, and their technology. The market they are in – Collaborative Business Intelligence – is very interesting.

The BI market has several strong established players, and most of them have been acquired by the industry giants: Business Objects by SAP, Cognos by IBM and Hyperion by Oracle. For now, they will still rule the Fortune 500, but there are new competitors coming up from the bottom. That is one of the characteristics of disruptive change, according to Clayton Christensen's book 'The Innovators Dilemma'.

What is new about vendors like Good Data? I'd say there are a couple of aspects:

SaaS Business Intelligence model (rather than on-site software)
Focus on user experience and collaboration
Pre-built vertical applications

These aspects improve the ROI of cloud business intelligence projects: it is less costly to roll out because of the on-demand model and the pre-built applications, and user adoption is higher because of the user friendliness and collaborative features.

Actually the best case for online business intelligence is made by Evangelos Simoudis on the Sandhill.com blog. He indicates that online systems are better at aggregating data from various locations, from inside and outside the company. Only this will create true new insights.

Also, a cloud-based analytics system is a natural for social features. Collaboration is taking place all over the web. Whether it's a generic social network like Facebook or MySpace, a white-label social network on Ning, or a micro-blogging service like Twitter. This has the potential to transform BI from a solitary activity to a collaborative process.

An additional benefit is more operational in nature. True cloud-based systems are multi-tenant: in other words, only one instance of the application is used by multiple customers. This is done in such a way that the data for each customer is totally isolated, but application maintenance is much easier. Even better, the actual end-customer never has to to application maintenance: the new features simply appear in the product.

Evangelos mentions a total of 12 points in favor of on-demand business intelligence. So if this is of interest to you, please be sure to read his full article.

Another recent article about the pros and cons of hosted BI was published on TechTarget.com. They are quoting a Forrester report by Boris Evelson. As the benefits he mentions: “less reliance on internal IT, anywhere access to the application, pay-as-you go pricing with no up-front cost and vendor management of the application and infrastructure.” But as a drawback he mentions “lack of built-in integration with the rest of an organization's data and processes”. The original report can be accessed on the Forrester website (subscribers only).

Conclusion

In this post I've tried to summarize some benefits of cloud-based business intelligence software, with links to other relevant articles. Please let me know if you have additional suggestions.

How Bank of America Steals from the Poor

2009-05-11T18:50:00.000-07:00

Normally I don't write about politics, I prefer writing about topics related to my job. I vaguely heard about a Credit Card bill that Obama has proposed to end abusive lending practices. I'm not familiar with that bill, but I do have an experience that I would like to share.

When I moved to the US almost 4 years ago, I did not have a credit history. Therefore I applied for a secured credit card at Bank of America. They provided excellent service, and I was happy that I could start building a credit history, even though I had to deposit $1000 to get a $1000 spending limit.

Being privileged with a stable middle-class job and healthy spending habits, I was able to get better credit card offers fairly quickly. However, every 2 weeks I still get a letter from Bank of America that tries to lure me into an unsavory deal.

The envelope says "Account Information Enclosed" and it contains 3 checks that you can use with a 1.99% promotional APR that is good until January 2010 (8 months). That sounds like a great deal: you could pay the rent or the mortgage, for only 2% interest.

What is does not say that a transaction fee of 4% applies (recently raised from 3%), and that after January 2010 the APR goes up to 20.99% (5% higher than the APR for credit purchases). Before BofA corrects me: it is listed in the small print, but it took me 5 minutes to find it.

So is this abusive or not? I tend to say 'Yes'. This offer is clearly designed for people who need cash most, and those are not financially priviliged, to say the least. The BofA letter only emphasizes the benefits, while hiding the downsides: people in urgent need for cash will be lured into this deal for sure. Therefore my strong statement: "BofA is stealing from the poor".

What do you think? Is this indeed unsavory, or is this just the American way of doing business: buyer beware?

PS. I called in to stop receiving these checks, but that didn't help, they just increased the frequency.

PPS. Also, I still pay a $39 annual fee just to have this BofA credit card (it's my oldest card, so I keep it for my credit history). BofA claims this fee is needed to ensure global acceptance, customer satisfaction, to provide online account access, to maintain security, and to give you balance transfers and cash access. Then why does my other credit card pay me approximately $1000 per year in cash back?

Collaborative Analytics

2009-03-31T22:47:00.000-07:00

Tomorrow I'm meeting with the marketing team at Good Data, an innovative provider of Collaborative Analytics software.

What is Collaborative Analytics?

As far as I currently understand, Collaborative Analytics allows a group of people to create reports on a dataset together, to discuss results, and to refine reports.

It seems to me that there is still an important role for IT, or at least for a reasonably technical person, to upload the dataset and configure the data model. But after that initial step is taken, the reports are fairly easy to use by non-technical people.

The 'collaborative' part of it is that they can leave comments in the reports, not unlike sticky notes. They also support tagging (like you do with blog posts) and revisions, so you can see who made which changes at which time (like with wikis).

Good Data's collaborative analytics solutions runs on Amazon Web Services, so it is almost infinitely scalable.

Stay Positive by Mark Victor Hansen

2009-03-30T20:09:00.000-07:00

How Mark Victor Hansen stays up through down times

It’s easy to stay motivated when times are flush. But staying up in down times? That requires a whole other set of skills.

This post is to illustrate how choosing the right keywords in your Title, Heading and content of the article have a dramatic impact on search engine rankings.

This article is about Mark Victor Hansen, and it talks about how he stays positive in a bad economy. So it is key to include his name, and the "Stay Positive" phrase in the title of the article.

Also, any bold or italic text is assigned more weight. On the bright side: it is fairly easy to improve the search engine rankings when you focus just on a couple of things.

This post refers to the article by Selling Power Magazine: Stay Positive. By linking from here, the original article get more credibility.

However, Google says it has not indexed this specific page. You can find out about this by typing the following in the Google search box:

cache:http://www.sellingpower.com/article/display.asp?coverStory=TRUE&aid=SP4774329&pageTitle=

However, the following URL is found:

cache:http://www.sellingpower.com/article/display.asp?aid=SP4774329

Therefore be careful with URL parameters: they may mess up your ranking.

If you search for "Stay Positive Mark Victor Hansen" the Selling Power website is only on position 29, and the URL that is indexed is not a permanent URL, but the temporary 'cover page' URL.

Wedding Website

2009-03-17T22:24:00.001-07:00

My fiancee and I recently created a website for our wedding. However, people google "Tina Jep Wedding" and they don't find our website.

I found out that the site (www.tina-jep.com) is not indexed by Google, probably because no other sites are linking to it.

You can add a site to Google, to make Google index it. But this can take a while.

Just to be sure, I'm also adding the link on this website. Google is adding more weight to websites if other websites link to them, ideally using the keywords that are relevant, such as: Tina and Jep's Wedding Website. I hope this helps!

Jep's main blog has moved

2009-02-22T08:00:00.001-08:00

Over the past couple of months I've started blogging at LeadSloth on Demand Generation. This is a blog about Demand Generation, and specifically about Marketing Automation tools that facilitate Demand Generation.

I cover Demand Generation Software, Webinar software and tools, Web Analytics, Email marketing, website management and landing pages, social media monitoring and search marketing.

I may occasionally still post on this blog, but please visit the LeadSloth blog for frequent posts.

Also, I sometimes update status on my LinkedIn page, so for visit LinkedIn if you're interested in that: Jep Castelein on LinkedIn.

Ajax Survey Results: What is happening in the Ajax market?

2007-12-16T15:26:00.001-08:00

Ajaxian and Richard Monson-Haefel did a market share survey of Ajax Tools, and the results were published this Friday. The results show that the Ajax market is more diversified in 2007 than it was in 2005. How is that possible?

First of all, this survey shows that ‘raw Ajax’ is disappearing rapidly, going from 40% to 25% to 13% in 2 years time. That is clear sign of a market getting more mature. However, that still leaves more toolkits out there, and no clear winners in terms of market share.

I don’t have access to the full list of results, so I have to guess a little. My first gut feeling is that more and more server-side projects include some type of Ajax – just as one of the many features – and they all get added to the list (e.g. Django). My second gut feeling is that many toolkits have less than 1% market share, making them less relevant. Maybe Richard can publish the full list so we can do some further analysis.

Also, I think developers start to find out what type of development paradigm they prefer. For example, GWT has a development model that appeals to a certain type of Java developer: those who have worked with Swing applications before. However, that’s only a small percentage of developers, so GWT is not in the top-10 Ajax frameworks. However, Swing developers love GWT.

Then we still see some new entrants into the top-10 such as jQuery and Ext JS. I don’t have hands-on experience with these frameworks, but based on what I read about them, they have introduced clear innovations in the Ajax market: jQuery with its programming model, which includes using CSS selectors; Ext JS with Widgets that look much better than the widgets of any other open source Ajax framework. That might also explain why Prototype looses market share.

What I find surprising is that Dojo is also loosing market share, and there is no obvious open source alternative for Dojo. I mean: an alternative that aims to be just as comprehensive. Does this mean that lightweight frameworks are gaining ground, or that people look at commercial frameworks if need comprehensive functionality? Or is it that people still find Dojo difficult to use: I’ve certainly heard several people who gave up on it.

Richard also mentions that Backbase is the only commercial Ajax framework with significant market share. That’s a trend that I’ve also seen: other than Backbase, many commercial vendors wither and then make their product open source in the hope they will get more adoption. It’s a really tough market for commercial products, because there are a lot of decent free products out there. The only option is to make a superior product, with excellent training, support and services. And – working for Backbase – I know we have focused on that: we aim to deliver the total package and I believe that is what made Backbase successful.

LinkedIn Profile

2007-12-10T22:23:00.000-08:00

I've updated my LinkedIn profile: Jep Castelein

Plaxo and Facebook are also getting more popular as B2B social networks, but for now I'll stick to LinkedIn because it seems to be the most popular. I hope to avoids having to update my profile in 3 different locations :-)

Ajax Training, Online Instructor-Led

2007-10-03T19:27:00.000-07:00

Backbase has an online Ajax training, which is specially developed for web developers within mid-size to large companies, who have worked with HTML and CSS before, but not yet with Ajax. Ajax is a combination of existing technologies, such as JavaScript, HTML, XML and CSS. The course provides a refresher on those technologies plus an explanation of how they work together to create Ajax applications. It only takes 10 hours, spread out over 3 days, to cover these materials: so a great way to get started with Ajax quickly. There are more advanced Ajax training courses available if you'd like to go beyond the basics. The next Ajax training course starts on October 22nd 2007. You can find more information here: http://www.backbase.com/services/training/ajax-training/

Accessibility for Enhanced AJAX Frameworks

2006-07-13T08:56:00.000-07:00

As AJAX is becoming more widely used, important issues like security, interoperability and accessibility are getting more attention. At the same time, different types of AJAX applicatications are being identified, which is also being picked up by the analysts, such as Ray Valdez of Gartner:

Snippet level
Widget level
Framework level
Enhanced Framework level

I feel the important AJAX issues can best be evaluated in the light of the different types of AJAX to result in the most useful recommendations.

AJAX Accessibility for AJAX Frameworks

I had to think about this classification because we just published a whitepaper on AJAX and Accessibility. A lot has already been written on this topic, so I was thinking how this whitepaper differentiates itself. Then I realized it's specifically about Frameworks and Enhanced Frameworks, where the user interface is fairly complex and uses a single-page interface. This is exactly the type of AJAX project that we're are typically working on.

So if you also work on more complex AJAX projects that are based on a framework (such as Backbase), you might want to take a look at this document.

Download the Accessibility Guidelines for AJAX (PDF, 140Kb)

Moved to San Francisco

2005-12-13T17:01:00.000-08:00

Since a couple of weeks I'm living in San Francisco, and working for the San Mateo office of Backbase. So I was pretty busy finalizing work in Amsterdam, moving my stuff out of my apartment, and so on. And on the other end of the ocean I had to find an apartment, buy a car, get a cell phone, bank account, credit card, etcetera. And obviously we had to get the office started, together with a team of local Backbase employees. In short: a busy time.

There is a lot of demand for AJAX software in the US market, and there are not that many vendors. Especially the new pricing of Backbase ($1995 per CPU, one-time fee) appeals to many prospects. So we made a good start with our office.

From now on I will try to write more frequently on this blog, and on the Backbase weblog. There are still several interesting AJAX topics to cover, and I will focus mainly on performance and networking issues, in combination with AJAX.

By the way, I just read an interesting post by Alistair Croll which explains why AJAX applications issue more HTTP requests, and often download more data, while still being more responsive than traditional applications.

Backbase compared with Microsoft Atlas

2005-10-13T11:04:00.000-07:00

On the Backbase weblog I've made a comparison between Backbase and Microsoft Atlas:
http://www.backbase.com/weblog/?p=11.

The Backbase Weblog based on WordPress

2005-10-13T05:36:00.000-07:00

In this blog I've mentioned my employer Backbase quite frequently. At Backbase we've now created a company weblog at http://www.backbase.com/weblog: from now on I will post most new articles on the Backbase blog, so please update your RSS feeds. The Backbase blog will cover general AJAX topics, with so now and then a Backbase-specific article.

On this weblog I will keep posting about AJAX & Performance and personal topics. For example, I will write some more about AJAX & Latency, which turned out to be a fairly popular topic.

The new Backbase weblog is built using WordPress. We've added some small Backbase features, such as animations, and input validation for commenting. Today it works only IE & Firefox/Mozilla, but we'll make it degrade gracefully for other browsers soon. I'm also looking forward to improve the commenting functionality, because I feel AJAX can have real usability benefits there.

JSON vs XML

2005-09-22T13:11:00.000-07:00

Dave Johnson has an interesting post about the preferred data transport format for AJAX: is it XML or JSON? He prefers XML. So do I. Dave emphasizes the importance of XML on the client: he uses a datagrid to illustrate this. Personally I like the clean architecture when you just load XML to the client and transform it to whatever you like using XSLT. The XML family of standards seems to be a very good fit with the browser world, and - according to Dave's article - the performance is also pretty good.

AJAX: reducing latency with a CDN

2005-09-12T14:15:00.000-07:00

In my previous article about AJAX and Latency I talked about the effect of high network latency on AJAX applications. My suggestion was that well-designed AJAX apps can still be more responsive than traditional web applications, even with high latency. Nevertheless, a low-latency connection is always better than a high-latency connection: so on backbase.com we're improving the infrastructure. First we've measured performance, and now we're optimizing the site itself, and we're considering a Content Distribution Network. A lot of this can also be applied to regular websites, but I'll highlight some AJAX peculiarities along the way.

Measuring latency

So now and then we get complaints about the speed of the Backbase website, so we've looked at several well-known performance management tools, such as Gomez and Keynote: they usually measure entire pages, including images, CSS and JavaScript. Although the Gomez service can handle JavaScript, it has problems with some AJAX sites, including our own: so we couldn't reap the benefits of this advanced service. Therefore we've settled for Watchmouse, which offers affordable availability and performance monitoring for single files from 14 world-wide locations. Watchmouse gives us the following data:

Connect time: the connection is made
First-byte time: the first byte of the response arrives
Download time: the entire file is downloaded

We measured the following averages (milliseconds):

	Connect	First byte	Download	Kb/sec
Netherlands	5.47	111.41	298.28	237.92
Sweden	28.50	154.00	413.83	149.81
Italy	49.00	225.00	448.57	185.58
New York	134.56	368.11	892.11	92.89
Florida	118.33	318.83	895.00	73.43
California	169.00	419.83	977.00	70.63
Texas	130.00	343.57	1724.86	29.72
Singapore	361.67	869.00	2102.00	32.62
Australia	369.37	763.17	2040.83	33.07

So the farther you get from our server in Amsterdam, the greater the latency. With latency I mean first-byte time (although you can define latency in different ways). This is a measurement for 1 file. I've made a rough calculation for the total download time of our home page:

download time = (# of files / 2 concurrent HTTP connections) * first-byte time + (download size / download speed)

I'm not sure if this is entirely correct, but it seems to give a good approximation, for example for California:

(70 / 2) * 0.41983 + 200 / 70.63 = 14.7 (latency) + 2.8 (download time) = 17.5 seconds

So the latency is about 4 times more important than download size. It also highlights that most web hosting providers offer adequate downloads speeds: our provider is small, but the connection is fast. We also tested the speed of some large providers, and this didn't make much of a difference in speed. Our action points are:

Reduce the number of file requests for the home page
Implement world-wide caching (CDN)

Reduce the number of files

When we first measured, the number of files was about 87. We've already reduced this number to 68 files by merging many CSS files into 2 files, merging many HTML files, and combining some images. As you can see in the table below, 2/3 of the files are images: because we don't want to change the design, we can't improve much further. We can still merge the JavaScript files, but then we're more or less done. So if we reduce from 87 files to 60 files we already have a 30% improvement. Then it's up to caching for further improvements.

	Size (Kb)	Size (%)	# of files	% of files
Images:	117197	62.9%	45	66.2%
HTML:	16695	9.0%	11	16.2%
CSS:	8615	4.6%	2	2.9%
JavaScript:	43753	23.5%	10	14.7
TOTAL:	186,260		68

World-wide caching (CDN)

Even if we have a home page with 60 files, the impact of latency is still considerable. Looking at the characteristics of latency, we have to get the files as close as possible to our web site visitors. Enter 'CDN', or Content Distribution Network. A CDN caches the most-requested files from your site on servers scattered across the globe, and they send visitors to the nearest cached copy of your web site. If files are not in cache or if files are dynamic, they are retrieved from the origin server, usually over an optimized connection.

There are a couple of things to consider when using a CDN with an AJAX website:

JavaScript cannot load files from other (sub-)domains
Some CDNs are more suitable for AJAX sites
AJAX actually works very well with CDNs!

The first item is the security-across-domains issue: if your page is on www.domain.com, AJAX cannot load files from www.whatever.com or whatever.domain.com (only with a trick in IE). Why is this important? Because several CDNs use an image.domain.com subdomain that you use to load all static files. This subdomain refers to the dynamic DNS server of the CDN network. An alternative is to have www.domain.com hosted by the CDN's DNS servers: now you should specify which files should be cached, and which files should be loaded from the origin server. I haven't tested this myself yet, so any feedback is welcome.

The first large CDN was Akamai: they now have 14,000 servers in 65+ countries. The last couple of years a new type of CDN optimized for rich media was introduced, for example by Limelight. Those providers have fewer servers, but connections optimized for fast delivery of large files with high quality of service. A third approach focuses on world-wide distribution of intranet applications (ERP, CRM, etc.). They link up a limited number of office locations: Netli is the pioneer in this area. In our case we have many small files delivered to a lot of visitors from many different locations: this seems to favor the Akamai model. Mirror Image (and possibly Savvis) offer a similar service. Again, feedback is welcome, as we are still selecting a CDN vendor.

Although AJAX creates some constraints for CDN usage, it's also more effective compared with regular websites. This is because you can 'assemble' the page on the client-side. In traditional sites, the page is either dynamic or static (I define static as 'the same for each user', so it could dynamically generated on the server, but just not personalized). If it's static it can be cached, if it's dynamic it cannot be cached. An AJAX page can be partly static, and partly dynamic, where the dynamic part is retrieved with XMLHttpRequest. This is also the case on Backbase.com: only 1 file is dynamic, the login dialog. So 98% of the files can be cached, except for this 1 file. Pretty good.

To summarize

If you are running a global AJAX website in which you have a lot of static file requests, first try to reduce the number of files, and then consider a 'traditional' CDN to further improve performance. Be aware of the 'security-across-domain' issue. When we've implemented a CDN I can tell you more about the results. If you have good tips for selecting a CDNs, let me know!

Backbase in Top 10 Ajax apps - twice

2005-09-06T12:28:00.000-07:00

Dan Grossman, a venture capitalist from Venrock Associates created a Top 10 of Ajax applications. Other than the Ajax app list on Ajax Patterns, this list has a ranking from 1 to 10. It does not include applications by large companies such as Google or Yahoo!

Number 1 is Kiko, the online calender, and number 2 is the Backbase RSS Reader, our newest demo application. The Backbase Portal (one of our most long-standing demos) is featured on place 8, and the recently updated Backbase Explorer is number 3 on the list of honorable mentions.

Personally I also like the Backbase Windows starter kit, although it could be expanded a bit more. The embedded movie is quite funny, by the way.

Improve the Backbase page on Wikipedia...

2005-09-05T10:47:00.000-07:00

We need your help: the Backbase page on Wikipage could be deleted if we don't add more content to it. As Wikipedia is a collaborative effort (and not a marketing brochure), you can help by adding text to this page. To contribute, just go to http://en.wikipedia.org/wiki/Backbase, and click on 'edit this page'. Just make sure the information has a neutral point of view and would be interesting for anyone who wants to learn more about Backbase.

Thank you!

AJAX Latency problems: myth or reality?

2005-09-04T10:56:00.000-07:00

I've read many articles on AJAX and network latency in the last year, but every article seems to claim to a different thing: one talks about latency as a problem specific to AJAX, while others claim that especially AJAX applications can overcome network latency problems. While yet others take a hands-on approach and build tools to simulate network latency on localhost. Confused...

So I searched Google for 'AJAX Latency', and read many of these articles again. Below is short overview of what I've found.

The first hit is from Wikipedia (3 Sept 2005):

"An additional complaint about Ajax revolves around latency, or the duration of time it takes a web application to respond to user input. Given the fact that Ajax applications depend on network communication between web browser and web server, any delay in that communication can introduce delay in the interface of the web application, something which users might not expect or understand."

They refer to 'Listen kids, AJAX is not cool':

"If you writing a user interface, make sure it responds in 1/10th of a second. That’s a pretty simple rule, and if you break it, you will distract the user."

I agree with one thing: you do want a response in 1/10th of a second. But is this realistic? Cédric Savarese points out that - even when it's not 1/10th of a second - the user expects to see something loading: he suggests using a loading indicator as a replacement for the traditional page refresh. But then he also mentions another perpective:

"What happens really is that XmlHttpRequest is not used for what it is good at: asynchronous, behind-the-scene, access to the server, but in the context of a synchronous transaction by the user. Users want instant feedback from an application, and a better way to achieve that is by freeing the application from its over-reliance on the server."

And Michael Mahemoff (of Ajax Patterns fame) adds the following:

"It's not an all-or-none thing. With AJAX, you can continue to download in the background if you want. "

So they suggest moving more intelligence to the client, and loading data in a smart way, ideally asynchronously without having the user wait for it: I think that's really what that first 'A' of AJAX is all about. But this could mean that you're loading more data on application startup, using precious bandwidth. Or maybe you're even loading data that the user will never see (pre-loading). I found a very punchy quote in a discussion on TSS:

"These days, bandwidth is cheap, latency expensive."

I can confirm this from my own experience: on www.backbase.com around 80% of the download time is caused by latency, and 20% by download speed (bandwidth). So you can better load some more data beforehand than have very frequent requests for small files.

We have measured latency and download speed with a global performance measurement system (more about this in part 2), but that's not convenient to use during development because it takes at least a couple of days before you have enough data. Then I read the article by Harry Fuecks:

"(...) alot of AJAX development is happening @localhost so these problems simply aren’t showing up."

So he has created an AJAX Proxy to simulate a high-latency environment on localhost: kudos! In another article he indicates that the use of synchronous requests should be avoided at all times. But even asynchronous requests need to be handled carefully: "Can multiple asynchronous XMLHttpRequests be outstanding at the same time?", asks
Weiqu Gao. Harry again did some research, and came up with a couple of recommendations:

Avoid Uncaught Exceptions: don't call the XMLHttpRequest object when it's still processing another request
Implement a solution for timeouts: XMLHttpRequest doesn't handle this automatically as do other socket client APIs
Make it possible to abort a request gracefully
Make sure that responses arrive in the right sequence

These are the technical aspects. I have found few articles about the usability aspects (probably because I didn't look very well). Marco Tabini quotes on his weblog: "one of the fundamental elements of AJAX programming (...) was to always give your users the appropriate feedback, so that they know when something happens." I agree with that: the user should not be surprised by unexpected behavior of the user interface. Interaction Designers should therefore also be aware of some of the latency issues. For them I would summarize it as follows:

If a user's action causes a server request, don't expect a response within 1/10th of a second: consider showing a 'loading' message
Specify the usage patterns of an application so that the developers know how preloading of data can best be implemented (think Google Maps, which prefetches maps just outside the border of the screen)
Be careful with 'hidden' functionality such as auto-save functionality, because it might conflict with other actions the user performs: cooperate closely with the developer(s) to avoid usability problems.
Clearly specify the sequence of events, e.g. 'action 1 has to be completed before the user should be allowed to start with action 2', which gives developers relevant information to avoid concurrency issues.

And to make the link between technology and usability, I have a quote of Jonathan Boutelle, who already understood all of this more than a year ago:

"Predownloading data is critical to providing low-latency experiences. But blindly downloading data without consideration for how likely the user is to need it is not a scaleable approach. RIA architects will have to consider these issues carefully, and ground their decisions about preloading in user research, in order to create superior user experiences."

After reading all of this I've come to a tentative conclusion: network latency is an important issue to consider during the implementation of an AJAX Application, both by the developer as well as by the interaction designer. If you make the wrong decisions, usability can be terrible. If you make the right decisions, AJAX will significantly improve web application usability. It is still a tentative conclusion, because I'm pretty sure I haven't read all the relevant articles: let me know what your thoughts are.

Custom Tags for Organization Charts

2005-08-31T07:18:00.000-07:00

We have created an interesting example of Backbase Custom Tags. Its goal is to simplify the creation of complex HTML structures by creating tags that have a higher abstraction level.

The example is an organization chart: this is usually somewhat complex to create in HTML and CSS, and requires quite a lot of HTML code: it's difficult to maintain, and it's easy to make mistakes. Therefore we created two shortcut tags 'orgchart' and 'subordinate' that can be used like this:


<b:orgchart b:label="Boss">
     <b:subordinate b:label="My subordinate">
         <b:subordinate b:label="My sub-subordinate"></b:subordinate>
     </b:subordinate>
     <b:subordinate b:label="My subordinate">
         <b:subordinate b:label="My sub-subordinate"></b:subordinate>
         <b:subordinate b:label="My sub-subordinate"></b:subordinate>
     </b:subordinate>
     <b:subordinate b:label="My subordinate"></b:subordinate>
</b:orgchart>

And this is how it looks (we used minimal styling):

The 'orgchart' and 'subordinate' tags are translated to HTML on the client-side, using the <s:htmlstructure> tag. Please have a look at the example: www.backbase.com/samples/grauw/orgchart/: use View Source to see how it's done.

The Custom Tags are defined here:
www.backbase.com/samples/grauw/orgchart/b-orgchart.xml (again use View Source).

And this is the CSS: www.backbase.com/samples/grauw/orgchart/b-orgchart.css

Of course, this is just one example where custom tags can be useful. Everyone can make their own custom tags, for whichever application. And maybe the best thing: slowly we are getting more of these examples on the Backbase Forum, creating an exchange of useful custom tags.

Java Pet Store with AJAX & XML

2005-08-31T01:29:00.000-07:00

My colleague Mark Schiefelbein has written an nice article for BEA Dev2dev in which he explains how we've rebuilt the Java Pet Store with AJAX and the Backbase XML Pipeline Server. The Java Pet Store is a well-know Java example application.

A common problem with AJAXifying an existing application is that the existing back-end is not optimized for an AJAX front-end: usually the flow of events is slightly different, and the data loading patterns are more 'on-demand'. The XML Server creates a bridge between disparate back-end systems and the Backbase AJAX engine. It can link to databases, Java objects, Web Services and custom connectors. Using an XML pipeline language you can link everything together. You can have a look at the AJAXified Pet Store here: http://www.backbase.com/xmlserver.

So although the Backbase AJAX Engine itself is a client-only application written in JavaScript, you can use various server-side add-ons that speed up AJAX application development. Backbase has both J2EE and .NET compatible products: the XML Server works on both J2EE and .NET, and the .NET Server features WYSIWYG AJAX application development using Visual Studio.NET. We're also working on a similar JSF application that uses Eclipse for WYSIWYG development.

Backbase has been classified both as a multi-platform technology (see Wikipedia) and as a pure JavaScript application (AJAX Patterns). We are actually both: we have a client-only AJAX engine, complemented with (optional) server-side components for .NET and J2EE. We feel this gives more flexibility than products with a mandatory back-end such as JPSpan (PHP), DWR (Java), AJAX.NET (.NET) or WebORB (.NET & Java). And more power than client-only products such as Dojo and OpenRico.

Some people ask why we don't offer a PHP version. Of course, you can use our client-only version together with PHP: actually, we'll soon launch a very interesting sample application that uses this combination. The difficulty with PHP is that there is no standard for GUI development. At Backbase we like to adhere to standards, so we've select JSF for Java, and use the defacto standard for .NET: Visual Studio.NET. But we haven't found a similar standard for PHP. I'm open to suggestions here, so let me know through the comments, of via jep [at] backbase [.] com.

AJAX jobs...

2005-08-24T13:59:00.000-07:00

It's pretty difficult to find good software engineers right now, especially engineers with the right experience. They should be good software engineers in general, but also have some experience with web applications, or ideally with AJAX. It's funny to see that even Google is accused of hiring all the bright engineers (NY Times article). Also see a surprisingly well-organized discussion on Slashdot about it.

In our own organization one potential employee went to Google (Zurich), instead of to Backbase, and several other people we've hired also considered Google. So I can't say that Google is luring away 'our' engineers. But I can confirm that it's difficult to find the right people, especially AJAX developers.

We've put job postings on Monsterboard, but very few people respond to our advertisements, and the Monsterboard CV database has very few interesting CVs. It's probably best to conclude that the economy is improving again. Which is good news, of course :-)

But anyhow: if you're a good software engineer and you would be interested to join a leading AJAX company, have a look at www.backbase.com/careers. R&D is based in Amsterdam, The Netherlands, which is very nice place to work. It even seems that the Dutch government improved their immigration procedures, so we can actually get work permits for people from outside Europe. We already have over 10 nationalities in our office in Amsterdam, so feel free to add to this.

PS. We're also hiring sales people for our new office in San Francisco.

InfoWorld reviews Backbase software

2005-08-08T12:56:00.000-07:00

No, it's not an advertorial, and we weren't even allowed to review the text before publishing. I find it very positive that the writer (Peter Wayner) really worked with the software himself and gave an unbiased opinion.

Read the review »

AJAX and Web Statistics

2005-07-22T00:05:00.000-07:00

Fredric Paul of Techweb brought up a new and interesting perspective on AJAX: how are web statistics and web advertising going to be handled if there are no more pages. The conclusion of the article in my own words: 'there is a problem, but we might find a way to solve it'. I was surprised by this article: I feel there are so much MORE possibilities with AJAX, not less.

With www.backbase.com I've been closely involved in creating and managing one of the largest corporate sites that are build with AJAX technology (using the Backbase software of course). We have around 4000 unique visitors per day, from over 160 countries in the world. For web statistics We've been working with standard log analysis software since the start. We're using Sawmill, but any other tool would also work. It gives us all the information that you also get on a 'normal' website. Reading the article on Techweb could make you wonder how this is possible.

I do understand the difficulty of grasping AJAX: it a popular topic, maybe even a hype. Many people write about it, and not everyone has a solid story. So certain aspects of AJAX that are repeated over and over again are catching on. One of the aspects is the death of the page refresh: with AJAX you can just load new information into an existing web page. In the Techweb article it is therefore assumed that there are no pages anymore, because the URL stays the same. This is not entirely true: you are still loading new information, it's just not an entire page. The new information is also a page on a web server, and it is therefore logged. On the backbase website we've stored all content-pages in one directory, in a hierarchical structure. This is how it looks:


content
  products
    product_overview.xml
    dotnet_edition.xml
    j2ee_edition.xml
    community_edition.xml
  benefits
    etc.

This means that you can easily see which information is requested by the user, and this is all stored in the web server logs. For web analysis software it's irrelevant whether this is a full page or only the content. It is important that 1 file contains one article though.

An analogy: the frameset tag

This topic brings back memories of seemingly ancient HTML tag: the frameset. Most sites with frames also had 1 URL, and new content was loaded in the 'content' frame. This is very similar to a content-rich AJAX site, and it worked fine with web statistics software.

Moving beyond basic statistics with AJAX

Of course, with framesets you could only load HTML pages. With AJAX you can load anything, such as unformatted XML data. In that case you might conclude that you cannot track how users are navigating through this XML data. This is not really a problem. First of all, the amount of data you can load at once into the browser is limited: it takes too long to download large amounts of data, and the browser could run out of memory. Nevertheless, with AJAX you move more intelligence to the browser: so you can easily track user behavior on the client, and periodically send an update to the server. Agree, there are no standard solutions for this at the moment, but that's definitely going to change. Let's look at an interesting scenario that we've worked on a while ago.

A financial services company wanted to optimize forms on their website. Their ultimate goal was to optimize revenue per form, thus minizing mistakes made by the user. They wanted to know how many times a certain form was filled in incorrectly, per user and on average. This information would allow them to continuously improve the form. The statistics they wanted weren't on a page level, but on a form field level. This is exacly what is possible for Rich Internet Applications. It's provides the opportunity to bring statistics to the next level.

Advertising & AJAX

I didn't understand the message of the Techweb article regarding AJAX and online advertising. Currently advertisements are typically loaded per page. With AJAX you have flexibility to decide when a new advertisement is displayed, you don't have to link it to a page refresh or loading of new information at all. You could put a timer on the advertisements: a new advertisement every minute for example. I don't get the point of the Techweb article: can someone explain it to me?

My First Hardware Hack

2005-06-17T22:39:00.000-07:00

Some people hack their Mac. Or Playstation, or XBox. I never hacked any hardware and I don't enjoy soldering: I'm more of a software person. But tonight I did my first 'hardware hack'.

A couple of weeks ago I splashed water all over my laptop. I completely disassembled it and let it dry for a couple of weeks. And - hurrah - my laptop was unscathed, or so I thought. The PC-Card socket didn't work anymore, nor did my Wifi PC-card. As a replacement, I ordered an Intel 2200BG mini-PCI Wifi card, because my laptop (Toshiba A30) has a mini-PCI slot with built-in antenna.

When I put the card in the socket, connected the antenna and installed the drivers, it didn't work. The hardware switch on the side of the laptop did not help. Through Google I learned about pin 11 and 13: I put tape on those pins and yes!, it worked. A tiny piece of plastic just saved me €185. Toshiba sells their own mini-PCI card for €215, while the Intel card costs €29. And I thought software had good profit margins...

Backbase Community / Essential web page features

2005-06-12T19:25:00.000-07:00

In response to my previous post, Ryan Brooks outlined his thoughts on Backbase. This is very useful feedback. One of the main points of his post was the need for more community. I could not agree more. As with most software, RIA/AJAX software becomes more useful once more people are using it. And especially at this moment there are an awful lot of frameworks popping up: just look at Michael Mahemoff's list of frameworks, which only mentions the open-source frameworks at this moment. So we need some critical mass, fast!

Community Edition

Luckily many thousands of people have downloaded the Backbase Community Edition in the first couple of days. Our servers are still alive, but we'll have to pay a hefty bandwidth fee at the end of the month. A fee we're happy to pay: the more downloads, the better. We're also happy to see users from all over the world: the US still has the biggest share, but our software is also especially popular in China. So we will continue to distribute the Community Edition to as many developers as possible.

Discussion forum

A couple of days after launching the Community Edition we opened up the Discussion Forum, and we're preparing some other initiatives. We're thinking about a code exchange, a best practices wiki, a mailing list, faq database, technical articles with code samples, tutorials, user groups, developer conferences, etc. Of course, this won't all happen overnight, but we will focus on steady improvement. Let us know which of these features will help you most, so we can fine tune our planning.

Essential web page features

A second topic of Ryan's article was focused web page features that you should get for free when you use AJAX (compared with Flash or Java applets). He discussed indexing by search engines, back- and forward buttons, permalinks and bookmarking. I'd like to add 'View Source' to this list.

Search Engines

Search Engine Optimization is indeed an area that requires some attention with AJAX applications that use a Single Page Interface (SPI), because there is a risk the search engine only finds the first page. On Backbase.com we're using a dual publishing model to avoid this problem: we use the same content files to publish both a rich single-page version and a plain multi-page version, which is indexed by bots. This requires some automation in the publishing process. As an alternative, the Backbase Tags allow you to use regular 'a href' links to load files with XMLHttpRequest: these links are also indexed by search engine spiders. In both scenarios, the search engine indexes 'pages' that are supposed to be part of an SPI. Therefore, some server-side logic is needed to convert these links to deeplinks that load the correct 'state' within the SPI. This topic will be covered in a 6-page technical article to be published in 1 or 2 weeks on the Backbase DevNet.

Backbase About Us page

Back-button and permalinks

This brings us to another topic Ryan mentioned: deep linking (with permalinks) and bookmarking. As I wrote in my previous post, we have some deeplinking support in Backbase.com. We are using URL parameters for this: for example, /devnet is rewritten as index.php?section=main_developers, which is parsed client-side: as a result, the Deck with ID 'main_developers' is selected. For people who haven't worked with Backbase: a Deck is a user interface concept similar to a stack of cards of which only the first one is visible. By selecting a card in a Deck, it is moved to the top, and becomes visible. This is what happens when the ID 'main_developers' is selected. The downside of using URL parameters is that the entire page is reloaded if we set a new parameter. An alternative is to use the pound sign (#), of which Tiddly Wiki makes good use: http://www.tiddlywiki.com/#UsingThisSite. At Backbase we are currently using the pound sign for Back/Forward support in Firefox: we could use a hidden frame for this, but this only works in Firefox when you are retrieving real pages from the server. In Internet Explorer you can retrieve 'virtual' pages by using the DOM, which is obviously faster. So maybe we could give users an option: either fast Back/Forward without permalinks, or somewhat slower Back/Forward with permalinks. If we build in this option, we should be able to support all scenarios.

"View Source"

An area that is getting more an more attention lately is 'View Source', which was one of the key factors in the rapid growth of the World Wide Web. Steve Yen makes the link to AJAX in this blog post, and there are probably many other relevant articles. Even the Macromedia guys now offer this feature, although developers have to specifically build this into their Flash applications, while it is a default feature of web applications. I think a potential problem with 'View Source' and AJAX is the large amount of JavaScript used. Also, in good AJAX applications the JavaScript code is encoded to limit the download size. So although you can view the source, it's pretty tough to make sense of it. The benefit of Backbase is that it is completely tag-based, so there is no need to look at JavaScript code. Looking at the source code of a Backbase application, you just look at Tags and you can quickly decipher the complete application. Give it a try with the deep-linking example in the previous paragraph: if you go to Backbase.com, do a View Source, then you find an <b:deck> tag, of which one of the <s:buffer> tags has the ID 'main_developers'. You can follow this link, etcetera.

wrapping up

So all in all this became a pretty long post: basically I just wanted to say we're growing the community, and all input and ideas are welcome. At the same time we take compatibility with the essential web page features very serious.

Practice what you preach AJAX

2005-06-08T20:18:00.000-07:00

Backbase's first websites were plain HTML. People asked us why we weren't using our own technology on our website. Good question. It should be possible to build a very nice website using our AJAX/RIA toolkit: AJAX shouldn't be just for web applications.

But people are never satisfied :-). A couple of months ago we redid our website using our own technology. And now some people say it looks like a Flash site and that it's an example of where AJAX should not go. So maybe it's good to tell a bit more about our considerations.

By the way: we are not against Flash, but people frequently make the comparison between Flash and AJAX as the main Rich Internet Application (RIA) technology options.

We wanted the site:

to be a technology showcase with a wow-factor
to load faster and be more responsive than a Flash site
to be usable and efficient
to have both a web-feel and an application-feel
to work like a typical website (e.g. back-button support)

a usable showcase

We thought: if we use our software on our own website, why not make it into a showcase. If people arrive on our home page they should clearly see the difference with 'regular' web sites. At the same time it shouldn't be a demo for the sake of being a demo: people come to our site to learn about our software, about our company, they want to download software, etc. This should be as easy as on other websites, if not easier. Of course, we also want to show that AJAX is faster and more responsive than other technologies such as Flash and Java, and our site should be a prime example.

information architecture

In general we tried to make the site more flexible, and less page oriented. For example, for almost all forms we are using in-browser pop-up windows. To display commonly used information we've used 'drawers', or basically tabs that fold out when you click on them: we use it for demos, downloads, and contact information. At the same time we have a fairly hierachical information structure: almost every piece of content is living somewhere in this structure. We have also tried to highlight clearly where the user is in the hierarchical structure. These hierarchical pieces of information are also available through deep linking, e.g. www.backbase.com/go/products_overview.php.

the wow-factor

To create the wow-factor, we decided to use many graphics and many animations. Both make the site more polished and more Flash-like, but graphics increase the download size and animation can be annoying. So we compromised a bit on the quality of the graphics and used very high compression. And for animation, we took a good look at operating systems such as MacOS X and Windows XP, and tried to design useful animations. These animations typically give feedback to the user about what is happening on the screen: for example, the main menu opens with a transition so people can see what's happening.

web-feel or application-feel?

Some GUI toolkits are only capable of creating desktop-like interfaces, which is not ideal for a content-rich website. You can also create application-like interfaces with Backbase (we will launch a desktop-like forum, and a desktop-demo soon), but it's just one of the options. Some desktop features can be useful though. For example: we've included pop-up windows on our site, and a tree view for the tertiary navigation in the documentation section. But for the rest we've focused on a web-feeling, for example by having 1 scroll bar to scroll the entire 'page'. In desktop applications you typically scroll only 1 panel (similar to using frames).

utility

People expect certain basic functionality when they are using a web page. They want to be able to create bookmarks, or forward a link to a friend. People who use an old browser, screen reader, or a mobile browser expect to get access to the content. The back- and forward buttons should work. This site should be indexed by search engines, such as Google. We needed some tricks, but we now got most of this working, although bookmarks are still not easy enough: we have to improve this.

performance

One objective which is not so difficult to achieve is to create a better performing site than comparable Flash sites. First of all the initial download time: incremental loading ensures that you don't have to load all files at once, you just load it when you need it. Of course, the images make our home page fairly large, but still significantly smaller than many Flash sites. Then responsiveness: the Backbase engine is optimized for performance so this should work pretty fine. Downloading additional information is quick because you only load the new information, and not an entire new page.

does it work?

Based on the feedback we get it appears that the majority of people enjoy using our site. Nevertheless, many people are sceptical at first, and are only convinced when they've tested all aspects of the site. This makes us extremely sensitive to problems and criticism, because we want to convince people that AJAX-powered sites can be both more usable and more fun. So if you have feedback: webteam at backbase.com, and we usually respond quickly.

PS. I'm planning to write some more about the technology behind Backbase.com, so if you have requests, let me know...

XTech Browser Tech Dinner

2005-05-29T08:21:00.000-07:00

Last Wednesday I organized a dinner for speakers at the the XTech conference in Amsterdam: we rented a boat to cruise through the Amsterdam canals. It was an interesting group of people: many Mozilla developers, people from Opera, and other browser experts such as Peter-Paul Koch. It was a lot of fun to talk to all these people. At Backbase we use the browser for everything we do, and we now had the opportunity to speak to the core developers of Mozilla and Opera. It is good to know these people in person: we were able to discuss some Firefox 1.1 issues with the engineers who are working on it. Very useful for both parties.

During the dinner I expected quite a bit of discussion about WHAT WG, XForms and the forms product of Backbase. We didn't really discuss that, maybe also because Steven Pemberton and Micah Dubinko from the XForms camp couldn't make it. So we mainly had WHAT WG people onboard, like initiator Ian Hickson, and contributor Anne van Kesteren. The next day on XTech Steven and Ian had adjacent presentations, and it became clear that both groups have their own proponents, and that the reconciliation as suggested by Micah will probably not happen anytime soon. At Backbase we have a forms model that is similar to XForms, with pure declarative markup, and focus on XML technologies such as XPath. So until a leading standard arises, it's probably best to stick to our own forms model.

At Backbase we have a new release upcoming, 3.0, and we've also demoed it during the dinner. Many people liked it, and can give it a try themselves with the free Community Edition. We also had the first builds with Opera 8 support, which pleased the Opera people, obviously.

It was also interesting to hear the discussions about the proposed new calendar plug-in for Thunderbird, Lightning: there is definitely a drive at the Mozilla team to provide a viable alternative for Outlook as soon as possible. I'd love to start using it at Backbase: together with Hula it would make a great alternative for Exchange, which we are now considering.

There was also some negative sentiment about Microsoft: not surprising with people like Håkon Wium Lie present :-). Nevertheless, most people who browse the web are still using Microsoft's Internet Explorer, so at Backbase we are maintaining a good relationship with Microsoft. And the IE7 initiative is a good development for sure, although the Avalon/XAML plans raise suspicions that Microsoft would rather do away with the Web as we know it today (not good, obviously).

I've uploaded pictures of the event to Flickr.

New website using AJAX

2005-05-10T11:57:00.000-07:00

Last week we launched a new version of the Backbase website, which now runs on the Backbase software (fully AJAX enabled). We've been able to tackle a number of typical AJAX challenges, as for example mentioned in the whitepaper by Luke Wroblewski.

Things we've solved:

Back-button
Bookmarks
Development speed

Because AJAX applications typically only have a single URL, the back-button is usually not functioning. In the Backbase software you can register changes in the user interface that should be reverted when you click on the Back-button. So you can build up a history file, and use the back- and forward-buttons to navigate through the history. Give it a try on the Backbase site.

With a single URL you might also have a problem with bookmarking. We've solved this with parameters in the URL, which are read by JavaScript that load the correct information. For example: www.backbase.com/developers loads the DevNet 'page'. Because browser don't allow us to update the URL bar, it's not possible to use Ctrl-D to add a bookmark. In a future update of the site we'll add a keyboard shortcut 'D' to add a bookmark with JavaScript.

If you do 'view source', you see that the development of the site is almost all done with extra tags, so-called B-tags. There are only a couple of lines of custom JavaScript code. Also a lot of code is in reusable skin files. If you use a B-tag, it is guaranteed to work in all browsers, so this also speeds up development.

Ajax: Where is it happening?

2005-04-02T19:05:00.000-08:00

Even with the global nature of the Internet, new technological advances can come from a specific region. I live in Amsterdam myself, and for Ajax we're not doing bad: quirksmode.org is based there, my employer Backbase is based there, and - last but not least - Amsterdam is the home town of the soccer club Ajax :-)

Silicon Valley and San Francisco might even have better credentials: the creator of the term 'Ajax' is based there, many of Google's new services have been developed in the Valley, several Dojo contributors are based there, and many more. Of course, it's not the first innovation that started in the Valley...

This week I'm visiting a friend in San Francisco, so - in addition to enjoying the city and the wonderful weather - I'm open to meeting people. Let me know at jep at backbase dot com if you're interested.

XForms Myths rebutted

2005-03-08T23:23:00.000-08:00

I’m not an XForms expert, I do not have specific interests in XForms, but I have to admit that I like certain aspects of XForms. When you’re into the XML-family of standards, it’s just a very elegant way to create form-based applications. Ian Hickson, the driving force behind WhatWG’s Web Forms 2.0, is clearly annoyed by the marketing speak of XForms proponents. I’ve added some serious and some not-so-serious comments on the arguments of Hixie, so please compare this with his article.

XForms is declarative
XForms is more declarative than HTML + JavaScript, but I think the main benefit is that 80% of the commonly used functionality is available as a tag, thus reducing the learning curve (although XForms is not so easy to learn because it introduces several more advanced concepts).

Scripting is bad for accessibility
Two competing standards (Web Forms 2.0 and XForms) is bad for accessibility, because screen readers will need to learn about both standards, instead of just one.

Script is harder to maintain than XPath expressions
I’m not an expert in this, but it seems that there are more degrees of freedom for JavaScript programs than for XPath expressions. More freedom means more power to do messy things.

HTML mixes presentation and content - XForms doesn't
Somewhat true, but I do like the client-side data instance of XForms. Some content should just be inserted server-side by a content management system, and there is no need to keep it separate on the client.

XForms is better than HTML because it is media-independent
Indeed, crap. What does the independence of the media have to do with XForms or HTML?

HTML mainly specifies how the control should look, while XForms specifies what the control should do
Yes, I think that’s a myth. From what I remember, XForms leaves it up to the XForms player to render the user interface. Just like the web browser renders the form controls.

HTML has limitations, so it had to be replaced with XForms
Yes, that’s something I can’t agree with. It’s better to extend HTML.

HTML requires authors to use hacks; XForms doesn't because is cleanly designed
Somewhat true: HTML was not designed to have client-side applications, but XForms was, so it’s easier to make a good implementation.

JavaScript switched on?

2005-03-08T22:20:00.000-08:00

Jeremy Keith argues that an Ajax application should also work if JavaScript is switched off in the browser. I think this approach will not unlock the true value of Ajax applications. In the more advanced Ajax applications business logic will partly move to the client: this is similar to how client-server applications compare to mainframe applications. For simple form validation, search queries and the like it does make sense to have a non-JavaScript version. For applications where not every mouse-click is communicated to the server and client-side logic is executed, it might be very difficult to build a non-JavaScript equivalent. I believe the browser is capable of more than just displaying static pages with a little bit of interaction: the browser is a complete software development platform. There are even people who have created a complete execution stack, with its own command prompt.

New interaction patterns

2005-03-07T13:38:00.000-08:00

In my previous post I mentioned I was looking for usability best practices for Single Page Interfaces. This was on response to an article by Jesse James Garrett that explained the technical concepts quite well, but not the usability aspects. His colleague Peter Merholz wrote a nice article about Google Maps in which he identified the core issue, I think: "how do you provide people with cues, so they know what to do, but enable new, more powerful means?"

This is probably one of the main questions that needs to be answered before you create a successful Singe Page Interface application. There are lots of new possibilities, but how does the user know about it? I’m just trying to think of a list of unexpected behaviors, but please add to it:

Drag-and-drop
Right-click and double-click
Keyboard shortcuts
Modal windows
Using decks instead of pages, enabling a more parallel workflow
Changes in one part of the screen trigger changes in another part of the screen

So which ideas are useful to explain people about these new features? Again, just some ideas:

A correct mouse pointer can give a hint that you can drag (which Google Maps is not doing, why not?)
A non-modal window can provide help (e.g. click F1 during a PowerPoint presentation to see all useful keyboard shortcuts: this is a modal window unfortunately)
Animations and effects: a good example is the cloud animation when you drag items out of the shopping cart in the Panic shop, or the Yellow Fade technique to highlight which area of the screen has changed.
Although a parallel workflow might offer many benefits, a step-wise input wizard might help first-time users
And, last but not least, it might be good to stick to well-known keyboard shortcuts, such as + and – for zoom in and zoom out (as Google Maps is doing)

As Jesse James Garrett mentioned: "[we can] begin to imagine a wider, richer range of possibilities".

Single Page Interfaces

2005-03-06T22:24:00.000-08:00

After Jesse James Garret’s article about Ajax there have been several interesting posts.

Cameron Adams argues that it’s acceptable for some sites to exclude visitors that have JavaScript switched off, especially for web applications (as opposed to content-rich sites). I agree: there are some standards-enthusiasts who promote unobtrusive JavaScript, but they usually come from a content-publishing background.

Tantek Celik proposes a new name for Ajax, to get rid of associations with soap or football clubs. He proposes Cadex, short for CSS Asynchronous DOM Ecmascript XML/XHTML. What I don’t like about both Ajax (Asynchronous JavaScript + XML) and Cadex is that they focus on technology instead of usability. What I see as the main different between Ajax and old web interface is that it’s actually a single-page interface, instead of a multi-page interface. Maybe the name it’s somewhat simplistic, but I would suggest using Single-Page Interface instead of Ajax.

To continue on the usability angle: Jason Fried explains that Ajax in itself does not improve the user experience: it enables it. The example of the Yellow Fade technique is one of the first examples I’ve seen with clear usability benefits. I’m myself working on a website with a Single-Page Interface, and it’s easy to come up with all kinds of spectacular effects, but difficult to find those effects that really enhance usability. A peak preview of what our technology is capable of can be seen in a shop and a portal demo, and the result of my project can be seen in a couple of months at Backbase.com. In the mean time I’ll be scouring the web for more usability best practices for single page interfaces. And if you know any great usability examples, please let me know.

WHAT WG or XForms: what is it going to be?

2005-02-22T14:01:00.000-08:00

Just read an interesting article on News.com, in which WHAT WG's Web Forms 2.0 is compared with W3C's XForms. A journalist from a Dutch IT newspaper called me today to ask for Backbase's opinion on this. In short, Backbase sees good things in both initiatives, but our approach is closer to XForms because of our focus on XML and declarative development (as opposed to scripting). The big difference is that Backbase Forms work in most modern browsers without plugins. I'll write a bit more about this later.

PS. also an interesting discussion on Slashdot

Dell and buying via the Internet

2005-02-11T22:39:00.000-08:00

May 2004 - On the first day of my new job I arrived at my new office punctual at 9am. I met my new colleagues, and after a while someone asked: did we buy a computer for him? Hmmm. Apparently not. No worries: the CEO gave me his car keys and his debit card and he suggested I buy a computer myself. So by 10.30 I was on my way. Unfortunately the recommended store was in the middle of Amsterdam, so by the time I arrived and found a parking spot it was 11 o'clock. Then I was waiting in line for 20 minutes in the 'fast lane', just to hear that buying a laptop did not qualify for the fast lane. Waiting. Model not in stock. Go to other store. Drive. Park. Wait in line. Then finally got it: too bad the CEO's debit card wasn’t accepted, so I had to pay for it myself. Hmmm.

After a small while, I became responsible for purchasing new computers for our company and I started buying from Dell: no hassles, just order via their website, via e-mail or over the phone. The computers are usually delivered within 2 weeks, and they offer good value for money. So if you manage to look ahead for about 2 weeks it sounds like an ideal solution.

Then some patterns started to emerge. With almost every order there was a new account manager, because the previous one was either fired or promoted. With 6 purchases over the last 8 months I had 4 different account managers. All of them were trying to sell me the professional line of computers (Latitude and Optiplex) instead of the cheaper Inspirons and Dimensions. They gave a high discount, but it was still more expensive than the consumer line. When you ask them for the differences between both lines, you hear a lot of vagaries, nonsense, lies and only 1 possibly valid reason: the consumer models change more often, which could result in higher support costs. Is that really true? I don't know, but for our company (30 employees and growing) it's certainly not relevant. One thing is sure: the Dell sales reps get more commission when they sell Latitude and Optiplex.

Of the 4 sales reps, two were fairly good so they were promoted almost immediately. Two were different, but similar in that they:
- Lacked any technical competence
- Broke their promises frequently
- Lied outright more than once
- Talked so smooth that it was either scary or hilarious
They promised things like 'I will take care of it today' and 'it will be delivered by October 1', and of course that didn't happen. They tell you lies like 'we don't sell Inspiron to corporate accounts anymore' and 'you will qualify for buying on credit'. For 5 times in a row they submitted an unsuccessful request to buy on credit (taking a couple of days), while we were perfectly happy to pay up front.

Finally I was so disappointed with the Dell sales reps that I decided to order without human intervention: via the Internet! I entered my order and indicated that I wanted to pay up front. A couple of days later the account manager called me: the request to buy on credit was denied (?), and if I could resend my order directly to him via fax. Even buying via the Internet doesn't work with Dell, apparently.

The Dell website itself is an interesting case, though: on the one hand it's great that you can configure your systems online, but from a usability perspective there’s a lot that can be improved. And they don't seem to have made any real improvements in the last couple of years. At my company we've created a demo application with some ideas how an improved Dell shop could work. It’s not intended to be completely foolproof, but it offers an interesting new perspective. Especially drag-and-drop and the animated sort-functionality are highly appreciated. Now just wait until Dell realizes their website is out of date...

Custom attribute with namespace: hasAttributeNS()

2005-02-10T11:17:00.000-08:00

A colleague today showed me that he had created a custom attribute in his own namespace. He created a small JavaScript function to sort an XHTML table, which is triggered by the attribute g:sort="yes". An example is on his webpage. The JavaScript file can be seen here.

He uses the hasAttributeNS() JavaScript as specified in the W3C DOM Level 2 specs. Unfortunately only Mozilla and Opera 8 have implemented this. I'm not sure about Safari: does anybody know more about this? I haven't see this function on Quirksmode yet. In any case, IE does NOT support this function.

Jim Ley mentioned that this will result in more complicated JavaScript code, because "IE doesn't have a getAttributeNS - you can only do getAttribute("chicken:feed") - which means you have to manage the namespace handling". I don't know what to think about that. Do you really want to handle namespaces? Or can you just do getAttribute("g:sort") and be happy with that.

Personally I'm pragmatic. I like it when scripts work on IE and Mozilla, and ideally on Opera 8 and Safari 1.2+. So getAttributeNS is elegant, but I wouldn't use it on my site. It's time for a JavaScript library that creates an abstraction layer, so you don't have to worry about all these browser quirks :-)

Custom tags, namespaces and DTDs

2005-02-06T07:29:00.000-08:00

When you want to add extra functionality to web applications, you might want to add extra attributes or tags. The idea of custom attributes is presented in a nice article by Peter-Paul Koch on A List Apart: JavaScript Triggers, and further explained on PPK's website.

In the article below I give some extra ideas about custom tags and attributes, and how they can be combined with namespaces and DTDs.

Namespaces and DTDs have a different purpose. Namespaces make it possible to mix different XML vocabularies in a single document. DTDs make it possible to check the validity of an XML document.

If you use a custom attribute ‘required’ in an XHTML document, you are basically mixing your own XML-language with XHTML. There could be naming conflicts if a future version of XHTML also introduces the ‘required’ attribute. Therefore it’s better to put your own tags and attributes in your own namespace. You indicate the namespace with a namespace prefix. This could be the result:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" >

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ppk="http://www.quirksmode.org/ppk" >

<body>
<form>
<textarea ppk:required="true"></textarea>
</form>
</body>
</html>

Then you might want to check for validity, both for XHTML and for your own attributes. Checking for XHTML validity is important to ensure compatibility with web browsers. You cannot change web browser implementations, so you better make sure your documents are compliant, otherwise your pages might be rendered incorrectly. Your own XML tags and attributes will NOT validate based on the standard XHTML DTD, regardless whether they are in their own namespace or not. But the good thing is that the browser also won’t mind about these extra tags: they’re just ignored (1).

So it’s your own responsibility to make sure that your own tags and attributes are processed correctly, using JavaScript. Then it makes sense to validate your custom markup, otherwise your JavaScript might not work correctly. For this purpose you can add your own tags and attributes to the DTD. For validation it is NOT important whether you use namespaces or not. A validating DTD parser is not even aware of namespaces (see Roland Bourret's Namespace FAQ). Validation is helpful during authoring of documents, and many authoring environments can use DTDs or Schemas for code completion and validation.

At Backbase we have introduced two additional namespaces (one for visible tags, and one for system tags), and we have implemented code completion and validation for DreamWeaver, Eclipse and Visual Studio.NET.

(1) NOTE: if you use a namespace, you have to declare it, otherwise some browsers (such as Mozilla 1.8) will display XML errors. In the example above I have declared the namespaces in the HTML tag.