![]() ![]() Much more annoying than, say, waiting for something to go from 0% to 1%. An experience with large time gaps calls the conclusion ("we can see movement") into question, since the majority of time the progress bar is not moving.įurthermore, there is user research on the subject of progress bars - ever watch something hit 99% complete and sit there for a while? It's annoying. The point is not "this would take 16 minutes to load", the point is that files can easily differ by orders of magnitude, so tying progress to file size means your progress bar will have gaps with orders of magnitude. (1 second / 10 kb) * (1000 kb / 1 mb ) * (10 mb) = 1,000 seconds.Īfter waiting for 1 second to see the progress bar move, you are now waiting 16 minutes to see it move again, according to our naive algorithm. 1 second for a 10KB file means to load a 10MB file would take. Now, let's take our naive loading algorithm and assume that it is linear with regards to file size. So, you sit at the loading screen, and after 1 second of watching an empty progress bar it goes up by half. Let's be unrealistic for a second to illustrate a point and assume that it takes 1 second to load a 10KB file. In this example, the two files differ by four orders of magnitude. Now let's look at the suggestion to fake progress bars with the naive approach of grouping files into buckets and just showing rough estimates progress. Less elements + higher chance something will hang = better reason to do the calculations to show what's left in the loading process. On a mobile device, however, two things are important: You send out a mobile useragent, which often gets you a simplified version of webpages, and you have a laggy, slow, fairly unreliable connection. If IE listed out every single element on a webpage and calculated how long each would load, it would probably spend more time on those calculations than actually acquiring the data through its fat pipe connection. The differences between the two are important. It's safe to say that in the author's case Internet Explorer is more likely to be hooked up to a high-speed internet connection, while xScope is most likely on a 3G mobile connection. If I were designing a loading screen, I wouldn't want to draw ire for making an entirely justifiable decision.įirst, let's look at IE vs xScope to understand how a donut and a progress bar serve slightly different uses. Internet Explorer is normally on a desktop machine, whereas xScope is a mobile browser. I just feel compelled to mount a brief defense of it, since the justification makes sense to me. The "donut" of the spinning progress circle gets a lot of shit. We don't really care as long as we can see movement. It doesn't have to be perfect if you load 2 files and one of them is 10KB and one is 10MB, but you allocate half the bar to the first one and half the bar to the second, that's tolerable. ![]() Put in a progress bar that fills up, once, until the load process is complete. Yet the tiny, free xScope browser for my Android phone includes a progress bar that shows me how much of the page has loaded. Giant Internet Explorer's little circle goes 'round and 'round, telling me nothing. However, there is one in particular that caught my eye: As always it's pretty great! I agree with a lot of the criticisms made. Bad Game Designer, No Twinkie! has a new installment up at Gamasutra.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |