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.
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.
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?
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).
> 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.
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.
> 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).
> 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.
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.
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.
> 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...
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.
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.
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.
> 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.
> <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