Utilisation d'un effet "lien hypertexte" dans les applications Winforms

Question

Que pensent les gens de l'utilisation de liens hypertextes, dans les applications Winforms?

Exemple:

alt text http://i49.tinypic.com/ic753k.jpg

Dans mon exemple, vous cliquez sur « dans » la carte d'enregistrement Organisation pour Acme Corp Inc ou « dans » les détails du prochain rendez-vous.

Si nous ignorons, pour le moment, comment l'utilisateur modifie l'Organisation ou ajoute/supprime un rendez-vous, est-il une interface sensible dans Winforms d'utiliser & bleu souligné pour signifier cliquez ici et je vais vous prendre à un nouvel écran

Comme dans:

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

Sans oublier:

TextBox1.Cursor = Cursors.Hand 

Ce serait pour une application raisonnablement riche (par exemple un CRM) où vous avez beaucoup de différents types d'écrans et l'utilisateur navigue entre toutes sortes d'enregistrements. Et vous voulez montrer à l'utilisateur qu'il peut naviguer entre les vues détail, grilles, enfants, parents, frères et sœurs, etc.

Avantages:

• il est familier aux utilisateurs et il est évident, sans être importun ou prenant un écran immobilier

• facile à mettre en œuvre

• le alte souvent utilisé rnative (un bouton avec une icône ou même seulement trois points [...]) ressemble un peu à l'ancienne, ne fonctionne pas très bien dans les réseaux, et prend de la place

inconvénients:

• avec toute la flexibilité et le contrôle vous avez une extrémité avant Winforms, vous devriez être en mesure de concevoir une puce ui sans avoir besoin d'emprunter navigateurs (peut-être ???)

• ces liens pseudo ne se comportera pas comme véritables balises d'ancrage (il n'y aura pas une « visité » [ie. tournez-moi pourpre si j'ai déjà été ici] ou "hover" comportement et aucun-ouvert-dans-nouvel-onglet caractéristiques, sans beaucoup de travail) ... potentiellement ennuyeux pour les utilisateurs?

• enlève rien à des liens authentiques (comme dans les adresses e-mail, etc.) - ceux-ci ne tiennent plus comme des liens « vers Internet » (au navigateur, à client de messagerie) ... problème très mineur?

Answer 1

Cela me convient. Le concept de liens a de toute façon déjà migré du Web vers les applications de bureau. Les utilisateurs devraient accepter cela sans problèmes (peut-être après dix minutes de jeu avec votre programme).

Aussi très populaire dans les applications d'entreprise. Peut-être envisager de changer la couleur, à, peut-être brun ou vert, de sorte qu'il n'implique pas immédiatement un lien Web natif.

De nombreuses applications Web construites avec certains frameworks événementiels (tels que ASP.NET WebForms, JSF, etc.) utilisent des liens qui ne lient pas n'importe où mais invoquent un traitement côté serveur (essentiellement un gestionnaire d'événements). Donc, ce n'est pas une utilisation inhabituelle.

Answer 2

Même les navigateurs ne fonctionnent pas de cette façon. Utilisez un LinkLabel, pas un TextBox.

Answer 3

Je ne l'aime pas. Si je vois un lien je m'attends à ce qu'il ouvre une fenêtre de navigateur quand on clique dessus. Plus standard serait d'avoir un petit bouton "modifier"/icône à côté de l'étiquette. Vous pourriez obtenir un style de lien "(edit)" après le texte, qui serait également tout à fait normal plutôt que de suggérer un navigateur est impliqué.

par exemple:

Organisation: | Acme Dustbins (éditer) |
ou
Organisation: | Poubelles Acme | (edit)

Answer 4

En général, c'est une bonne idée d'utiliser des liens hypertexte (réels ou simulés) dans des applications de client lourd pour ouvrir des formulaires d'informations supplémentaires. Il est utile de distinguer entre un contrôle qui navigue simplement (un lien hypertexte) et une commande qui modifie les données sous-jacentes (un bouton de commande), afin que les utilisateurs sachent dans quoi ils s'engagent. Je ne pense pas que la plupart des utilisateurs se soucient (ou même savent) si un navigateur est impliqué ou non. La navigation est la navigation. Faire ressembler une valeur d'attribut et agir comme un lien hypertexte comme vous l'avez fait va bien, sauf pour une chose qui est une vitrine pour la plupart des applications: elle empêche toute autre interaction avec l'attribut. L'utilisateur ne peut pas modifier ou même copier la valeur de l'attribut, car tout clic dans le champ lancera le nouveau formulaire. Gardez à l'esprit que pour modifier une valeur, par exemple pour corriger un jour du mois, l'utilisateur peut être enclin à cliquer au milieu du champ pour positionner le curseur. Même si vous utilisez un menu déroulant (par exemple, pour définir l'organisation), vous souhaitez autoriser les utilisateurs à cliquer dans le champ et à les sélectionner en tapant les premières lettres de la valeur souhaitée. Si votre application dispose d'un champ d'exploration modifiable qui doit être modifiable, aucun de vos champs ne peut utiliser des liens hypertexte pour assurer la cohérence interne. Tout le processus de recherche doit être effectué par une autre méthode.

De même, bien que les liens hypertexte soient intuitifs pour la navigation, comme l'exploration descendante, je ne suis pas sûr qu'ils soient bons pour affectant une valeur de champ. Il y a une différence entre obtenir plus d'informations sur l'organisation d'Acme Corp (ce que suggère votre lien Acme Corp) et obtenir une boîte de dialogue pour choisir l'organisation pour John Smith (une fonction d'affectation). Donc, si votre intention est l'affectation plutôt que la véritable analyse, alors les liens ne sont probablement pas une bonne idée. Pour l'attribution, le bouton avec les trois points a beaucoup de sens. L'affectation modifie les données sous-jacentes, elle devrait donc utiliser un bouton de commande.C'est une extension naturelle du bouton dans un contrôle déroulant. La légende du bouton à trois points minimise l'espace utilisé et est associée aux boîtes de dialogue puisque c'est ce qu'elles impliquent dans les légendes de menu et de bouton. Cela peut sembler démodé, mais c'est pour cela que cela fonctionne, c'est cohérent avec les expériences utilisateur passées.