- From: Scott Luebking <phoenixl@netcom.com>
- Date: Sun, 24 Oct 1999 18:16:58 -0700 (PDT)
- 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. Scott > 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