Re: FAQ Topic - I have window.status="Moomin"; why doesn't the statusbar change? (2009-11-04)

Dr J R Stockton wrote:
In comp.lang.javascript message <hdb977$r3r$1@xxxxxxxxxxxxx
september.org>, Tue, 10 Nov 2009 00:45:25, Garrett Smith
<dhtmlkitchen@xxxxxxxxx> posted:
Dr J R Stockton wrote:
In comp.lang.javascript message <hd08pq$r54$1@xxxxxxxxxxxxx
september.org>, Thu, 5 Nov 2009 20:30:46, Garrett Smith
<dhtmlkitchen@xxxxxxxxx> posted:
Dr J R Stockton wrote:
In comp.lang.javascript message <hcu27a$p7i$1@xxxxxxxxxxxxx
september.org>, Thu, 5 Nov 2009 00:26:13, Garrett Smith
<dhtmlkitchen@xxxxxxxxx> posted:
Dr J R Stockton wrote:
In comp.lang.javascript message <4af0c409$0$278$14726298@xxxxxxxxxxxxxxx
, Wed, 4 Nov 2009 00:00:02, FAQ server <javascript@xxxxxxxxxxxxxx>
posted:
-----------------------------------------------------------------------
FAQ Topic - I have window.status="Moomin"; why doesn't the
statusbar change?
-----------------------------------------------------------------------
There is no good reason for doing this.
Your experience is limited. Those with different experience can
think
[...]


Now I see: NOT WORKABLE FROM WEB.

I am not interested in figuring out whatever it is you want me to
download. Can you provide a simple example on-line?

Not tonight. But if you had read all of that little box, you would have
seen "This page requires _include1.js_ and wants _styles-a.css_.
NOT WORKABLE FROM WEB. Use a local copy.", with links as indicated.

You should not expect a simple and convincing example, since the essence
of the situation is that it is for code which does a lot.


Perhaps not. The lack of a good example does not prove that the status
bar is not useful. However, evidence that the status bar is a good place
to provide notifications for user interaction has not yet been provided.

I anticipate that such example will instead emphasize the premise that
changing status bar text will be a worse user experience than status
notification on the page.

That is only one premise.

The others are:
* Questions about the status bar are rare
* Status bar notifications provide inconsistent user experience (the
status bar is not present in many browsers)
* Where the status bar is present, the browser may be configured to
disallow modifications to its content (a default security setting for
many browsers).



But try <URL:http://www.merlyn.demon.co.uk/estr-bcp.htm#JS>, second
blue form, containing "From : To : [Long Test]", with "To" set to
5700000 (the repeat interval). In my IE, the box under "Clear" does not
change during the test (unless there is an error), but the status bar
does. In my Opera, both change.

Using window.status (choosing a browser that does it)

Presuming which browser the user is using is a mistake.

I can use any browser I like. I happened to be running Firefox (with
NoScript set to allow "demon.co.uk").

is far easier to
program, and the progress can be seen with just a corner of the window
showing. Moreover, it does not delay progress by imposing timeouts.


I find it hard to believe that given two programs running a loop L.
1) run L and update status
2) run L

That the performance would be the same. I believe the performance
would be slower in the program that updates the status bar.

And probably reason for:
| if (!(Y%1000)) window.status = F.XXv.value = Y

Updating only the input is sufficient, and should be faster than
updating the input and the status bar.


// Store that element reference prior to looping.
var inp = F.elements.XXv;
for( ... ) {
if ( Y%1000 === 0 ) {
inp.value = y;
}
}



[...]

Where present, the status bar is often ignored by the user.
Not the point. You have above "Most browsers are configured, by
default, to disallow scripts from setting the status bar text." Safari
& Chrome have no bar; IE & FF allow setting; only FF disallows. That's
not most, or even many.
Removing the entry would fix that.

Unhelpfully.


Safari recent versions (at least in Windows) has a bar that is hidden by
default.

So the script may be able to set status bar text, and the FAQ would be
wrong from a technical standpoint.

Regardless, it is of absolutely no good is it if the user can't
see it.

[...]



But an author/tester using a PC can be sure of having a status bar,
by
choosing the browser that he is using to work on the internals of a
page. The bar is an available resource.

The FAQ covers debugging tools, such as Firebug, IE developer toolbar,
Dragonfly (use opera.postError).
It does. But debugging tools are not a good way of providing a
progress
indicator to an end user.

The end user? You were arguing for "an author/tester using a PC".

It is necessary to consider both. Without an author, there can be no
end user; but every author hopes for end users.


Fine, just stick to one argument at a time.

You're flipping back and forth to try to prove a point.


For environments where a debugging tool or console is unavailable, debug
info may be shown as text in an element (e.g. TEXTAREA, PRE).
It can. But that's more effort, and occupies space within the
window;
the status bar is already there and on the edge, which, as I have
explained before, can be useful.

That works in a few browsers.

And if one has several browsers, one can choose a browser in which it
works.


The user is not going to know to switch the browser to view the status
bar. The user will see nothing.

If the user sees nothing, and the browser is unresponsive, it is
unlikely that he will assume that the status bar is being updated, but
that his browser does not allow that.

It is possible that the page contains instructions to read the status
bar (as you mention), however that message cannot be expected to be
visible to the user. Indeed there are many cases where it won't be.

Moreover, when it is visible, it is placed out of the way, apart from
the thing the user took action upon, away from where the user is
focused.

Instructions for the user of where to look is a failure to communicate a
status update. I tells the user "you're looking in the wrong place; look
at the status bar". That is a horrible user experience.

First of all, the user should not be expected to read that text. Second,
if he does, it is inefficient in that the user has to look first to the
instructional text and next to the place where the instructional text is
telling him to look.

If, instead, the page should not provide such instructional text.
The page should provide a notification of status change near where the
user clicked/acted.

I am not an expert in HCI, but I have been lucky enough to have worked
with some good user experience developers.

Try looking at some Ajax examples. You'll see that virtually none of
them use the status bar for update notifications. Instead, they provide
a notification prominently displayed in the page. This is desirable.

It is unlikely that the user will decide at that point to launch another
browser and type in the URL (as select-copy-paste the current location
from the busy browser will not be possible while that browser is
processing the script).

Does this make sense?

[...]

No, that is not true.

The user doees not see the status bar in many cases, and so when the
browser is frozen in 10k iterations, it's end-task or force quit.

The author does need to choose a number of iterations such that the bar
is updated about once in every 0.2 to 2.0 seconds. And the author can,
as in the example linked above, mention the status bar.



The author can provide instructional text on the page, telling the user
to look.

The user cannot be blamed for not reading every bit of instructional
text. Indeed, things such as "look at " or "click on" indicate that the
UI is not intuitive.

Instead, the author should update an element that is in close proximity
to the thing the user took action on (clicked/activated). That way, the
user does not have to take instructions on where to look. It's right
there.

Status indicators are important.

The window status bar is not closely related to things in the document
(input buttons, etc). It often not present (visually) in the users
browser.

Don't regurgitate what is taught in the lower-class institutions;
consider it to be less likely to be sound than TL thinks DG is.

I could care less which schools you attended.

Unfortunately, it is wisdom on your part which we need in order to have
a good FAQ.

The entry will be removed.

And lack.


I lack wisdom? How does that support your argument? Sounds more like
DM is having an influence on you.

Would it not be smarter for you to write a new section which describes,
in sufficient detail for the intended FAQ readership, how progress
should (in your limited view) actually be indicated during a long
operation, giving due consideration to the differences between browsers?
You might say, for example, something about opening a small child window
to remain visible and show progress.when the main window is minimised.

A pop up window? Are you serious? Users don't like popups and they are
often blocked by "pop up blockers".

AISB, the FAQ entry:
http://jibbering.com/faq/#updateContent

| Using the non-standard but widely implemented innerHTML property:
| <div id="anID">Some Content</div> with script:
|
| document.getElementById("anID").innerHTML =
| "Some <em>new</em> Content";
|
| If the new content is only text and does not need to replace existing
| HTML, it is more efficient to modify the data property of a text node.
|
| document.getElementById("anID").firstChild.data = "Some new Text";
|
| Compatibility Note: Implementations have been known to split long text
| content among several adjacent text nodes, so replacing the data of
| the first text node may not replace all the element's text. The
| normalize method, where supported, will combine adjacent text nodes.
|
| Note: Make sure the element exists in the document (has been parsed)
| before trying to reference it.

Talking me down with things like "in your limited view" isn't helping
your argument.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
.

Relevant Pages

  • Re: FAQ Topic - I have window.status="Moomin"; why doesnt the statusbar change? (2009-11-
    ... september.org>, Tue, 10 Nov 2009 00:45:25, Garrett Smith ... change during the test, but the status bar ... Using window.status (choosing a browser that does it) is far easier to ... and the progress can be seen with just a corner of the window ...
    (comp.lang.javascript)
  • Re: formatting in a text box
    ... > different browser is used. ... It's on the drawing tool bar. ... View the page in HTML code mode? ... Use an HTML validator. ...
    (microsoft.public.frontpage.programming)
  • Re: Kiosk Mode for IE6
    ... There is a difference between full screen and kiosk mode. ... browser you should look at using Group Policy settings or try the MS ... from the View>Explorer Bar menu. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Internet Explorer URL spoofing threat
    ... Recently I advised Microsoft of a vulnerability in Internet Explorer ... completely different URL in the address bar. ... copy/paste the URL into a browser. ... it hardly reduces the effectiveness of this attack. ...
    (Bugtraq)
  • Internet Explorer URL Spoofing Threat
    ... Recently I advised Microsoft of a vulnerability in Internet Explorer ... completely different URL in the address bar. ... copy/paste the URL into a browser. ... it hardly reduces the effectiveness of this attack. ...
    (Focus-Microsoft)