Browser Abuse Syndrome

BrowserAbuseSyndrome is when a person or company abuses a Web browser by stretching it beyond its intended use. HTML, the language that browsers currently parse, is a scripting language for documents, not applications. People could be far better off using real applications, or a browser that is not so HTML-centric (ComponentBrowser, RemoteGuiProtocol).

Examples:

using a text field for writing a post (like this one) when you should be using a text editor or a browser with a text edit plug-in of your choice.
playing a video game online in a browser, using some java applet or flash, instead of getting a real program that runs on the computer
chatting in an online chat room instead of using a program like IRC, trillian, etc.
using webmail to check email instead of using an email client such as eudora, procmail, Sylpheed Claws, Outlook(sigh), Emacs, etc.
- But useful if you use different machines at different places and have to switch clients, in which case your information is scattered on multiple machines under the fat-client approach. I just wish they made better web versions of email managers.
- If you're using different machines there's no reason you couldn't use software on each system to check your email. Or if you want something generic, I think HTML is still the problem - so a ComponentBrowser or RemoteGuiProtocol would be fit. I think the reason you "wish they made better web versions of email managers" is because they can't make them. HTML limits them. The richest HTML email managers I've seen out there are slow even on a new processor.
- That assumes you have authorization to install software on the machine you're using. Web browsers are now ubiquitous. You can use them on any random PC.
- Yes those situations are a problem. That's why I say a component browser or a browser that is more complex for "applications" is needed. In otherwords, when you can't install a thin client on a machine, a generic browser not based on HTML is needed, that everyone has installed. Like someone else said, HTML is more like an e-brochure, but not fit for application.
- That's why we have JavaScript.
- Please, you aren't serious? Surley you are joking, shirley. JavaScript plays a part IN BrowserAbuseSyndrome
- Yes, I'm serious. JavaScript turned simple HTML browsers into this magical "component browser" you imagine. There's nothing "abusive" about using JavaScript to add new features to the browser.
managing files on your hard drive inside a browser all the time instead of using a file manager program
This above problem is an issue with KDE. They set up Konquerer to manage your files. It's better than some web browser-based file managers, but it's still abuse. Why? Because other stuff gets in your way and it's still not a file manager. The menu systems are generally designed for browsing, and hacks have to be done to get the browser turned into a file manager. In addition, even the old unix philosophy doesn't advocate having one tool do three million different things. It's useful to the casual user who doesn't manage their files that often. But it isn't total Commander or Krusader or Seksi Commander. All the menus and keyboarding in the browser are geared toward the browser, not the file manager. Since file managers are partly keyboard driven (like Total Commander). A browser based file manager solution is just extra bloat in the linux distro, for some.
downloading files from an FTP server in a browser regularly (emergency is ok)
using PHPmyAdmin regularly (emergency is ok, see PhpMyAdminSucks)
Online RGB color pickers, online HTML to RGB converters (It would have been quicker to download the program that did this, the HTML just took so long to parse the silly color picker java craplet in the first place, sigh)
Online Hex to Dec converters.
Using Cpanel to control a linux web server. (Sadly, Cpanel has many features but is buggy. I wish I didn't have to. Anyone know of a replacement? Root access isn't the solution and neither is SSH, since some people don't have that on some hosts.)

Why are any of these uses considered "abuse"?[duh] [It's abuse because Web browsers are neither general enough nor powerful enough. It's abuse because HtmlSucks; it's not a pure transport protocol as described in HtmlSucks, let alone a general or powerful protocol. It's abuse because Java craplets suck; distributed applications with no meaningful security whatsoever. And so on and so forth.

Having said that, applications suck. Not just the applications mentioned above, but all applications everywhere. See NoApplication. The default UI should be an ObjectBrowser framework that calls specialized code for handling specific classes (eg, class movie, class musicFile)].

The Web has made it easy to share stuff. Unfortunately, there is not a decent real HTTP-friendly GUI standard yet, so people end up pushing HTML to its limits to achieve what the customer envisions. (RemoteGuiProtocols)

<rolleyes> There isn't a decent text standard yet! HtmlSucks

HTML browsers should be kept for reading simple documents, similar to an RTF program.

Alternatives to HTML could also be developed for reading simple documents with hyperlinks, but not much more.. such as an RTF-like design where we always use a WYSIWYG design (no one ever hacks their RTF files in a text editor, do they? Even advanced programmers who use RTF never hack their RTF files in a text editor... so think about that hard now, why do we still use text editors to edit HTML? because HTML is slow to parse and no software is available, other than bloated applications like DreamWeaver.)

Real world example section please contribute your real world examples which (would) reduce Browser Abuse

Emule: Almost an example of what a web browser needs to be like. Emule connects to the internet but does not use HTML. It is a client with listboxes, menus, etc.

Client like "Emule" has basically NOTHING to do with HTML. HTML or a Web browser (topic at hand) does not need to be used in order to "use the Internet in a useful manner".

Emule is for file sharing, but my point is this could be a shopping cart application too.. NO HTML, NO BROWSER - still connected to the Web, but NO HTML, NO BROWSER. The reason I pick Emule is because it has so many intelligent features.. a shopping cart application that looked like Emule would make Web shoppers go crazy. People would never visit these obsolete 'HTML' Web sites again.

Even Google is an example of browser abuse. When I look up information for programming tips or source code I use Google. However I constantly find myself wishing to have a software application that connects me to only software servers developed for programming, like an Emule program (not the P2P part, just the design of the application and lack of browser/HTML). All the server load that Google takes in just for me to find information about some simple programming question is ridiculous, compared to say some software application designed like Emule that only connected to servers related to programming, and displayed the search results appropriately (in a proper ListView? or Grid, not HTML).

One problem with browsers is their heavy mouse reliance. In order to go to a homepage on a Web site I should be able to hit CTRL-H or META-H. With current browser-abuse-syndrome developers (asexually reproducing worldwide), we'll never end up seeing Web sites that can be controlled by the keyboard optionally. Come in here with a VBscript and I'll hurt you, think on a deeper level please.

It can be done, but the problem is having a site with enough content and regular visitors to justify doing that.
- Ok, so an example: I've never seen this in practice at some of the most popular shopping cart sites in the world. There are a lot of Web sites out there with a lot of visitors. Yet, it really isn't that hard of a thing to implement in a software application, it's pretty much done for you in Win32.
- Well, that's true, but as far as implementing this on the Web it isn't 'normal'. Most people aren't used to using the keyboard to navigate, so although the possibility of implementing keyboard navigation on the net is quite possible, it isn't just a case of not enough people and not enough content, but actually getting them to use it. Most wouldn't; instead, they'd rather point-and-click.
  - It isn't? What about E-mule? Sorry, it's the only application I can think of that is a Web App and not HTMl based. It's not just the 'keyboard', it's the design of how my keyboard responds to the GUI (i.e. instead of tables and linear selections, you have listviews, menus, pop-ups, etc.). The keyboard is just an example. We are not asking for someone to write up a script that will make a html website work with the keyboard, because it lacks the design to do that in the first place.
  - E-mule is not, by the normal usage of the term, a Web Application. E-mule is a traditional compiled application that uses traditional techniques to do P2P networking. Web Applications, as normally used, refers specifically to "applications" which are implemented on top of and accessed with HTTP and HTML, in a browser.

Just for the record, this post (and all navigation leading up to it) was made entirely from the keyboard. Mozilla is a wonderful thing.

On a more serious note, I find myself using the keyboard very frequently to navigate all sorts of Web sites. I usually only drop back to the mouse for text selection, and random access browsing from a long list (RecentChanges, for instance). In the first case, pointing just seems to make more sense (a search and replace would involve typing in most of the text I wanted to avoid typing in the first place), although good cursor/arrow key support would be nice. In the second, again the 'random access' nature seems to be a better fit.

One gripe I do have about Mozilla's incremental find is that although it will find text in a text box, the only way to keep the cursor there is to click... escape loses the focus; tab, shift+tab sends you back to the previous cursor position.

-- WilliamUnderwood

But you can browse Google via the keyboard in the Opera browser too. And you can turn images off with the G key, etc. You can write a keyboard tool that hacks into the IE6 API that lets you navigate sites 'properly' according to how you want it done too if you really put your mind to it. But really putting your mind to it just to do something simple and tedious indicates lack of proper upfront design in the first place. We can all use RoboForm? to manage our passwords (sigh), but look at the bloat needed to hack into the document and IE6 API. Not proper upfront design.

HTML is like Word. it's for documents - sure, you can program documents with external software (browsers), javascript, (excel macros, word macros), API's, etc. But the question is: Do you want to?
Do you want to carry around a 100MB browser and a bunch of plug-ins that hack on to HTML just to do a few things on a web page, and write bloaty plug-ins for the browser that in the end just tap and hack onto HTML designed pages? Why not do it backwards and do all the hacking first, before using HTML. Everyone is hacking on top of HTML, rather than eliminating it.
Do you want to have a proper up-front design instead, where we don't use HTML as the main programming language that everything is trying to wrap to? All server languages in the end are just wrappers for HTML. What kind of a programming language is HTML? What kind of a programming language is RTF? Word?

Specify the accesskey attribute for each important link when writing the HTML. The user can hit Alt-H, for example, to jump to the home page. See "Day 15" of MarkPilgrim's "Dive into Accessibility" tutorial (http://diveintoaccessibility.org/). The access key trick works in MozillaFirefox and InternetExplorer but not SafariBrowser. As far as I'm concerned Safari sucks. HtmlSucks as well, but what suck more are the HTML-generating IDE's and libraries and inadequate education about HTML. Hence the importance of LearningHtmlAndCss if, for some reason, HTML is what you want or have to use. Some standardization of accesskey shortcuts would help as well.

There is some controversy, however, about the accesskey attribute. As of July 2004 the XHTML 2.0 Working Draft replaces the accesskey attribute with a new attribute called "access". The proposed new access attribute would allow the user to specify what keystrokes to assign to the access points, once browser makers get on the stick. Read more about this in "The Future of Accesskeys" article (http://www.wats.ca/articles/thefutureofaccesskeys/66). -- ElizabethWiethoff

From WhatIsWrongWithTheGeneralVisualBasicApproach

I agree that an app designer should have this power and this is why web-based GUIs are insufficient. You cannot reasonably expect to have that level of control over a browser. This is why writing a custom thin client is often the best (and, sadly, usually overlooked) solution to most of these problems. Once you factor out all the cross-browser issues (.NETs postback handling is nice in theory but generates exceptionally messy code and is difficult to override. It also creates a tendency to much tighter lockin than even the old "Only use the IE DOM" way did). Disclaimer: I write web apps for a living. The need to provide rich client functionality in a fundamentally limited platform is one of the most annoying parts of my job, especially when the gains from browser based functionality are generally minimal.

[Web based GUI's are only inefficient because of what limits them, HTML. HTML is the main programming language that everything wraps. HTML needs to be ditched for real web apps. See also ObjectBrowser, ComponentBrowser]

Companies seem to like the easy deployment of web apps and appear willing to sacrifice better GUI techniques and frameworks to get it. I often don't agree with this, but if the customer wants it, what else can you do? Also, sometimes they don't seem to understand the extra effort and complexity that results from forcing web apps to act like real GUIs. On the one hand they may complain about being married to Microsoft if they use VB, but don't mind sticking to IE-specific standards to get more client features.

(Following the move over to here) I agree, as said above it's what I get paid for. They sell themselves on the idea because of the ease of deployment, and because it's in all the trade journals. I've suggested client side apps a number of times and always get shot down. It's especially frustrating when I'm busy turning down requests for extremely rich data entry support that I can't provide because a browser doesn't expose the events I need, like high tech masked entry boxes. [Ease of deployment can work both ways though:

HTML which is so easy to deploy: you are competing with guess who: people who can build web pages, tons of these people. Even kids can create web pages, so why would people hire you? Your customers want something better than what everyone else on 1st street is doing, but of course it isn't here yet, because people are still using HTML.
C++ is a complex language yet it is highly popular. It seems the human brain is quite capable, otherwise more people would be using VB (now they came out with Visual C#). So saying that the reason people use HTML is because it's easy to deploy is like saying the reason we all use VB is because it's easy to deploy. If you want real results, you don't use VB for several reasons.. It's just not a LONG TERM solution. HTML is not a long term web application solution, it is a 'document scripting' solution.

Maybe sneak it in using Flash Forms or something. (I don't know if Flash supports masks, but it is richer than most HTML.)

Re: "using a text field for writing a post (like this one) when you should be using a text editor"

It would be nice if browsers allowed one to plug in their favorite TextEditor to replace the default one.

[They would with a ComponentBrowser or ObjectBrowser]

LynxBrowser allows this. :-) Launch Lynx, go to the Options page (o), and enter the path to your Editor in the General Preferences section.

Yes, some browsers are wonderful with features; however, these are all just hacks on top of HTML still. Why not design it better first, before tapping on to it and smack-hacking it? Not proper up front design and engineering. Even Emacs let's us do wild things like browse websites. These are all just hacks. You could ride your bicycle to Africa across the ocean if you lived in Florida, but isn't that just a hack? You need proper equipment that was designed right for the job.

If Emacs is the answer, I'm not sure I want to know the question!

Re: "People could be far better off using real applications that run on their computer, not inside their Web browser."

I don't think those are the only options. I believe in the idea of RemoteGuiProtocols such that we don't need fat clients, or at least app-specific clients. The problem with the current set of browsers is that they were fundamentally built for e-brochures, not business forms or highly interactive interfaces.

You're right. What I meant was either a different type of generic web browser which uses not html, but plug-ins and components. Or, a real application (thin client) for more customized work when you need more than just the browser, and you are allowed to install that client on the machine you are at. I've changed the paragraph at the top.

This page seems to come from folks with the assumption that the best technology will be the most successful technology. It's been obvious for a long time that HTML (plus JavaScript, Flash, plug-ins, etc.) was not the best technology for many of its current applications, but it's been equally obvious that it has been and will probably continue to be the most successful technology. Replacing HTML with a better remote GUI technology won't generate cash for anyone any time soon. HTML is good enough and popular enough that it has inertia on its side.

Note: Browser abuse typically occurs more when people design, or try to design applications in browsers. Since HTML is hypertext geared, applications have trouble existing as HTML alone. All server side languages still end up existing as HTML in the end, on the browser side. This is part of the problem. This page is not arguing that html browsers suck, but more about the abuse of html browsers when designing applications. Html browsers, I agree, are useful for reading HTML documents (help documents, instructions, things like that.). But for things like banks, software upgrades, service applications, shopping carts, video games, sending email,... browsers are lacking a basic engineering. That's why incomplete solutions like JavaScript and Robo Form, and non-standard unneeded browser hacks exist(variations between mozilla, opera, IE, konqueror)

In what way is JavaScript an "incomplete solution"?
- You'll have to use your imagination ;)
- Also it appears WardCunningham started a page himself, which may lead you in some direction. JavaScriptSucksInBrowsers
You made the claim. Can you explain?
For the same reason that an Edit Box is not a complete solution, or for the same reason a wrench isn't as complete of a solution as a screw driver when you need it. Use your imagination.

No hope from 'RIAs' (RichInternetApplications), Flex, Silverlight, etc.? How about Windows 8's Metro system? Is it true, now all of the worst limitations of HTML can be applied to desktop applications?

I'd say their success is roughly in this order: Flash/Flex, Java, Silverlight. However, the industry wants an open standard.

CategoryWebDesign, CategoryRant, CategoryMultiPurpose