Author Topic: Keeping the UI Responsive - What Would You Do? (Read 11274 times)

Renegade · « **on:** May 07, 2011, 11:35 AM »

yeah yeah yeah... I know... Keep the UI responsive...

However, I'm looking for advice on WHAT YOU WOULD DO.

I have a few places where some user initiated network activity cause delays.

Those delays are actually very short with only a few hundred bytes being transferred. 2 Kb tops.

However, as we all know, network latency and speeds can be murder.

I'm finding that on my uber-slow, kill me now, assie Internet connection that I can't even display a Windows form in time before some operations are complete. That slows things down because I'm chewing up resources to display a form that may or may not be needed, but I cannot predict if it will be needed or not... Catch-22...

(The form is to alert users that they may need to wait a few seconds.)

So... Create an in-form panel and do it that way? It's possible of course. I just kind of don't like that...

Anyways, does anyone have any preferred ways?

skwire · « **Reply #1 on:** May 07, 2011, 11:40 AM »

I like to use the status bar area for this sort of thing with either a progress bar or looped bit of animated text:

Example #1:

[Select]

Downloading data.
Downloading data..
Downloading data...

Example #2:

[Select]

Downloading data |
Downloading data /
Downloading data -
Downloading data \

Renegade · « **Reply #2 on:** May 07, 2011, 11:42 AM »

It's indeterminate, so I don't like loops for things like that.

It it were a knowable time, then that would be another matter.

skwire · « **Reply #3 on:** May 07, 2011, 11:44 AM »

Yes, I understand it's indeterminate. That's why I use one of the two examples I listed above. Neither one is a finite type of notification. All it serves to do is give the user some notice that the application is "doing something" even if that something is waiting on data.

Renegade · « **Reply #4 on:** May 07, 2011, 11:57 AM »

That's WHAT to display, but I'm looking for HOW to display.

I could use delegates and do it that way, or spin off the processing in a thread, but those are the kinds of things that I'm looking for.

What would be the easiest, best way to keep a responsive UI and keep control with the user, while maintaining a UI that updates in time. (See above for that last problem.)

worstje · « **Reply #5 on:** May 07, 2011, 12:15 PM »

For such a problem, I would pop up a window after around ~2 seconds. On any reasonable internet connection, whatever you are doing should have long happened. If it takes longer the window will pop up right as the user begins to wonder 'what the fuck is the delay about'.

In JottiQ's case, I show a dialog in all instances where I get the maximum supported filesize of the service, explaining exactly what my delay is about. This is for two reasons: 1) it happens at the first time an item is added to the queue, which is not a time internet connectivity would otherwise display and my intended userbase is paranoid enough about security and random connections not to display anything, and 2) it tends to take a second or two. Setting up a SSL connection simply takes a few minutes.

(I was supposed to post this like 30 minutes ago, but I went to eat after clicking submit.. and came back to find someone ninja'd me and that my post never went through. Argh. $:-\$ )

Stoic Joker · « **Reply #6 on:** May 07, 2011, 12:33 PM »

The absolute best "User Friendly" option is (IMO) to have either a progress bar, or text message (depending on projected length of time) stating what is or is about to happen, on a secondary thread.

Even knowing what I know, it still pisses me off when an apps UI locks up because it's busy doing something that takes a bit...but it doesn't give me any feed back as to what/why/how it's going.

The secondary thread option also affords the user the option of saying screw it - [Cancel], without having to be stuck looking at the white-ed out app not responding nonsense while they wait for process X to get the die message.

Rule of thumb 1: Making the user guess is bad.

kyrathaba · « **Reply #7 on:** May 07, 2011, 01:34 PM »

I'd use a BackgroundWorker thread for the heavy-lifting. Keeps UI responsive AND a BG-worker thread permits certain UI elements to be updated from within the heavy-lifting thread.

Ath · « **Reply #8 on:** May 07, 2011, 03:21 PM »

Another vote for a separate thread from here

wraith808 · « **Reply #9 on:** May 07, 2011, 08:53 PM »

Another vote for the thread idea. I try not to do any sort of work on the UI thread except in the simplest of cases (or in cases where it would make the app quite complicated).

Renegade · « **Reply #10 on:** May 07, 2011, 09:29 PM »

I don't think I articulated that well enough and I think I even confused it more above.

Here's the problem again...

The networking code needs to be spun off in a thread or background worker, yes, but the time it takes can be very very low, and low enough that a notification window won't fully display before it needs to be ripped down again.

So I need some mechanism that will quickly alert users that an operation is taking place. It should offer the chance to cancel as well.

Here are some options that I think would solve the problem:

* Pop a panel over the form with a waiting graphic and a cancel button (seems messy to me)
* Create the "waiting" window at startup so it's already in memory and doesn't need to be created, then update it's UI and .Show() it when needed
* ???

At the end of the working thread, rip down the notification.

Does that make sense?

I think for the actual display, I'd like to use something like this:

http://www.codeproje...ogressIndicator.aspx

Screenshot - 2011-05-08 , 12_26_45 PM.png

Keeping the UI Responsive - What Would You Do?

Circles are perfect for indeterminate wait indicators.

kyrathaba · « **Reply #11 on:** May 07, 2011, 09:41 PM »

Renegade,

Of the ideas you've mentioned, I'd favor this one:

Create the "waiting" window at startup so it's already in memory and doesn't need to be created, then update it's UI and .Show() it when needed

Show the window just before entering the worker-thread, then as the thread completes have it close the window.

I ran into a similar but not analogous issue when coding KyrCrypt; in my case, I wound up using both a per-item progress bar and a batch progress bar (along with the requisite Cancel button).

The in-memory window should be serviceable enough, I'd imagine. Maybe not as elegant as you'd wish, but simple and intuitive, two things users need

wraith808 · « **Reply #12 on:** May 07, 2011, 10:04 PM »

I don't think I articulated that well enough and I think I even confused it more above.

Here's the problem again...

The networking code needs to be spun off in a thread or background worker, yes, but the time it takes can be very very low, and low enough that a notification window won't fully display before it needs to be ripped down again.

So I need some mechanism that will quickly alert users that an operation is taking place. It should offer the chance to cancel as well.
-Renegade (May 07, 2011, 09:29 PM)

Ah. I understand the problem more now. How does your main UI look? Is it possible that in the statusbar (or some other similarly always on type of area) you could put the notification and the possibility to cancel? And optionally dim the main window when the event occurs?

Renegade · « **Reply #13 on:** May 07, 2011, 10:29 PM »

The UI is minimalistic (Super Simple Photo Resizer).

Screenshot - 2011-05-08 , 1_17_18 PM.png

Keeping the UI Responsive - What Would You Do?

I've tried to avoid putting anything in there that I can avoid, e.g. no menu, no status bar. So the only option is to either create a new display element, e.g. a pop up window or panel as above, or go back and rethink how to put in a notification area that's unobtrusive, yet obvious enough when needed.

The event happens when clicking the SNS icons.

I'm still debating whether to redesign the UI as noted here:

https://www.donation...ex.php?topic=26601.0

Still leaning towards stuff like this:

Screenshot - 2011-05-08 , 1_24_20 PM.png

Keeping the UI Responsive - What Would You Do?

Screenshot - 2011-05-08 , 1_27_17 PM.png

Keeping the UI Responsive - What Would You Do?

But it would require making the main UI similarly styled... And that I am still debating...

Putting that progress indicator as a permanent element in the main UI along with a blank space to use for a cancel/ok button might work...

worstje · « **Reply #14 on:** May 08, 2011, 05:20 AM »

My opinion might not be that of the great masses and it might not be useful to you very much, but any application that tries to 'differ' from the standard Windows UI immediately gets a negative 10 points that almost always makes me move to the never-trying-it-out phase. (Hell, as it is I don't really like most of the UI of the last generation of browsers.) Different UI means users need to train and learn different elements and habits, and no matter how much time you spend on it you will miss things that some users might need.

With JottiQ, I tried really hard to stick to a standard interface, and what did I find? Mousewheel breaks/acts up due to a .NET control bug. Different DPI screwed the pooch and made text unreadable. Different colour settings made stuff unreadable. If it wasn't for cranioscopical, I would never have found half of those issues.

Sure, with a custom interface you solve the problem of not needing to take every possible Windows setting into account, but you forget that the user has configured those things like that for a reason. Maybe they have bad eyesight, maybe they have a big screen and don't want to scroll 3 lines at a time, or maybe they plain hate bright colors.

The world is bad enough with the big vendors reinventing user interfaces every product cycle. Let's not follow their habit with our small applications, please.

Rather focus on the features you can offer and a simple interface to go along with it.

Renegade · « **Reply #15 on:** May 08, 2011, 12:18 PM »

My opinion might not be that of the great masses and it might not be useful to you very much, but any application that tries to 'differ' from the standard Windows UI immediately gets a negative 10 points that almost always makes me move to the never-trying-it-out phase. (Hell, as it is I don't really like most of the UI of the last generation of browsers.) Different UI means users need to train and learn different elements and habits, and no matter how much time you spend on it you will miss things that some users might need.

With JottiQ, I tried really hard to stick to a standard interface, and what did I find? Mousewheel breaks/acts up due to a .NET control bug. Different DPI screwed the pooch and made text unreadable. Different colour settings made stuff unreadable. If it wasn't for cranioscopical, I would never have found half of those issues.

Sure, with a custom interface you solve the problem of not needing to take every possible Windows setting into account, but you forget that the user has configured those things like that for a reason. Maybe they have bad eyesight, maybe they have a big screen and don't want to scroll 3 lines at a time, or maybe they plain hate bright colors.

The world is bad enough with the big vendors reinventing user interfaces every product cycle. Let's not follow their habit with our small applications, please. Rather focus on the features you can offer and a simple interface to go along with it.
-worstje (May 08, 2011, 05:20 AM)

That's one of the problems that I want to address -- the standard Windows UI is simply difficult for a lot of people. (It's also pretty boring a lot of the time.)

One of the things that people are used to is surfing, and while it's kind of nutty to reproduce that, it shows that people can adapt to different UIs as long as there is a certain amount of standardization.

The problem with non-standard UIs in Windows Forms is that they go way too far with widgets that nobody has seen, or are very uncommon. e.g. The highlighted button here is for a menu (as per the mouse over):

Screenshot - 2011-05-09 , 2_42_14 AM.png

Keeping the UI Responsive - What Would You Do?

But, when you click it, you get this:

Screenshot - 2011-05-09 , 2_42_43 AM.png

Keeping the UI Responsive - What Would You Do?

It slides up.

Not what you'd expect from a menu.

Now, it certainly looks nice, but there's still a lot there, and non-standard things get lost quickly.

From the above shot of Photo Resizer, here're "standard" looks:

Screenshot - 2011-05-09 , 1_30_55 AM.png

Keeping the UI Responsive - What Would You Do?

Screenshot - 2011-05-09 , 1_31_33 AM.png

Keeping the UI Responsive - What Would You Do?

Both very boring.

Also, the title bar serves no purpose, and in the first one, it is only confusing with extra buttons that are not needed.

Back to the version I'm debating:

Keeping the UI Responsive - What Would You Do?

It's clear, looks better, and had less in it that can be confusing. There's 1 thing to do. Click OK. Not 2 or 3. Just 1.

Pick ANY web site at all and there's a 100% chance that it will be more confusing/complex. If people can handle a web site, they can handle that. (Which amounts to a normal Winform with a background image and a button with an image.)

Also, you're not really in the target audience. It's meant for regular people, and not power users and programmers.

JottiQ has a much more complex UI, which is everything I'm trying to avoid -- i.e. if the program can make a reasonable decision for the user, then do it. Avoid options at all costs.

At the moment I have notifications with 2 options - continue or cancel. I'd kind of like to only have 1, but as I'm dealing with SNS accounts, I have to make sure that people can opt out at any point. It's their information after all.

But, if you look at the UI, there are no tricky or unusual components. The buttons are still buttons, and the text is still text. The form border is set to None, but that's the most extreme part. And the border isn't needed. (The form is still movable from any point on it - click and drag - which is actually easier than clicking the title bar.)

I know a lot of people here are DC are vehemently opposed to anything other than the run-of-the-mill form and opposed to any kind of design in a form. But I don't think the people at DC are representative of the market at large.

Anyways... I'm still debating things... Not sure myself...

worstje · « **Reply #16 on:** May 08, 2011, 12:31 PM »

JottiQ is about as simple as an application for its intended audience can be. We're talking about scanning specific files with an online service there. People want to know the results in detail. So I agree - very much different than your audience.

Yes, it is boring. It is dull. That is because you allow your Windows to look dull. Deviantart and a dozen other places offer perfect ways (also for novice users) to skin their Windows as they want it. My point is still usability.

But regarding your designs, as you seem set on the idea (although I could swear I already feedbacked that too...) I still feel that your white text on those backgrounds is unreadable, and no matter what audience I am or I might be aiming for, there will be people who agree with me on that. Your text layout needs work in those example dialogs. The icon is super gigantic: yes, it gets your attention, but it might just be a tadbit too big. Its size is of the format that the only thing I can think about are those bloody annoying smiley-pack advertisements... Hope you can use that.

Stoic Joker · « **Reply #17 on:** May 09, 2011, 06:57 AM »

Anyways... I'm still debating things... Not sure myself...
-Renegade (May 08, 2011, 12:18 PM)

As a rule I agree with worstje completely about highly stylized UIs being an annoyance. However (that being said) I think you've done a fine job of splitting the difference. Honoring the Spirit-of-the-law so to speak.

The "Standard" dictates the use of expected controls like the OK/Cancel/Yes/No buttons, and this expected behavior is there. App & System menus are not mandatory on all windows, so their omission isn't a big deal.

Only when the Form of the app starts to blur the function(ality) of the app does the whole thing go to hell. Asus being a stunning example of taking things way to far. The software that came with my Asus Commando motherboard was so jacked-up/flashy that it was bog slow, confusing, and completely usable. Case in point, I ended up bricking the first Mboard simply because I completely missed the missmatch error due to all of the UI noise. The app had automatically downloaded the firmware it said it need, and them changed its mind a tad to late.

Renegade · « **Reply #18 on:** May 09, 2011, 07:18 AM »

Anyways... I'm still debating things... Not sure myself...
-Renegade (May 08, 2011, 12:18 PM)

As a rule I agree with worstje completely about highly stylized UIs being an annoyance. However (that being said) I think you've done a fine job of splitting the difference. Honoring the Spirit-of-the-law so to speak.
-Stoic Joker (May 09, 2011, 06:57 AM)

That's what I've been aiming for. A balance.

The normal Windows UI is boring and dull.

I'm trying to reach out to "regular people" and create a bit more fun experience...

My general design skills are not very good, so I'm trying to be very minimalistic. A gradient. Some flashier buttons. A cartoon here and there. Not sure if I'm succeeding though... And still very much debating it all...

ecaradec · « **Reply #19 on:** May 16, 2011, 07:11 AM »

Anything lengthy should be put in a thread. There is no other way, some api have callback mecanisms, which usually means there is a thread inside the api. Threads are easy to deal with if you do everything only by messages. If you pass some data to your thread, forget about it until it come back. In C++ I would do something like this :

[Select]

threadid=createthread(threadproc, uiThreadId)
postthreadmessage(threadid, wm_process, new DataToProcess)

Then just answer in your thread when you are ready or when you progress

[Select]

postthreadmessage(uiThreadId, wm_progress, 50)
postthreadmessage(uiThreadId, wm_complete, pDataProcessed)

Just do that, forget about mutex, semaphors, etc... It's only useful if you want super efficient interthread communication.

ewemoa · « **Reply #20 on:** May 16, 2011, 06:11 PM »

May be not quite what's being sought after...but there's some possibly related bits in Crockford on JavaScript — Scene 6: Loopage starting at about 00:31:36 (Remote Procedure Call slide) to may be 00:33:29 (Latency Compensation slide).

Slides available via:

http://yuiblog.com/assets/crockford-loopage-slides.pdf

Spoiler

So when will it be possible to specify locations in videos and specific spots in presentations via URL?

Renegade · « **Reply #21 on:** May 16, 2011, 06:43 PM »

Well, I've used a combination of threading techniques with blocking and non-blocking techniques where I use blocking Forms, e.g. Form.ShowDialog(), and non-blocking forms, e.g. Form.Show(), that get dismissed automatically at thread termination.

I think I still need to do an "idiot review" to rule out some possibilities, but things are looking good so far.

One issue I ran into was the VS WebBrowser control... I hate that thing sometimes... It's just an ActiveX control underneath. I wish they'd do a real .NET browser. The current control is a POS sometimes. It's mighty convenient, but still... Has its drawbacks too.

Anyways, you have to be very careful with it as you can't use it with threads very easily. Underneath, it's still a POS. I don't think I'll swap it out for XulRunner, but it does give me pause for a second thought there.

Incidentally, for anyone that is interested, check out MozNet. It picks up from GeckoFX. (XulRunner/Firefox for .NET.)