When you hover over a UI element and the cursor changes, this is an implementation of the Cursor Invitation design pattern. It indicates to the user that the UI element may be interacted with. The convention is to use it only when the interaction may be non-obvious, so it’s not used with standard buttons.
I was wondering if the convention was to use it with buttons in the form of icons. I couldn’t find anything about it online, so I looked at some Websites using icon-buttons to see what the consensus was. In all examples I found, hand cursors were used for icon buttons. This is logical, since not every icon on every Webpage is interactive. This isn’t consistent with Windows, where the cursor doesn’t change over icons. (This is also logical – every icon in Windows is interactive by default, so the extra prompt is unnecessary.)
It’s very easy to implement this in Silverlight – in both XAML and code-behind. You can just set the cursor property to the hand cursor.Eg:
XAML:
<Grid x:Name="LayoutRoot" Cursor="Hand">
C#:
target.Cursor = Cursors.Hand;
Even better, setting IsEnabled to false stops the cursor change from occurring – so there’s no need to change the cursor property manually when the button is disabled.
Excellent. Actually i am scierhang some articles to learn silver light. Finally i got a this.This article is just excellent. U r doing good job. Keep it up…Thank you….
Thank you 🙂
I would call out the this.NavigationService.RemoveBackEntry(); method.Calling this from the OnNavigatedTo() of a page will rvmeoe the last page from the navigation stack. This affects the behaviour of the back key.I use this when I want to redirect the initial page load of an application, say to a login page. This gives the user the expected behaviour of the back button exiting the application, even though they are technically two pages deep.It can also be useful if you allow the user to change language or other styles from within the app, you can clear the back stack, then navigate forward to the home page (rather than back from the settings page) which forces a redraw. A bit of a hack, but very simple.
I came into development from a grpihac design background so I’m one of those middle-men’, although I’m a better coder than designer these days. I think the main problem is the assumption that MSFT make about the designer/developer split in organisations. In my whole career I’ve only worked for one company who have a separate design team,..and that was a web development company working with ASP.Net. Blend HAS to be included as part of your Visual Studio licence or else it’s never gonna pick up sales. It’s either that or throw out Cider and build Blend in.Can we drop Xaml altogether, in theory yes. There really isn’t much argument against it. Xaml is NOT HTML (of any flavour) and doesn’t require you to know the markup in the same way mostly because you’re not targeting different browsers and having to combine it with other technologies like JavaScript and CSS. The complaints about Blendability’ are sometimes fair but rarely showstopping and I wouldn’t call it jumping through hoops to get there. In my experience, properly designed applications are implicitly Blendable’, not always, but most of the time.Yes Blend does some crazy stuff with margins. Yes the layout engine needs some work. Hell yes it needs to be included with VS and YES,..you will be a better designer and developer if you know the Xaml. Blend is another leaky abstraction too add to our toolbelt but consider that I’ve recently had to rework a VERY poorly written system with maybe 200+ very large screens. The initial redesign took about 1 and a half months using Blend. If I was writing the Xaml out by hand, I’d still be nowhere near done.
Is it okay to place part of this on my personal website if I publish a reference point to this web site?
Sure, no problem.