Browser throbbers are broken

17 Aug 2006 - 6:46pm
7 years ago
3 replies
1120 reads
Gabriel White
2005

Browser throbbers are broken. These spinning, swirling, pulsing
artifacts were a great way of indicating state back when a web page
wasn't loaded until it was loaded, and once it was loaded it didn't
need to load any more.

But the Web 2.0 blah blah has crept up on us, and I suddenly find
myself waiting for pages to load with no indication of state. I
interact with pages, wait for a response, but find myself without any
idea of whether the connection is actually working, or how long it
might take to finish the transaction. Okay, so www.gmail.com has it's
"Loading..." jigger and www.newshutch.com has it's own contextual
throbber. But these are local pieces of code that are invoked when
users click on something: they still appear even if there's no
connection with the server and nothings is actually happening. And
they provide no indication of progress.

What's needed? Well, I'd like to know the progress of the transation
(a need already served by browsers, it just doesn't work for AJAX),
and I'd like to know whether the server connection is alive (something
browsers don't do now, and pages might work with many different
servers at the same time, so this isn't exactly trivial).

These are not site-specific needs; this is what's required for the
next generation browser (Firefox? Flock?). I don't want to have to
learn each site's design for tracking state and progress - this should
be something that works at the browser level.

Gabe

www.smallsurfaces.com - Mobile user interface and interaction design resources

Comments

24 Aug 2006 - 2:50pm
jonathan d p fe...
2006

hi.

gabe:

I agree. But it's not a limitation of a browser. Browsers just render.

If you want *state* the whole Web is broken. HTTP is stateless.
No browser will be able to know state without a stateful protocol.
Sorry.
That's why I love to hate the Web we all can't live without. Turning
state
into a hack leads to broken UI designs--- and bad interactions:
"Don't click again" messages, "Wait for the server" messages, etc...
the list
is quite endless.

As people on the list have stated before, the Web turned back the clock
on UI design by about 10 years or so...

Keeping state is slightly more complicated, and usually more bandwidth
intensive. Because of that, and because the genius of the Web is the
super-simple HTTP/HTML, it does not, and probably will not, include
state. If you want state, petition the W3C, or make a new *stateful* web
protocol standard.

In my narrow opinion, all attempts (even the much flaunted Web 2.0) to
create state with seriously I/O bound web-based applications
are hacks--- until the Web has state at the protocol level--- not
application
level.

Anyway. My $0.02.

have a nice day.yad
jdpf

On Aug 17, 2006, at 5:46 PM, Gabriel White wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Browser throbbers are broken. These spinning, swirling, pulsing
> artifacts were a great way of indicating state back when a web page
> wasn't loaded until it was loaded, and once it was loaded it didn't
> need to load any more.
>
> But the Web 2.0 blah blah has crept up on us, and I suddenly find
> myself waiting for pages to load with no indication of state. I
> interact with pages, wait for a response, but find myself without any
> idea of whether the connection is actually working, or how long it
> might take to finish the transaction. Okay, so www.gmail.com has it's
> "Loading..." jigger and www.newshutch.com has it's own contextual
> throbber. But these are local pieces of code that are invoked when
> users click on something: they still appear even if there's no
> connection with the server and nothings is actually happening. And
> they provide no indication of progress.
>
> What's needed? Well, I'd like to know the progress of the transation
> (a need already served by browsers, it just doesn't work for AJAX),
> and I'd like to know whether the server connection is alive (something
> browsers don't do now, and pages might work with many different
> servers at the same time, so this isn't exactly trivial).
>
> These are not site-specific needs; this is what's required for the
> next generation browser (Firefox? Flock?). I don't want to have to
> learn each site's design for tracking state and progress - this should
> be something that works at the browser level.
>
> Gabe
>
> www.smallsurfaces.com - Mobile user interface and interaction
> design resources
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

25 Aug 2006 - 8:18am
spyboy
2006

I always equated the web with EGA graphics when PC's were at SVGA levels :)

Want to hate it more? Look no further than phone web apps...

Getting back to stateless throbber indicators.. Unless the apps are
utilizing a plugin (such as Active X) to keep a locked connection, it's
definitely difficult to know how much is going to be pushed through.
Framing pages (or just pulling content from multiple sources on the same
page with layers or other fun stuff) makes it even worse (as well as for
bookmarking).

Some browsers show what's being downloaded, granted that won't give you a
0-100% status bar, but you can at least see that "something" is happening
(this can be bad, since it's exposing all your little bits & pieces of your
application as they download).

I think it would be nice if there was a new tag for web pages indicating
"web 2.0" (I really hate that term) or "application" or something, so that
it can disable the url bar, back/forward/stop/reload buttons. The homepage
of an app wouldn't be considered the "app", only when the user logs in and
begins their real app session. I've attempted this in the past, with
chromeless windows, but a user can still right click or hit the extra mouse
buttons to go back on a page, so it's not perfect.

Perhaps when a web 2.0 app is loaded the first time, it can put an icon on
the desktop (like it was an installed program) and that icon/shortcut would
launch a specialized app browser.

Just my $0.02, (hey, now we're up to $0.04...bonus!)

Kirk

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
jonathan d p ferguson
Sent: Thursday, August 24, 2006 3:51 PM
To: IxD Mailinglist
Subject: Re: [IxDA Discuss] Browser throbbers are broken

[Please voluntarily trim replies to include only relevant quoted material.]

hi.

gabe:

I agree. But it's not a limitation of a browser. Browsers just render.

If you want *state* the whole Web is broken. HTTP is stateless.
No browser will be able to know state without a stateful protocol.
Sorry.
That's why I love to hate the Web we all can't live without. Turning state
into a hack leads to broken UI designs--- and bad interactions:
"Don't click again" messages, "Wait for the server" messages, etc...
the list
is quite endless.

As people on the list have stated before, the Web turned back the clock on
UI design by about 10 years or so...

Keeping state is slightly more complicated, and usually more bandwidth
intensive. Because of that, and because the genius of the Web is the
super-simple HTTP/HTML, it does not, and probably will not, include state.
If you want state, petition the W3C, or make a new *stateful* web protocol
standard.

In my narrow opinion, all attempts (even the much flaunted Web 2.0) to
create state with seriously I/O bound web-based applications are hacks---
until the Web has state at the protocol level--- not application level.

Anyway. My $0.02.

have a nice day.yad
jdpf

On Aug 17, 2006, at 5:46 PM, Gabriel White wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Browser throbbers are broken. These spinning, swirling, pulsing
> artifacts were a great way of indicating state back when a web page
> wasn't loaded until it was loaded, and once it was loaded it didn't
> need to load any more.
>
> But the Web 2.0 blah blah has crept up on us, and I suddenly find
> myself waiting for pages to load with no indication of state. I
> interact with pages, wait for a response, but find myself without any
> idea of whether the connection is actually working, or how long it
> might take to finish the transaction. Okay, so www.gmail.com has it's
> "Loading..." jigger and www.newshutch.com has it's own contextual
> throbber. But these are local pieces of code that are invoked when
> users click on something: they still appear even if there's no
> connection with the server and nothings is actually happening. And
> they provide no indication of progress.
>
> What's needed? Well, I'd like to know the progress of the transation
> (a need already served by browsers, it just doesn't work for AJAX),
> and I'd like to know whether the server connection is alive (something
> browsers don't do now, and pages might work with many different
> servers at the same time, so this isn't exactly trivial).
>
> These are not site-specific needs; this is what's required for the
> next generation browser (Firefox? Flock?). I don't want to have to
> learn each site's design for tracking state and progress - this should
> be something that works at the browser level.
>
> Gabe
>
> www.smallsurfaces.com - Mobile user interface and interaction design
> resources
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org List Guidelines
> ............ http://listguide.ixda.org/ List Help ..................
> http://listhelp.ixda.org/ (Un)Subscription Options ...
> http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org Home
> ....................... http://ixda.org/ Resource Library ...........
> http://resources.ixda.org

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org List Guidelines ............
http://listguide.ixda.org/ List Help ..................
http://listhelp.ixda.org/ (Un)Subscription Options ...
http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org

2 Sep 2006 - 12:41pm
stauciuc
2006

But wouldn't that break a lot of user expectations about the web? We all
know users rely heavily on the browser navigation functions when online, and
they don't really care if it's web2.0 or web apps or just forms and html.

I appreciate that Gmail lets me use the back button to go to my Inbox or
previous message, and I don't really care how much they had to hack to do
it...

0.06$..we're making a fortune here

On 8/25/06, spyboy <spyboy at gmail.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I always equated the web with EGA graphics when PC's were at SVGA levels
> :)
>
> Want to hate it more? Look no further than phone web apps...
>
> Getting back to stateless throbber indicators.. Unless the apps are
> utilizing a plugin (such as Active X) to keep a locked connection, it's
> definitely difficult to know how much is going to be pushed through.
> Framing pages (or just pulling content from multiple sources on the same
> page with layers or other fun stuff) makes it even worse (as well as for
> bookmarking).
>
> Some browsers show what's being downloaded, granted that won't give you a
> 0-100% status bar, but you can at least see that "something" is happening
> (this can be bad, since it's exposing all your little bits & pieces of
> your
> application as they download).
>
> I think it would be nice if there was a new tag for web pages indicating
> "web 2.0" (I really hate that term) or "application" or something, so that
> it can disable the url bar, back/forward/stop/reload buttons. The
> homepage
> of an app wouldn't be considered the "app", only when the user logs in and
> begins their real app session. I've attempted this in the past, with
> chromeless windows, but a user can still right click or hit the extra
> mouse
> buttons to go back on a page, so it's not perfect.
>
> Perhaps when a web 2.0 app is loaded the first time, it can put an icon on
> the desktop (like it was an installed program) and that icon/shortcut
> would
> launch a specialized app browser.
>
> Just my $0.02, (hey, now we're up to $0.04...bonus!)
>
> Kirk
>
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
> jonathan d p ferguson
> Sent: Thursday, August 24, 2006 3:51 PM
> To: IxD Mailinglist
> Subject: Re: [IxDA Discuss] Browser throbbers are broken
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> hi.
>
> gabe:
>
> I agree. But it's not a limitation of a browser. Browsers just render.
>
> If you want *state* the whole Web is broken. HTTP is stateless.
> No browser will be able to know state without a stateful protocol.
> Sorry.
> That's why I love to hate the Web we all can't live without. Turning state
> into a hack leads to broken UI designs--- and bad interactions:
> "Don't click again" messages, "Wait for the server" messages, etc...
> the list
> is quite endless.
>
> As people on the list have stated before, the Web turned back the clock on
> UI design by about 10 years or so...
>
> Keeping state is slightly more complicated, and usually more bandwidth
> intensive. Because of that, and because the genius of the Web is the
> super-simple HTTP/HTML, it does not, and probably will not, include state.
> If you want state, petition the W3C, or make a new *stateful* web protocol
> standard.
>
> In my narrow opinion, all attempts (even the much flaunted Web 2.0) to
> create state with seriously I/O bound web-based applications are hacks---
> until the Web has state at the protocol level--- not application level.
>
> Anyway. My $0.02.
>
> have a nice day.yad
> jdpf
>
>
> On Aug 17, 2006, at 5:46 PM, Gabriel White wrote:
>
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> > Browser throbbers are broken. These spinning, swirling, pulsing
> > artifacts were a great way of indicating state back when a web page
> > wasn't loaded until it was loaded, and once it was loaded it didn't
> > need to load any more.
> >
> > But the Web 2.0 blah blah has crept up on us, and I suddenly find
> > myself waiting for pages to load with no indication of state. I
> > interact with pages, wait for a response, but find myself without any
> > idea of whether the connection is actually working, or how long it
> > might take to finish the transaction. Okay, so www.gmail.com has it's
> > "Loading..." jigger and www.newshutch.com has it's own contextual
> > throbber. But these are local pieces of code that are invoked when
> > users click on something: they still appear even if there's no
> > connection with the server and nothings is actually happening. And
> > they provide no indication of progress.
> >
> > What's needed? Well, I'd like to know the progress of the transation
> > (a need already served by browsers, it just doesn't work for AJAX),
> > and I'd like to know whether the server connection is alive (something
> > browsers don't do now, and pages might work with many different
> > servers at the same time, so this isn't exactly trivial).
> >
> > These are not site-specific needs; this is what's required for the
> > next generation browser (Firefox? Flock?). I don't want to have to
> > learn each site's design for tracking state and progress - this should
> > be something that works at the browser level.
> >
> > Gabe
> >
> > www.smallsurfaces.com - Mobile user interface and interaction design
> > resources
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org List Guidelines
> > ............ http://listguide.ixda.org/ List Help ..................
> > http://listhelp.ixda.org/ (Un)Subscription Options ...
> > http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org Home
> > ....................... http://ixda.org/ Resource Library ...........
> > http://resources.ixda.org
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org List Guidelines ............
> http://listguide.ixda.org/ List Help ..................
> http://listhelp.ixda.org/ (Un)Subscription Options ...
> http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org Home .......................
> http://ixda.org/ Resource Library ........... http://resources.ixda.org
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
Sergiu Sebastian Tauciuc
http://www.sergiutauciuc.ro/en/

Syndicate content Get the feed