Snip/Shot by Toddy Mladenov: Technology

pipes If you are one of those people who get overwhelmed with information then you may try using technology for pre-sorting it for you. I certainly am such a person – I like getting more information but so far I couldn’t find good way to keep track on the latest and greatest. Having in mind that I have full time job and quite busy life, I am still looking for the perfect technology that will deliver the right content to me at the right time. Unfortunately I have to deal with the current state and use whatever is available.

For me RSS feeds are not enough. I like the bloggers but (I hope they will forgive me) I don’t want to read every piece of crap they put in front of me through their RSS feeds (the same way I don’t expect you to read every piece of crap I write:)). There are a bunch of feeds filtering web sites where you can go and filter your RSS feeds using keywords (you can read about some in Josh Catone’s post 6 Ways to Filter Your RSS Feeds). I took those as a starting point and here is what I came up with.

Blog Aggregation Pipe

Using Yahoo Pipes I created a giant pipe where I dumped the RSS feeds from blogs I currently try to follow - a bit over 30. This became my Blog Aggregation Pipe.

You do that by just adding Fetch Feed Source and typing the RSS URL in the available input box. The benefit of having pipe like that is that you can easily add additional RSS feeds by just adding one more entry to the source.

Topic Funnels

After that I created few other pipes each one of which filters the content for specific topic. Everyone of those pipes uses the Blog Aggregation Pipe as input. Those pipes I use as Topic Funnels – for example this is the Analytics Funnel.

You create this funnel by using the Blog Aggregation Pipe as a source and passing the output from it through a Filter Operator. Here is how the configuration looks like:

I went with the basic approach – filtering only the title for particular keywords. Going forward I will try to improve the filters based on the posts I read and the keywords I see in those posts but for now I think this is enough.

One thing you need to be aware is that browsers cache the content of the pipe and if you test you changes in the same window you may start seeing the same results again again – either use Ctrl+Shift+F5 or just open new window when you run your pipe.

Time to Go and Read

Once you have all the funnels configured you can click on the conveniently located Add to Google button after you run the pipe. The neat things about Google Reader are that it marks certain posts as Read once you read them as well as it allows you to add notes to the posts (something I always wanted Outlook to do:)).

Now I think I am all set to read only things I am interested in and don’t spend time on random posts.

Very often I participate in discussions where web response times are discussed and I hear all kind of strange statements (called “crap”:)). While browsing the Web for the last 13 and so years, starting with slow (9.6Kbps) modem connection over analog telephone line and ending with quite satisfying (6Mbps) broadband one I can certainly say that I’ve build my own opinion. When I hear statement “typical page load time is 6 sec” I get really pissed off. I want to scream: “Are you nuts?!!!! 6 sec is ridicules time! Who is going to wait 6 seconds for your crappy page to load?”

I remember few years ago at SAP when we developed one of the first WebDynpro application and our prototype page loaded in… (hold on)… 20 mins. And I remember the time before SAP when colleagues of mine developed online PDF merger that presented the success page with link to the merged PDF after… (hold on again)… 20 mins (I don’t know what is so “typical” about the number 20 but they really responded after approximately 20 mins of time). Twenty minutes is totally unacceptable response time for any application (not only Web) and this examples triggered research I did years ago (SAP one is from 2003 and the PDF one from 2001) to understand what are the acceptable response times in Web space. After searching Google for the PDF scenario and reading the UX guidelines for the WebDynpro one, the number 3 stuck in my mind and I can’t get it out now.

3 seconds is the response time you should not exceed on the Web! That’s it!

Searching in Google today here is one of the top results you will receive The Psychology of Web Performance. I really like the following sentence from the post:

“Keep your page load times below tolerable attention thresholds, and users will experience less frustration (Ceaparu et al. 2004), lower blood pressure (Scheirer et al. 2002), deeper flow states (Novak, Hoffman, and Yung 2000), higher conversion rates (Akamai 2007), and lower bailout rates (Nielsen 2000).”

10 years ago when the modems ruled the world the goal was to create small pages that can be served fast via modem connection. Today we create huge pages that contains tons of images, videos, style sheets, JavaScripts, Flash and who knows what else. Some of these can exceed few hundred kilobytes. However users don’t care how big the pages are; they don’t care how many images there are on the page; they don’t care how many servers are in your web farm. Most of the users don’t understand the mechanics behind the page, and why should they? The only thing they care about is how fast your page is loaded via their 6Mbps broadband connection.

Here is my table for tolerable response times on the Web. It is based on the post above as well as on Response Times: The Three Important Limits.

Response Time	Analysis
<0.1 sec	I don’t think you can achieve this one on the Web (if you can, the the user’s browser will not be able to render it:)) but it is goal that you may want to pursue.
<1 sec	Your page load time is great. You can continue to improve your performance but only if you don’t have better things to do.
<3 sec	Your page load time is OK, however you need to keep an eye on it. You are on the border for broadband users. However if this is the load time over narrowband you should not be worrying too much.
<4 sec	This is the limit for broadband users. I certainly think you have a problem if your users need 4 secs to load your pages and I will suggest you spend some time improving your performance.
<6 sec	You are on the border for narrowband users. Performance should be one of the things you should be thinking already.
>6 sec	You are amateur:) Your web site may still be visited but you will lose visitors (approx. half of them including myself). If you don’t care keep going.

Few more things that you need to think about when you exceed the 1 sec threshold. The first one is that you need to provide feedback showing the user you are still working on the request. Modern browsers do provide progress bar although it is not useful all the times because it spins like the hourglass in Windows without giving you any indication when the result will appear. If you go above the 6 seconds threshold you must think of ways to change the workflow or even the architecture (we managed to solve the 20 mins issues above only through major changes in the architecture).

Although performance is not the only key it is one of the keys for your web site’s success. If you target the thresholds in your performance testing you will surely be screwed because you don’t account for the unknowns and you will surely exceed the threshold. What happens next – the user moves on.