We have a view in which the users current location can be used.
We are doing the standard 'can we use your location' when the view is 1st shown (and the user hasn't previously said no). If user says yes then it looks up the current location and then shows this.
If user says no (or this isn't the 1st time) then the view stays on screen with the choice of either entering a location textually or pressing the 'use current location' button. Clearly if user has declined location previously we then prompt for permission again if they press the 'use current location' position.
We have this currently implemented through a 'prompt for permission' property on the View Model which the view then subscribes to. If the user says 'yes' we (the view) executes the 'userconfirmed' command in the view model otherwise we execute the 'userdeclined' command (in the view model).
Whilst this works, it just doesn't feel right. We've seen the UserError code and could potentially use this but it feels a bit strange using a mechanism potentially for errors to prompt the user for permission. Clearly this is a scenario which MVVM implementations have numerous different solutions but given the concise nature of ReactiveUI we expected a subtle solution.
Suggestions anyone?
The UserError framework would work well for this scenario, it's probably what I would do. The advantage of using UserError is that you can simulate all of the scenarios really easily (i.e. user declines first view, decides yes later; user clicks yes; etc etc).
Define a subclass of UserError (LocationPermissionError or something), then register a handler on your View that is only interested in LocationPermissionError.
Related
I have this link:
The Best Page
The ajax-populated and -revealed element that exists within the current page is an "enhancement" and has aria-hidden="true". It would be preferable for screen-readers and assistive tech to follow the link's href to the subsequent static page, rather than triggering the click handler (especially since the element that it will acts on is already hidden, as previously mentioned).
Will this behavior already take place or do I need to add something?
When pressing enter on a link, it does the same as a click, and it's a very bad idea to intercept the enter key in order to do something different.
There are keyboard users, perfectly sighted, who aren't using screen reader. These users will experience an unexpected behavior.
Screen readers may choose to send directly a click event, rather than keyboard events, even though enter has been actually pressed. So idem in the opposite direction.
There may be other ways to activate a link, other than click or enter: spacebar, tap on touch screen, assistive techs to click by winking the eyes, etc. How it should behave in these cases ?
By the way, you can't do something different based on whether a screen reader is used or not, simply because you have no 100% reliable way to detect it.
The questions you should ask yourself are:
Why do you want a different behavior between click and enter ? or between screen reader and normal users ?
Are you trying to work around inaccessible content, or do you have two versions of the same content (an accessible and a unaccessible one) ? In that case, it would be much better to have a single content and make it accessible. Rare are the cases where it's really impossible, and experience shows that the two versions are eventually going to be out of sync, more quicker than you think.
When I close the window from cross button it popup for do you want to save the changes you have made as I know I can use button with this code
EXIT_FORM(NO_VALIDATE, NO_COMMIT);
but if user close form from cross button it popups what I did
WHEN-WINDOW-CLOSED
EXIT_FORM(NO_VALIDATE, NO_COMMIT);
but it didn't work why I need I have some information which triggered on WHEN-NEW-FORM-INSTANCE.
So if user commit save some data must be saved which I don't want to save.
As far as I can tell, EXIT_FORM accepts none, one or two parameters, which are:
exit_form
exit_form (commit_mode)
exit_form (commit_mode, rollback_mode)
You used the 3rd option with two parameters, but - both of them belong to the commit mode (which are ask_commit, do_commit, no_commit, no_validate).
Maybe Forms got confused by such values and prompted the user nonetheless. I suggest you try with just one of them, e.g. no_validate as it will
exit the current form without validating the changes, committing the changes, or prompting the operator
By the way, saying
if user commit save some data must be saved which I don't want to save.
doesn't make sense to me. It is user who should decide whether to save changes, not you. If you, as a developer, want to take control over it, create validation triggers (WHEN-VALIDATE-ITEM, WHEN-VALIDATE-RECORD) and - if there's something wrong, raise an error.
Thanks little foot i appreciate you every time respond to me I got answer
What i did in simple is that i did SDI Window -Closed allowed :No
and windows style change Document to Dialog
and i get what i need
again thanks for your kind response
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 have this application where the users can change text files and when they forget to save them, a little message pops up reminding them that the changes are not saved and asks them if they want to save the changes or not with two buttons "Yes" and "No". It also has a little checkbox that says "Disable this warning". And as the same says, if the user checks it, the message will never pop up again when the text files have unsaved changes.
A couple of questions:
1) Should the checkbox value (if they checked it) be remembered if the user only selects "Yes", only selects "No" or any of them?
2) Let's assume the user checked the checkbox so is not warned again about unsaved changes. What should be the expected behavior the next time the user forgets to save the changes?
Should I always assume a default action (yes: save changes, no: discard changes) after the user disabled the warning? If so, which action?
Or should I always save the changes or always discard the changes accordingly to the last user action right after the he disabled the warning?
What you're doing is a common UI pattern but IMHO I think it's not a good user experience. Here is an alternative that I think is much better:
New files save automatically every minute or so (vary this by how long it takes to save);
It saves to a temporary file;
If the user saves a file then give it a name and save it to that location;
If the program crashes then the temp file is still there. The program should ask what you want to do with it when you start up;
Closing the program should have a simple checkbox "Save Now?" (Yes/No). None of this "Are you sure you want to..." rubbish. Not saving should leave the file as a temp file;
Getting rid of the temp file requires selecting a Discard action (with confirmation of "Discard Now?");
Opening an existing file has the same save every minute functionality except that the saves are to a temporary file. Never modify the original unless the user explicitly saves the file, at which point copy the temp file over the original.
Temporary files should be visible on a collapsible pane (or equivalent) including the date of the last edit and preferably a preview to remind the user what it is;
There should be no option to disable this behaviour. It's not invasive or intrusive. As Joel says, every time you give a user an option you force them to make a decision. Options are way overused.
To specifically answer your question: you should never discard anything unless the user asks you to.
Controlling Your Environment Makes You Happy is a must-read on usability. Don't Make me Think! is too.
Since the checkbox says "Disable this warning", that's exactly what it should do. Don't be wishy-washy with what you're presenting to the users, just do what you say you're going to do!
If they forget to save their changes and they aren't warned, then they should not have checked the box. You are correct to always discard changes when the warning is disabled.
Make the checkbox say '[ ] And always do this'.
Then it's clear that if they select 'No', and check it, it'll always choose 'No', and vice versa.
Or should I always save the changes or
always discard the changes accordingly
to the last user action right after
the he disabled the warning?
I believe that should be the expected behavior. It would be nice if you had a hint on the screen of the default action that will take place.
I recommend the book About Face 3: The Essentials of Interaction Design for some really good GUI designing ideas.
1) You should also have a “Cancel” button that aborts the exiting, allowing the user to return to the document to see if s/he wants to save it or not.
2) “Disable this warning” is a little too geeky. Try, “Don’t show this warning again.” This tells the user that the warning will not be shown and implies no saving will happen in future cases. That’s probably not a good idea, and you should reconsider providing such a warning-suppression feature at all.
3) Far more often in this situation a user will want to save things than not, so that’s what your app really should do if there’s no warning. The checkbox in that case should be “Always automatically save changes when exiting.” This implies no warning will be shown in future cases.
4) If you do 3, you also need an alternative way for user to recover from totally botching up the file and not wanting to save. It could be an Undo dialog that allows the user to make big jumps backwards or maybe a menu item like “Go back to previous saved version.” Ideally, this feature should be available even after the user exits and re-opens the file.
5) If users can be made aware of 4), consider making 3) the default or sole option --don't have the warning at all.
All this assumes that periodic implicit saving is not an option.
Better option is Auto save the document into drafts. It is possible to do that asynchronously.
I say, always automatically save. Forget the dialog. If they want to exit without saving, make that an explicit action on the file menu.
Think of how often you want to save versus those times you don't. The ratio is probably 100 to 1 or even 1000 to one. You want to inconvenience the user 999 times to protect them once?
The user of an application wants to
assign a task to a programmer.
The "Edit Task" form is presented to the User.
A popup (actually an absolutely
positioned div) window comes up with
all the programmers to choose from.
The programmer is not there so the
user asks for a "new programmer"
screen. The popup is replaced with a
"New programmer" form.
The user fill the data, and comes to
"Works at" field.
A (2nd or 3d) popup comes to the
stack with all the "Places" to
choose from.
This can go ad infinitum.
How do you design your applications, to avoid the infinite stack of lookup/Entry forms?
Alternatively to creating a (recursive) stack, you could make it a sequential queue of information that still needs to be entered (similar to a wizard). I.e. where you select the programmer, an item would say "(new - will ask for details later)". If it's going to be a wizard, it should have forth-and-back buttons everywhere.
If all the information is required, and none of it is in the system, I don't see how you can avoid having that many dialogs, really.
You can design the UI so it's not to intrusive, of course - try to make the transition between "pick a place" and "new place" as smooth and seamless as possible. In particular, I'd try to avoid it making the first dialog "go away" as such - perhaps just make it extend the existing one, collapsing the existing choices.
It sounds like you've got an appropriately logical division between "who" and "where" though, which I like - I hate entering completely disparate pieces of information on the same form, even if cuts down the total number of forms displayed.
Try not to lose the scope and the target of the screen. For example, in the "Programmer" screen, you need at least to add the basic details of the new programmer item. The user shouldn't add all the details. If the user wants to add more details, he should add it later from the related "Add Programmer" screen.
Check GMail when you create a new filter and you need to add a new label for example.