Phil Bernie Consulting

Tomato Sauce is horrible on its own. In fact, it’s that bad that people dare each other to drink glasses of Tomato Sauce after a big night out. Despite the repulsion one might have to an individual serve of Tomato Sauce, it is actually brilliant when added to a meal. It adds taste and flavour to all sorts of meals including meat, chips, hamburgers and hot dogs. However, Tomato Sauce needs to be kept in place. Too much of it, and suddenly the meal it’s being added to, doesn’t taste so great, in fact it’ll ruin most meals if not used in moderation.

When it comes to building web applications that utilise AJAX, I consider AJAX to be akin to Tomato Sauce and ASP.NET akin to a Meal in that I love AJAX when it’s used to compliment an application, but absolutely hate it went it is applied so thickly that it ruins the application.

AJAX has been around for a good while now and I would have thought that people would understand that AJAX should be considered a complimentary tool designed to help add those nice extra touches to your ASP.NET applications, not the cornerstone for all architectural and design decisions involved in your application. One recent discussion I had with a solutions architect resulted in the solutions architect telling me that they were going to build the entire application using AJAX.

I felt like saying “I’m sorry, but you’re actually going to build an application using nothing but Asynchronous JavaScript and XML calls? That is very impressive”

If you were invited over for dinner and the host said “I’m going to cook you roast lamb, but I know you love tomato sauce, so Instead of using lamb, I’m just going to make the whole roast out of tomato sauce” I’ve got no doubt you’d be finding yourself suddenly busy that evening.

In recent times I’ve seen and heard of applications that seem to have been completely consumed by AJAX to the point that they’re just a horrible unmaintainable mess of hacks and JavaScript and like someone pouring a litre of tomato sauce onto a steak, the application is horrible to consume. It becomes slow and unresponsive, despite the fact that this is what AJAX is supposed to address and maintenance becomes a nightmare.

Like sauce, AJAX lends itself to being used more in some applications than others. You’d have no problem applying sauce liberally over a plate of chips, but you might just want a dash of it with a steak. Similarly, AJAX lends itself nicely to applications like google calendars and google maps, but it doesn’t really work so well when it comes to complex workflow applications or a web site like SMH, so you need to consider how much AJAX to use when designing your application.

So much hype has been generated about AJAX in recent times that you could be forgiven for thinking that AJAX will actually build applications for you, but developers really need to start understanding that AJAX is designed to complement the tools you already have and is not meant to be consumed on it’s own.

When I first started working in my first grad position, the company I worked for used Lotus Notes. Now before people start saying “Lotus is really powerful, but most companies just don’t configure it correctly” let me just say that’s nice, but I don’t care. The fact that most companies can’t configure it correctly doesn’t make my life easier. Besides, it wasn’t so much Lotus Notes I had a problem with, it was the Lotus Notes client that sucked, and it still sucks. When it comes to email clients, I don’t care how whiz bang super ajax Web 2.0 your web based client is, I don’t care how open source it is, I just don’t care about it if it isn’t Outlook.

And it seems like the more I use Outlook, the more feature I find that the competitors just don’t have. Like today, I found Custom Views.

If you don’t know what custom views are, then you’re in for a treat. Today I was trying to organise my emails into folders and I found this little drop down on the menu bar:

Having no idea what it was I clicked it and found out that this little dropdown was the custom views dropdown. It was like I was discovering outlook all over again for the first time. After about 30 seconds of playing with it, I was saying Bye Bye rules and folders for sorting and saying hello to harnessing the power of custom views.

So by default the custom views defined are pretty sweet

You get

1. Messages – A standard message view
2. Messages with AutoPreview – Same as messages but previews unread messages
3. Last seven days – Self explanatory
4. Unread Message in this folder – again self explanatory
5. Sent To – Shows who messages were sent to
6. Message timeline – This is a funky view that shows all your messages organised in a groovy little timeline
7. Outlook data files – Shows outlook data files
8. Documents – Shows emails with document attached

Whilst these views are a pretty good start, the real power comes with the last option to define your own views.

Clicking on the “Define Views” option bring up the Custom View Organizer:

From here you can create your own custom view or modify the existing ones

Click on the new button and you get to create a new view.

You can choose from all different type of views:

And then it’s time to get view crazy!

The view builder lets you organise your data in pretty much any way you choose.

You can add your own fields to the view, group, sort and most exciting of all, filter them.

You can even edit the filter SQL to tweak it to exactly what you want:

You can also use the “Other Settings” to do a ton of other cool things like enable autopreview, reading pane and format the text in the columns if you like.

This is extremely helpful for me as I’ve been able to setup views for individual clients, help desk cases and personal emails which allows me to quickly access all my emails when I need them.

Just another reason why there is no alternative when it comes to email clients than Outlook

Following on from my post on WPF in browsers I began to think that some of these problems could be overcome if the browsers themselves exposed some sort of API that allowed programmers to interact with certain events happening in the browser. For example, when a user clicks a back button or performs a page refresh, or resizes the browser, it would be extremely useful if there was a standard JavaScript browser API that would allow developers to know how users are interacting with their application.

By doing this, hosted applications like those being developed with WPF and Flash would have some way of interacting with the browser and by doing so, would enable these applications to deliver a truly rich user experience.

I understand that security is a concern, but really… how much damage can people do by knowing what that a back button even has been raised?

But think of the benefits of being able to detect a back button click and save someone’s work without them knowing, or picking up the browser size and re-laying out your webpage to suit.

I think the push for Web 2.0 Applications and rich user experiences are fantastic, but with a little help from a standard browser API I’m sure the future Web 3.0 applications will be much easier to build and blur the lines even more between desktop and web applications

I’ve been using Windows Vista for a few months now and it’s been an interesting experience. Some things I like a lot, like the Aero interface, the new users directories (“C:\Users\Username” just makes so much more sense than “C:\documents and settings” although I think they could reduce it even further to be C:\usr\UserName but it’s a start). Other things I don’t have much time for, like the sidebar or the new security features which I’ve turned off.

One thing that really annoys me is that I’ve noticed that Vista can come to a grinding halt at times, particularly if you’ve been doing anything in Visual Studio and the only thing to get my snappy responsiveness back is rebooting. But I hate rebooting, it takes up to 15 minutes sometimes and I don’t have 15 minutes to be waiting around to check my emails so I just plug away with crappy performance till I can’t take it anymore. Then I reboot and curse myself for not doing it sooner because everything is just so much quicker. So to ensure that every day I have a nice responsive machine when I start working, I’ve decided to schedule reboots for 3am every morning.

At first it wasn’t completely obvious how I would do this, but a quick search reveals that there’s a pretty nifty little utility called shutdown.exe in the C:\Windows\System32 folder. All I needed to do was go to Control Panel -> Administrative Tasks -> Scheduled Tasks and add a new task which fired up shutdown.exe with the –r –f switches. –r tells your machine to reboot, -f tells it to force all running programs to exit. After that it was a one way street to waking up to a nice responsive machine every day.

On a side note, I don’t know why I should have to do this… I don’t have an underpowered machine, this thing has 4gb ram, dual core processor and 2 video cards running in SLi. To be honest, the whole concept of not being able to leave my computer on for months on end really doesn’t impress me much. I get a 5.8 windows ego experience index which as far as I can tell should mean I’ve got more than enough grunt to leave this thing running forever. With a Mac and OS X I can leave that thing on till the end of the world pretty much and never have a problem. If the only thing that the Windows team worked on for the next release was superior uptime I’d be a much more satisfied user.

At first, allowing WPF to run in a browser sounds great. You get to maintain a single code base between your winforms and webforms apps, you can simplify deployment and as Scott Hanselman explains you get to use the full .Net 3.x framework in your browser. However a few things have been bugging me lately about WPF in browsers and it’s made me think that maybe it’s not such a great idea.

1. Like AJAX, Flash and anything else that breaks the traditional HTML page model, using WPF breaks the back button in the browser. This might not sound like a huge issue, but accidentally hitting the back button in your browser window before you’ve saved your WPF application data is a one way street to customer complaints. I’ve lived through this problem with AJAX and it isn’t pretty. Customers expect that all native browser behaviour will work when you’re developing an application that runs within a browser, regardless of if it’s a web application or not.
   
2. With WPF, it’s not easy to send someone to a specific page within your application. One of the most infuriating websites on the planet is www.seek.com.au because you can’t copy and paste the URL from a job page into an email or messenger window and post it to a friend because you get a stupid session time out error. Not being able to send people to specific places within your application via URL is something that I’m not sure I’d be willing to sacrifice for smooth graphics.
   
3. Like Flash and Java applets, WPF apps deployed in browsers would appear to have the same problem of needing to have the entire application downloaded to the client machine before you can start using it. This might be ok for a couple of simple page applications, but if a user has to download even 5 mb of data each time they want to use the application they’re not going to like the initial load time, even if responsiveness is better once they have the application loaded.
   
4. I did a bit of research on web services from WPF apps and my basic understanding of the process was that when calling web services from within browsers and it seems that all web service requests need to be routed back through the hosting server. So you essentially send your web service request to the hosting server which then forwards it on to the actual web service. The results are then sent to the web server which then forwards it back down to the client. This is not only an awkward way of programming it also creates double the traffic. Also, according to WPF Wonderland you don’t get access to the WCF from within an XBAP so again, you’re losing some connectivity options. UPDATE: Thanks to Walt in the comments for pointing out that this issue is now fixed. Check here for more info.
   

I haven’t gone into the SEO and accessibility issues that you’re also going to encounter with WPF applications in web browsers because I think it’s a bit of a moot point as the types of applications being built using the WPF aren’t usually going to be exposed to google for searching and whilst they may need to address accessibility issues, they generally aren’t going to be available to the general public so you should be able to control the impact of accessibility issues. Having said that, it’s important that you realise that there will be SEO and accessibility issues when deploying WPF applications for browsers.

To be clear, I like the concepts behind WPF and it got me excited thinking about deploying a WPF application to the browser, but once I started to think about the potential problems with WPF it no longer felt like it was the best way to approach building a complex application that needed to be deployed via the web. So whilst I’ll look forward to the future developments of WPF, for now I think I’ll be sticking to the tried and true ASP.NET development model.