Testo dell'interfaccia utente e Guida per Visual Studio

Testo e terminologia dell'interfaccia utente

Il testo comprensibile è fondamentale per un'interfaccia utente efficace. Gli utenti software tendono a leggere prima le etichette, ovvero quelle più rilevanti per completare l'attività a portata di mano. Il testo statico viene letto con minore frequenza. Pianificare agli utenti di avviare le sessioni di lavoro con un'analisi rapida dell'intera finestra, seguita da una lettura dell'interfaccia utente in questo ordine approssimativo:

1. Controlli interattivi al centro

2. Pulsanti commit

3. Controlli interattivi trovati altrove

4. Istruzioni principali

5. Spiegazioni supplementari

6. Titolo finestra

7. Altro testo statico nel corpo principale

Modelli di utilizzo per il testo dell'interfaccia utente

Testo per la barra del titolo

Il testo della barra del titolo deve corrispondere al comando che ha generato l'interfaccia utente.

Testo informativo (testo helper)

In alcuni dialoghi, è utile fornire istruzioni principali importanti per spiegare cosa fare nella finestra o nella pagina. Questo viene talvolta definito "testo helper".

Scrittura di regole di stile per il testo helper

• Non spiegare l'ovvio. A meno che non sia assolutamente necessario, non includere testo informativo.

• Il testo informativo viene sempre posizionato nella parte superiore del dialogo e deve fare riferimento all'attività eseguita.

• Spiegare esattamente agli utenti cosa devono fare. Evitare un numero eccessivo di comunicazioni e ridondanza.

• Esaminare ogni finestra ed eliminare parole e istruzioni duplicate.

• Mantenere il testo informativo breve. Se sono necessarie altre informazioni per determinati utenti o scenari, fornire un collegamento a un argomento concettuale dettagliato online.

• Scrivere il testo in modo che ogni parola contenga peso ed è necessario.

• Seguire le linee guida Microsoft esistenti per Testo e stile e stile dell'interfaccia utente e tono.

Istruzioni supplementari

Le istruzioni supplementari forniscono informazioni aggiuntive che consentono all'utente di comprendere i controlli o i raggruppamenti di controlli. Questo potrebbe includere anche il testo del suggerimento necessario per comprendere il formato previsto dal controllo di input. Usare le istruzioni supplementari con moderazione. Riservarli per i casi in cui è probabile che l'utente non comprenda completamente le ramificazioni della scelta che stanno facendo.

Testo supplementare in Visual Studio

Testo supplementare in Visual Studio

Informazioni Suggerimenti

Spesso, il testo di istruzioni potrebbe essere troppo lungo per posizionarsi sul posto nell'interfaccia utente o potrebbe essere utile solo per i nuovi utenti, sentendosi come disordinato per gli utenti esperti. In questo caso, il testo informativo/informativo deve essere inserito come descrizione comando in una descrizione comando.

Le informazioni Suggerimenti devono essere posizionate vicino ai controlli a cui sono correlate e devono usare l'icona di descrizione informazioni specifica, che non è intrusiva ma evidente.

Esempio di descrizione informazioni in Visual Studio

Scrittura di regole di stile per Info Suggerimenti

• Scrivi info Suggerimenti come frasi complete. Richiedono verbi specifici, maiuscole e minuscole e punteggiatura finale.

• Usa Info Suggerimenti per integrare le tue istruzioni o informazioni principali. Se si usano solo parole diverse per riformulare l'idea principale, non è necessaria una descrizione informazioni.

• Mantieni info Suggerimenti brevi e dolci. Usa parole piccole e semplici, linguaggio quotidiano che supporta e incoraggia l'utente.

• Seguire le linee guida Microsoft esistenti per Testo e stile e stile dell'interfaccia utente e tono.

Etichette di controllo

Le etichette di controllo devono essere brevi, concise e seguire le indicazioni di Windows Desktop per i controlli.

Per altre informazioni sul formato e il posizionamento dell'etichetta di controllo all'interno dell'interfaccia utente, vedere Layout per Visual Studio.

Collegamenti alla Guida

I collegamenti alla Guida possono essere inseriti all'interno del testo informativo o nel corpo dell'interfaccia utente. Possono essere collegamenti alla Guida o avviare finestre di dialogo interne.

Regole di stile dell'oggetto visivo per i collegamenti alla Guida

• Usare i colori di ambiente corretti per i collegamenti ipertestuali. Un collegamento ipertestuale con stile corretto non lampeggia brevemente rosso quando si fa clic. Se viene visualizzato, si tratta di un'indicazione che i colori dell'ambiente non vengono usati.

• Le sottolineature devono essere utilizzate solo al passaggio del mouse o quando il collegamento è incorporato in un paragrafo.

• Per informazioni più dettagliate sugli stili di visualizzazione e interazione per i collegamenti ipertestuali, vedere Pulsanti e collegamenti ipertestuali.

Scrittura di regole di stile per i collegamenti alla Guida

• Quando si avviano finestre di dialogo, mantenere gli standard per i puntini di sospensione: nessun puntino di sospensione per lo spostamento, puntini di sospensione se l'attività richiede un'interfaccia utente aggiuntiva.

  

  Un puntino di sospensione (...) in un collegamento della Guida indica che l'attività richiederà un'interfaccia utente aggiuntiva.

• I collegamenti non devono iniziare con "Learn", in quanto non è la finalità dell'utente. L'utente vuole rispondere a una domanda specifica, non ricevere un'istruzione generale.

• Collegamenti alla Guida di frasi in modo che chiedano la domanda a cui risponderà l'argomento.

  Risposta errata: "Altre informazioni sui prezzi di Windows Azure Servizi mobili"

  Risposta esatta: "Quali opzioni di prezzi sono disponibili per Windows Azure Servizi mobili?"

• Non usare mai Click... per il testo del collegamento.

• Non collegare mai solo la parola "qui". Questo problema è problematico per alcune utilità per la lettura dello schermo, che vocerà solo la parola con collegamento ipertestuale.

  Risposta errata: "Trovare informazioni in Windows Azure Servizi mobili qui"

  Risposta esatta: "Quali opzioni di prezzi sono disponibili per Windows Azure Servizi mobili?"

• Per altre informazioni sullo stile di scrittura corretto per i collegamenti alla Guida, vedi le linee guida di Windows Desktop per la Guida.

Hint text

Il testo dell'hint viene visualizzato come filigrana all'interno di un controllo o sotto il controllo. La formattazione corretta verrà applicata usando il token VSColors appropriato, Environment.GrayText.

Può essere visualizzato in diverse forme.

• Al posto dell'etichetta del controllo:

  

• Con un verbo, fornendo istruzioni:

  

• Con testo che indica una voce obbligatoria:

  

Testo filigrana

In un'area di progettazione vuota, il testo deve indicare cosa fare, nonché fornire collegamenti per aprire altre finestre correlate, se appropriato:

Esempio di testo della filigrana in Visual Studio

Terminologia comune

Termine	Spiegazione	Commento
Accedi/Esci	Verbi usati come sinonimi con il Web per rappresentare l'autenticazione in una proprietà Web. All'interno dei client, viene usato una volta come nozione di primo livello per l'accesso e la connessione utente all'esterno dell'IDE, che rappresenta un'identità di primo livello che fornisce funzionalità di livello superiore, ad esempio roaming e licenze che non sono disponibili con tutte le altre connessioni.	L'utente dell'IDE è l'unica funzionalità che deve rappresentare un verbo di accesso/disconnesso, in quanto rappresenta l'utente dell'IDE di primo livello.
Connessione/Disconnetti	Usare in posizioni in cui una funzionalità mantiene una singola connessione a un servizio online.	Esplora server, in cui è possibile avere una sola connessione di Azure attiva alla volta, è un esempio di Connessione/disconnessione.
Aggiungi/Rimuovi	Non distruttivo. Usare quando si aggiunge o rimuove un elemento da un elenco.	La finestra di dialogo elenco di server tfs Gestione connessioni è un esempio di aggiunta/rimozione.
Elimina	Distruttivo. Usare solo quando l'elemento da rimuovere verrà eliminato definitivamente o eliminato dal disco.	"Elimina" richiede in genere un prompt se il risultato elimina un file dal disco.

Messaggi di errore

Gli errori accadono. L'impostazione delle limitazioni sulle operazioni che l'utente può eseguire è un primo passaggio sensato per evitare messaggi di errore evitabili. Tuttavia, quando si verifica un errore, un messaggio di errore ben scritto può andare a lungo per attenuare il problema. I messaggi di errore sono probabilmente uno dei tipi più importanti di notifica visualizzati dall'utente, perché sono sincroni e indicano un problema che deve essere risolto. I messaggi di errore scritti in modo non corretto lasciano gli utenti autonomamente a decidere la causa degli errori e le possibili soluzioni.

Gli utenti potrebbero smettere di prestare attenzione ai messaggi di errore sovrausati o confusi, quindi scrivere solo i messaggi necessari che aggiungono valore all'esperienza utente. Se il messaggio è semplicemente una notifica, usare una presentazione alternativa.

Regole per la creazione di un messaggio di errore

• Quando si creano messaggi di errore, scegliere il livello di errore appropriato per il gruppo di destinatari. Mirare a riepiloghi semplici che forniscono un'azione che l'utente può intraprendere, se applicabile. Non dichiarare nulla che l'utente non debba sapere.

• Fornire assistenza costruttiva. È più facile leggere e agire su un messaggio di errore che contiene istruzioni.

• Non usare i doppi negativi.

• Eseguire sia una grammatica automatizzata che un controllo ortografico manuale su qualsiasi messaggio di errore scritto.

• Per i messaggi di errore complessi, evitare comunicazioni sequenziali. Non usare mai un hook F1 per il messaggio di errore. Il messaggio stesso deve essere sufficiente.

• Usare l'icona corretta.

• Semplificare la comprensione e l'uso dei pulsanti con scelte chiare, ad esempio "Elimina" e "Annulla".

• Per gli avvisi, è chiaro quale sarà la conseguenza di procedere. I pulsanti devono indicare la conseguenza.

• Per gli errori, descrivere le operazioni che l'utente può eseguire per risolvere il problema. I pulsanti devono essere azioni o dire "Chiudi". Non usare un pulsante "OK" per un messaggio di errore.

• Alcune domande da porsi quando si crea un messaggio di errore:

  • L'utente può capire come risolvere il problema solo con questo errore?

  • L'utente usa lo stesso vocabolario di questo errore?

  • Questo errore è ambiguo o condiviso in più situazioni? In tal caso, come si guidano gli utenti alla soluzione necessaria?

Errori di compilazione

Poiché Visual Studio è uno strumento di sviluppo software, molti dei relativi componenti hanno un passaggio di compilazione, conversione o codifica per convertire il lavoro dello sviluppatore in formato binario. Queste conversioni possono causare errori quando il compilatore non è in grado di elaborare file creati in modo non corretto o quando le opzioni del compilatore non sono state impostate correttamente.

Gli utenti di Visual Studio possono trascorrere un numero enorme di ore di sviluppo che risolvono gli errori di compilazione. Questo tempo di risoluzione aumenta quando gli errori presentano dipendenze o quando i messaggi di errore sono scritti in modo non corretto, il che può rendere difficile individuare l'origine dell'errore.

I migliori errori di compilazione sono quelli che non si verificano al primo posto, motivo per cui Visual Studio fornisce il completamento automatico e gli squiggli di IntelliSense. I validator dello schema e gli strumenti simili forniscono lo stesso tipo di feedback. Questi meccanismi guidano in modo proattivo l'utente a costruire codice ben formato, riducendo la probabilità di errori di compilazione.

Visual Studio offre una finestra degli strumenti in cui gli utenti possono leggere e esplorare gli errori che si sono verificati nelle finestre dei documenti. I tasti di scelta rapida vengono forniti in modo che l'utente possa spostarsi rapidamente in grandi quantità di codice e passare direttamente alla posizione del problema. Visual Studio consente anche di collegare ogni errore di compilazione a una determinata parola chiave/ID contesto della Guida in modo che l'utente possa passare direttamente a un argomento della Guida che fornisce informazioni più approfondite sull'errore.

Scrivere errori di compilazione chiari e concisi:

• Usare il linguaggio normale che spiega il problema con un gergo del compilatore minimo o nullo. Il testo di un errore di compilazione non deve essere eccessivamente tecnico.

• Possibili cause della struttura. Ad esempio, "Manca un punto tra la proprietà e il valore nella dichiarazione '(property) : (valore)'.

• Fornire informazioni dettagliate sulle potenziali correzioni. Se non è disponibile spazio sufficiente, è possibile inserire ulteriori dettagli nell'argomento della Guida corrispondente.

Componenti di un messaggio di errore ben scritto

Usare il servizio della finestra di dialogo della shell per i messaggi di errore.

L'uso del servizio della finestra di dialogo della shell consente di controllare l'aspetto del messaggio, in particolare i tipi di carattere, senza modifiche importanti ai singoli elementi. Usare i meccanismi IErrorInfo e segnalarli usando IVsUIShell::SetErrorInfo/ReportErrorInfo.

Scegliere una presentazione di notifica efficace e appropriata.

Usare una finestra di dialogo modale con un avviso critico se è necessaria un'azione immediata per evitare la perdita di dati (notifica sincrona). Le icone critiche sono riservate alle situazioni in cui la chiusura del messaggio senza leggerla può causare conseguenze negative. La perdita di dati è una situazione critica che richiede una risposta a livello di allarme. L'uso eccessivo dell'icona critica desensizza gli utenti alla sua importanza. Se il messaggio di errore è di natura informativa, prendere in considerazione le alternative a un dialogo modale (notifica asincrona).

Fornire una spiegazione pulita e concisa del motivo per cui si è verificato il problema anziché una spiegazione tecnica.

Sovraccaricare gli utenti con dettagli tecnici nella spiegazione li renderà più probabili ignorare i messaggi di errore. Esempi di buona messaggistica:

• "Impossibile aprire il file richiesto".

• "Impossibile connettersi a Internet".

Fornire informazioni su come risolvere il problema.

Offrire all'utente suggerimenti su come risolvere il problema. Essere onesti con l'utente se non ci sono suggerimenti. Fornire collegamenti diretti a origini online alternative, ad esempio supporto tecnico o supporto della community. Provare a indirizzare gli utenti a informazioni online specifiche pertinenti al problema. Per un ID errore, è consigliabile collegare gli utenti a un thread di discussione relativo a tale errore specifico. Esempi di buona messaggistica:

• "Assicurarsi di essere connessi a Internet e riprovare a eseguire l'operazione."

• "Assicurarsi che il file esista e che si disponga dell'autorizzazione per aprirlo".

Scrivere un messaggio breve e verso il punto.

Un messaggio di errore può notificare, spiegare e offrire una soluzione, ma essere comunque ignorato se è troppo wordy. Una soluzione consiste nell'usare la divulgazione progressiva con un pulsante dettagli. Ad esempio, fornire una breve descrizione/soluzione e quindi inserire altri dettagli sotto un pulsante dettagli. Se gli utenti scelgono di leggere altre informazioni sull'errore, è possibile farlo.

La lingua nel messaggio deve essere:

• Appropriato per il dominio. Usare la lingua che l'utente comprenderà. Anche se i clienti sono sviluppatori, spesso non hanno il contesto e la terminologia disponibili.

• Specifico. Evitare la formulazione vaga e assegnare nomi e posizioni specifici degli oggetti coinvolti. Ad esempio, un messaggio di errore come "carattere non valido" non è utile. Quale personaggio? "File non trovato". Quale file?

• Cortese. Non incolpare l'utente o farli sentire stupidi. Evitare un linguaggio ostile o offensivo (uccidere, eseguire, terminare, fatale, illegale). Evitare il testo maiuscolo, spesso visto come gridare e non è leggibile. Non usare l'umorismo.

• Risposta esatta. Usare l'ortografia e la grammatica corrette (anche in alfa). Gli errori di digitazione non sono professionali e imbarazzanti.

• Contestualmente appropriato. Usare il testo del pulsante appropriato. Evitare il pulsante "OK" e usare invece "Continua" o "Sì/No".

Esempi di messaggi di errore

Bene	Non valido
"Il numero che hai composto non è più in servizio. Controllare il numero e comporre di nuovo o comporre 0 per l'operatore."	- "Errore (449): numero non valido" - "Questo errore di eccezione non gestita indica che l'operazione è stata completata correttamente".

Accesso alla Guida

Oltre alla documentazione in MSDN, un utente di Visual Studio ha diversi punti di accesso per assistere l'utente durante l'interfaccia utente. Per garantire che questi punti di accesso siano costantemente disponibili, i team delle funzionalità devono sfruttare il sistema della Guida offerto dall'ambiente. Questi punti di accesso sono:

• Testo informativo e supplementare nei dialoghi. Testo statico che fornisce direzione o spiegazione, nell'area dell'interfaccia utente o disponibile al passaggio del mouse su un'icona di descrizione informazioni.

• Guida sensibile al contesto (solo editor). All'interno dell'editor di Visual Studio, un utente può considerare attendibile che in qualsiasi momento, premendo F1 verrà visualizzato un argomento della Guida specifico della selezione corrente. Assicurarsi che gli argomenti associati a F1 siano appropriati e informativi.

• Collegamenti ipertestuali agli argomenti della Guida. Collegamento ipertestuale all'interno di una finestra di dialogo, di una finestra degli strumenti o di un'area di progettazione che avvia un argomento per aiutare l'utente a ottenere altre informazioni su una tecnologia, una funzionalità o informazioni su come eseguire un'attività.

• Meccanismi dell'interfaccia utente helper, ad esempio smart tag e finestre di dialogo di compilazione. Questi meccanismi consentono all'utente di comprendere un elemento dell'interfaccia utente o facilitare un'attività, ad esempio smart tag o dialoghi di generatore.

• Pulsanti della Guida dell'interfaccia utente (deprecati). Indicatore visibile nella barra del titolo che consente di accedere all'argomento della Guida sensibile al contesto correlato.

Testo

Testo informativo e supplementare nei dialoghi

Nelle finestre di dialogo che supportano attività complesse, potrebbe essere necessario fornire testo informativo all'interno dell'interfaccia utente, spesso nella parte superiore della finestra di dialogo o in prossimità di controlli complessi. Per informazioni dettagliate sullo stile di scrittura, vedere Testo e terminologia dell'interfaccia utente.

Informazioni Suggerimenti

Spesso, il testo di istruzioni potrebbe essere troppo lungo da posizionare nell'interfaccia utente o potrebbe essere utile solo per i nuovi utenti, sentendosi troppo disordinato per gli utenti esperti. In questo caso, il testo informativo/informativo deve essere inserito come descrizione comando in una descrizione comando.

Le informazioni Suggerimenti devono essere posizionate vicino ai controlli a cui sono correlate e devono usare l'icona di descrizione informazioni specifica, che non è intrusiva ma evidente.

Esempio di descrizione informazioni in Visual Studio

Meccanismi della Guida interattiva

Guida sensibile al contesto

La Guida sensibile al contesto è necessaria all'interno di un editor o di un'area di progettazione, ma non altrove nell'ambiente di Visual Studio.

Collegamenti ipertestuali agli argomenti della Guida

I collegamenti ipertestuali possono essere usati per eseguire un'azione, spostarsi all'interno dell'IDE o avviare la Guida in un browser. Vedi Testo e terminologia dell'interfaccia utente per informazioni dettagliate sulla lingua e sui pulsanti 07.10.01 e collegamenti ipertestuali per linee guida per oggetti visivi e layout.

Pulsanti della Guida [?] nelle barre del titolo della finestra di dialogo (deprecato)

Nella maggior parte dei casi, i pulsanti Guida [?] nella barra del titolo delle finestre di dialogo sono deprecati. Gli argomenti dell'interfaccia utente non fanno più parte del modello di documentazione e pertanto potrebbero non esserci argomenti rilevanti a cui collegarsi. Essenzialmente, il pulsante della barra del titolo era la stessa cosa della Guida F1 e che non è più necessario nelle finestre di dialogo. In alcuni casi, questo può comunque essere usato come indicatore che è disponibile più informazioni concettuali o procedurali, anche se i collegamenti ipertestuali sono più comunemente usati nell'interfaccia utente più recente.

Dialoghi creati tramite l'ambiente

Molte finestre di dialogo della shell vengono create tramite la funzione VBDialogBoxParam . Questa funzione condivisa è stata aggiornata per facilitare lo spostamento del pulsante ? dalla finestra di dialogo al pulsante ? mantenendo un'architettura compatibile con le versioni precedenti ed estendibile.

In particolare, la funzione VBDialogBoxParam esamina il modello di finestra di dialogo per un pulsante il cui ID è IDHELP (9) o l'etichetta è Help o &Help. Se viene trovato un pulsante ? viene nascosto e lo stile di WS_EX_CONTEXTHELP viene aggiunto alla finestra di dialogo, che posiziona il pulsante ? nella barra del titolo della finestra di dialogo.

Quando viene creato il dialogo, esegue il push del processo del dialogo in uno stack e richiama il dialogo con una procedura di pre-elaborazione denominata DialogPreProc. Quando si fa clic sul pulsante ? viene inviato un WM_SYSCOMMAND di SC_CONTEXTHELP alla finestra di dialogo. DialogPreProc acquisisce questo comando e lo modifica in un messaggio WM_HELP, che viene passato alla procedura originale del dialogo.

La maggior parte delle finestre di dialogo create dall'ambiente include un pulsante ? nella finestra di dialogo. Quando viene visualizzata la finestra di dialogo, il pulsante ? è nascosto automaticamente e funziona solo il pulsante ? . Se il pulsante ? viene rimosso o modificato in Windows, questa soluzione consente di tornare rapidamente ai pulsanti della Guida originali.

Questa soluzione presuppone quattro presupposti che potrebbero causare bug:

• Il pulsante della Guida della finestra di dialogo è IDHELP (9).

• La finestra di dialogo è corretta quando il pulsante ? è nascosto.

• Il dialogo non sostituisce il relativo winproc.

• Il dialogo non è incorporato all'interno di un altro dialogo.

  Se la finestra di dialogo si trova all'interno di msenv e non usa VBDialogBoxParam, esaminare l'uso di VBDialogBoxParam prima di implementare il proprio gestore.

Finestre di dialogo create tramite altri pacchetti

È possibile implementare una soluzione personalizzata per i dialoghi che risiedono all'esterno di msenv. Per una classe di dialogo condivisa nel pacchetto VSPackage, è consigliabile spostare il pulsante sulla barra del titolo o implementare un gestore in ogni finestra di dialogo. Il codice seguente è uno scheletro di un'implementazione che consente di iniziare:

struct DLGPROCITEM
{
    FARPROC proc; // The info used to create the dialog.
    DLGPROCITEM* procPrev;
};

DLGPROCITEM* g_dlgProcStack = NULL;

// A dialog starter/wrapper function is used to push the new
// dialog proc to the top of our dialog proc stack.

int SomeDialogStarterFunction(hinst, id, proc, etc)
{
    if (g_dlgProcStack == NULL)
    {
        g_dlgProcStack = new DLGPROCITEM;
        g_dlgProcStack->procPrev = NULL;
    }
    else
    {
        DLGPROCITEM* procItem = new DLGPROCITEM;
        g_dlgProcStack->procPrev = g_dlgProcStack;
        g_dlgProcStack = procItem;
    }
}

// Pop this dialog proc off the dialog proc stack.

DialogBoxIndirectParam...(...)
{
    DLGPROCITEM* procItem = g_dlgProcStack->procPrev;
    delete g_dlgProcStack;
    g_dlgProcStack = procItem;
}

// A wrapper dialog procedure will allow us to capture the
// SC_CONTEXTHELP button on the title bar from Windows and
// forward it as a simple WM_HELP message back to the dialog.

INT_PTR CALLBACK DialogPreProc(HWND hwndDlg, UINT uMsg,
    WPARAM wParam, LPARAM lParam)
{
    if (uMsg == WM_SYSCOMMAND && wParam == SC_CONTEXTHELP)
    {
        uMsg = WM_HELP;
        wParam = 0;
        lParam = 0;
    }
    return CallWindowProc((WNDPROC)g_dlgProcStack->proc,
        hwndDlg, uMsg, wParam, lParam);
}

Pulsanti della Guida nel codice gestito

L'override del comportamento predefinito della barra del titolo della finestra è semplice nel codice gestito. Di seguito è riportata un'applicazione demo completa che illustra questo comportamento. In sostanza, è necessario eseguire l'override del metodo WndProc del modulo e quindi attivare le richieste della Guida F1 quando viene intercettato un messaggio di SC_CONTEXTHELP.

using System;
using System.Windows.Forms;

public class HelpForm : Form
{
    private const int SC_CONTEXTHELP = 0xF180;
    private const int WM_SYSCOMMAND = 0x0112;

    public HelpForm()
    {
        this.ClientSize = new System.Drawing.Size(300, 250);
        this.HelpButton = true;
        this.MaximizeBox = false;
        this.MinimizeBox = false;
        this.Name = "HelpForm";
        this.Text = "Help Form";
    }

    protected override void WndProc(ref Message m)
    {
        if (m.Msg == WM_SYSCOMMAND && SC_CONTEXTHELP == (int)m.WParam)
            ShowHelp();
        else
            base.WndProc(ref m);
    }

    private void ShowHelp()
    {
        MessageBox.Show("F1 Help goes here.");
    }

     [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.EnableRTLMirroring();
        Application.Run(new HelpForm());
    }
}

Vedi anche

• Tipi di carattere e formattazione per Visual Studio
• Layout per Visual Studio
• Notifiche e avanzamento per Visual Studio