I'm looking for advanced strategies for dealing with User Object Handle limits when building heavy-weight windows interfaces. Please explain how you overcame or bypassed this issue using SWT or direct Windows GUI APIs. The only thing I am not interested in is strategies to optimize widget usage as I have done this extensively and it does not solve the problem, only makes it less likely.
My Situation:
I have an SWT based GUI that allows for multiple sessions within the same parent shell and within each session their are 3 separate places where a list of user generated comments are displayed. As a user opens multiple sessions and pulls data that populates those lists, the number of user object handles can increase dramatically depending on the number of comments.
My current solutions:
1. I page the comments by default thereby limiting the number of comment rows in each session, but due to management demands, i also have what is effectively a "View All" button which bypasses this completely.
2. I custom draw all non-editable information in each row. This means each row utilizes only 2 object handles.
3. I created JNI calls which query the OS for the current usage and the Max usage. With this i can give indications to users that a crash is imminent. Needless to say, they ignore this warning.
First off, are you sure the problem isn't desktop heap vs. handle count? Each handle can consume a certain amount of Windows desktop heap. One USER handle may eat a lot of space, some very little. I'm suggesting this to make sure you're not chasing user handle counts when it's really something else. (google for Microsoft's dheapmon tool, it may help)
I've read that you can alter the maxes on handles by changing keys in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\Windows\ USERProcessHandleQuota and GDIProcessHandleQuota
This could be a short term fix for users.
I'd approach this by first figuring out what 2 user handles need to be maintained for each item (like 2 for each item in a listbox?). This seems suspect. User handles are for only a few top-level Windows UI objects (Windows, menus, cursors, Window positions, icons, etc...). I don't see why your widget needs to keep 2 objects around for each item (is it an icon handle??).
If you're looking to rip the whole thing apart - this sounds like a job for a virtual-mode List-View (LVS_OWNERDATA).
You should think about using windowless controls. They are designed for precisely this situation. See "Windowless controls are not magic", by Raymond Chen
Not only top-level windows, but most native controls use one user object each. See Give Me a Handle, and I'll Show You an Object for an in-depth explanation of user- and other handle types. This also means that SWT uses at least one user handle per widget, even for a Composite.
If you truly are hitting the limit of 10000 user objects per process, and you don't have a leak, then your only option is to reduce the number of widget instances in your application. I wrote a blog article about how we did this for our application.
Related
If one is attempting to build a desktop program with a semi-complex GUI, especially one in which users can open multiple instances of identical GUI components such as having a "project" GUI and permitting users to open multiple projects concurrently within the main window, is it good practice to push the event listeners further up the widget hierarchy and use the event detail to determine upon which widget the event took place, as opposed to placing event listeners on each individual widget?
For example, in doing something similar in a web browser, there were no event listeners on any individual project GUI elements. The listeners were on the parent container that held the multiple instances of each project GUI. A project had multiple tabs within its GUI, but only one tab was visible within a project at a time and only one project was visible at any one time; so, it was fairly easy to use classes on the HTML elements and then the e.matches() method on the event.target to act upon the currently visible tab within the currently visible project in a manner that was independent of which project it was that was visible. Without any real performance testing, it was my unqualified impression as an amateur that having as few event listeners as possible was more efficient and I got most of that by reading information that wasn't very exact.
I read recently in John Ousterhout's book that Tk applications can have hundreds of event handlers and wondered whether or not attempting to limit the number of them as described above really makes any difference in Tcl/Tk.
My purpose in asking this question is solely to understand events better in order to start off the coding of my Tcl/Tk program correctly and not have to re-code a bunch of poorly structured event listeners. I'm not attempting to dispute anything written in the mentioned book and don't know enough to do so if I wanted to.
Thank you for any guidance you may be able to provide.
Having hundreds of event handlers is usually just a mark that there's a lot of different events possibly getting sent around. Since you usually (but not always) try to specialize the binding to be as specific as possible, the actual event handler is usually really small, but might call a procedure to do the work. That tends to work out well in practice. Myself, my rule of thumb is that if it is not a simple call then I'll put in a helper procedure; it's easier to debug them that way. (The main exception to my rule is if I want to generate a break.)
There are four levels you can usually bind on (plus more widget-specific ones for canvas and text):
The individual widget. This is the one that you'll use most.
The widget class. This is mostly used by Tk; you'll usually not want to change it because it may alter the behaviour of code that you just use. (For example, don't alter the behaviour of buttons!)
The toplevel containing the widget. This is ideal for hotkeys. (Be very careful though; some bindings at this level can be trouble. <Destroy> is the one that usually bites.) Toplevel widgets themselves don't have this, because of rule 1.
all, which does what it says, and which you almost never need.
You can define others with bindtags… but it's usually not a great plan as it is a lot of work.
The other thing to bear in mind is that Tk supports virtual events, <<FooBarHappened>>. They have all sorts of uses, but the main one in a complex application (that you should take note of) is for defining higher-level events that are triggered by a sequence of low-level events occasionally, and yet which other widgets than the originator may wish to take note of.
I want to do some tests on our tcl tk application regarding the user interaction. As the application has parts similar to a CAD for which every mouse movement is relevant, I would like to do something like record all events of some user interactions. My goal would be to playback these events laterwards and on every program change to discover potential changes. Or even better to assure the GUI behaves always the same and produces always the same data.
I know, that I can generate some enter motion and button events, but this would not be the same like the thousands of events generated by a real user interaction. But it is very important for me to have exactly these thousands of events.
Is there any possibility to achieve this?
It's relatively easy to record events of particular types with bind — you'll find that <ButtonPress>, <ButtonRelease>, <Enter>, <Leave>, <FocusIn>, <FocusOut>, <KeyPress> and <KeyRelease> cover pretty much everything that you are interested in — and then play them back with event generate. (You need to record quite a bit of information about each event in order to regenerate it correctly, but the underlying model is that of X events with similar names.) Assuming you're not wanting to support inter-application cut-and-paste or drag-and-drop for the purposes of recording; those complicate things a lot. You'll likely have a lot of events; recording to an SQLite database might make a lot of sense.
However, you should think carefully about which parts of the application you want to record. Does it matter if the order of two buttons in the outer shell of the application outside the CAD-like area get swapped in order? For most users, provided you're clear about what the buttons do (through clear labels and icons) it isn't very important, but for replaying recorded events it can matter hugely. Instead, for the parts of the application that are simple buttons and edit fields, I'd not record the details of them but would instead just record when the buttons are clicked and the changes to the text content of entries and so on. In effect, it's capturing higher-level events, and that's much easier to replay correctly. It's only when the user is in that main CAD area that you need the full detail.
Also, beware of changes to font sizes and screen sizes/scaling. They can change how things are laid out and may happen because of system-level alterations outside the scope of your application.
We started out the way you describe: record all those thousands of motion events, etc. Including exact timings which are extremely important for a GUI application as well.
It quickly became appearent that those recordings became too hard to maintain. They are also overly brittle in light of UI changes. Another problem where the hardcoded time values. A switch to a more powerful machine (or a cpu under load) would break the execution.
The two biggest improvements we introduced
Event compression: recognize the high-level action the user wanted to perform (like selecting a menu item). The recorded activateItem command would then perform the necessary work (event emulation) on replay.
Synchronization functions: instead of relying on a particular timing commands like waitForObject wait for an object to come into existance and become ready for interaction.
It took several years for this to work fluently, however. Including a central Object Map repository, property and screenshot verifications, high-level test descriptions in BDD and others. Feel free to take a look a the Squish for Tk product that came out of this work.
We update content control for every character typed in the task pane’s input field. So that user can see the live updates on the word document.
Recently we added functionality for locking content controls. And it happens as below:
User input (types a character) in a input field
We search a content control for that input field (involves context.sync)
Unlock the content control (involves context.sync)
Update value in content control (involves context.sync)
Lock back the content control (involves context.sync)
All this works nice in Word for windows without problems.
But is extremely (visibly) slow with Word for Mac (apple machines)
How should I overcome the delays happening on Mac?
As Juan mentioned in the comment, there are some important details that the team would need to investigate. Sample code would be good too.
That being said, just looking at what you describe, I think you can dramatically cut down on the context.sync() statements. Unlocking the content control, updating its value, and locking it should all be possible to do in one sync.
I have a bunch of details about minimizing sync-s in my book, "Building Office Add-ins using Office.js. Quoting one of the sections from it:
As an add-in author, your job is to minimize the number of context.sync()
calls. Each sync is an extra round-trip to the host application; and when
that application is Office Online, the cost of each of those round-trip adds up
quickly.
If you set out to write your add-in with this in principle in mind, you will
find that you need a surprisingly small number of sync calls. In fact, when
writing this chapter, I found that I really needed to rack my brain to come up with a scenario that did need more than two sync calls. The trick for
minimizing sync calls is to arrange the application logic in such a way that
you're initially scraping the document for whatever information you need
(and queuing it all up for loading), and then following up with a bunch
of operations that modify the document (based on the previously-loaded
data). You've seen several examples of this already: one in the intro chapter,
when describing why Office.js is async; and more recently in the "canonical
sample" section at the beginning of this chapter. For the latter, note that the
scenario itself was reasonably complex: reading document data, processing
it to determine which city has experienced the highest growth, and then
creating a formatted table and chart out of that data. However, given the
"time-travel" superpowers of proxy objects, you can still accomplish this task
as one group of read operations, followed by a group of write operations.
Still, there are some scenarios where multiple loads may be required. And in
fact, there may be legitimate scenarios where even doing an extra sync is the
right thing to do – if it saves on loading a bunch of unneeded data. You will
see an example of this later in the chapter.
It happens sometimes that one feature seems to belong to more than one place.
Trivial example, let's say I've got the following menus :
File
Pending orders
Accepted orders
Tools
Help
I've got a search feature, and the same search window work for both pending and accepted orders (it's just an 'order status' combo you can change)
Where does this search feature belongs?
The Tools menu seems to be a good choice, but I'm afraid the users may expect the search accepted orders to be in the accepted orders menu, which would make sense
Duplicating the menu entry in both pending and accepted order seems wrong to me.
What would you do? (And let's pretend we cannot merge the two orders menu into one single menu)
I think the problem you've run into is that you're thinking like a programmer. (code duplication bad). I'm not faulting you for it, I do the same thing. Multiple paths to the same screen, or multiple ways to handle the same process can actually be extremely beneficial. I would guess that more than one person is going to use your program and each probably have slightly different job functions. In essence, they have different needs for the application and will approach using it different ways. If you stick to the all items have one way of being accessed, some people will find the application beneficial and others won't. Sure all people can learn to do a task a certain way, but it won't make sense to some users. It's not intuitive (read familiar) to they way they are used to processing information, which means the application will ultimately be less beneficial to them. When people find a process (program etc.) frustrating, they won't adopt it. They find reasons why the process will need to be changed or abandoned.
An excellent example of the multiple approaches to a problem is with Adobe Photoshop. Normally there are at least 2 different ways to access a function. Most users only know of one, because that's all they are concerned with, but most users are really comfortable with using one, because it makes the most sense to them. With a little extra work, Adobe scored a huge win, because more people find their product intuitive.
Having a feature in multiple locations is not a bad thing. Consider the overall workflow for viewing both pending orders and accepted orders, and think of your new feature as a component, rather than a one-off entity.
After you map out exactly what tasks a user completes in the pending and accepted order viewing process, see where having the ability to search would provide value (by shortening the workflow or otherwise). This is where your search component belongs.
The main thing to remember about UI is that all that really matters in the end is whether your design makes using your application or site a better experience for your users.
In the search example you list above you'll commonly see apps take two approaches:
Put the search feature in a single location and allow the user to filter the search by selecting pending or accepted, or
Put the search feature in both menus, already configured for the type of search to be done based on the menu it was launched from.
If you repeat the above choice for a number of factors you'll see a much more advanced (aka 'complicated') search interface for number one, and a much simpler (aka 'restrictive') search interface for number two.
Which one is best completely depends on your users. This is why many general applications have a simple search by default and a link to a more advanced search for those that want or need the additional capabilities; they're attempting to make everyone happy. There is absolutely nothing wrong with that if you're writing for a wide variety of people with different needs. If you're writing for a set of users with a restricted set of needs however, you can make some better choices.
In my experience your best bet is to work with one or two of your primary users and map out all of the steps they need to take to get each of the tasks the application will be helping them with accomplished. If there aren't a lot of branching points in that sequence of steps there shouldn't be a lot of choices or settings to make in the application; otherwise the users may feel that the app is harder to work with than it needs to be.
For the search example above, if the user has already navigated into the Pending Orders menu, the likelihood that they'll want to launch a search for Accepted Orders is very small and having to make that choice, or go elsewhere to do the search, will be an extra decision or action they'll need to take. Basic principle is if your user has already made a decision, use it; don't make them tell you again.
Use the UI you come up with as a first cut. Let your users, or a subset of them, try it out and make suggestions. If you have the option, watch them use it. You'll learn far more about how to improve the interface by seeing how they work with it than you will from what they tell you.
Generally you do not want the same menu item appearing in different menus. It adds complexity and clutter to the menu, and users will wonder if the two menu items are really the same or not. When it appears that a menu item belongs in two places, then you may have a more basic problem with your menu organization.
For instance, your example shows a menu bar that is organized by the class or attribute of the object the commands within act on. In general, the menu bar should be organized by category of action not type of object. For example, you could have a Retrieval menu for commands like Search and other means of displaying orders, and a Modify menu for processing the orders (e.g., updating, accepting, forwarding). Both menus would have menu items that apply to both types of objects, although some commands may apply to only one.
Organizing commands by object type is actually a good idea but it is better accomplished with a context menu (right click) than the menu bar.
I would try the search in both the Accepted Orders and Pending Orders menus. However, user testing will show if this is a good idea or not. But it also depends on your user base.
You are doing user testing right?
...you may already know this, but this is a good place to use the command\action pattern IMHO.
So to answer your question: IMO, yes, it is ok :) This situation is definitely warranted.
Just put it under both menus and have it open your search window, pre-configured for the order type who's menu it was launched from. Name them accordingly and voila they're actually two different actions - even though they use the same code/component.
Keep the user-selectable "status combo you can change" in the search window active though so the user still can adjust the settings without relaunching it from the other menu... and then perhaps rethink the structure, see some of the great answers in here for ideas ^^
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
This is a perennial question for me that I've never really resolved so I'd like your input. If I have actions that I know a user will not be able to perform due to insufficient privileges or object state, should the UI elements for those actions be hidden from the user, visible but disabled, or visible and result in an error if attempted? What would be the rationale for your answer? If disabled, would you communicate the reason why and, if so, how?
This is a web interface so I already know that I need to check the incoming post/get for permissions and handle errors there anyway. I'm primarily talking about how to handle the UI.
This is similar to Rules about disabling or hiding menu items, though I am interested in all types of UI elements not just menus.
Examples:
I have a New page that allows a user to create a new Event. Events can be master events or subevents. Creating a master event requires "EditMasterEvent" privilege, while creating a subevent requires only "EditEvent" privilege. I have a drop down that allows one to choose an existing event as the parent (master event) or no parent (this is a master event). Should the "Create Master Event" choice be shown on the dropdown or omitted if the user only has "EditEvent" privileges.
Deleting events requires that you be an application administrator or have the appropriate edit permission for the event type. In the latter case, the event must also be more than 5 years old. Deleting an event causes major cascading deletes of related data in the system and for legal reasons this data must be kept for at least 5 years after the event. Since this operation is rare for the normal user, the typical case is that the action is not available. Should it be shown always or only when actually possible?
Hidden - This is the best approach for actions that are never available to the current user. There is no point in having the user waste mental effort figuring out why something is disabled if there is no action they can take to change this.
Disabled - This is the best approach for actions that are sometimes available, but not at the moment or in the current context. A disabled option should convey two things: first, the action is not available right now, and second, there is something the user could do to make the action available (change some setting or permission, select an item, enter prerequisite data, etc.). If you can indicate what needs to be done to enable the action in a tooltip - all the better. Enabling/disabling actions as the user enters data or changes context provides excellent feedback about what the program requires.
Fail with an Error - This is the worst choice. You should only resort to an error report for operations that might work: you can't tell that it will fail except by trying.
As with nearly all UI questions, the answer is "it depends".
You need to weigh discoverability with user satisfaction, among other things. For example, allowing an invalid action gives you an opportunity to explain why something is invalid. This is particularly useful if the answer to "why is this disabled" isn't obvious. For an application where most users are beginners, that's important.
On the other hand, it can be mightily frustrating to see a control, click on it, only to be rewarded with a "sorry, you can't do that now" message. An app I inherited a couple years back was rife with that sort of stuff and it made using the UI an exercise in frustration.
Completely hiding functionality is probably rarely a good idea. Imagine knowing some feature "was there a minute ago" but now it's gone. Whether it's a menu item or a toolbar button or something else entirely, making it hidden can be an exercise in frustration for the end user.
Try doing a little usability testing, if only by asking the next person you see "hey, does it make sense to disable this or show you an informative dialog". Just one other opinion is often enough to get you to look at the problem from another direction.
Bottom line: do what best serves the user. All the scenarios you mention are valid under certain circumstances. As with all UI questions, ask yourself (or better, your users) what best serves their needs.
I disable the elements instead of hiding them. That way the user knows the option would normally be available, and I provide a tooltip to explain why the element isn't currently available.
It depends. Do you want the user to be aware that the action is possible, just not for them? In that case, show them the button, but disable it. An example might be if a user doesn't have delete authority, but other users do, they should know that entries CAN be deleted, so they can ask someone to do it for them if they need the action.
On the other hand, if the user is not supposed to even know about the action (for example, a user who does not have read access to audit logs probably shouldn't know that these logs exist) should not be able to see the button, so hide it completely.
Great question!
A couple of considerations:
If you place the elements on the page but disable them, there's still a remote chance that the user could doctor the system and enable them using a javascriptlet.
If you do not show them at all, the overall functionality may be a bit confusing to the general user. "Shouldn't there be an edit button here?"
If you're going to either display and disable or display and verify the elements, I would definitely do server-side validation. Don't leave the validation in the hands of JavaScript; I think the reasons for this are obvious.
I tend to handle the two different types of situations differently. Is this an action that is governed by privilege and by state of the object.
If the person does not have enough privileges to do an action, I hide the option, they do not know they can perform the action.
If the option is not available because the object is not in a state that can use that option, I disable it, allowing the option to be visible to the user, but no action can be done.
From your examples:
I would not have "Create Master Event" as an option. The user has insufficient privileges to view it.
I would have the Delete button visible to the administrators. Then depending on how you do the rest of the site (a lot of visible text, tooltips, help icon, etc) I would follow that convention about informing the user why the button is not usable at this time. And possibly putting a timer on, above, near the button with either how old the post is or how long until it can be deleted.
Depending on the item, we will either hide them or disable them. If the user has access to a large feature, but not to a smaller piece inside it, then we will hide the smaller piece. However, if the user has access to several large features, but not to others, we'll leave them visible but disabled as a marketing ploy to remind them that the features are available for purchase if they should decide they want them.
I've also seen some programs that disable the menu item and change the text of it to "Log in to do blah..."
I like this because it doesn't leave me with the "why isn't this working?" feeling and tells me immediately what to do to get it working. Not applicable in every case, but this is a nice approach if you can implement it.
The general rule is use disabling if the user can do something in the UI to get the privilege. Disabled means “you can do this command, but just not right now the way things are.” The “way things are” includes the current selection, so use enabling/disabling if the user has the EditEvent privilege for old objects but not for new objects. There should be a clear indication which objects are delete-able so users understand why the associated commands are disabled for some objects (e.g., if users generally know that records must be kept for 5 years, a simple Age field maybe be sufficient, perhaps reinforced with a graphic difference for records over 5 years old).
Use message boxes instead of disabling if there is no way to make the reason for the disabling clear to the user assuming they have average knowledge of the domain. Tooltips for disabled controls, BTW, are a great idea, but may not be sufficient by themselves.
Use hiding if the user never has the privilege no matter what they do in the UI given their current position in the organization (e.g., they are not an Application Administrator). It is cluttering and frustrating to use disabling or message boxes for this case. As far as the users are concerned, actions they don’t have the privilege for are not their job (otherwise they’d have the privilege), and so the associated controls should simply not exist in their UI. Documentation or organization procedure manuals may tell users how such actions are accomplished (e.g., “Your supervisor creates new events for you.”).
I’ve more details at http://www.zuschlogin.com/?p=40.
I would say disable with a hover containing the reason.
It prevents the user from wondering what the hell is going on while at the same time letting them know certain actions are possible under the right conditions.
I have a particular hatred of applications that disable buttons. If you're an end user - you want to know why you can't use that button. Having it greyed out doesn't tell you anything. How do you get to the state to enable it? Tooltips are one solution, but they aren't the best, a lot of users will struggle with tooltips (unless you're working with experienced users).
My personal feeling is that the elements should always be present. If the user doesn't have enough permissions to do them, they should generate an error when clicked upon.
I know that translators don't really enjoy creating a zillion different "permission denied" error messages, so this is often not done in localised applications, which tend to hide the elements instead.
In practice a lot of people tend to hide the options instead even in non-localised apps.
Other people have provided good answers with valid suggestion to avoid hiding elements and instead disable them and provide some hints for the reasons.
So, I would like to look at it from different perspective - but how to hide some UI elements in cases when user does not need to see them, no matter if he has or has no permissions for particular actions related to the elements?
For example, let's say, users of some role are given access to sellers records in the system.
But then business analyst says: "Look, there is a dropdown with sellers list in this form and we should not allow some specific roles to see it".
Developer asks: "So, we just remove the "Read sellers" permission from this role, right?" But the analyst replies: "No! This role should still be able to view the sellers on the Sellers page. It's just this single form where we should hide the list for some roles and show it to some other roles."
So, the developer adds permission called "Show sellers dropdown on the form X".
Ooops, now we have a problem. Access to the same data is being controlled by two separate permissions. Now we have to figure out how to combine both of them. And what if there are more than one form where seller's list should be hidden for some roles? How do we combine it with "Read seller's list"? For us, developers, it is somewhat clear that "Read" permission should have higher priority above "View", so even if a user can "View" a list, he still should not see it (or see empty or disabled with a helpful hint) if he does not have "Read" permission. We, developers and analysts of the system know it. But how should the system administrator know it? Should we teach him this? How can we guarantee that the admin won't confuse all those "View" and "Read" for the single data list?
As you see, it all gets messy for one reason - we are mixing data processing permissions with UI conveniences in the list of role permissions.
I have seen many projects where it gets messy because permissions on the server side get coupled too much to UI, which asks for troubles and possible security holes (because you have multiple items in your role permission editor for the same actions on the same data).
Permissions are about access and operations on some specific data. UI can only react to permissions in consistent way throughout entire system (disabling with hints, hiding etc.). We should never invent new permission entries just for UI purposes.
Now the question remains - but how do we actually hide UI elements for some system users to avoid overwhelming them with huge amount of always disabled items? One solution might be role workspaces. If we clearly know that users of some role will never ever need access to some specific data, we create a set of UI control entries, similar to permissions, but this time we don't call them permissions. And we can get really fancy here, even allowing users themselves to freely customize their workspace and choose what they can or cannot see. Of course, permissions will always take the highest priority, but it will only affect the data and state of UI elements and not visibility.
That's my two cents. Unfortunately, I myself haven't worked on such a system where permissions and UI workspace options are neatly separated because I always somehow come too late to a project, when the "damage has been done". But I hope some day I'll have a chance. I just hope to find a good example how to do this right, but somehow internet searches do not give me anything useful. Does it really mean that nobody else has came to the same conclusions as me? I don't believe it, somebody in the enterprise design pattern world should have noticed this UI<->permission impedance mismatch long ago.