A WinForms program will inevitably send notification to user. There are two types of notifications:
Important: user needs to take action on it
Non-Important: kind of like "there is something going on, and you might want to pay attention".
It's pretty common that MessageBox is used for both of the two types. But recently I found MessageBox is kind of annoying: it steals user's focus and user has to click to dismiss it. I want to know what's the alternatives for MessageBox and their pros/cons?
To start, here is some idea:
Statusbar: not easy to display lengthy notification
taskbar notification: does people think it's evil since most internet ads popup use that approach?
floating statusbar: Chrome/IE9/Evernote use similar floating statusbar, which is hidden when there is no link address or no message.
Chrome UI: Infobar and Status Bubble
IE9: Notification bar
We implemented a mechanism similar to taskbar notification, but placed in some coordinates inside a WinForms control.
This has some advantages:
You have some context about where (location) the notification is shown and why.
It is non modal, so it not blocks the GUI.
It's easy to implement using a owned form without border.
You can place it wherever you want.
You can show a link label with a short explanation and show help, other dialos, or link some actions if the user needs further explanation. The user experience is improved.
But I recommend using notifications only for informative messages.
You must take into account some tips about the messagebox:
It's the standard way to show information to the user.
It should be user to notify an error message or a warning. The messagebox ensures that the user, at least, clicked ok. So the user is aware that something happens. Yes, maybe he didn't read the message, but at lease he saw an error or warning.
It is possible that the user ignores other reporting mechanisms.
Hope it helps.
I have been working on a C# WinForms solution using the WebBrowser control on a form.
At this time it has three modes: Prompt; Countdown Prompt; Countdown Timer and Combo(box) prompt.
Using the webbrowser control allows HTML to be used which gives you free selection of Fonts; Colors and sizes.
I'd share what I have if I only knew how to share a solution instead of a code snippet.
What I've got works and has two parts, the designer and the prompt itself.
If an admin will contact me I can provide a download link and they can review to see what they think.
Related
Is there a button property that is analogous to swing's tool tip? I want the user to be able to long press a button and see a message describing the button, but I can't find any such property. (The button doesn't and can't have a visible name.) Tool tips are so useful to users, so I assumed there must be one, but I can't find it.
The ToastBar (https://www.codenameone.com/blog/toastbar-gaussian-blur.html) might work.
There was also an old demo using the GlassPane for a tutorial overlay which allowed some quite neat effects. Can't find it on the CN1 website now though.
What is the best approach to make an SPA (AngularJS) Accessible (for screen readers etc)?
I have little to no experience with the aria specification, and I wonder if it will at all work on a single page application.
What are the common pitfalls when developing?
How do one debug and test the accessibility when developing?
This could cover a broad swath of issues here. So I'll go through some of the basics in the hopes that it starts you on your way, the common pitfalls, as it were.
Firstly, like the commenters said, yes, you need to make sure ARIA tags are employed correctly. So, say, if you wanted to expose a div as a button, you'd have something like this.
<div id="mysuperflashybutton" ... role="button" aria-label="Super flashy" tabindex="0"></div>
This button when selected by a screen reader will be called "super flashy button", so you don't need to put button in your aria-label attribute. There are more complex examples out there, but that illustrates the basics of it, pretty much. Role, aria-label and tabindex will be the most prevalent ARIA attributes you see.
Tab-indexing elements that you want screen reader users to click on is vital to this. Set tabindex to 0 to include it in its default location on the document. If you don't want it to necessarily normally be reached by people using keyboard navigation, set it to -1. This means it's out of the normal tab order, but can still be navigated to if you want to put the user's focus there manually through javascript/jquery .focus().
As mentioned, sometimes you can assist keyboard navigators/screen reader users by moving their focus for them. An example would be if they click a button and a menu appears. You could do something like this to put them on the first link of the menu:
$('#linkmenuactivator').on("click", function () {
$('#linkmenu').find('li:first a').focus();
});
I know that's in JQuery, I'm not familiar with AngularJS but my brief view makes me think it's more of a ViewModel controller as opposed to something UI specific like JQuery, but correct me if I'm wrong.
Live regions can be used if you're doing funky things on screen that will make no sense to a screen reader user. You can write text to the elements in these regions to put the information out textually. The easiest way to do this is to use a role of alert or status, for important messages or generic status updates respectively. These roles make your element a live region by default, and any text changes in there will be reported to the screen reader. So a quick example would look something like this:
<p id="ariastatusbox" ... role="status"></p>
Then later in JQuery (taking the example of you loading a document and fading it in when you've got it):
$('#maincontent').fadeIn(function () {
$('#ariastatusbox').text('Document loaded');
});
This will let the screen reader know that the document is loaded and ready to be read on screen. Live regions can be slightly tricky, but they're a powerful beasty if you can master them.
Finally, as to accessibility testing, there's a few options. Something I recently stumbled across is Wave which appears to be an online testing tool. It looks good from a first glance, you could give it a try. Another option is to grab a screen reader yourself and give it a go. I recommend NVDA which is an open-source (so therefore free) screen reader. It's my screen reader of choice and is pretty damn good. The synthesiser it comes bundled with doesn't have the nicest voice, but there are other options, or you could turn off the speech output and view a textual display of what it would be saying using the Speech Viewer. A final option is to ask for accessibility testers to take your app for a test drive. For consumer products or things in those brackets, blind people and other users of accessible tech may well volunteer to do it if asked. For more business oriented apps that you might not want out in a public forum, there are several organisations that can consult on issues of making web applications accessible.
This is by no means a comprehensive manual on accessibility, I was hoping to really kickstart you in the right direction. For a bit of a deeper look, try looking at the ARIA roles documentation (all of it will help but the code is under the definitions heading), and on from that the ARIA States and Properties documentation. They both can be a little dry, but also have the full list of everything you can use ARIA wise. Google should be able to yield some tutorials, too, I hope.
I hope this helps get you started. Good luck!
I am making a WPF application that is to be used on a kiosk with no hardware keyboard. Currently we are using a third party on-screen keyboard, but the Windows 8 version is a lot better and we are thinking of switching to it.
So my question is simply if it is possible to show/hide it as well as show a numeric only version using c#.
Thanks!
David
From this source:
There is no direct way to control the touch keyboard programmatically.
Requiring the user to set the focus rather than the program is a
deliberate design decision to prevent UI churn.
See Input Hosting Manager and the Touch Keyboard for more information
on how and why this works. The User-driven invocation section of that
document explains the specific behavior you are asking about.
But, once the user touches an input control, the soft keyboard will automatically be displayed (with no extra coding needed).
Finally, to address your question on a numeric-only version of a keyboard, you may propose a different keyboard layout using InputScope on a TextBox. The different input scopes are enumerated here, but one of them is "Number".
I've published a sample on how to trigger the touch keyboard in WPF applications when a user clicks into a Textbox, its here:
http://code.msdn.microsoft.com/Enabling-Windows-8-Touch-7fb4e6de
I've been working on this sample for many months and am glad to finally contribute it to our community. Please let me know if there are any questions, suggestions, problems, etc in the sample Q&A pane
Also note that while demonstrate how to "show" the keyboard, i'm not sure how to dismiss it programmatically at this point so its important to test any actual implementation to ensure its a good experience. For example some controls like Button will dismiss the keyboard when they get focus from a TextBox, but certain ones like Checkbox will not and I demonstrate that in my sample.
I have a certain UI element, which when clicked should navigate to another URL.
I tried handling the mouse down event and execute something like this:
System.Windows.Browser.HtmlPage.Window.Navigate(new Uri("http://google.com"), "_blank");
However, this gets blocked by the browser (I tried both Chrome and Firefox) unless I disable the popup blocker.
I did some research and it seems that the browser blocks navigations that don't occur as a result of user interaction and as far as the browser is concerned this navigation is initiated by a plugin (Silverlight), not a user.
OK, makes sense. But then I tried using a HyperlinkButton instead and it was NOT blocked.
I wonder why these two approaches get different treatment from the browser. Any idea?
I actually worked around the problem by wrapping the navigation triggering UI with a HyperLinkButton, but I'm still very curious...
I'm going to pull a fancy corporate quote and say "It is a feature, not a bug."
The Silverlight team is obviously worried about Security. They don't want crazy haxorz like you and I to do crazy things with our apps--you know, like popping up a bunch of browser windows all routing people to Zombo.com. Just imagine the choir! Zombo!
Summarized from their documentation: They want us to only use the HyperlinkButton to go outside of their application. In fact, they went the extra step, and depending on our settings, they will even throw a SecurityException for us if we navigate to an outside page--Even from a HyperlinkButton. How nice.
The real question: Why the Hyperlink Button and not something else?
Only one "thing" can navigate. this take saves time for Microsoft while testing Silverlight. This one thing can navigate to both internal XAML pages and external web pages--Might as well be consistent and have only one way to do navigation.
It is a UIElement. It's code behind likes to run in the primary visual thread. It can promise the browser that a Visual Element wants to go somewhere. Microsoft can also put its limiting logic in a control that requires a mouse-click/keyboard-input event tree.
All in all, it makes sense to start simple by making a control do the work.
Fun stuff! Hope this helps you.
When I have 2 apps open and one has the focus but I want to execute a command in the other app, it requires a click to regain focus and another to execute the command. Is there some good reason why I couldn't take focus on MouseOver? I'm working with a WPF app if that is pertinent. TIA
EDIT: Oddly enough the MouseOvers work without focus.
I would not recommend doing this. This is not a standard way of working in Windows, so you will confuse your users. People are used to clicking into an application (or tabbing) to provide focus.
However, this is a configurable setting via the Accessability Tools in Windows. It can be enabled by choosing "Activate a window by hovering over it with the mouse" globally. Let your users specify this behavior if they want it.
The setting is configurable at a system-wide level. You should never ever override the user's current setting regarding this.
MS Windows Vista -- focus follows mouse (There's also a link on how to do it on XP.)
Edit: Normally, you can click a button on a form and both bring focus to the window and click it at the same time. The origins of the current setting "eating" the initial mouse click that brings focus to a window started as a fix to a bug in the Ribbon UI. The discussion is somewhere in this video: The Story of the Ribbon. Sorry I can't narrow it down more than that, but at least the video is a great insight and work watching - maybe you can send a message to Jensen Harris if you need a faster answer.
Edit 2: I just added a button to a WPF window, and I'm able to click it as long as I can see it - whether or not the window has focus.
You can take focus on MouseOver manually