Other Software > Developer's Corner

Keeping the UI Responsive - What Would You Do?

<< < (3/5) > >>

Renegade:
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.codeproject.com/KB/progress/ProgressIndicator.aspx

Keeping the UI Responsive - What Would You Do?

Circles are perfect for indeterminate wait indicators.

kyrathaba:
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
--- End quote ---

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:
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)
--- End quote ---

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:
The UI is minimalistic (Super Simple Photo Resizer).

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.donationcoder.com/forum/index.php?topic=26601.0

Still leaning towards stuff like this:

Keeping the UI Responsive - What Would You Do?

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page