iRider - The browser UI that should have been...

I promised to talk more about iRider and why it kicks so much ass compared to "tabbed" browsers...

First, iRider isn't a full blown "browser" exactly. It is just a shell that wraps around IE. It is still the IE engine that does the HTML rendering while iRider replaces the address bar, toolbar, status bar, side-bar, and navigation features. Under the hood pages still load up using IE.

That means that if IE can display the page, so will iRider.

It also means that the plug-ins for IE are available in iRider too. The only thing you might miss are the third-party toolbars (like the google toolbar and similar).

The most striking thing you'll notice about iRider is the side-bar. Instead of using tabs along the top, pages open in the side-bar as you navigate the web.

The sidebar takes up a good bit of horizontal space, but with modern screen resolutions this shouldn't be a problem for many people. If you are using a widescreen monitor (and really... who the fuck isn't?) then you probably have plenty of horizontal space to spare anyway.

The sidebar can have a lot more pages open without crowding than you get with tabs. It also displays much more information about the open pages.  With tabbed browsing, you get less room to show the page titles as you open more and more tabs.

The sidebar contains a thumbnail, progress bar, page title, pin button, and close button for each open page.

You can control how big the items in the sidebar appear... specifically, how big the thumbnail image will be. If you are like me then you don't care about thumbnails, so you can shrink them to make more room for more pages! If you prefer visual cues then you can make the thumbnails big, or even huge.

The side-bar gives you a visual relationships between pages. Pages from the same site are grouped together. As you click links, pages in the same site also indent below the page you came from. This visual navigation history really beats the crap out of the old back button.

That's all cool stuff, but iRider's real strength is in the many more subtle features.

Left-clicking a link opens a new page in the main window. The old page remains in the sidebar so it is easy to get back to it.

Right-clicking opens the link in the sidebar, but leaves the main window where it is. This is similar to the "open in new tab" command in tabbed browsers, but is a lot less annoying. This is called "surf-ahead" in iRider.

How often have you opened several tabs in IE or Firefox, then had trouble figuring out which of the 15 tabs contain the pages you haven't looked at yet?

The sidebar in iRider has an elegant solution to this problem. That progress bar serves two purposes. It tells you if a page has finished loading yet, but then it stays lit up after the page loads until you've looked at the page. You can glance at the sidebar and see instantly which pages you've looked at and which you haven't.

Another set of cool features are the bulk-operations.

If you want to open a bunch of links from a page at the same time? Just drag-highlight the links and right click. ALL of the links in the highlighted part of the page will open at once!

The sidebar has bulk operations too. If you want to close a bunch of pages at the same time (and this will come up often) then you can just click-and-drag over several "X"s at once. All of them will close when you release the mouse button (excluding pinned pages).

The sidebar allows you to "pin" pages too. Clicking the "X" will not close pinned page (which prevents accidents with the drag-click closing of several pages at once). Additionally, pinned pages automatically re-open when you launch iRider. And pinning can be done in bulk with click-and-drag in the same way that the close button can.

iRider also has several neat enhancements to the "favorites" that allow you to do neat stuff too. You can create favorites that open multiple pages all at once. I have an "AtWork" favorite that I use to open about 6 to 10 code reference sites at the same time. I have another one for news sites that will open all of my favorite news outlets in one click.

The ideas in iRider's UI are very well thought out, elegant, and graceful. The iRider developers really understand the idea of how users "surf" multiple pages and sites.

It is depressing that most of iRider's features remain obscure and have gone unnoticed by the major browser makers. The UI in iRider is at least 5 or 6 years old now.  But the best that Firefox, IE, and Safari have managed to give us is crappy-ass "tabbed browsing", which is a clumsy and user-hostile shadow of what iRider offers.

OH MY GOD! Someone Put Tabs in My Pants?!

Software is very much like any other business. Sometimes it isn't the best idea that wins in the market. All too often the winner is just the one that happens to get noticed first.

Back when browsers were evolving in the 90's, Netscape was king and they had a head start on that whole interweb thing by several years. By 1995 when the net was getting popular, everyone else playing catch up to Netscape.

The easiest way was to just copy Netscape, change the colors, then make millions selling the resulting knock-off browser.

Netscape was making its millions giving away their browser for free, so there must have been some sort of quantum economics that made this a compelling business plan for everyone else. But a lot of companies entered the browser market and all of them wanted the whole Schrödinger's pie!

The problem was that Netscape's products were total crap even by the modest software engineering standards of the time. Other than being first to market they had little going for themselves.

Among Netscape's many flaws was that it was a Single Document Interface (SDI) design. SDI just means that it can only have one "document" (or web page in this case) open at a time. If you wanted two web pages open you had to open two whole instances of the application.

I always suspected that the SDI nature was just that Netscape's programmers lacked the skills to build a good Multiple Document Interface (MDI). But around the same time frame there was also a bizarre religious movement among programmers. The new doctrine claimed that MDI was bad and that SDI was the way to go.

Its hard to tell if the SDI trend was started by Netscape's success with a high-profile SDI application, or if it was just that Netscape became the misguided poster-child for this really fucking dumb-ass idea...

Through the last half of the 90s, nearly all other browsers were playing copy-the-leader with Netscape and so nearly all were SDI clones of Netscape's design. Eventually Netscape imploded due to a combination of bad products, a bad business plan, and real competition from very experienced software shops. Microsoft got the blame for it all, but in reality Netscape was pretty well doomed from the start. All Microsoft did was speed it up.

The only relevant exception to the SDI browser design was from a little company called "Opera" whose developers realized that people often wanted more than one web page open at the same time... I know... fucking crazy right!

But Opera didn't gain much of a user-base since you had to pay actual money to get the Opera browser back then and everyone knew that paying for a browser was a violation of human rights or something.

So by the start of this decade, Opera was just sitting there being awesome while everyone else was using IE instead.

The whole MDI vs. SDI concept is still hotly debated in the developer community today, but most developers have conceded that some apps lend well to MDI while others should go SDI. And most of them also concede that a web browser is an obvious candidate for an MDI design.

Those Netscape developers managed to get their new owner, AOL/Warner, to continue to pay them. So eventually they managed to write a new browser for the open source Mozilla project. Fortunately, they had also learned how to code better and so Mozilla turned out to be quite a good browser.

But no one really cared much about Mozilla until someone decided to try out that whole MDI thing. The Firefox browser was born and with it the fascination with what we now call "tabbed browsing".

Tabbed browsing is just an MDI design with lipstick. The use of MDI in Firefox was trivial, but it was still refreshing enough to get regular people to notice:

"Oh my god!
Look at this!
You can have more than one page open at a time!
And there is a little tab at the top!
Amazing!
Firefox is better than sliced bread!
M$ sucks!
Open-source rawks!"

Of course MDI wasn't new, tabs weren't new, and Firefox was about as revolutionary as shit-stained underwear...

But Firefox did at least get MDI concepts noticed by the mainstream market at least.

After Firefox, Microsoft and the rest had little choice but to start the copy-the-leader game all over again.

Now they all have tabbed MDI designs.

But what frustrates me is that tabbed browsing is not really all that great an idea compared to other possible approaches. Before Mozilla released Firefox, there was already a much better MDI design in the browser market.

That browser is called IRider. It  might have spurred some real advancement in the browser UIs had it just gotten the attention it deserved.

I'll discuss iRider more in another post...

Why is my phone bill so high?

When you think about the U.S. phone system, you have to be amazed! Copper and fiber wires running all over the country connecting nearly every home and business, plus all the equipment in between that makes the magic happen. Its massive and staggering in both scale and complexity.

All that infrastructure cost a fortune to create, but it must also be enormously expensive to maintain and keep up with too.

So when you think that a phone line only cost between $20 and $30 a month, it really is a pretty sweet price tag.

In contrast, cellular networks must be dirt-ass cheap to both create and operate.

Sure, you have to have lots of towers and connect them all via fiber or copper wire... but that is nothing compared to the sheer scale and fagility of the old system of wires.

Upgrading and maintaining the cell networks has to be far easier than sending technicians out to each individual home every time something needs connecting, breaks, or when construction crews dig up some back-woods line somewhere.

And never forget that once upon a time the phone companies were only able to sell one phone line per household. But cell networks can sell one phone line for each member of each household. So the entire size of their market is much larger than the size of the old phone market.

So why then does my cell plan cost $80 per line?

Sure I have data services, but I had that on my land-line once for only $10 extra and it worked a hell of a lot faster than my cell phone's connection.

My cell phone is portable and more convenient than my land line, but the wireless aspect is what should be saving my phone company an embarassingly large amount of money.

I can call the entire U.S. on my cell phone without paying any extra, but that doesn't cost the carrier significantly more than a local call does either.

So what am I actually getting for all that extra money? The cell phone doesn't do anything I couldn't do with my land line, and much of it the land line did better.

I guess the only reason my cell phone bill is $80 is because customers are willing to pay that much.

Its too bad the artificial barriers to entry are so high in the cell business. If entry wasn't controlled by so much regulation and real competition was allowed into the cell market I wonder how much my phone bill would be now?

Train or Checkpoint?

Caress made the ultimate statement while playing The Darkness for XBOX 360 the other day.

"They really should put a checkpoint at the end of the tunnel!"
 
-- Caress Redd

I agree...  they really should...

Graffiti Beta 1 - Review (part 2): Performance

I finally ran some simple performance tests on Graffiti Beta 1. By simple I mean that only a stopwatch and web browser were used. The purpose was to get a general "feel" for Graffiti's performance with a large numbers posts in the database.

I ran the test on a Dell Inspiron Laptop (2GHz Core Duo, 2GB Ram, 7200 RPM HDD) running Windows Vista 32bit, IIS 7, and SQL Express 2005.

Since I was using my own development laptop, and it has limited free HDD space, I changed the DB recovery mode to "Simple". No other database tuning was performed.

To generate the data I just created a SQL Schema project in Visual Studio 2008 Team System then created a simple data generation plan. The generated data included 5 categories, 100,000 posts, and 200,000 comments. The posts were split evenly among the 5 categories. Comments were also split evenly among the posts (2 comments to a post). 

Results:

100k posts and 200k comments:

• Graffiti was able to display the user facing pages with only a minor performance impact.
   
• The initial load of the site's home page took nearly 5 seconds.
    
• Refresh of the home page took less than 1 second.
   
• The initial load of a category page took about 2 seconds, with refreshes being nearly instant.
   
• Clicking the "older posts" button in any content list took about 4 seconds. Once loaded though, revisiting those pages was nearly instant.
   
• Loading a content item's view took about 1 second on first load, and was nearly instant thereafter.
   
• Loading the control panel resulted in a SQL Timeout error every time.
  

  Looking at the queries in SQL Profiler: It performs a select count against the posts table, probably for use by the summary chart on the dashboard.
    
  Testing the query manually: about 1 minute and 30 seconds to count through the table using the same where and group by clauses. Counting the posts without any where or group clauses still takes around 30 seconds. HDD throughput was at 100% during the entire duration of the query's execution.
   
  This is an area where a full version of SQL server on a dedicated piece of server hardware would make a huge difference. This kind of query bottlenecks on the low throughput of the laptop's hard drive... Low HDD performance is a typical problem on any laptop though.

 50k posts and 100k comments:

• User facing pages loaded with no noticeable performance problems. Speeds were a little snappier than with 100k posts especially on initial page loads and when using the pager in content lists.
   
• The admin dashboard page loaded in 17 seconds on the first load, and was nearly instant on subsequent loads. The "posts" tab of the admin section was the slowest, taking about 28 seconds on the initial load, and about 9 seconds on subsequent loads. The "comments" tab of the admin tools was surprisingly snappy, taking only 3 seconds to load initially.  

Conclusion:

Graffiti beta 1, without special optimization, should be able to serve the needs of most realistic sites in it's target market.

Even on a modestly equipped laptop, performance did not significantly degrade until the number of posts exceeds the 50k mark. On real server hardware it would probably be able to handle well over 100,000 posts with little problem for the end users. The admin tools will degrade more significantly than user-facing pages.

Oddly, the number of comments seemed to have little impact on overall performance.

Looking at the queries that had the most significant performance problems, it will be rather trivial for Telligent to either optimize the queries for larger numbers of posts, or provide alternate configurations that trade convenience features (such as daily report generation rather than real-time reporting) for better performance.

Reality Checks:

• If you actually have anywhere near 100k posts, you probably are not going to be using any off-the-shelf product without significant customization and DB tuning anyway. Keep in mind that it takes 273 posts a day to get to 100k in a single year. Only a large news outlet is likely to generate that quantity of content and most of them would still take a few years to break the 100k mark.
   
  However, 100k comments isn't too terribly unrealistic for a very popular site.
   
• There is one major difference between this test and a production environment of Graffiti. In a production situation, Graffiti would have created one folder on the file system for each post that was created via the GUI tools.  Within each generated folder would be a generated "default.aspx" file. The main purpose of these files is to give IIS a default document to use since the graffiti URLs don't specify actual page names. Graffiti also stores a little bit of metadata in these files that can help it render the posts faster (it doesn't seem to have trouble rendering the post if these files are absent though).
  
  I was unable to quickly find a convenient way to mimic how Graffiti generates these folders and files without resorting to writing a custom app of my own... but this is a simple test, so I deemed it not to be worth the effort.
  
  I personally would not want to deploy Graffiti on a large scale without a way to disable the creation of these files and folders. Strictly speaking, this feature is only necessary on IIS 6, or IIS 7 when using the classic asp.net pipeline. It would not be unreasonable to expect that Graffiti will support the IIS7 integrated pipeline in the future and allow the per-post folders and files feature to be disabled (please!).