W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 1999

Re: Single Browser Intranets (was: Web Accessibility Myths)

From: Scott Luebking <phoenixl@netcom.com>
Date: Sun, 24 Oct 1999 18:16:58 -0700 (PDT)
Message-Id: <199910250116.SAA05241@netcom19.netcom.com>
To: phoenixl@netcom.com, unagi69@concentric.net
Cc: w3c-wai-ig@w3.org
Hi, Gregory

The question still goes back to choice of browsers.  There are different
reasons for different approaches for choosing browsers.  Probably the
question is more like what browser features will I give up on browser A
so I can use the web page with browser B?  It depends on the purpose of
the application, the targetted users, the amount of support staff, etc.
I've been talking with a couple long-distance learning companies.
They tell their customers they only support two browser families.
One guy laughed when I asked about supporting lynx.

(If web pages don't take advantage of new browser technology,
why use new web browsers?)

I believe a new HTML version is being developed for small screen
web page viewing.  My suspicion is that the executives will get
tired of doing a lot of panning and will want smaller, trimmer pages
for their cellular phones.  For example, I can see executives
requesting more drop down list boxes than lists of radio buttons.

I've been developing some Java software which combines template
technology and XML/HTML so that web pages can be constructed to
meet users needs on the fly.  It's not hard to use, but does require
the developer to think on a more abstract basis.  It is kind along the
lines that Jakob Nielsen talked about.

People working on software they know makes sense until the newer
version of software will make them productive enough in the long
run that it is worth a period of less productivity during the
transition phase.  Carefully implementing transition techniques
along with good support can help diminish the pain of change.


> aloha, scott!
> as a former intranet administrator slash architect slash implementer, i believe
> that you are focusing on the wrong problem -- the problem isn't quote how can i
> design for browsers X, Y, Z, and Q, unquote but quote how can i design the
> content i need to deliver to my audience in a manner that will work with X, Y,
> Z, and Q unquote
> web design should promote interoperability -- anything else is merely glorified
> desktop publishing...
> when executives from a company want to interface with their corporation's
> intranet via their cell phones, what are that company's IT people going to tell
> the people who sign their paychecks when the pages that comprise the company's
> intranet won't work with their phone browser because the intranet was maximized
> for browser Z, and uses proprietary markup that the phone browser doesn't
> understand, and which may cause it to render either no content, or only the
> portion of the content that it can recognize and which isn't hidden behind
> proprietary markup, an unsupported format (such as Flash), or invalid markup? 
> hell, in an aural environment, even the use of physical markup instead of
> structural markup can make content far less than comprehensible, not to mention
> inattention to such apparently quote minor unquote details such as ALT text,
> table summaries, NORFRAMES, etc.
> the focus needs to be on the content and its most effective delivery, not the
> browser, and the first step towards such effectiveness is NOT designing for a
> specific browser, and that can be done, today, on a number of authoring tools,
> and through such simple checking mechanisms as HTML Tidy, Bobby, the W3C
> Validator, and the like...
> gregory.
> PS: as an intranet administrator who also worked in a vastly under-peopled IT
> department, i still maintain that people are more productive when they use
> tools that are familiar to them and with which they are comfortable...  sure,
> there may be security issues that eliminate browsers Z and Q from
> consideration, but they are minimal compared with the frustration of the user
> who suddenly can't get their work down because they've been needlessly forced
> to migrate to a different browser...  and, no, i'm not advocating employee
> choice on all applications used throughout a company or organization, but i
> did, and would again, advise everyone in that company or organization to do
> such simple things to promote interoperability when exchanging documents with
> people outside of the company or organization to save documents in Rich Text
> Format and to email them in both RTF and plain text, so as to ensure that the
> recipient has at least  one version of the document that he or she can read...
Received on Sunday, 24 October 1999 21:17:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:06 UTC