John Wood

Will Web 2.0 Lead to HTML's Demise?

When the web first took off HTML was quite primitive. It handled flow layout well, could provide tables for more complex layout, and was able to post data back to a server to provide some degree of interaction, to name but a few features. When it came to presentation though, it really wasn't that much more advanced than, say, Word.

But there was one common thread between all web sites: they had a monopoly on both the user interface and content of their site.  If they wanted to provide news, then they would decide how it gets rendered. If they wanted to provide a shopping cart then they would decide how that would look.

As HTML has matured so has its place in the browser. Technologies such as more advanced scripting capability (DHTML) and more advanced data integration technology (AJAX) have transformed the role of HTML from the only way to access content on the Internet, to Just Another User Interface technology. As HTML advances, more emphasis is put on client-side processing. This is the basis of Ajax for instance. But with this emphasis comes a natural progression from tightly coupled content and presentation to loosely coupled. More and more sites are separating their content from their presentation, simply because it's more scalable and makes for a better user interface experience.

And so, as Web 2.0 permeates throughout the Internet, the HTML monopoly diminishes.

The best evidence of this is the huge explosion of mashup websites over the past year. But while these mashups are implemented in HTML using AJAX, they certainly don't need to be.

The next best evidence is the popularity of RSS. Many people interchange the terms RSS and blogs, but they forget that RSS is actually the largest movement so far to separate content from presentation. It's the first real liberation of HTML from the Internet.

When you take HTML as being Just Another User Interface Technology, it suddenly doesn't look so great. Sure it has some fantastic layout features, but no matter how you twist and mould it, at the end of the day it has its roots as being a document technology and not an application user interface technology. All the recent advances in HTML just make it more and more like a smart client technology. This puts it in a new realm, with new competitors. It puts HTML up against a whole new standard of quality.

The browser of yesterday is an HTML rendering tool. The browser of today and tomorrow will be a navigation tool at best. HTML might have a place for adhoc information pages, much like a magazine. But when competing with other user interface technologies - WPF, WinForms, Flash, to name a few - it really is inferior.

Humans are generally lazy creatures. They like convenience. This is one reason why the Internet has become so popular - it's just so convenient to have all that information brought together in one place. More power to Google for creating a convenient tool for accessing this information. But only now is it becoming clearer that even searching for information is a burden.

The ultimate in convenience is not searching for information, it's having an application that can search for you. RSS aggregators can bring together news from all over. Kayak.com can bring together flight information from most major airlines in the world. But these really only scratch the surface of what's possible.

Mashing up information is the first step. The next step is to scale this and really innovate with the user interface. Realtime results, advanced graphing, being able to process more data and extract more information and present it in less space will be the key to future mash-up applications. We're talking about pushing the user interface technology beyond simple document layout. HTML just won't cut it for this demand. Consumer demand for convenience will drive the focus away from HTML and towards smart client technology.

And, ironically, Web 2.0 is the catalyst for this change.

Has all this been said before? I think there's something new to say now. The landscape has changed drastically over the past year or two.

Ajax has taken off, RSS has taken off - both of which are tearing apart HTML sites. Then we have important advances in smart client technology. As more computers come with .Net 2.0 installed, there are more computers capable of running ClickOnce based websites. ClickOnce provides the means to run rich .Net code in the browser with the same peace of mind you have viewing HTML. Sure the Google spreadsheet may seem quite an accomplishment, but only because they've written a spreadsheet in Javascript, an interpreted, typeless scripting language. It really wouldn't take much for someone to create a .Net spreadsheet and have this hosted on the web, running seamlessly and safely in the browser. And Google's spreadsheet will look FAR inferior next to this rich client technology.

And then there is WPF, even WPF/E for non-Windows platforms. With incredibly rich three dimensional graphics, WPF offers to bridge the gap between the dazzling experience we get from the graphics we see on television and how we experience information on the Internet. It's only a matter of time before every computer is capable of running WPF just as transparently as HTML. For creating superior looking web sites in the future it won't be a question of HTML vs. Flash, it will be HTML vs. WPF.

These transitions will come, it's just a matter of time. The clock is ticking for HTML, and all these Web 2.0 companies investing billions into HTML will ultimately be left behind.

When Coder Turns Father

Can it be? Some words emanating from my fingers that have nothing to do with technology? It's true. This is a personal post. It's Fathers' Day weekend and, well, I have something to say about it, and it's not in C#.

Being the father of a 15 month old has been such an extraordinary experience it's something I can't help but write about.  Given it's father's day weekend, why not share the experience with everyone else?

I can't say I wasn't scared at the prospect of having kids. My wife always wanted kids, and so did I. The only difference was that I used to joke that I wishes children would be born 10 years old, to avoid the whole diaper changing, sleepless nights, temper tantrum-ridden terrible-two years and, well, all the joys I thought being a father was about.

That wasn't really what I was scared of though. It was more finding space in my life for kids. I spend so much time working on software, the the rest of my time with my wife and... well, sleeping, I honestly wondered how I would ever make room for the hundreds of hours a week of attention that a child demands.

Throughout most of my wife's pregnancy I hardly tried to imagine what life would be like after my daughter was born. That always seemed to be a different phase of my life that I would tackle when it arrived.

All my friends also joked (or half joked) that the end of my life as I knew it was imminent. They warned me that nothing would be the same again.

Well, they were right.

Not only did my life change, but I feel like my life began when my daughter was born.

She is such an amazing and delightful character. Somehow, through some kind of mysterious magic (or perhaps genetics), she seems to have become this perfect combination of my wife and I. Beaming with everything I love about my wife, she's exciting and fun to be with and I miss her like crazy when we're apart.

When you have kids, it's not just you that changes. The whole world changes. Now you look at everything differently. You experience everything as if it's the first time you've experienced it. You have a new best friend to share everything with. More importantly you're now a family, not just a couple. This seems to elevate your status in the world, you become a bigger person.

The knowing looks you get from other fathers when your kid is crying in the store, or running around screaming with excitement, is like a passport into a secret fathers club. They've all been there before. With a simple (manly) nod you're saying 'respect, i've been there too and you're doing a great job'.

Having a child teaches you more about life and humanity than you could ever learn any other way. The most important lesson for me was that logic and reason (or more precisely algorithms and software) can't explain everything. When your kid wakes you up in the morning with a beaming smile, run up to you and hug you, or laugh and kiss you on the cheek - you realize that nothing else matters in this world. Not even Ajax.

So if you're a workaholic like I am, and are scared to commit to having kids - don't shy away from it. It's time to wake up and smell living, it changes everything for the better. And don't try to imagine what it's like, because you just can't. It's one of those things you only understand when it happens to you. Believe me.

Plus you get to use father's day as an excuse to buy yourself a new gadget.

Optimizing Reflection

For the purpose of optimizing an application of mine I set out to evaluate the performance of retrieving members (eg, GetField or GetProperty, anything derived from MemberInfo) from a Type.

I created a test to see whether it is faster to cache the MemberInfo in your own hashtable, or whether the performance of the GetField and GetProperty functions are actually more optimized than a simple hashtable lookup.

The setup was a class that contained 21 fields and 21 properties, 42 members in total (excluding the constructor).

I stored a list of these member names in a string array. I then looped through some code that looked up the MemberInfo for each member, and repeated this 20,000 times.

The second test cached each MemberInfo in a hashtable, and the loop instead retrieved the data from the hashtable rather than from the type.

The result was quite surprising.

The first test, using GetField or GetProperty, took about 3.8 seconds. The second test, using the hashtable, took 0.19 seconds. That's about 20 times faster. This was .Net 1.1 - in .Net 2 it's about 8 times faster (reflection was optimized in version 2).

So if you're have some code that makes heavy use of GetField/GetProperty methods, you may want to conisder caching them in a hashtable first.

What is Ad-hoc Reporting?

Most applications have some form of reporting. Any printing of data is, in essence, reporting.

When you need a report you're often looking down a list of available, stock reports, looking for one that may include the data you were looking for. It's often the case that you need to print several different reports and then piece the data together yourself, to get to what you want.

Report generation is often a complicate thing, and a task most definitely suited to a programmer. Using tools such as SQL Query Analyzer to develop the query, Visual Studio to write the code that executes the query into datasets, and then Crystal Reports to design the actual report. Not to mention the complexity of deploying the report to the users, and training the users how to read the reports.

At many companies I've visited the typical turnaround for a report is a couple of days for a simple report, and maybe even a couple of weeks for the more complex reports. It's common for there to be a backlog of reports waiting to be developed.

Because of the time involved in generating these reports, and the never-ending changing of requirements that mandates new reports to almost constantly be developed, reports are an expensive and frustrating business for many companies.

But help is available.

Reporting doesn't have to be difficult. At a fundamental level reporting is just about extracting data from a database, applying some degree of filtering, joining and formatting and presenting it. The fact this is a complicated procedure is purely because of the tools that are used.

Ad-hoc Reporting refers to a type of reporting application that allows power-users to produce their own reports with little technical knowledge. No programmers, no designers, no SQL and most importantly no wait.

Typically an Ad-hoc Reporting tool presents a view of the database's structure, and the user visually drags and drops the fields from the structure onto the report - specifying any filtering, grouping or sorting they wish to apply. The report is then saved and can be pulled up and executed any time the user wishes: The report is under total control of the user.

There are no deployment issues with Ad-hoc Reporting tools, other than installing the tool itself and a viewer. Many Ad-hoc reporting tools are web based, making installation unnecessary.

The best aspect of Ad-hoc Reporting tools is that they put users in charge. The users know what data they need, and they can go straight in and pull it out.

Of course there are some disadvantages.

For one, the database is a shared resource. Managed reports (ie. Those that are not ad-hoc) are crafted by technical engineers who understand the database and how far it can be stretched. They ensure the queries are using indices, for example, and that the user cannot download so much data that the database grinds to a halt. With ad-hoc reporting you have few safeguards to stop the user from hogging the database and slowing everything down for everyone else.

While ad-hoc reporting tools provide users with the ability to construct quite complex queries, they won’t be able to do everything. Some complex joins and custom calculated fields may not be possible for the user to produce.

Also, there will be some training involved to get the users constructing their own reports. With managed reports they simply had to click a link and maybe enter some parameters to launch a report, now the bar is considerably higher.

But for many organizations the benefits outweigh the drawbacks. The cost savings alone make it worth installing and training users to create their own reports.

More Information

Microsoft have a video on setting up the Report Designer (Ad-hoc reporting tool) that comes with SQL Server 2005. You can watch the video here.

ANN: FTP Upload Utility - ftpupload.exe

Here's a free little utility I wrote for uploading files to an ftp site in one command, from the command prompt. You can download the utility here.

We all know that downloading files from an FTP site is easy, you can do that in explorer. But uploading is a bit more tricky. You can use the ftp.exe command from the prompt, but this requires you to understand the FTP commands. The ftp program also doesn't allow you to automate uploads because it requires user interaction.

Uploading files automatically is exactly what I wanted to do, so to solve this problem I created a utility whole sole purpose is to upload a file to an FTP server.

To upload the file you simply run:

ftpupload [servername] [username] [password] [serverpath] [localfile]

Where...

servername = the host name of the server, eg. ftp.yourdomain.com.
username = the user name used to login to the FTP server
password = the password
serverpath = the path on the server to put the file. If this includes spaces, enclose the path in double quotes. eg. "/files"
localfile = the file on the local machine to upload. If this includes spaces, enclose the file in double quotes, eg. "c:\myfiles\blah.zip"

Files are uploaded in binary mode. Progress is indicated as the file is uploaded.

I find this utility particularly useful for backing up files to a web site automatically, as the upload can be run from a DOS batch file on a schedule.

Let me know if you find any bugs.

User Interface Cross-Roads

We've hit a cross-roads. If you had to decide, today, which technology to use in order to create the user interface for a consumer application, which direction would you go? It seems that more options are being added to the list every other week. Lets look at technologies available today:

1. Win32 App, developed in VB6, C++, Delphi etc.
2. .Net WinForms, smart-client
3. .Net WinForms running in a browser deployed with ClickOnce. Admittedly not much different to above, but you do have to take special precautions with how you're interacting with the system to ensure you don't step outside your privelege box.
4. .Net ASP using server-side controls and viewstate.
5. Atlas with ASP.
6. Standalone Atlas with no ASP side.
7. Plain old HTML and JavaScript.
8. Flash.
9. Java. Yes people are still developing in client-side Java.
10. Microsoft's Script# - developing HTML/JS with C#.
11. Google's Web Toolkit - developing HTML/JS with Java.
12. WPF - not released yet, but something many companies are using already and would be stupid to ignore.
13. WPF/E - unless you're targeting multiple platforms (on, like, the Internet), then you need to write to a subset of WPF with JavaScript as your language.
14. Access. Ok I had to mention this because believe it or not you can still create those forms-over-data type apps using Access without having to touch a line of code.
15. DOS. Ok maybe that's taking it too far.

Alright I'm sure there are a lot more options. But it does go to show you that the simple question 'what should I write this in?' isn't quite so simple to answer. The front-runners would have to be Microsoft and Google, but which do you bet on? Microsoft may even be competing with themselves to take developers away from WinForms and ASP and move them to WPF.

These are difficult times for developers. Hopefully in a few years the path will seem clearer, in the meantime all we can do is take a gamble.