I think your basic idea to mix the two controls is the correct approach. It is not inconsistent because you have two different controls doing two different things –links for navigating and buttons for “actions” (what I would call a “command”). This is consistent with user expectations for these controls, and, as I’ve discussed in my answer to HTML buttons vs hyperlinks, I believe it is important to distinguish when users are about to command versus navigate.
However, there are a couple things to consider with your “Edit Selected Item” example, assuming that is an actual case from an app you’re designing.
Is it a Command or Navigation?
A control to “Edit Selected Item” is actually in a gray area between navigation and command. Yes, it does navigate in the sense that it brings the user to a dialogue, but it’s a dialogue strictly for executing a command, namely an edit. The fact that you are labeling it with a verb implies it’s primarily a command, not navigation.
Look at it this way: suppose the users want to edit an item. They know this is a command, but they aren’t going to necessarily know that they have to navigate to complete the command. Thus they’re going to be scanning your page for something that looks like a button and may not even notice anything that looks like a link. On the other hand, it is also helpful to signal to the users that they have to provide additional input to complete the command –that edit doesn’t happen immediately on clicking the control
Fortunately, there is a well-established convention to address this issue, and that is to use a command button, but add an ellipsis (“…”) to the end of the label.
I discuss gray areas more at Links and Other Wrong Controls.
(Another possibility is “Edit Selected Item” isn’t just for editing. Rather, it’s really drill-down. It shows the item in greater detail, allowing the user to change individual fields or attributes, but it also allows the user to do other things, such as delete the entire item, or forward it to a friend, or even simply view fields that aren’t shown on the parent page. If that’s the case, then "Details" or "Properties" may be a better label, and it’s a link, performing general navigation rather than a single command.)
Does it Really Need a Long Label?
I think you really should be able to label the control simply “Edit…” The text “Selected Item” doesn’t convey much of any information to the user. “Item” in particular is unspecific, but maybe that’s the best you can do (e.g., items in a shopping cart). But usually it’s implied that a command like Edit edits a selection. Users don’t see GUI apps with labels like “Cut Selected Item” or “Copy Selected Item” or “Delete Selected Item.” What these commands act on is indicated by their position and function (e.g., being in an Edit menu). Perhaps you can do the same, which will eliminate the problem of ugly long buttons. Long captions not only make ugly buttons but also add clutter which can obscure or demote more important controls. I wouldn’t use a label like “Edit Selected Item” unless I had usability test results showing that users are confused, and even then, I’d first try alternatives such as…
Can You Use In-line Documentation?
Sometimes there’s no escaping needing clarifying text for a button. Sometimes, however, you can avoid a long label by putting some of text outside the button as in-line documentation, such as shown for the Add button below:
In your case, you could have “Edit…” as the button label, and “selected item” as a static text to the right or below the button. Or if you have multiple commands that act on the selected item (and if you don’t I don’t see why you’re supporting selection), you could group all these buttons together with short labels (“Edit…”, “Delete”, “Forward…” “Activate”) and put them in a frame labeled “Selected Items” at the top.
Do You Need an Edit Command Anyway?
Ideally, your app should support edit-in-place. Don't make the user select and navigate to edit an item. Rather provide the controls to edit the item right where it's being shown for selection. For example, instead of showing the item as static text, show all the fields in text boxes, dropdown lists and other controls and allow the user to make changes directly. This simplifies your app and makes editing faster and easier, in addition to eliminating the problem of how to show "Edit Selected Item."
