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.

Page loads like normal:

User clicks a button that triggers some code in C#.

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.

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.

It's OK to be a developer who knows little about UI design. Back-end & front-end are different things. Many UXers can't code either.
–
dnbrvJan 12 '12 at 17:12

Can you link to a live example of this "page flicker"? I've never seen it before.
–
dnbrvJan 12 '12 at 17:14

An example of the flicker would be great. I'd just advise "use AJAX" but I'd love to see the issue in action to know what the problem is and how signifigant it is.
–
Ben Brocka♦Jan 12 '12 at 17:41

2

@dnbrv while it's accepted, I don't call it "OK". The more UX dev's know and the more dev UXers know, the better the solution. It's really inefficient, IMHO, to have teams dedicated only solely to UX or dev.
–
DA01Jan 12 '12 at 19:34

3 Answers
3

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".

Your answer presents the most feasible options to me, because (although I'd like to) I can't really do a user study. We try to beta test all our websites and set expectations with user groups, but it doesn't always work out because we have such a wide range of technical knowledge in our users. I think our best option would be clear communication of the effect. Unfortunately, my boss is quite tied to the ASP.NET WebForms way of doing things (since it shortens our development cycles), although I would prefer to just use straight AJAX.
–
jwiscarsonJan 15 '12 at 2:52

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.

Right, but if it's not something anyone can really fix, doesn't it become a non-issue? I mean, yes, it impacts the user experience if the page flashes white while loading things, but you have to find out from your users how significant it is. And then you'll know. But you'll still have to decide whether to fix it or not, and if it isn't fixable, then I guess that's that.
–
Rahul♦Jan 12 '12 at 20:08

I'm aware of how the web works, hence this question. We've already implemented your suggestions. My question is only about this: is the page flicker/page redraw time enough of a negative user experience to warrant a shift in application development?
–
jwiscarsonJan 12 '12 at 19:49

We can't answer that until you define what's causing the flicker. If it's due to page requests, then, as you seem to know, that's how the web works. So if it is a detriment, then it's a detriment to most any site on the internet. But maybe this flicker has a different cause. We need more info.
–
DA01Jan 12 '12 at 20:08

Oh, I see you've updated your question with details. THANKS! So, yea, that's how the web works. This is completely normal/expected behavior on most any site built in the past 15 years. If you've done all the above, then I'd leave it. Anything to 'fix' this is really going to be a form of large hack that will likely cause more issues later in terms of maintenance/upkeep.
–
DA01Jan 12 '12 at 20:10

BUT...final question: what web browsers are you using internally to view the site with? Many (most?) if the newer web browsers minimize this flicker these days.
–
DA01Jan 12 '12 at 20:11

1

Exactly -- your last comment is what I'm trying to get at. Sorry -- I explained this terribly! I know I can avoid this problem entirely by using JS/AJAX instead of ASP.NET server controls, and I'd like to make that case if the page flicker is a bad user experience. I do understand what you and @Rahul are getting at, however; I need to find out from my users if this really is a problem for them before I proceed further.
–
jwiscarsonJan 12 '12 at 20:24