Is JS ubiquitous now?

Forum Moderators: open

Message Too Old, No Replies

Is JS ubiquitous now?

numnum

5:18 pm on Jul 17, 2014 (gmt 0)

Here's what I mean by the subject header:

Do all widely-used browsers now have built-in Java (no manual plug-in by user required). I'm thinking of inserting a line of JS on many of a site's pages, which script would hide the answers to quiz questions until the user clicks on "Answer." These question-and-answer quizzes are an important feature of the site, and so I don't want to use JS if doing so will render the quiz useless to more than a very small minority of users.

Fotiman

5:37 pm on Jul 17, 2014 (gmt 0)

Java is not the same thing as JavaScript.
While I don't have any physical proof, some searching seems to suggest that the number of users with JavaScript disabled was somewhere around 1% about 4 years ago, and I can't imagine that number has grown.

I'm thinking of inserting a line of JS on many of a site's pages, which script would hide the answers to quiz questions

I don't want to use JS if doing so will render the quiz useless

You might consider approaching the problem from a different perspective. That is, develop the site for the JavaScript-disabled user first, then your JavaScript code can enhance the user experience.

For example, how might you handle the problem of keeping the answer hidden if the user doesn't have JavaScript? Well, you could always add that functionality server side, but that might be more work than it's worth. For example, the answer button could submit a form that results in the server regenerating the page with the answer shown. A different alternative might be to just use CSS to position the answers far down the page, requiring the user to scroll down to see the answer. Then for users with JavaScript enabled, append a class to your <html> element indicating that JavaScript is available, and write styles that prevent the positioning styles from taking effect, and hide the answers instead.

lucy24

6:02 pm on Jul 17, 2014 (gmt 0)

overlapped Fotiman, but I think we say the same thing

built-in Java

Did you mean "javascript" here?

I think you'd have to search really hard to find a living browser that can't do javascript. But it's the wrong question. It's whether a browser does do javascript. Many users-- especially, ahem, the ones reading these forums-- turn off scripting by default.

It's perfectly legitimate to say that a particular voluntary extra feature will only work if the user has scripting enabled. Most easily, you can put this information inside <noscript> tags. That's the user's choice, not something they're stuck with. Well, maybe unless they're reading your site at work using a computer they can't configure. But that's at their own risk anyway ;)

numnum

6:04 pm on Jul 17, 2014 (gmt 0)

For example, the answer button could submit a form that results in the server regenerating the page with the answer shown. A different alternative might be to just use CSS to position the answers far down the page, requiring the user to scroll down to see the answer.

I used the former method back in 1996-97 but thought it clumsy for the user to simply reload the same page with the answer (and explanation) appended. And two versions of each page add up quickly. The next method I used was to create an answer sheet for all answers -- a separate page that opened in a separate window.

What I do now is put a question and its answer on the same page and simply position the answer down the page and out sight until the user scrolls down past an intervening ad. What bothers me about this method is that positioning an ad between the question and answer seems a bit cheesy, and the whole method seems a bit outdated. In other words, the user might get the impression that the pages are ad bait or that the site is "obsolete" because it doesn't hide/reveal answers on click or hover.

Nevertheless, I've waited until now to implement a hide-reveal function because I just haven't been convinced that enough folks use JS-enabled browsers. Hence my query.

Fotiman

6:17 pm on Jul 17, 2014 (gmt 0)

Well, I disagree with lucy's claim that

Many users

turn off scripting. Like I said, I think the number is somewhere around 1%.

numnum

6:21 pm on Jul 17, 2014 (gmt 0)

I think you'd have to search really hard to find a living browser that can't do javascript. But it's the wrong question. It's whether a browser does do javascript. Many users-- especially, ahem, the ones reading these forums-- turn off scripting by default.

Right, that's what I meant -- i.e, virtually all browsers do JS. And that's what I've needed to be convinced of before implementing the hide/reveal function. (I could have addressed this a few years ago, but I'm just getting around to this now.) In another area of the site I've been instructing the user to do {this} if JS is enabled or do {that} otherwise. A bit clumsy, but at least a clear choice is offered and the functionality is there for all users.

lucy24

8:05 pm on Jul 17, 2014 (gmt 0)

I think the number is somewhere around 1%.

Yes, and most of that 1% are WebmasterWorld readers ;) Most ordinary humans haven't a clue that they can change any aspect of their browser prefs. Heck, a depressing lot ot ordinary humans don't even know what a browser is.

But all this only reinforces my main point: If a user doesn't have javascript, it's from their own voluntary choice.

Fotiman

12:21 am on Jul 18, 2014 (gmt 0)

If a user doesn't have javascript, it's from their own voluntary choice.

Agree. :)

Readie

4:12 pm on Jul 20, 2014 (gmt 0)

1% of all people on the internet is still many people :)

lucy24

5:39 pm on Jul 20, 2014 (gmt 0)

Yes, but they're the most involved and knowledgeable 1%. Now, maybe 1% of that 1% are grandmothers of people who came by and set up their browser prefs for added security. But those .01% will just have to resign themselves to phone calls complaining that websites don't work any more.

I don't think public terminals normally block js. It would break too many sites. They probably can't even block cookies; at most they might wipe them all at shutdown.

numnum

5:57 am on Jul 21, 2014 (gmt 0)

I don't think public terminals normally block js. It would break too many sites. They probably can't even block cookies; at most they might wipe them all at shutdown.

Our local public library doesn't block anything, and I don't think the user can change the settings. I know you can't switch to private browsing.

If the user closes down the browser properly, I think the cache is cleared, but I'm not sure. I've started new sessions there and opened the browser to find the prompt asking if I want to restore the previous session. So I've tried clicking yes just to see if the previous session was actually still in the cache, and sure enough up pops the previous users' private emails, facebook account, or whatever was left open when the user ran out of time at the terminal.

A bit OT, but what's worse is that if you want to print a document and aren't paying close attention, it'll be saved to the hard drive, and you can't delete it. It will stay there until after hours, when they power down all the terminals. In the meantime anyone else using the terminal can open or copy any doc on the drive. I mentioned this to a library tech support guy, and he just shrugged his shoulders as if it were no big deal.

What's worrisome is that the sorts of the people typically using these terminals are rather vulnerable and/or clueless -- esp. "marginal" folks and older tourists needing quick access to a PC to check their brokerage accounts and so forth. I've seen some "characters" at those 60-minute terminals that have a look about them that says they're in the identity-theft business.

Again, a bit OT, but the library here just replaced their 14" CRTs (not a typo) a few weeks ago, they keep reducing their hours, and they're relying more and more on self-checkout and volunteer staff. And this is a very, very wealthy community.

tangor

1:49 pm on Jul 21, 2014 (gmt 0)

There are any number of thoughts regarding JS and users...

There's just as many webmasters with different thoughts.

Personally, I think the number of JS off is larger than 1%. Some of the earlier data collected suggested that 2.4% in the USA surf with JS off. What those numbers might be in 2014 is unclear. I can't find any reliable reporting on that.

What I have seen (and others have noted) is that the number of ad blockers is increasing and thus it might also apply that JS blocking might be o n the rise as well.

That said, my personal web master philosophy is to avoid JS UNLESS it is truly necessary.

In the instant case above ordinary HTML and CSS will do the same thing... ie. no JS required.

Then again, those who consciously surf with JS off are usually savvy enough to know when to turn it on if there's a benefit.

Personally I surf with JS off. And with all kinds of filters and blockers, too... so I'm not really the "average" user. When I come across a site which is so very JS... I generally look at the source code before I turn the JS on... and most times I don't have to do that. :)

lucy24

3:46 pm on Jul 21, 2014 (gmt 0)

On many sites, one js-dependent function is analytics. So you can look at your analytics data and see what proportion of visitors are untrackable. (Not to be confused with the Do Not Track folks-- a mutually exclusive group, at least in Piwik, though some may not realize this.)

numnum

11:41 pm on Jul 21, 2014 (gmt 0)

In the instant case above ordinary HTML and CSS will do the same thing... ie. no JS required.

That would surprise me. I just checked the Internets, and the only pure CSS solution I found was to use a <LI> block display and combine the link and target URL (the answer and analysis) in the same (and only) list item -- essentially a faux pull-down menu where the list item is revealed on click. It works, sort of, but I'd prefer not to resort to a hack like this.

tangor

8:53 am on Jul 23, 2014 (gmt 0)

No hack, just a different way of doing the same thing. If backed by Perl or php a true interactive occurs without JS. Just a different way of doing the same thing... Different language. One with some control that JS gives up. (Yeah, I know there will be arguments in that regard)

Boils down to what you are used to, I suppose, or (ahem) taking the easy way out.