views:

275

answers:

4

What do people think about using pretend hyperlinks, in Winforms apps?

Example:

alt text

In my example you would click "into" the Organisation record card for Acme Corp Inc or "into" the details of the next appointment.

If we ignore, for the moment, how the user edits the Organisation or adds/removes an appointment, is it a sensible UI in Winforms to use blue & underline to signify click here and i'll take you to a new screen

As in:

TextBox1.Font = New Font("Blah", 8.25!, FontStyle.Underline etc
TextBox1.ForeColor = Color.Blue

Not forgetting:

TextBox1.Cursor = Cursors.Hand

This would be for a reasonably rich application (for example a CRM) where you have a lot of different kinds of screens and the user is navigating between all sorts of records. And you want to show the user that he can navigate between detail views, grids, children, parents, siblings etc.

Pros:

  • it's familiar to users and it's obvious, without being obtrusive or taking up any screen real estate

  • easy to implement

  • the often-used alternative (a button with an icon or even just three dots [...]) looks a bit old-fashioned, doesn't work very well in grids, and takes up space

Cons:

  • with all the flexibility and control you have in a Winforms front end, you should be able to devise a smart ui without needing to borrow from browsers (maybe???)

  • these pseudo links won't behave as true anchor tags (there won't be any "visited" [ie. turn me purple if I've already been in here] or "hover" behaviour and no open-in-new-tab features, without a lot of work) ... potentially annoying to users?

  • detracts from genuine hyperlinks (as in email addresses etc) - these no longer stand out as links "out to the internet" (to the browser, to email client) ... very minor issue?

+2  A: 

Looks okay to me. The concept of links has anyway already migrated from web to desktop applications. Users should accept this without problems (maybe after first ten minutes playing out with your program).

Also quite popular in enterprise applications.

Maybe consider changing the color, to, maybe brown or green, so that it doesn't immediately imply a native web link.

Also many web applications built with some event-driven frameworks (like ASP.NET WebForms, JSF etc.) heavily use links that do not link anywhere but invoke some server-side processing (basically an event handler). So it's not unusual use.

Developer Art
+2  A: 

Not even browsers work this way. Use a LinkLabel, not a TextBox.

Hans Passant
hawbsl
A button is the usual choice. If your UI is otherwise very browser-like, I don't see a problem with a LinkLabel.
Hans Passant
+1  A: 

I don't like it. If I see a link I expect it to open a browser window when clicked. More standard would be to have a little "edit" button/icon next the label. You could get away with having a link-style "(edit)" after the text, that would also look quite normal rather than suggesting a browser is involved.

e.g:

Organisation: | Acme Dustbins (edit) |
or
Organisation: | Acme Dustbins| (edit)

John
what if i'm not editing, just navigating to the Acme Organisation's record card
hawbsl
Hmm. Underline in black if you really want that approach. Or have a "view"/"details" button instead of "edit". That way it's still flexible if some users can view and others can edit.
John
Like the label "Details" for all cases, and I'd make it a link, not a button. "Details" makes no assumption on the users' actions (what if a user wants to edit -will they think, "oh, I can only View with this View button"?). Such a label is consistent with links being labeled by where they go, not what the user does. OTOH, it's a long word, consuming a lot of space, even as a link rather than a button. Abbreviate? Or maybe something this important is worth a large mouse target?
Michael Zuschlag
+3  A: 

In general, it’s a good idea to use hyperlinks (real or simulated) in thick-client apps for opening forms of additional information. It is helpful to distinguish between a control that merely navigates (a hyperlink) and a command that changes the underlying data (a command button), so the users know what they’re getting into. I don't think most users care (or even know) if a browser is involved or not. Navigating is navigating.

Making an attribute value look and act like a hyperlink like you’ve done is fine except for one thing that is a showstopper for most applications: it precludes any other interaction with the attribute. The user can’t edit or even copy the attribute value since any clicking in the field will launch the new form. Keep in mind that to edit a value, such as to correct a day of the month, the user may be inclined to click in the middle of the field to position the cursor. Even if you’re using a drop-down menu (e.g., to set the organization), you want to allow users to click in the field and select by typing the first few letters of the value they want. If your app has one drill-down-able field that needs to be editable, then for internal consistency none of your fields can use hyperlinks –all drilldown needs to be by some other method.

Also, while hyperlinks are intuitive for navigating, such as drill-down, I’m not so sure they’re good for assigning a field value. There is a difference between getting more information about Acme Corp organization (which is what your Acme Corp link implies) and getting a dialog to pick the organization for John Smith (an assignment function). So if your intent is assignment rather than true drill-down, then links are probably not a good idea. For assignment, the button with the three dots makes a lot of sense. Assignment changes the underlying data, so it should use a command button. It’s a natural extension of the button in a dropdown control. The three-dot button caption minimizes the space used and is associated with dialogs since that’s what they imply in menu and button captions. It might look old-fashioned, but that’s why it works –it’s consistent with past user experiences.

Michael Zuschlag