How much effort should be invested in developing UI's for web apps? - Hendrik Swanepoel

Hendrik Swanepoel

How much effort should be invested in developing UI's for web apps?

I know a lot of web developers and developers that have to code web applications from time to time. The funny thing is, all of these developers hate coding client-side javascript - I would know, I hate it too sometimes. 

I'm not just talking about client-side validation - this is a must according to me. I'm talking about UI's that operate in their own framework. This will include stuff like functions to launch certain content in formatted pop-ups - without needing to understand the plumbing of the code. Also needed is dragging functionality for these pop-ups, scrolling capabilities for the pop-ups, etc. And rich functionality like this needs to be downloaded, so to try and avoid huge downloads, a download on demand model can be implemented.

A UI like this definitely gives you an edge in the market. It's easier to demo your tool to potential customers, people are rarely impressed by a demo if you have to keep telling them how cool the product is. It's sad but true, but people are more impressed by a product with a nice (and easy to use) look than a product with excellent functionality.

The problem with coding these nice interfaces is that nobody wants to specialize in it. Developers tend to think of Javascript and client side coding as grunt work. A designer designs the look and feel, but a developer must still make it work - due to a fact that most designers' Javascript knowledge is extremely limited.
Complicated Javascript takes ages to code, due to a a few factors:

  • The debugging is horrible - to date I haven't encountered a decent debugger for it. For example, one of the rich web apps that I had to write references around 10 different separate .js files. When an error is encountered with the functions in these referenced files, IE just notifies you of the line it occurred in the file - but not the file it occurred in. To make matters worse, these files aren't all referenced from the start. The UI works with a download on demand model, so that needs to be tracked too.
  • An unexpected limitation always curve balls your master plan. Even if you always provide a POC for the UI before starting to code, some limitation always hinders the development. Most of the times a workaround can be found, but this invariably takes a lot of time.
  • The stabilization period takes much longer, due to the fact that a lot of user acceptance testing must be done on the UI.

I agree that it's real important to have an intuitive and well designed UI. The problem is that it takes much too long to implement and it limits the available time to spend on the server functionality.

An obvious solution is to get somebody that specializes in UI building, so that the “real” developers can focus on what they want to do. But where to find such a person? I've never came across somebody that specializes in front-end javascript coding.

Then there is another solution - The smart client application model. The smart client approach gives you both from both worlds. It allows you to provide a rich UI, and even allows the user to work offline.

It can also be kept up to date by use of the .Net Application Updater block.  This alleviates the problem of administration and versioning of the product.

This doesn't mean that smart clients will replace web applications. Web applications are still great for apps that doesn't require rich UI's and it's platform independent.

But I'm really excited about it, this may mean that we'll have to struggle less and less with web UI coding, and focus more on “real” coding.

Posted: Mar 08 2004, 11:02 AM by hendrik | with 3 comment(s)
Filed under:

Comments

Colin said:

I don't know about specializing in javascript code, but I spent some time getting to grips with "real" javascript programming. Not just writing button click code, but looking at the object orientated side of javascript. It's a very powerful language, being able to create classes "on-the-fly" and attach properties and methods to existing objects. You will find that you can develop a "toolbox" of classes and methods that get used over and over. It's a different mindset to strongly typed languages. I have been meaning to look at how jscript.net is implemented, but I haven't got round to it yet.
# March 8, 2004 12:37 PM

Hendrik said:

Thanks for the comment! I do indeed use my own javascript objects, and have an extensive toolbox by now.

For example: http://dotnet.org.za/hendrik/archive/2004/03/02/571.aspx.
I also have a very useful class which controls the UI components and tools that I download dynamically from the client side on demand. This is helpful in our wysiwyg editor, because it prevents functionality from downloading each time - only on demand.

The problem for me with the javascript route isn't the reusability of code, but the debugging if something goes wrong and the limitations set by the browser.
I just find client side coding takes much longer than server side coding - and I had to work with it quite a lot the last 6 months, so perhaps I'm just a bit tired for it by now :).

Do you perhaps know of a cool Javascript debugger?
# March 8, 2004 1:02 PM

Colin said:

The only half decent debugger was the previous version of visual studio (v6, interdev), you could see all the local objects etc, but even that was a bit lame. What I found was the most efficient way of coding was to develop/test against mozilla, because the javascript compiler was stricter, and all those little typos and gremlins were found a little quicker.

Unfortunately you need to write some very "defensive" code to trap invalid inputs if you want any hope of tracking down bugs, and for me the most frustrating thing was definitely the browser limitations.
# March 8, 2004 1:22 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: