News Flash

Every attendee to http://FutureOfWebDesign.com gets a free copy of the Web Designer's Toolkit ($95 value): http://j.mp/webdesignkit

Author Archive

18 September 2008

The internet would never have become the phenomenon it is today without the web browser; the simplicity of the browser concept allowed the Web to grow rapidly. Developers just had to write basic text documents using a simple markup language (HTML) and the browser took care of everything. As websites became web applications developers still did not have to deal with the complex task of building client applications in the traditional sense: make it work in a browser and anyone can access it without having to install any new software, no matter what device (or OS) they are using.

While the browser makes life easy in many ways for developers it also throws up certain challenges. Major software companies such as Microsoft, Adobe and Google are now trying to address these challenges, albeit in different ways. This article will focus primarily on the option of building desktop applications, what the key drivers and considerations are, and how this may affect the future of the web browser.

What are the Challenges?

The recent launch of Google’s web browser is the latest shakeup in the browser wars that have raged for over a decade. Of course, competition has been good for the evolution of the Web, by bringing us new technologies such as CSS and Ajax and driving adoption of web standards, but there has been some negatives.

The inconsistencies between browsers have always been a major headache for developers. What works in one browser doesn’t always work in another or, worse yet, works differently. Many of the latest web applications now utilise Ajax for a superior user experience, but unfortunately Ajax libraries are so bloated to handle cross-browser quirks that they can cause performance problems. Even with the latest “standards compliant” browsers a lot of time has to be invested in making web apps work and look the same across IE, Firefox, Safari, Opera, and so on.

Today’s web apps are complex and, perhaps, pushing the browser to its limit. Other technologies are emerging to try and help developers build the next generation of Rich Internet Applications (RIAs): Flash has been around for many years, but now Adobe offers Flex and Microsoft have given us Silverlight. In the context of the web browser these are great options and will certainly challenge the traditional mix of HTML, JavaScript and CSS as the standard way of building web apps.

These new technologies are still running up against one of the age-old challenges: the more browsers do to protect the user from viruses, spyware and the like the more these security barriers limit a web app’s interaction with the user’s PC. Uploading your latest holiday snaps to Flickr is a painful process, primarily because anything running inside a browser is abstracted from the user’s desktop.

In addition, a number of social networks and services have run into the other major challenge with browsers: if the user does not have the browser open with the site loaded and are looking at it they have no idea what’s going on in their network. This creates a level of separation between the app and the user which is problematic if part of the application’s benefit is live data.

What’s the answer?

The problem of keeping users up-to-date when the browser is not running (or the app is not loaded in the browser) has seen a raft of third party desktop applications pop-up. For example, just look at the array of desktop applicationss for Twitter (Twhirl, Twitterific, Snitter, Tweetr, Twitteroo), FriendFeed (AlertThingy, Sobees, Feedalizr) or Facebook (FizzBoost, Facebook Desktop Client). These are just a small selection from the vast number out there.

These have been made possible by, firstly, the growth in web apps providing developers access to their functionality via APIs and, secondly, by the increased ease of building desktop applications. While developers have been focused on the Web (browser) as the main app platform the major vendors have been working on ways to make traditional desktop application development faster and more accessible. The latest and most popular of these is Adobe’s AIR technology which allows developers to use the knowledge and skills acquired from building web apps to develop cross-platform desktop applications. Using HTML, JavaScript, and CSS you can now build a fully-functional desktop application with AIR that runs on PC, Mac and Linux.

Desktop applications have a number of advantages over those that run in the web browser. They provide an “always on” method of communicating with the user. AlertThingy, for example, can hide in the system tray, but pops up an alert in the bottom right corner of the screen whenever a new notification comes in. They also have far greater access to the users’ system than anything running within a browser: uploading files suddenly becomes as easy as drag’n’drop; user data can be saved on the user’s machine; and the app can continue to work without an internet connection. These benefits can be put to incredibly powerful use in building feature-rich apps that provide a great user experience.

Providing users with a web-based interface and a desktop version with additional functionality is not a new idea, nor is it the preserve of Web 2.0 start-ups. Microsoft Outlook, with its companion web app version, Outlook Web Access, is a well-known example of this, having been around since 1997. Fortunately, the technology available to developers has come a long way since 1997: a benefit of Adobe Flex is that the exact-same app can be hosted within AIR or the browser; you just have to disable certain features in the browser. That’s both options covered with very little extra work.

The traditional difficulties associated with building desktop applications are done away with with technologies such as AIR. Not only can you use web development skills to build a desktop application, but the runtime also takes care of features like the ability to have the application automatically update to new versions. By building within a runtime, the developer does not have to worry about the awkward plumbing of desktop apps, such as minimizing to the system tray. Plus, Dreamweaver suddenly becomes a desktop development IDE!

Important considerations

There are some important questions to answer when deciding to build a desktop application. The first is whether it is really necessary. Many web apps work perfectly well within a browser and would not add any benefit for the user by having a desktop version. Building a desktop application just because you can is not a valid reason.

Next, however easy it is for a user to install an application there is still the question of whether they will. Some are put off by the idea of installing something on their machine and will choose not to. You are adding one more barrier to entry that does not exist with traditional browser-based web apps. Will the user see the benefits and that they outweigh any reservations they may have?

Finally, it is important that as an industry we do not go crazy building desktop apps. The swelling numbers of Twitter, FriendFeed, Jaiku, etc. desktop clients is already creating problems for users who do not want (or have space on their screen for) so many apps. When we released AlertThingy, we received a lot of feedback from users asking us to add certain features just so they could stop using one of their existing desktop apps and use AlertThingy instead. This takes us back to the issue above: will users want to install the app? The more apps they have the more challenging this becomes.

One area in which this can be addressed is that there are different types of desktop app. If your potential app is providing basic information requiring little user interaction or a small amount of screen space then Mac Dashboard widgets or Vista Sidebar gadgets are a great option. They are easy to develop (again utilising web technologies), lightweight and easy to install.

Is the browser a dead man walking?

I mentioned earlier Google’s latest browser, Chrome, which comes bundled with Gears. It is an attempt by Google to increase the install base of Gears and drive development of Gears-based apps. They are certainly highlighting other features of Chrome but Gears is most likely to be Google’s motivation for investing in their own browser, especially as it will benefit their own applications, such as Google Docs.

This situation is interesting because Gears attempts to overcome the issues discussed above, like Adobe AIR, but using the browser instead. This strategy could mark a new dawn for the web browser, which some believe will lead to it replacing the desktop OS (or at least rendering it redundant) but consider this: the Web is more than the browser, so much more, and with the growth of APIs and web-enabled platforms should we not look beyond the browser as the only client in future?

The first generation iPhone used the Safari browser as its application platform for third-party developers. This had limits and developers were desperate to be able to build native iPhone apps. Apple has now given developers that ability through the iPhone SDK. Many of these iPhone applications will be web apps (communicating with server-based applications) but not browser-based apps. We have seen a much more rapid growth in these types of applications compared to the previous Safari-based ones. And it’s not just the iPhone, surely a Java app on a Nokia phone is more powerful than anything running with the phone’s web browser?

As our TVs, cars and even fridge-freezers become internet-enabled the reach of the web app grows, but many of these devices will never have a browser. I have always found it strange that people think of what they see in the browser as the internet but not their email. As we move forward developers will be focusing on building internet applications, rather than browser-based apps, which can be accessed by a multitude of more powerful native clients on different platforms.

With Chrome joining IE, Firefox, Safari and others the browser war is set to rage on but the glory days of the web browser itself may be past.

Continue reading 2

8 May 2008

As an agency that helps clients in the web start-up market to design and build web apps, Howard Baines is familiar with the popular approach of using open source technologies and tools to get the job done economically. We’ve worked with PHP, Rails, MySQL and others, and have experienced the highs and lows of doing so. Late last year we decided to fly in the face of popular opinion and build a web app of our own… using the Microsoft platform.

Deciding on the app

We decided to build a meeting organizer application which we called ‘Meet with Approval’. The application allows anyone who wants to arrange a meeting to create a dedicated event page with date and time options and send out email invites. Invitees can then select the dates that suit them, add comments and are informed when the meeting is confirmed. We knew that from a technical perspective we wanted to use some AJAX, incorporate maps and integrate with third party services such as Plaxo and PayPal.

MeetWithApproval

Our aim was to have an application that we could use to experiment with new concepts and technologies whether open source or paid for. The process of designing and building the application would provide a case study for us.

How to measure success

Our clients share key goals when it comes to web development: minimize development time to get their product to market faster, to start generating revenue and gain a competitive advantage; reduce development cost; and improve reliability. A reliable application requires less ongoing investment and is available to users more of the time, which maximizes revenue earning opportunities.

This means we need development tools that allow us to reduce development time and labor while delivering maximum reliability and a fantastic user experience. These were the challenges and benchmarks against which we wanted to test the Microsoft offering.

The development process

For those unfamiliar with Microsoft their platform is the .NET Framework and for web this means using ASP.NET (http://www.asp.net). At the time we were building our application Microsoft released the latest version of .NET and their development tool Visual Studio 2008. Possibly the main argument against using Microsoft from the open source point of view has been the issue of expense. However the .NET Framework can be downloaded for free plus they also provide ‘Express’ versions of Visual Studio and their SQL Server
database software which we used and are also free.

Visual Studio - MeetWithApproval

A key benefit of new web specific frameworks such as Rails is that they allow rapid development of common features. Visual Studio provides a number of prebuilt web controls that we were able to drag and drop onto our pages and allowed us to get a considerable way before having to write any code. A criticism of this approach is that such controls output bad HTML or restrict design however we did not find this. We were impressed by the way in which .NET produced relatively little code and we were able to apply all styling via CSS. Visual Studio 2008 offers a full WYSIWYG editor with CSS support that we found to be better than Dreamweaver although we did find rendering problems within the IDE when coding for cross browser CSS.

When it came to coding we used Microsoft’s latest data access offering called LINQ (Language Integrated Query). LINQ offers a way to access data held in a database or other format such as XML using a single language. The concept is not new and other frameworks and scripting languages offer a similar approach.

Data Schema - MeetWithApproval

The real bonus came in the form of the InteliSense in Visual Studio which not only made learning and writing LINQ queries fast but also supported our underlying data model. InteliSense within Visual Studio included support for frontend JavaScript which again helped to speed up development. Moreover the InteliSense features really cut down on the number of time wasting runtime errors and helped to reduce bugs. In fact using the various prebuilt controls and functions of .NET helped us to significantly cut down the number of bugs.

One of our objectives was to provide a great user experience and today that frequently means using AJAX. Visual Studio 2008 has inbuilt support for Microsoft’s own AJAX libraries called ASP.NET AJAX. While these can be used independently and scripted against like JQuery Visual Studio provides a number of controls which can be added to by downloading the AJAX Control Toolkit. Once again these provide great AJAX features such as the textbox auto complete. We did script against the AJAX libraries to integrate the Plaxo widget with our AJAX functionality.

Using Plaxo (Free) was one example of where we integrated non-Microsoft services which included PayPal and a Yahoo! Geocoding web service (Free) which we used together with Microsoft’s Virtual Earth (Free).

Thinking about moving to .NET?

For any developers considering making the change to .NET Visual Studio 2008 makes it extremely easy. There is a range of programming languages to choose from including C#, VB.NET, J# and IronPython which means there is probably one that suits your taste. For Rails developers there is IronRuby and an MVC Framework currently in pre-release versions. The Microsoft website provides articles and tutorials for transitioning from other platforms such as PHP to ASP.NET and there is a wealth of blogs and websites with code examples or ‘Starter Kits’.

Whatever your preferred approach or experience there is probably something for you in the Microsoft offering and in many cases the IDE and integrated stack bring benefits over other development options we have tried.

How it worked out

Within three weeks we were able design, develop and deploy our application at extremely low cost. Since launching in late 2007 we have had only 2 bugs reported with over 2000 users in the system and over 500 meetings created. We felt that we were able to deliver on our objectives of fast, cost effective, reliable development that produced a great user experience which you can judge for yourselves at www.meetwithapproval.com.

Meeting Microsoft

We caught up with Microsoft at the October Future of Web Apps in London and discussed our experiences. They were excited to hear about what we had been doing and chose to write a case study about Meet with Approval.

A common misconception is that companies of the size of Microsoft are remote from small businesses. The truth for us has not been the case as we were invited to take part in the official press launch of Visual Studio 2008, SQL Server 2008 and Windows Server 2008 on 27 February in London. We were along side a select few companies that included McLaren, EasyJet and Grey Group.

Our case study is now available on the Microsoft website as part of the Heroes Happen Here Launch Evidence (www.microsoft.com/ casestudies).

Despite the frequent criticisms of Microsoft we have learnt that this should not be a barrier to prospective start-ups when looking for a suitable technology platform. Microsoft is clearly working hard to be friendly, accessible and cost attractive to entrepreneurs and potential start-ups.

Continue reading 2

Sign Up to our Newsletter

Enter your e-mail address below to receive regular updates on web design, web development and web business. Subscribe today and receive a free 44 page PDF "Designing Web User Interfaces" by Ryan Singer of 37signals.

Subscribe to the Think Vitamin articles RSS feed

Future of Web Apps Dublin May 14 2010

News

Twitter

Follow us on Twitter

Subscribe

Article Subscribers

Feedburner blog subscriber indicator

News Subscribers

Feedburner blog subscriber indicator

Subscribe by Email

You can receive Think Vitamin updates via email. Just pop your email address in the box below and click the arrows.

Subscribe by RSS

You can also receive new Think Vitamin posts via your RSS feed reader

Subscribe RSS Think Vitamin is a proud member of the Smashing Network

Ads Via The Deck