Should a lock/unlock button show state or functionality? - user-interface

Purpose
Allow enabling/disabling of a text field, by a lock/unlock icon
Proposed
Icon show state
i.e. when locked, show locked icon
when unlocked, show unlocked icon
Question
When toggling between locked/unlocked state, it seems counterintuitive to click the locked icon, but the action is actually unlocking the text field.
Should I show the functionality instead of state instead?
unlocked icon button
locked icon button

Related

How to restore missed keyboard state after showing popup in AppKit?

I'm writing an AppKit application that within its window may open up a popup menu to resolve ambiguities when certain hot keys are pressed. My problem is that the popup seems to catch all keyboard events so they no longer end up in my main NSView and therefore the main view never seems the key up event. The user presses alt+tab, clicks something in the menu, and my app things alt and tab are still pressed when the popup is gone. Since it's a popup, there is also no event indicating that the window became deactive or otherwise lost focus because it didn't.
Is there:
a way for the view to still receive at least the key up that opened the popup?
a way to read all currently pressed keys (I only know of NSEvent modifierKeys) so I can restore the correct state when I know the popup closes?
Thanks

VoiceOver focus does not move with keyboard focus while navigating through Mac app menu items

I have a Mac application of type agent (LSUIElement is true).
When app is executed, app icon is shown in top menu bar. On clicking the app icon in menu bar, menu items (NSMenuItem) are displayed.
Please find below my observations on following two scenarios:
App is executed without assigning tooltip to menu items:
While navigating using keyboard, VoiceOver focus remains on menu item on which there is a keyboard focus.
This is working as expected.
App is executed after assigning tooltip to menu items (using setTooltip method):
While navigating through menu items using keyboard, suddenly VoiceOver focus is shifted to some other UI element on screen (e.g. Finder window, Safari window, etc) or VoiceOver focus does not move with keyboard focus.
I observed that, this happens when keyboard focus is kept on a menu item for some time (e.g. around 4-5 seconds) before navigating to other menu item.
This is not working as expected.
Ideally, VoiceOver focus should move with keyboard focus even if tooltip is assigned to menu items.
Can anyone please tell me how to fix this.

CustomTaskPane Visibility in Outlook

I have a custom TaskPane in Outlook. When the user toggles the visibility, I record it in the settings object so that the next time Outlook starts it will be shown/hidden as the user left it.
CustomTaskPane.VisibleChanged is raised in each of the following scenarios
The user clicks the X in the top right corner of the task pane
TaskPane.Visible is set in response to the user pressing a toggle button in the ribbon
The user presses the File menu button on the top left
The first two ways, the user clearly meant to hide the task pane. The third way the user was just trying to go to the menu screen (perhaps on their way to hit the Exit button).
Question
Is there anyway to determine that the event was raised because of the File Menu? Any way to programatically determine if the File Menu is currently open?
Here's what I mean by the File Menu Screen:
The Backstage UI provides two callbacks that can be used for tracking when the File menu is open and closed:
onShow - The Backstage view is displayed which triggers the OnShow callback procedure.
onHide - when the Backstage view is not longer visible.
The onShow attribute and the onHide attribute of the element can point to code that performs that kind of action.
<backstage onShow="OnShow">
See Customizing the Office 2010 Backstage View for Developers for more information.

Click on a submenu item in windows

all.
I'm trying to do the following, using standard windows menus. I have a menu with a sub menu attached to it. I need to perform different actions when user clicks the menu item that opens a submenu, and user hovers over the menu item and submenu opens without a click.
As far as I could see WM_MENUCOMMAND is only sent when user clicks on a menu item that does not have a submenu attached. Also no mouse click messages are sent when I actually click an item that contains submenu.
So is this even possible?
Thanks.
I believe you can tell when the mouse moves over an item by watching for WM_MENUSELECT. You would then have to start a timer, and if the timer expires before the cursor moves again, you'd have to manually pop open the submenu. I'm not sure how to accomplish the second part.
And it's pretty non-standard behavior that might confuse users. What are you trying to accomplish? And how do you expect it to work for users with only keyboard access?

Back button only return in Windows Phone application

Is it allowed by Windows Phone application certification rules, to only have users be able to return to a previous screen with the use of a hardware back button?
In my scenario, a user clicks on a setting button and lands at a settings page. He changes settings if he decides to, and all the changes get saved automatically, like in iOS.
But currently, the only way for the user to get out of the settings screen, is to press a hardware Back button on the phone.
Will such implementation of navigation functionality pass the Windows Phone certification?
Yes - leave the back button as the navigation method to get back to your main page after visiting the settings page. Not only is this allowed, but it is the desired method of back navigation, and it is what Windows Phone users expect. Here is a great article on the subject: http://blogs.msdn.com/b/ptorr/archive/2011/10/06/back-means-back-not-forwards-not-sideways-but-back.aspx
As far as I understand the terms of the navigation guideline is your usage the right way to go.
Back button
Pressing the back button from the first screen of an application must exit the application.
Pressing the back button must return the application to the previous page.
If the current page displays a context menu or a dialog, the pressing the Back button must close the menu or dialog and cancel the
backward navigation to the previous page.
You should only implement back button behaviors that navigate back or dismiss context menus or modal dialog boxes. All other
implementations are prohibited.
See this cheat sheet for more informations on the design guidelines.

Resources