Post #245,116
2/17/06 11:53:20 AM
|

Well, I should mention that we had a big
animated gif we put over the middle of the stuff and people "HATED" it.
I will pass along your comments though.
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #245,134
2/17/06 12:49:06 PM
|

Re: Well, I should mention that we had a big
Bickford did some research on this: - 50% bail after 8.5 seconds without proper visual indication - switching to a watch cursor delayed the bail-out to 20 seconds - an animated cursor is good for a minute - a progress bar will keep them waiting until the second coming.
Our own internal testing supports this. We've got one of those annoying animated gifs on a search page that takes a while, and we found that people dislike it, but they dislike it less than not knowing what's going on. At the very least you should consider changing the cursor. Even moving the "Loading..." message to the product area would be a big improvement.
The problem is that people notice changes on the screen by movement. Small-scale changes aren't noticed unless there's a color change involved (so maybe putting your Loading message on a yellow background would be sufficient), and the subtle animated dots behind the Loading message aren't big enough and don't change quickly enough to draw the eye.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #245,140
2/17/06 1:05:47 PM
|

I've seen some of that research
a few problems we hit were
1) browser rendering is slooooooow (and fiddly and usually wrong besides) - so adding additional progress indication actually made your results take more than twice as long to arrive 2) gif animation stops when the JS interpreter is running scripts and during iframe loading - which made people think it had crashed 3) First impressions are one thing - but people pick up on where to look for progress indication pretty fast and then they're OK with it being less obvious. For instance, I wasn't initially too shot with Safari's use of the url field as the progress bar indicator (especially when everyone else used an animated icon in the upper right) but I got used to it pretty fast and it seems fine to me now. 4) The search api wasn't designed for this interaction model and so the backend is doing some fairly convoluted processing right now. The api *is* being enhanced and additional indexes are added. So - again - it will improve.
But I'll speak to the designer this afternoon and see if maybe an additional indicator might not be a bad idea. Perhaps changing the bar color where the Loading... is placed to draw your eye. That would be cheap and easy.
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #245,143
2/17/06 1:13:08 PM
|

I don't think it's slow enough to need a progress indicator
The color change would probably be sufficient. Alternatively, I've had good luck with fade effects (opacity). The apparent motion draws the eye pretty well. The trick is to make any changes to the screen gradual in some fashion so that it's still changing a split second later when you look at it. Half a second seems to be a good sweet spot -- long enough to serve as a good target, short enough not to annoy.
That page uses an iFrame? Any reason for that as opposed to DOM manipulation or innerHTML?
Safari's bar has the benefits of both a color change and movement.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #245,168
2/17/06 3:17:15 PM
|

There are two ways to do "ajax"
XMLHttpRequest or you put a hidden IFrame on the page and set its href (which populates it) then get its contents.
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #245,186
2/17/06 5:52:08 PM
|

Yeah, I know that.
I was asking why you picked that method.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #245,196
2/17/06 6:28:53 PM
|

Lots of reasons
many of them historical.
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #245,197
2/17/06 6:31:38 PM
|

Were any of them technical?
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #245,224
2/17/06 8:14:11 PM
|

Yes it is not subject to these limitations
Security Issues
When the XMLHttpRequest object operates within a browser, it adopts the same-domain security policies of typical JavaScript activity (sharing the same "sandbox," as it were). This has some important implications that will impact your application of this feature.
First, on most browsers supporting this functionality, the page that bears scripts accessing the object needs to be retrieved via http: protocol, meaning that you won't be able to test the pages from a local hard disk (file: protocol) without some extra security issues cropping up, especially in Mozilla and IE on Windows. In fact, Mozilla requires that you wrap access to the object inside UniversalBrowserRead security privileges. IE, on the other hand, simply displays an alert to the user that a potentially unsafe activity may be going on and offers a chance to cancel.
Second, the domain of the URL request destination must be the same as the one that serves up the page containing the script. This means, unfortunately, that client-side scripts cannot fetch web service data from other sources, and blend that data into a page. Everything must come from the same domain. Under these circumstances, you don't have to worry about security alerts frightening your users.
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #245,225
2/17/06 8:16:07 PM
|

Yeah, those don't affect us at all.
We're entirely single-host (virtual, of course) based.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #245,231
2/17/06 8:25:05 PM
|

So I showed you mine
what's your's do?
(BTW the progress indicator is being redesigned next week)
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #245,239
2/17/06 9:17:00 PM
|

Re: So I showed you mine
Bond trading tools. One is a market evaluation tool, the other is a specialized trading desk application for a particular type of bond.
Realtime information updates coupled with AJAX techniques for displaying and manipulating orders and so forth.
Regards, -scott
|
Post #245,247
2/17/06 10:35:02 PM
|

Is this for a trading house or general consumption?
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #245,249
2/17/06 10:37:38 PM
|

Both.
At least the evaluation tool is. The other is strictly for traders.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #245,145
2/17/06 1:15:45 PM
2/17/06 1:24:38 PM
|

Another idea:
A quick pulse effect on the line item being checked would signal that something has started as well. As it is just checking the box doesn't seem to do anything if you don't notice the loading. Visual feedback that you've started an operation as opposed to just changing local state is very important. The only reason I didn't go looking for an "Update" button was that you'd said it was AJAX. :-)
I have a big AJAX application that's going into production next week here to which I added fade effects and so on; at first people laughed and thought it was just a ridiculous developer video game mentality, but then they started to realize the importance of change indication. Additionally, gradual changes are much less jarring to the user that simply inserting or removing rows and the like. We have another app in development that doesn't do that, and the difference is quite apparent.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."

Edited by admin
Feb. 17, 2006, 01:24:38 PM EST
|
Post #245,214
2/17/06 7:40:56 PM
|

ICLRPD
- a progress bar will keep them waiting until the second coming.
Cheers, Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|