In a GUI application (desktop or web), there could be multiple editable text boxes in one page/window/whatever. Do people maintain one undo buffer for each text box, or just a global buffer for the entire page/window/whatever? What's the usual practice?
GMail example
There seems to be one global buffer for GMail (or maybe for browsers?). I can't undo email body edits and email subject edits separately.
I think this comes down to what users would expect from the type of app. If you think of MS Word, the undo buffer is per document. On the other hand, in a business app, if the user visits multiple 'pages' to accomplish a given task, then it could make sense to keep a global undo buffer that includes their navigation history.
The Monitored Undo Framework is a .net library that allows you to set up these 'scopes' of undo at whatever level you see fit.
Related
I have a Cocoa app that presents a folder structure to the user and allows basic file system operations such as move/copy/rename.
I perform all file system access on a background queue and use file coordination via NSFileCoordinator.
Let's imagine the user drags the file "Notes.txt" into the folder "Project B". Here is what I do:
I schedule the file operation of moving the file on the background queue.
Once that's done, it calls a block on the main queue where I update the outline view
Let's assume the background operation moving the file takes some time. I need to prevent that the user continues to move files around or performs other actions until the first operation completes.
Hence I would like to:
Disable all user interaction with the window
Disable most menu items and keyboard shortcuts
Keep certain menus such as [Quit Cmd-Q] working
Don't block the main thread
One solution that comes to mind: use a modal sheet?.
I don't want to do this, because most of the time, the operation will finish quickly and the sheet would only be shown for a fraction of a second, which is distracting.
I keep track of how long the operation takes would switch from "interaction blocked mode" to "modal sheet" if it takes more than 500 ms.
The question is: how can I implement such a "user interaction blocked mode" without actually presenting a modal sheet?
Alternative idea: disabling all controls
I considered setting isEnabled = false for all controls, but that's not an option, because the UI can be arbitrarily complex and it won't prevent actions via the menu or keyboard shortcuts.
You may find helpful The Responder Chain article in Apple's Documentation. Proper solution depends on what you exactly need. Overriding NSMenu's - (BOOL)validateMenuItem:(NSMenuItem *)menuItem; let you control over enable menu items and its shortcuts. You may also put transparent NSView over the area you want to prevent from user's interactions.
I am facing an architecture question and I am wondering if anyone know if my idea is feasible or has a better architecture idea.
My situation is that I have CoreData data model for tracking some financial data, imagine it is bank accounts (it's not so don't worry about the security thing). Data for the core data objects is mainly user input.
I know well how to make user input screens (implemented as sheets on top of the main window) and how to implement undo for these input sheets. For simple sheets like edit account i simply copy data from the relevant core data object to the sheet's controller and write back on OK-Close. The write back to the CoreData object is wrapped in an undo grouping which gives me a single undoable action to restore the state to before the edit. This works fine.
Now I am contemplating a more complex edit control where the transactions on the account would be shown in an editable grid (like excel) and it would be possible to edit, add or remove actions. For this control it seem difficult to copy all data to a new data structure. Instead I was thinking of using the core data store as the data source directly, meaning core data objects would change, be created and deleted as the user edit rows in the control. Within this control i then know how to get step by step undo.
The issue comes upon end of the edit session if the user then clicks cancel. I figure to handle this instance I could wrap all actions in the control into one undo group and undo that.
The issue is that after this the canceled actions are then available as a redo on the redo stack. This is cleared as soon as the user does another undoable action but I would like to ensure that this redo action is never recorded at all.
A work around I have thought about is to do some (no-op) action that is undoable after the cancel to clear the redo stack, but then this no-op shows up in the undo stack instead which is also undesirable.
Basically what I'd like to do is to do some form of core data rollback to the state before the complex edit sheet is activated without this rollback being re-doable. The edit sheet is modal and it can be guaranteed that no other changes will happen in the core data model while the edit sheet is active.
Also worth knowing may be that the core data context is not guaranteed to be saved before the edit sheet is activated so simply throwing away the context and reloading from persistent store is not an option. (And would also lose previous undo history as well which I do not want)
The simple question is then, how do I clear the redo stack of the core data NSUndoManager? More generally does anyone know if this is the right solution to my problem or where should I look for a better design solution?
I was wondering if, whenever I have a situation in which I have to hide some UI element temporarily, it is sufficient to hide it (many frameworks give this option) or I should delete the object in memory and recreate it later when needed again (with the same parameters).
What are the pros and cons of each solution? I was thinking that maybe by hiding the element you save state informations that may be important, and you also save the allocation time, so maybe it is the better way for elements that must be hidden for a short period of time. But what if the time becomes bigger? I would then have a non-needed object in memory for the whole time.
One example, to give a clear picture of what I am talking about, would be a toolbar that changes buttons based on some context change. That is, normally there are some buttons attached to the toolbar, but when the user select one action in some other part of the interface, those buttons must be replaced by new ones (one of which is the "Done" button). Similarly, when the user selects the "Done" button in the toolbar, it goes back to the initial state.
I don't know if this is a stupid question and maybe it could be that I'm doing something like premature optimization... but I will be thankful for all your answers.
I think that the general rule of the thumb is that elements that you plan to reshow, should be hidden; otherwise destroyed (some exceptions obviously apply). When/if this becomes infeasible, you could consider further optimizations.
It's a very good question. Here's what occurs to me:
Suppose (just for the sake of argument) you have lots of different forms that could be displayed in the same space. Then if you create/destroy controls, you are only paying at any one time for the controls that the user can see. On the other hand, if you hide/show controls, you are paying all the time for the large number of controls the user isn't looking at (and may never look at). So I always create/destroy. (Actually I keep previously used controls in pools so I'm not actually re-creating them.)
Many people store user state in the controls of the UI, but personally I hate that and I never do it. I think if some information is worth remembering it belongs in application data structure. This means of course, that the controls of the current visible form have to be "bound" or kept current with the application data structure. I just make sure I can do that no matter what.
I've had to be inventive to accomplish these in a way that simplifies application code, and as a result the method I use is not well known, which exacts another kind of price.
There is no general answer to this question. It depends on the system type, CPU and RAM restrictions, the number of UI elements in question, how frequently the UI is going to be shown / recreated, etc. Perhaps if you could give an example we might be able to give you more concise feedback.
Javascript objects are not like Windows (GDI) objects: they usually don't have a will to send/receive messages - almost passive. It takes less code to hide, right?
Perhaps it depends on total amount of interactive objects per user session.
I have a bit of a challenge.
In an earlier version of our product, we had an error message window (last resort, unhandled exception) that showed the exception message, type, stack trace + various bits and pieces of information.
This window was printscreen-friendly, in that if the user simply did a printscreen-capture, and emailed us the screenshot, we had almost everything we needed to start diagnosing the problem.
However, the form was deemed too technical and "scary" for normal users, so it was toned down to a more friendly one, still showing the error message, but not the stack trace and some of the more gory details that I'd still like to get. In addition, the form was added the capabilities of emailing us a text file containing everything we had before + lots of other technical details as well, basically everything we need.
However, users still use PrintScreen to capture the contents of the form and email that back to us, which means I now have a less than optimal amount of information to go on.
So I was wondering. Would it be possible for me to pre-render a bitmap the same size as my form, with everything I need on it, detect that PrintScreen was hit and quickly swap out the form contents with my bitmap before capture, and then back again afterwards?
And before you say "just educate the users", yes, that's not going to work. These are not out users, they're users at our customers place, so we really cannot tell them to wisen up all that much.
Or, barring this, is there a way for me to detect PrintScreen, tell Windows to ignore it, and instead react to it, by dumping the aformentioned prerendered bitmap onto the clipboard ready for placing into an email?
The code is C# 3.0 in .NET 3.5, if it matters, but pointers for something to look at/for is good enough.
Our error-reporting window has these capabilities:
Show a screenshot that was taken when the error occured (contains all the open windows of the program at the time, before the error dialog was shown)
Show a text file containing every gory detail we can think of (but no sensitive stuff)
Save the above two files to disk, for latter attaching to an email or whatnot by the user
Sending the above two files to us by email, either by opening a new support case, or entering an existing support case number to add more information to it
Ignore the problem and hope it goes away (return to app)
Exit the application (last resort)
We still get screenshots from some users. Not all, mind you, so my question is basically how I can make the PrintScreen button help us a bit more for those users that still use it.
One option: Put the stack trace and other scary stuff into the error screen using small, low-contrast type -- e.g. dark gray on light gray -- so that the user doesn't really even see it, but the Print Screen captures it.
But if you want to detect the PrintScreen and do your own thing, this looks like an example of what you want.
Wouldn't it be possible to disable the Print Screen button altogether when the error popup is active? Have it display a message along the lines of "Please use the clearly visible button in the middle of your screen to report the error" I agree it breaks expected functionality, but if your users are really that stupid, what can you do...
Alternatively, have it report errors automatically (or store the data locally, to be fetched later, if you can't send without asking for some reason), without asking the user. If you want to be able to connect print screened screenshots with detailed error data, have it send a unique ID with the data that's also displayed in the corner of the popup.
What about offering them a "Print Screen" button that performs these actions as well as performing the print screen? If you're locked into this method of having your customers send error details, this may be an easier route to take.
Lifted from my comment below for easier reference (looks helpful, perhaps):
codeproject.com/KB/cs/PrintScreen.aspx
This is in theory...the best way to deal with it I would think
Intercept a WM_PRINT message or inject one into your process... see this article here
Install a system-wide keyboard hook and intercept the print-screen key and swap it around with your contents prior to the capture. Now, I can point you to several places for this, here on CodeProject, and here also, keyboard spy, and finally, global Mouse and keyboard hook on CodeProject.
Now, once you intercept the print screen, invoke the WM_PRINT message by capturing the contents that you want to capture.
I know this is brief and short, but I hope this should get you going.
The only solution i came up with was to offer big, large, easy to read toolbar buttons that give the user every opportunity to save the contents of the error dialog:
Save
Copy to clipboard
Send using e-mail
Print
And after all that, i use the Windows function SetWindowDisplayAffinity in order to show the user a black box where the form should be:
This function and GetWindowDisplayAffinity are designed to support the window content protection feature that is new to Windows 7. This feature enables applications to protect their own onscreen window content from being captured or copied through a specific set of public operating system features and APIs. However, it works only when the Desktop Window Manager(DWM) is composing the desktop.
It is important to note that unlike a security feature or an implementation of Digital Rights Management (DRM), there is no guarantee that using SetWindowDisplayAffinity and GetWindowDisplayAffinity, and other necessary functions such as DwmIsCompositionEnabled, will strictly protect windowed content, for example where someone takes a photograph of the screen.
If their screenshots show a big black box, hopefully they'll get the hint.
I did add a defeat, if they hold down shift while clicking "show error details", i don't add the protection during form construction:
//Code released into public domain. No attribution required.
if (!IsShiftKeyPressed())
SetWindowDisplayAffinity(this.Handle, WDA_MONITOR); //Please don't screenshot the form, please e-mail me the contents!
I was browsing the Worst UI You’ve Ever Used question, when I realized that many of them involved the options dialog of some application. This is obviously an area where a developer could get "lost" easily, since there are often a large number of options available which can be hard to organize. (Especially to the stereotypical programmer)
So since I'm getting ready to design an options dialog for my own application, I was wondering: what makes a good options dialog?
Tabs? A hierarchical treeview like Visual Studio that sort of acts like tabs? (I'm currently leaning toward this)
What do you think?
Options windows tend to be crowded, cluttered, and confusing, making it hard for the user to find the option she or he wants. They are often thrown together at the last minute of design without a whole lot of thought or coordination with the rest of the design. That’s what makes them a common target of ridicule. Here’s how to avoid that fate.
Restrict the number of options. The fewer the options, the fewer things to obscure what the user really wants.
Limit options to those that accommodate known individual differences in your users. For example, if your users come from different legacy systems, you may have an option to emulate the keyboard shortcuts of each system.
Even then, consider that forcing a small number users to make a small change in habit may be worth the usability savings in confusion associated with adding another option. Remember that having a single standard UI for all users helps users support each other.
Unless your app has a “playful” side (like Facebook), avoid options for trivial aesthetic preferences. Focus on options that improve the task performance for select users (e.g., options that support accessibility).
Don’t use an option to force the user to make design decision you yourself should make. For example, don’t have options for choosing control locations or color coding color-by-color. Your users are not UI designers and in nearly all cases, you can come up with a better design compromise than your average user.
Don’t use options to set attributes of the data (e.g., the margins of a specific document). Options are attributes of the application and should apply by default to whatever data is shown.
Organize options by function as your users see it. Consider using a card-sort method to categorize your options. Do not hide less commonly used options on an “advanced” tab or dialog. You may have statistics on the use of each option but your users won’t. They’ve no way of knowing if the option they seek is “advanced” or not, forcing them to search the Advanced junk-drawer tab in addition to other tabs.
Move functionality off of the Options window, and make it proximal to the place where the user decides to set an option. Rather than having an option to set a default, use the same interface for overriding the defaults. You can have a “Make This Printer the Default” button in the Print dialog. Include a “Keep View” menu item in the View menu that preserves across sessions the sort order, filtering, and column selections the user set for the window. Alternatively, consider automatically preserving the view –even window sizes and positions -across sessions, and providing a Default View menu item to revert it.
If you have a very large number of options, consider having a dedicated pulldown menu for them on the menu bar, with each menu item opening a different dialog box for each major category of options. Multi-tiered tabs or trees in dialog boxes are nature’s way of saying your Options window is too complex.
A dedicated Options/Preferences pulldown menu is also a good place to put three or four adapting/variable menu items that anticipate the options a user would like to set in a given context. For example, when an email arrives, a menu item can appear that sets the alerting parameters for new email (e.g., sound given, notification shown). When the user changes the default printer to something else, a menu item can appear to make that the new printer the default printer.
Use web-style graphic design, small illustrations, and visual hierarchy to make options easier to find and understand on a given panel. Use font size, color, and/or weight to make commonly used options salient, while still organizing all options by function. Something like:
(source: zuschlogin.com)
Encourage easy exploration and experimentation of options:
The checkboxes and other controls for options in the Options windows should apply instantly on selection so user can immediately see the impact of each option as it is selected. There should be no OK and no Cancel buttons, but only a Close button (there may also be a Reset or Undo button). It’s frustrating to open the typical Options dialog, select an option and hit OK, only to find one has set the wrong option and has to start over. Also, if the user selects multiple options, hits OK (or Apply), and ends up with a totally wacked-out UI, the user won’t necessarily know which option needs to be undone; the user may not even remember all options selected.
Include “What is this?” Help for each option so users can find out more about what an option does and when it should be used.
Consider making the Option window modeless, so the user can pan around the primary window to better see what an option does.
Be sure all option names and their synonyms are in your Help documentation, and be sure the Help documentation shows the user exactly where to find the option. Often users may not know if an option exists, or if it’s an “option” or other kind of command.
Make the most common options easy to find, and the advanced options "optional" to even look at... Hiding the options 99% of your users won't care about is very effective.
The main issue is not overwhelming the audience. Options dialogs tend to be crazy, just because people put every option available in there.
Having a good, clean logical grouping of options, with common options easy, and "advanced" sections making the obscure options less noticable is usually more important than a specific layout.
I think this really depends on how many options you will have, what their logical groupings can be, and where they can come from (the application, external plugins, etc.) The tree-style dialog used by Visual Studio is a good choice because of the large number of options and the many plugins/packages which provide options that are manipulated in this dialog.
The common patterns that I've seen are:
The Visual Studio type dialog (tree view).
The Word/Office options dialog (particularly in Office 2007/2010).
A standard tabbed dialog (only a good options with a small number (less than 4) of tabs).
A single dialog with options grouped using group boxes (standard .NET style or Office style). This is only viable with a small number of options.
Not having an options dialog is best.
If you do however have a lot of options, making it searchable is really helpful.