A daft question, but I really cannot get this to work: I have some long-running process in a Swing application which may take several minutes. I want to display a progress dialog to the user while this process is ongoing. I also want to prevent the user from performing further actions, eg pressing a button while the process is going on.
If I do the process on the EDT, this obviously prevents the end-user from doing anything while the process is going on. But because the EDT is busy processing, it never gets around to rendering the dialog's content, so I just get the outline of the dialog.
But if I do the process in a worker thread, the end-user can click buttons and cause the EDT to manipulate state that the worker is also manipulating at the same time, with bad stuff as a consequence. If I make the dialog modal, that does not happen, but modal in Swing also implies blocking, so the moment I call setVisible(true), the thread blocks forever.
So my current "solution" is to use a worker thread, and then spawn off a separate thread whose only purpose is to absorb the blocking nature of setVisible. Surely there must be a better solution!
So how do I get a dialog that prevents the user from interacting with the rest of the system (modal) but does not block the thread that causes it to be visible?
You should be using the GlassPane from preventing the user from interacting. The good thing is this is modal for the user and not your program so your thread won't get blocked.
The great news is that you can also use it for cool GUI effects like shading the GUI portion busy and the user can't interact with. You can also display a busy gif image in the GlassPane.
Links:-
Official tutorial on GlassPane
Some helpful tutorials
Another tut
Oreilly's Swing Hacks is excellent.
You must be doing something wrong. Try the tutorial on How to Use Progress Bars. If you can understand how that code works, it should give you the direction for achieving the required feature.
Note that progress bars are usually modal.
Related
I have written a control that makes a star formation, the number of points and the length of each point is configurable via dependency properties. I can bind them to Slider controls and it all works.
Now I've written a behaviour that 'injects' this star control into the visual tree of a loaded control and then, in code, makes an animation to make the star grow and disappear like a cartoon flash going off.
My animation doesn't run. The Storyboard.Completed event fires, but a breakpoint in the change handler for the dependency property being animated is never hit after its initial setting when the page loads.
I'm using a couple of DoubleAnimation instances.
(this is Q/A I solved it after 3 hours)
You need to set the EnableDependentAnimation property on your DoubleAnimations. From MSDN:
Not all custom animations you create can run by default in a Windows
Runtime app, if the animation system determines that the animation
might cause bad performance in your UI. Animations where the system
determines there could be a performance impact are called dependent
animations. It's dependent because the clocking of your animation is
directly working against the UI thread, which is also where active
user input and other updates are trying to apply the runtime changes
to UI. A dependent animation that's consuming extensive system
resources on the UI thread can make the app appear unresponsive in
certain situations. If your animation causes a layout change or
otherwise has the potential to impact performance on the UI thread,
you often need to explicitly enable the animation to see it run.
That's what the EnableDependentAnimation property on specific
animation classes is for. See Dependent and independent animations for
more info.
Very discoverable. Lucky you chose to RTFM on this day, else you could have ended up writing your own timers and stuff to force all the rest of the work on the clever star control not to have been wasted.
I'm building a web application where one of the features causes users to be notified in real-time when an alert pertaining to them occurs, similar to the big orange bar in Stack Overflow.
I have a few options, and I was wondering if there was a usability guideline on the best way to go about this. One option is to have a small notifications box on the screen that flashes colors when an alert appears, but I'm worried that a simple, repeated change in color won't be sufficient to attract the user's attention.
Another option is to have a window come floating across the screen, demanding the user's attention, but I've always found those to be obtrusive. Maybe another form of animation could be less annoying yet equally likely to attract the user's attention?
I'm not really looking for an opinion as much as I'm looking for a usability discussion/resource that might cover this kind of decision.
The answer somewhat depends on how important it is that the user pay attention and how important it is that they take some action? E.g. is the alert of the "your server just crashed" kind or "you have new e-mail from aunt Zelda" kind?
For the first kind, something obtrusive is the best - either your option of floating a window, or may be change the page background to flashy color (and blink??? Don't hit me please!). One other nice way of grabbing attention I saw was to change the page (and thus a browser window) title to a flashing set of "* * * * * *" - that is un-usual enough to attract attention sometimes.
For something less obtrusive for less critical-too-notice-quickly, SO's top notification bar is one of the very best solutions from usability standpoint (if not the best), going by the main metrics (how much work does the user need to do to deal with this and to look at it, and how intuitive its behavior is):
The user's eyes travel to top of the screen more often and more likely than elsewhere
It is very easy to get rid of once you notice it - the bar is wide (easy to hit with mouse, no horisontal adjustments needed) and at the very top (not too much fine mouse work to get the pointer there).
IMHO, the annoyance level should reflect the error level...
For an error, a layer with the error message, preventing the user to do anything else should be better.
For a notification, a box that appears on the top of the page (like a browser asking you to save a password) is nice.
So I don't think there is a better solution... It just depends on the type of the alert... : )
Check out JGrowl, it's a nice framework for unobtrusive notifications, you can find some sample screenshots here.
If you are looking for resources, I suggest Don't Make Me Think by Steve Krug. His site, Advanced Common Sense, is also a great source.
Another great site for Usability tips and guidelines is Jakob Nielsen's useit.com
I was at a site the other day that had a product download button. I clicked on it, it seemed nothing had happened. I clicked it again, and the download link that the first button created did a little shake at me. Very effective and it got a laugh:
http://haanstra.eu/putty/
My system has three types of notifications. Each type of notification is styled with a border and background color:
Success: Green
Warning: Yellow
Error: Red
Alerts, like "You didn't fill that field in properly!" are handled inline, so no popups to irritate the user.
I've designed my system to fade out notifications a few seconds - this means that users are accustomed to seeing the green box that fades away after a few seconds. However, when an error or warning occurs the box stays on the screen right in front of the user, demanding attention.
I believe warnings and errors should be used only when absolutely necessary - that way when they are used, they maintain a significant level of impact. In my system, warnings and errors don't fade out - they stay there to remind you SOMETHING IS NOT QUITE RIGHT.
In my experience, if you're going to interact with a user, make it large and in their face, but don't make it so much so that it obstructs the rest of the page. So no prompts, or lightbox style overlays (in my opinion).
I find the jQuery UI highlight() effect function is good for unobtrusively alerting users that something has changed; however as others have said, it depends on the importance of the message - sometimes you just need to be obtrusive!
I'm using the excellent BeautyTips plugin as a means of indicating validation failures to end users and I'm running into positioning problems whenever page content is dynamically added, removed, or animated.
Here's a concrete example. I have a DIV at the top of each page that’s used for confirmation/error messages. It's displayed in $(document.ready) using slideToggle(). This naturally "pushes" all subsequent html content down, throwing off the positioning/alignment of the beautytips. If I call the plug-in's built-in refresh method after slideToggle() has fired, said positioning problems are corrected. You can see the before/after screen-shots here and here.
One possible workaround would be to programmatically detect DOM changes, specifically changes to css, so that I could then loop over each beautytip and manually reload it. However, it appears that there are no native jQuery events which expose such functionality. I've seen the impressive jQuery plug-in by Rick Strahl that monitors CSS changes, but it seems based on the assumption that one knows ahead of time the specific HTML element(s) they wish to monitor. I want to monitor the entire document, since I can't be expected to know what html elements might exist on a given page that a) are going to be animated and b) would be at such a position in the document that they would "push" down the my beautytips. And I certainly don't want to have to incur the massive performance penalty of polling every block level element in the document.
I should mention that the plug-in works perfectly if I use it in its default "hover" mode in which beautytips are displayed only in response to user mouse input. Unfortunately, there is a design constraint imposed on the application that states all validation errors must be displayed after form submission without additional user interaction.
I'm sure there's a really simple/elegant fix that is completely eluding me. I could avoid all of this hassle, of course, by simply not using animation to display page content, but that seems like a high price to pay.
I have a flex/actionscript based project. The project has various view stacks and tab navigators and a few popup windows. The whole thing is managed in pureMVC framework.
When transitioning between various view states, opening a popup, switching a tab, etc, I find the app to exhibit various redraw glitches. Parts of views will be partially drawn or flicker in odd ways. I am fairly confident that the code is working correctly, just seems to be an issue with the overall heaviness of the UI.
Is this a common issue? Are their tried and true techniques to optimize this problem?
In particular what event handlers are available to delay the drawing of view components until the last moment when everything is ready to quickly display to the screen?
Say for example I have a VBox inside a viewstack, and inside this VBox I have a fairly complex datagrid. Can I prepare the datagrid and/or delay the viewstack change until all subview components are in fact ready to be quickly drawn.
What are some possible symptoms to this kind of glitchiness?
just a guess, but this might be related to the flex framework ... i experienced this kind of behaviour too ... i guess it is related to the way flex framework works when carrying out ui tasks ... a lot of deferred instantiations/calls and so on ... when there is a lot going on, the framerate drops and since deferring is framebased, that is probably when the resulting delays become noticable ...
greetz
back2dos
Not sure if this applies to you, but in Firefox/OSX there is a known bug when you make too many javascript calls, and the result is similar as you say... the whole interface shows various glitches and flickers... The solution was to delay the JS calls a bit, so they don't get called too often... this was a serious issue with swfaddress for instance (I think it still is).
http://www.bigspaceship.com/blog/labs/mac-firefox-30-flash-javascript-random-artifacts/
I assume you need the datagrid already attached to its parent container and you are loading data while it's being shown so it constantly updates and renders its content.
Have you simply tried setting its visibility to false until everything is loaded while keeping includeInLayout true and giving it a fixed size?
I'm working on a web application where we have a modal panel/dialog popup to collect user data. The form within the panel has grown large and we've suggested splitting the form across multiple tabs, but our client has suggested adding scrollbars within the modal panel.
Are there usability issues with scrollbars within a modal panel? I believe it's a bad practice but I'd like other opinions.
Thanks,
Glen
Update:
I'll explain the scenario in more detail. We have a search page where search result items can be saved (copied into a another area of the system). Additional information can be saved with this items (e.g. additional comments, assignment to other buckets - I can't get into any more detail than that). When a user wants to save a search result item, they can check one or more items and click a save button - that's when our modal panel popups.
Originally, the users were taken to a separate page and they followed a series of pages. Our clients felt this was time consuming, so we changed the page to use a modal panel.
I'm not 100% sure using a modal panel is the best design, but that's what we have now. I welcome any other ideas.
Well, I gotta ask, if you have a modal form that's so long, shouldn't it be made into its own page?
I mean, the whole point of modal dialogues is to tell the user something he needs to know (which are usually disregarded and are annoying) or to get some information from the user that is necessary before proceeding.
You say your form is for gathering user input. If it's something the user must enter before proceeding (as in a part of a checkout flow or something like that), then I would say it's probably best to dedicate an entire page to the flow.
If it's something that's more of a "log in here before proceeding with what you're doing" kind of thing, again, I think it would make more sense for it to be its own page that brings you back to the page you were on before you entered it once you're done filling out the form. That's how the Stack Overflow human-verification page works.
If it's something annoying like "give us your feedback about the site", then it shouldn't be modal at all but rather an easily-dismissed (dare I say it?) pop-up window.
Modal dialogues really should be kept as brief as possible. If brevity is impossible, and the dialogue really must be modal, then I think it would make more sense to create a flow of pages that must be filled in before the next one can be accessed. Like a checkout: you need to add products to a cart before adding shipping information, and you need shipping information before you can determine the cost of the shipment. That kind of thing.
But without knowing the exact nature of your modal dialogue I can't tell you exactly which way would be best.
EDIT: Aha! Your clients felt this was time consuming, eh? This is the type of situation where you should do a very quick and dirty live usability test to see which way is actually better. Grab some people from down the hall, show some of them the modal way (with scrolling) of doing it and show others the old (non-modal) way of doing it and see what they have to say.
(Ideally you are recording the session and the screen, and you make sure to not let your own personal preferences show through. Just ask them to use the system while you watch to see how well they perform the task. Use the recording to time both methods to see if one way really is faster than the other.)
You shouldn't ever make a usability decision that goes against the norm (the norm in this case being "large forms merit their own pages") without making sure that it actually is more usable the abnormal way. When it comes to usability, the norm is usually the norm because it's usable (but not always, which is why you must test). If the client fights back, you'll at least have evidence that they're going against hard empirical evidence that what they want is silly.
Ultimately, though, the clients are the ones paying the bills. If you can't get them to see reason then you'll have to make the most of what they tell you. If the form must be in a modal dialogue, then you can at least try to hide non-essential fields under the fold (if there are non-essential fields) so that the majority of users will never have to scroll.
Make sure the buttons to submit the form (or whatever it is that you need to do with the form) are visible no matter where the user has scrolled. A really bad idea would be to put all the required fields at the top and then force the user to scroll down anyway to hit the submit button. That's just rude.
It seems to make sense to put a modal window here--I assume you're doing it as a layer on the page. But what it sounds like is that it's getting crowded, and you're looking at ways to manage the ever-increasing array of UI elements.
To answer your initial question about scrollbars, no, they are not verboten. However, as another responded asserted, you should never design action UI elements within the scrolling area.
It sounds as if some good user research could be useful here. What items are important to users. Which items are required and which are optional? Can they be categorized?
Some people suggest that tabs are useful for categorization when the number of UI items overflows a dialog box. In this case, though, I think this would be a bad idea. This isn't a setting category of dialog box, but more of a confirmation/selection/entry dialog where users will save whatever is entered and chosen. There's a good chance with tabs that users would miss the tabs and miss entering information. And if something on a "back" tab is required and a user doesn't go there, then you have a really poor error experience.
One of the things about scrolling is that it is easy for users with mice. they have the option of either clicking on the scrollbar or (for many) rolling a scroll wheel.
One thing you may not have considered, especially if some things that users can enter or choose are optional, is to create sections within the dialog box that can be collapsed and expanded. Sections with required elements would be expanded by default and sections with optional elements would be collapsed by default. If expansion of a section adds a scrollbar, that addition to the UI is obvious to users.
Of course, you may have to figure out how all this would work for people who have only keyboards, who have disabilities, and who might be accessing this on a mobile device.
I don’t think a tabbed panel is fundamentally better or worse than a scrolling panel. Each has advantages in different situations. However more important in your case is this: If you need tabs or scrolling then your panel is probably too complex to be modal. The more information input in a modal panel, the more likely a user will need to go somewhere else to get an answer, and the more work you throw away if the user decides they must go somewhere else for any reason.
The solution is to move as much information as you can out of the panel and onto the parent page/window. Let users enter the “additional information” right onto the search results page, allowing them to explore the results to help them decide on the information. Since the additional information apparently consumes a lot of space, make its controls show-able and hide-able, but always preserve user inputs between hides and shows. I think it’s okay to either tabs or scrolling to keep the footprint small. Additional information about a single search result should go in controls next to that search result, rather than in a separate panel.
The modal Save panel should only include a few controls that are instrumental to saving, such as the filename and location, and maybe the file type. If all the information is instrumental to saving, then make the save panel modeless. Who says you can’t?
Putting all the save information on another page is not much better than a modal panel, since that is also effectively modal, in the sense that the users can’t go somewhere else without losing their input. Even if you take steps to preserve users’ inputs to the page if they go to another page, most web-abused users will think they might lose their input, so they won’t try.