Is the screen flicker during a partial page reload a bad user experience?

Question

Background: I work for a community college with fairly limited resources, but we recently received a grant that allowed us to hire a new developer, and I'm responsible for the initial training. We usually prefer ASP.NET WebForms applications (complete with postbacks to facilitate any step-by-step data retrieval we need).

However, while training our new developer, I wondered if this preference is bad. I've received some sparse feedback (I do want to stress that I've only heard this three or four times) from instructors that the page flicker on an ASP.NET form is confusing or disorienting. On some of our webpages, I've circumvented this by using AJAX.

Question: is the ASP.NET page flicker a truly bad user experience? If so, is it so bad that it warrants moving away from that technology?

As an aside: I recognize that both options have downsides, and that neither really degrades gracefully if any of our users have JavaScript disabled or use screen readers. Nonetheless, I've been told that this is a problem we are simply not equipped to handle, and that we will address these "exceptional cases" if necessary.

It's difficult to show a live example, as our websites are internal and secured by nature (since we generally deal with private student data, and that's federally protected). The still image below will have to do.

1. Page loads like normal:
2. User clicks a button that triggers some code in C#.
3. Page goes completely white during postback (this may last less than 1/60th of a second, but typically is about 0.1 seconds long). I won't waste your time with an image of a white page.
4. Page reloads with new data (similar to or exactly the same image in 1, depending on the operation performed).

I found something that's close to what I'm talking about on the Infragistics website. If you click between the examples on the left-hand side (switching between Activation and Selection, for instance), you'll see that the header and most of the upper menu stay intact, but the content of the page goes blank briefly (or not so briefly, since this is Infragistics) until the new content loads.

The page flicker effect I'm talking about is not as long-lasting as that -- rather than a few seconds, mine lasts at most one second -- but is otherwise the same.

Answer 1

Now, that you've added details and examples, it's obvious that your "flicker" is the blank browser window that is displayed while data is sent/fetched to/from the server & the page is being rendered.

The other answers have correctly suggested to analyze and modify the code to reduce loading times. However, you've mentioned that your organization's budget is limited so such a solution might not be feasible in the short term despite being the better one in the long term. Thus, you have to improve the UX with quick & cheap interim fixes.

Users' satisfaction depends on their expectations for the service, which, in turn, are determined by their assumptions/knowledge of operations and the information provided within the service. Teaching people how the Web works and that the "flicker" is normal will be quite a laborious task. Therefore, you should take a look at how you're setting expectations within your web forms.

Ideally, you need to discuss 2 things with 10-15 of your users (especially the ones who have complained and those who have never spoken to you): 1) what confuses them the most in the forms and 2) why it confuses them. This will help you identify the precise elements where the text needs to be changed.

If you can't do a user study, you can try reviewing your instructions and workflow by yourself to see whether anything implies that there won't be any page reloads:

• If there's only an edit screen, then you need to add a view screen so that the screen workflow becomes view -> edit -> view so that users understand the blank page. In the long term, this needs to be changed to AJAX inline editing.
• If there's no absolutely obvious way for user to know that the changes have been submitted successfully, then the page rendered upon submission needs to have a div with the success message. Such a message, actually, has to be present in every workflow that contains data submission.
• If there're some instructions about how to use the form, add "The page will reload upon submission to reflect the changes" at the end or something similar so that users understand it's not a "screen flicker".

Answer 2

If the flicker happens often enough to be reproducable, get a couple of users in front of it and see if they notice it or respond to it. If they don't, you can deprioritise it as necessary. If they do, make it a point that this needs fixing because it's getting in the way of people using your site.

The least the dev team could do is investigate and see whether it's something that can be fixed in a reasonable amount of time or whether, for instance, it's inherent to how WebForms work and would take a lot of work to fix.

Apple would fix it.

Answer 3

What do you mean by 'flicker'? Do you mean the process of a page being redrawn after a new request is sent to the server?

If so, then this is how the web works. It's how it's always worked and always will.

Now, there are things you can do to minimize the perception of the flicker:

• if an internal application, make sure users aren't stuck on ancient web browsers like IE6

• make sure the page weights are pragmatic

• use best practices to ensure proper caching of CSS JS and other page assets

• minmize usage of .net postback viewstates (these are GIGANTIC on some poorly built .net pages)

• as it makes sense to, use more AJAX type interactions with the server rather than sending full page requests.