Is usability so important?

Please forgive me for having taken such a controversial title, the title of the original is "browser is not what". I personally feel that the author is a bit out of the question, but that doesn't affect the point of view that it wants to present.

Usability has always been one of the main points of contention in our front. But think about whether we deserve to invest in additional, >javascript, blind readers or those who disable Http://www.aliyun.com/zixun/aggregation/33906.html " A lot of development costs to "meet" them?

Recall that in the early days of chaos, the computer did not sound, and if this feature is required, you need to insert an additional sound card. After a period of time, some computers by default to join the sound card, while others still maintain the "dumb tradition."

Then for many years, board vendors integrated the sound card directly into the motherboard-almost all computers have a sound card configured. So the question is: What has the multimedia industry done to change all this?

At the beginning, the application emits the sound that it wants to use only through the built-in PC speakers. Then, after a period of time, there were applications that could use both speakers and sound cards.

In other words, is there anyone who cares if there is a sound card on the machine? I don't think so. Even I think people have forgotten the speakers in the chassis.

For example, I've never seen a game automatically turn off its voice without a sound card on the machine--and, of course, if I can't hear it, it's a different story.

With so much to say, the story is very similar to the browsers and JavaScript stories. The difference is that today's developers, while developing applications, are still considering this without scripting support.

In fact, and the same year's sound card popularization, JavaScript was invented in 1995 (already 15 years ago). Its share of browsers was less than 1%, and users (even developers) thought it was dispensable.

My point is that every WEB application should be able to run in as many different environments as possible, but it does not imply unconditional indulgence in a situation, consistent in any case.

For example, in a browser without JavaScript support, a news class site can still display its main content (news) without ensuring that the album script that relies on JavaScript still works.

What we now call "browsers" must be: it understands HTML, renders pages with CSS, and drives JavaScript scripts. An application can only do one or two of these functions, then this is simply not a "browser".

For example, the search engine understands HTML (and some CSS prevents cheating), we just need to provide content to include it--and it doesn't need to know much about GUI-related design.

In terms of content, I actually only care about two things: search engines and browsers. First, the first thing I need to do is create semantically HTML (which is not easy for HTML), and then use CSS to format and support modern browsers, and then use JavaScript to add CSS rules for IE (obviously the original author hated ie very much).

My workflow is sometimes blamed for having JavaScript support for older browsers to introduce CSS rules for itself. At the same time the situation may become ambiguous, I really do not think what we call "browser" thing is not to support JavaScript, even if it is what can be called antiques (IE?). ）。

All in all, our ideas should be developed for the future, not the past (we should develop for the future is not for the past.).

We should serve most (users) rather than few. If 0.1% of our users disable JavaScript, it seems to me that we may not be worth a lot of development time to win over 0.1% of our users.

Another fact is that if we let users feel that they can use our apps without JavaScript, they won't hesitate to disable it (similar to NoScript plug-ins). So it's almost impossible for us to push the Web forward, and we and our users will think that JavaScript is an extra accessory.

Finally, what I want to say is that before embarking on actual development, we first plan for those limited resources (such as time, manpower, etc.)-whether their planned inputs and actual outputs meet our expectations.

--Split--

Original address: http://blog.istvan-antal.ro/2010/10/what-is-not-a-browser/

--EOF

Source: http://www.gracecode.com/archives/3035/