The Artima Developer Community
Sponsored Link

Weblogs Forum
When the Browser is an Inadequate Interface

48 replies on 4 pages. Most recent reply: Mar 17, 2005 9:36 AM by Erik Neu

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 48 replies on 4 pages [ 1 2 3 4 | » ]
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

When the Browser is an Inadequate Interface (View in Weblogs)
Posted: Feb 28, 2005 9:36 AM
Reply to this message Reply
Summary
I believe that using a typical web browser as an interface to certain online services is inherently flawed and a better separate technology is need.
Advertisement

I have been using SourceForge.net a lot (I just made release 2.1 of the YARD parser and release 1.0.0 of the OOTL library) and I am really frustrated with the web interface. It is very slow and complicated and lacks a lot of features. It also requires numerous other pieces of software to access advanced functionality (such as ftp, sftp, ssh, cvs, etc.). I do not believe the problem with SourceForge however is the fault of the implementation, but rather the fault of the limitations of using a web browser and http!

In the case of SourceForge for developers, the most logical choice of technology for implementing the interface is html. There are several reasons for this AFAICT:

  • it is platform independant
  • a client already exists on virtually every machine
  • designing and modifying the interface can be quickly and easily done
  • the interface metaphors are widely known, understood and tolerated

I want to explain why I said "tolerated". If I wrote almost any piece of PC software for a client (say for the sake of argument a word processor) which had the same kind of user interface as a web site (e.g. didn't save work on crashes, pauses of multiple seconds, etc.), they would fire me. We have become very complacent with regards to web site interfaces, simply because it is the best that exists.

My point is that a web browser and html is not the best possible technology for sophisticated online services. We see far too many broken ad-hoc javascript implementation which attempt to address these issues but they always seem to succumb to the fundamental flaws of http technology. I propose that we need a new kind of technology for these kinds of web services which require logging in and manipulating information online.

Any thoughts or comments? Would you like to see a new kind of interface to your online services which was easier to use for you and your clients?


Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: When the Browser is an Inadequate Interface Posted: Feb 28, 2005 11:35 AM
Reply to this message Reply
I have also provoked some discussion on the same topic at Joel on Software : http://discuss.joelonsoftware.com/default.asp?joel.3.86173.5

Jeremy Huiskamp

Posts: 3
Nickname: kamper
Registered: Feb, 2005

Re: When the Browser is an Inadequate Interface Posted: Feb 28, 2005 6:00 PM
Reply to this message Reply
No offence, but I thought that much was obvious. There certainly are people working on solutions already. I have seen some nice slightly-fat client stuff from Microsoft (although I'm not very familiar with it).

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: When the Browser is an Inadequate Interface Posted: Feb 28, 2005 6:22 PM
Reply to this message Reply
> No offence, but I thought that much was obvious. There
> certainly are people working on solutions already. I have
> seen some nice slightly-fat client stuff from Microsoft
> (although I'm not very familiar with it).

And then there is Swing. There are some big enhancements in JDK 1.5.

Plus, IBM is basing the entire line of Express products on a UI based on SWT. This is software aimed at small-businesses.

So, yes, HTML is a pretty ugly UI for many more involved applications. It is also more work to develop apps with HTML. Honestly, I think having to write request-response controllers for every single user interaction with the UI is a terrible waste of development time, IMO. Why not use a more intelligent UI toolkit, such as Swing? This is really an issue of code resuse. An XHTML/JavaScript-based UI toolkit is long overdue, I think. And applets may have a comeback, anyway, because of the JDK enhancements (JAR caching, etc). So maybe that rich-client "HTML" UI is actually Swing?

Kirk Knoernschild

Posts: 46
Nickname: kirkk
Registered: Feb, 2004

Re: When the Browser is an Inadequate Interface Posted: Feb 28, 2005 7:55 PM
Reply to this message Reply
Imagine if each day you went to work, your IDE was a browser. I doubt it would take long for a career change to occur. Yet, when we develop these intranet applications, we make our end users work hours each day in the very environment we would never work within ourselves. All for the sake of ease of deployment.

Ged Byrne

Posts: 22
Nickname: gedb
Registered: Nov, 2003

Re: When the Browser is an Inadequate Interface Posted: Mar 1, 2005 1:59 AM
Reply to this message Reply
I abandoned Word a long time ago in favour of a very simple Wiki interface.

At the moment most fat client applications are more frustrating than a web interface.

I choose a Wiki because it is clean and simple, and offers the functionality I need.

Michael

Posts: 12
Nickname: target
Registered: Jan, 2005

Re: When the Browser is an Inadequate Interface Posted: Mar 1, 2005 3:35 AM
Reply to this message Reply
> I abandoned Word a long time ago in favour of a very
> simple Wiki interface.
> At the moment most fat client applications are more
> frustrating than a web interface.
> I choose a Wiki because it is clean and simple, and offers
> the functionality I need.

Yes, I think the same way. Many desktop applications are very complex for end users. They have so many different controls, unusual screens and so on.

It is harder to create 'complex' and 'hard-to-learn' interface using HTML (but possible :). And, yes, it is easier to deploy and it could be accessed from extranet.

So performance is the only issue for me (but important one).

Michael
http://www.targetprocess.com
XP Planning & Bug Tracking Tool

Dennis

Posts: 1
Nickname: diong
Registered: Feb, 2005

Re: When the Browser is an Inadequate Interface Posted: Mar 1, 2005 1:29 PM
Reply to this message Reply
> I do not believe the problem with SourceForge however is the >fault of the implementation, but rather the fault of the >limitations of using a web browser and http!
>

I have to disagree with this statement. SourceForge is difficult to use because, though technical functionalities are all present in the site, it lacks effective usability and interface design.

Though browser and http lacks the richness of fat client apps, putting high regard to user interface design, color, layout, typography: graphic design stuff, http and browser based applications can be as equally effective as fat client ones.

Steven Elliott

Posts: 1
Nickname: selliott
Registered: Dec, 2004

Re: When the Browser is an Inadequate Interface Posted: Mar 1, 2005 3:17 PM
Reply to this message Reply
If SourceForge is your only metric then you'd be right in coming to the conclusion that you have. But with a little knowledge and techincal creativity (you know the kind that got you hooked on programming in the first place and that you apply to every task that comes your way) then I think you would find how exciting interface design for VERY complicated web applications can be.

Writing Web interfaces requires a broad knowledge of HTML, CSS and JavaScript (not to mention SMIL and SVG coming to a browser near you soon) as well as traditional UI tools (i.e. case tools, flowcharts). These tools can provide you with drag 'n drop capabilities, dynamic pages which refresh or retool only those parts that need it without requiring an entire page refresh, undo capabilities and if something catastrophic does happen you can log back in and resume working up until the last action you took. It is just a matter of programming.

Personally, I think it is a fallacy to say that the tools do not exist to make sophisticated application interfaces for the browser. It may be true that not many people make correct use of these tools so that web application interfaces are generally bad. But that says more about the inadequacy of the programmer than the browser.

my €0.02

Joe

Posts: 24
Nickname: larson
Registered: Nov, 2004

Re: When the Browser is an Inadequate Interface Posted: Mar 1, 2005 7:25 PM
Reply to this message Reply
> I abandoned Word a long time ago in favour of a very
> simple Wiki interface.

Please, this is such a simplification! You obviously used the wrong tool. Word is a word processor and Wiki is collaboration / web management tool. There is no way that you ever get the same control over formatting of a page in Wiki (or therefore html) as you get in Word. Not to mention all these features that we take for granted: spell checking, table of contents etc.

> I choose a Wiki because it is clean and simple, and offers
> the functionality I need.

Well as I sad, you obviously wanted a totally different functionality. The clean and simple user interface of Wiki consists of cryptic formatting tags that are even different to existing html tags. I really thought with the advent of WYSIWIG in the mid 1980's we got over that stage!

Please try to tell the average secretary to replace Word with Wiki...

Joe

Posts: 24
Nickname: larson
Registered: Nov, 2004

Re: When the Browser is an Inadequate Interface Posted: Mar 1, 2005 7:43 PM
Reply to this message Reply
> Why not use
> a more intelligent UI toolkit, such as Swing? This is
> really an issue of code resuse. An XHTML/JavaScript-based
> UI toolkit is long overdue, I think. And applets may have
> a comeback, anyway, because of the JDK enhancements (JAR
> caching, etc). So maybe that rich-client "HTML" UI is
> actually Swing?

Years ago I played around with my own JavaScript UI toolkit. Meanwhile there are some open source projects around that address that. But at one point (hehe, maybe 3 days into development of my UI toolkit) I realized that whatever I come up with could be done simpler and cleaner in a java applet.

I never really understood why java applets did not take off. They got stuck at the level of dancing duke. I remember having a presentation in 1997 where I announced that soon Microsoft Office would be replaced with a set of applets... The java powered browser would be the next operating system...

I don't believe that java applets will have a comeback. Lets face it it is possible for almost a decade to write browser hosted applications with a rich UI, but nobody wants it. Nobody does it.

I see mostly rich clients supported by good IDE support to take this place. They will be deployed via the internet but no need to host them in a browser.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: When the Browser is an Inadequate Interface Posted: Mar 2, 2005 2:10 AM
Reply to this message Reply
The main reason that Java applets never got anywhere is because of the amount of downloading required before they worked. When applets came to the market the majority of people were on dial-up, pay-per-minute Internet connections. Applets of useful complexity took a prohibitive time to download.

Connecting to the Internet is a lot faster and cheaper now but still nothing is more offputting than to see an interface that consists of a grey square with "Please wait while the applet loads." on it.

V.

Ged Byrne

Posts: 22
Nickname: gedb
Registered: Nov, 2003

Re: When the Browser is an Inadequate Interface Posted: Mar 2, 2005 6:33 AM
Reply to this message Reply
How many use Word for the fine layout of docuemnts. My wife's a teacher and her school create a range of documents in Word, such as lesson plans and class lists. Many developers use Word to create specs and test scripts. Every profession abuses word in their own way.

My point is that sometimes the simplicity of a Web interface is preferable to a 'rich' interface.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: When the Browser is an Inadequate Interface Posted: Mar 2, 2005 7:00 AM
Reply to this message Reply
> The main reason that Java applets never got anywhere is
> because of the amount of downloading required before they
> worked. When applets came to the market the majority of
> people were on dial-up, pay-per-minute Internet
> connections. Applets of useful complexity took a
> prohibitive time to download.
>
> Connecting to the Internet is a lot faster and cheaper now
> but still nothing is more offputting than to see an
> interface that consists of a grey square with "Please wait
> while the applet loads." on it.

JavaWebStart solves this problem for repeatively used applications. I've moved away from sourceforge to java.net because I prefer their level of frustration from what I experienced at sourceforge. Integration of CVS with the IDE is a done deal. But, I suppose that depends on which language and build environment you are stuck with.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: When the Browser is an Inadequate Interface Posted: Mar 2, 2005 7:06 AM
Reply to this message Reply
> <p>In the case of SourceForge for developers, the most
> logical choice of technology for implementing the
> interface is html. There are several reasons for this
> AFAICT:
> <ul>
> <li>it is platform independant</li>
> <li>a client already exists on virtually every
> machine</li>
> <li>designing and modifying the interface can be quickly
> and easily done</li>
> <li>the interface metaphors are widely known, understood
> and tolerated</li>
> </ul>

While it is true that HTML provides some of these things, not all web browsers have zero bugs related to these functions. So, we all have to suffer through this fact.
<p>
This alone, for me, is the best reason to never rely on a web browser interface for a production service. But, alas, many services are deployed as web service based applications through web browsers. And, many are successful.
<p>
Over the years, I've developed the opinion that software which I am not incontrol of is not a good thing to have in a system I have to support. So, I'm not very keene on anything but fat clients that I am in complete control of. People don't like this for things that they use seldom for short term activities where the startup of a new application is a time consumer. But, I still contend that disk and memory speeds will continue to be less of an issue and that fat client applications will be the right answer for many types of applications.
<p>
Interworking between applications becomes more of a consideration though. I'm a Java/Jini fan, and so I use Jini remoting for most of my interworking. This means I can have secure interworking as well as distribute it differently, at will, and thus retarget my applications as needed for different tasks.

Flat View: This topic has 48 replies on 4 pages [ 1  2  3  4 | » ]
Topic: The Humane Interface Previous Topic   Next Topic Topic: Architecture the Accelerator

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use