Web apps

I’m using a web application for recording time with certain clients. I can’t believe how pathetic it is. To do the same job using any rich client would take a fraction of the time and be much more flexible.

I know there are many great web apps out there, and many more waiting to be built. I also recognise that the multiple user/ geographically dispersed user story is much better with server based stuff. And of course installation/administration goes away.

But I can’t help thinking the browser has an awful long way to go to come close to the richness of office. Makes me see the sense of where MS are going with Excel services. More native server friendliness directly in the Excel client might be nice  (for a better information sharing story).

Have you go any web app horror stories – something that is trivial in Office but mind numbingly painful via browser interface?

It reminds me of the project where the guy next to me had 5,000 lines of javascript to do sorting and filtering. Hello? thats like 3 or 4 lines of code in Excel/VBA.



9 Responses to “Web apps”

  1. Harlan Grove Says:

    Re native server friendliness in Excel.

    Much has been written in this blog, in the articles and responses, about versionitis. Why is that such a problem with Excel? Because it’s both too easy to dump lots of data into workbooks (an that’s only going to get MUCH WORSE with the new grid size) and because it’s relatively difficult to extract data from other workbooks and data sources.

    How could this situation be improved? First, Excel needs a built-in equivalent for the the add-on SQL.REQUEST function. Second, there should be a mechanism to tie database tables/views as (static) Tables, which implies a new type of Sheet which consists of a single table with a fixed layout, and which also implies the need for filtering/multiple-row-selection syntax in structured referencing. Finally, Excel needs a complete syntax make-over for external reference and DDE links that allows any piece of the link expression to change dynamically.

    Going further, it’d be nice to have references to database tables/views that could be used like named ranges in function calls, e.g., VLOOKUP against database tables as 2nd argument. Lotus 123 has had that facility since the early 1990s.

    Bluntly put, Excel is horrible when it comes to using data from other files. It’s too darn easy to make redundant copies of data in other workbooks. It’s too darn difficult to refer to external data dynamically.

  2. Simon Says:

    I had always thought Excel was good at external data access, but now you mention it I think I agree with you and there is much opportunity for improvement in this area.
    When I think about it I’m not sure how much progress there has been since 97 in this area. And bear in mind availability of corporate data has expanded massively in that time.

  3. Rob Bruce Says:

    I returned to Excel development about a year ago after spending a few years in multi-tier VB6 development and subsequently ASP.NET development.

    I never really ‘got’ why people were prepared to make so many UI compromises just to get their app to run in a browser – anything resembling rich functionality required a really expensive roundtrip to the server, and even then what you got was only a pale imitation of Windows/MacOS/Linux functionality.

    Alternatively, AJAX has emerged to allow mini-roundtrips, keep communication with the mothership down to a more acceptable level and create a more dynamic page refresh. Unfortunately, it seems to do this by moving business logic out of the business layer and into the UI – a maintenance disaster waiting to happen.

    Anyone else remember the advent of .NET when MSFT was pushing the idea of downloadable, one touch deployment smart clients that communicate securely over the WAN via web services? I’ve worked on one or two of these projects and, to me, they offer the perfect compromise between wide distribution and a rich user experience, but they’ve never caught on. Maybe everyone is still expecting Windows to loose significant market share and make them unworkable, or something.

    On Harlan’s point, I think MSFT has always considered it to be our job to glue Excel to a back end. It has also tended to push an N-tier architectural approach to development generally, and giving Excel direct access right into the back end data doesn’t really fit in with this, does it?


  4. Stephane Rodriguez Says:

    “It reminds me of the project where the guy next to me had 5,000 lines of javascript to do sorting and filtering. Hello? ”

    You’ve lost me here. There are a tons of Javascript libraries for doing sorting and filtering. That some guy wants to reinvent the wheel just resonates as dumb attitude to me (by default, of course).

    “thats like 3 or 4 lines of code in Excel/VBA.”

    When you do that, however, there is all the stuff that Excel implies in the calculation, locale handling that are specific to Excel, that won’t be ever ported to any other environment without a rewrite.
    Again, that’s a choice.
    Don’t forget, the Excel team at Microsoft are shipping virtually a whole operating system in the name of a spreadsheet program.

    “I never really ‘got’ why people were prepared to make so many UI compromises just to get their app to run in a browser”

    Why? Because the Excel UI is a standard UI and it can run in a web browser.
    VB6, AJAX, I don’t know how many acronyms you can throw here, but one thing for sure : if you don’t use the right technology, it sucks. Let me put some irony here recalling a customer story downloading 3GB reports off the web (only to be unable to do so because Microsoft’s wininet library is capped at 2GB per connection).
    I can also second that in the BI world, the future is web-only software. Even if you are not much involved in BI, just do some research.

  5. Simon Says:

    Why did you go back to Excel? (I’ve tried the VB/ASP/.net escape route, but it was not financially appealing).

  6. Rob Bruce Says:

    Simon, partly for personal reasons that you’ll appreciate are irrelevant to an Excel blog, partly because every VB or VB.NET job I ever had would sooner or later disappear to India after the R&D phase had been completed, and partly (related to the latter) because I saw a gap in the market for small scale systems targeted at local/regionally-based small organisations. In my opinion, this type of system is the least likely to get outsourced to the other side of the world.

    Stephane, I wasn’t talking about the Excel UI in particular, but rich UIs in general. I’m not sure that I understand your point. Excel doesn’t run in my browser, by the way.
    I do agree with you about using the appropriate technology, but that also includes not using a technology that forces the user to jump through hoops just to get at the information s/he needs and not using a technology that forces the developer to jump through hoops to provide a decent UI.
    You’re right that the future of most business software is web-orientated, but Web=/=Browser: Web=HTTP, and thick, rich HTTP clients are not dead yet.

  7. Harlan Grove Says:

    I got off-topic before. Sorry.

    I’m a user rather than a developer of browser-based apps, so I may have simplistic views. If the bulk of the software is running locally with the data stored remotely/centrally, how does this differ all that much from the diskless Unix workstations of the 1980s and 1990s? Possibly naive, but that seemed to have worked because the OS and network were set up to work that way – optimized for two-direction data flow of the same magnitude. Browser-based apps may be able to fetch large amounts of data, but they seem to choke on sending large amounts of data, though that may not be the apps’ fault but rather the ISP restricting outbound bandwidth.

    I’ve avoided the UI issue. I can’t help thinking that the old X Windows or current Terminal Services approach is the better way to go, but I realize that the powers that be are fixated on browsers. Looking just at one aspect of browsers, it doesn’t seem to be possible to move objects in the browser dynamically. I just searched for online drawing programs – there are several – but none of the half dozen I tried allowed me to select anything and move it around the canvas the way Paint does. That seems to me to be a critical barrier: browsers can’t change what the user sees without some action that’s equivalent to either a refresh or loading a different url.

  8. Harlan Grove Says:

    I take back my previous UI comments. Google Spreadsheets allows me to move charts around the worksheet.

  9. Stephane Rodriguez Says:


    I can’t name a UI functionality in Excel that is unsuitable for a web browser. That’s probably because Excel is a standard UI. Ironically enough, it’s new technologies such as Microsoft WPF that put new apps at odd with everything that exists (users have to learn new UI paradigms before they can do anything).

    “Excel doesn’t run in my browser, by the way.” Tried Google docs and spreadsheets? EditGrid? Zoho?

    “You’re right that the future of most business software is web-orientated, but Web=/=Browser: Web=HTTP, and thick, rich HTTP clients are not dead yet.”

    This era of fat clients has come to an end. It’s over.

    As for Web=HTTP, I’ld like to add that HTTP is the cross-platform conduit at the basis of the web. And that anybody can implements its own protocols on top of it. For instance, you can choose the ratio of requests sent over through the wire, in order to limit the number of requests, the size of requests, and so on. Along this, it is possible to provide what works best.

    Technologies like ClickOnce don’t work outside intranets. Reason is deployment of .NET apps/addins is extremely problematic (I’m being nice to describe what is actually a major cluster fuck). You can find VSTO horror stories everywhere you go.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: