Domanda

Ho aggiunto questa domanda su SuperUser per la prospettiva dell'utente.

Quindi creo un'applicazione in Delphi o .NET che verrà eseguita su un sistema desktop. Qualche bella interfaccia grafica con tutti i tipi di funzionalità e belle caratteristiche. Funziona bene, i test mi dicono che è quasi privo di bug e sto per implementarlo ...

ASPETTARE! Ha bisogno di un file di aiuto, quindi gli utenti possono richiedere un aiuto sensibile al contesto dall'applicazione!

O no? Oggigiorno i file di aiuto sono davvero un requisito per le applicazioni desktop? E hanno davvero bisogno di essere sensibili al contesto, tenendo le mani dell'utente per dire loro che devono compilare il loro giorno di nascita in questo campo etichettato " Giorno di nascita " ;? O i file di aiuto stanno diventando un po 'vecchio stile?

Questo è qualcosa di cui mi chiedo e questo è un po 'soggettivo, quindi chiederò qualcosa di diverso a tutti voi che sviluppate applicazioni desktop: Offrite (ancora) file di aiuto sensibili al contesto?

Sì o no, per favore. Sentiti libero di aggiungere alcuni testi soggettivi, ma per me è importante sapere se gli sviluppatori moderni stanno ancora aggiungendo un aiuto sensibile al contesto alle loro applicazioni GUI.

(A proposito, io stesso sono passato a file PDF non contestuali che possono essere stampati come manuali. È molto più facile da mantenere.)

È stato utile?

Soluzione

Sì.

Motivo: Non posso aspettarmi che l'utente sappia come funziona il programma. Ok, descrivendo cosa deve essere inserito in un "Giorno di nascita" il campo è un po 'estremo, ma normalmente ci sono cose più complesse in un sistema software. Ho dovuto scrivere un file di aiuto per il nostro sistema di contabilità dei costi proprio oggi, descrivendo come funziona il sistema per determinare il prezzo da utilizzare per il calcolo. Non credo che nessun utente saprebbe come configurare il sistema senza questo file di aiuto.

Altri suggerimenti

Parlando come utente, non come sviluppatore, sì, voglio un file di aiuto sensibile al contesto.

Ad esempio, sto attualmente valutando i controlli di terze parti per l'inclusione in un nuovo progetto. I controlli che hanno una buona guida sensibile al contesto (cioè puoi selezionare una proprietà nella finestra delle proprietà o una parola chiave nel codice e premere F1 per andare direttamente all'argomento della guida) sono molto, molto più facili da imparare e usare.

Al momento non lo facciamo, ma non scriviamo molte app di Windows. La maggior parte sono basati sul web. La maggior parte delle nostre app di Windows sono piuttosto piccole e ben documentate al di fuori di un file della Guida.

Inoltre, abbiamo gli utenti finali che scrivono la documentazione durante il processo di sviluppo, quindi la documentazione è qualcosa che capiranno.

Tuttavia, se stavo scrivendo un'app di grandi dimensioni per molti utenti (non un'app interna), includerei un file della guida sensibile al contesto. L'ho fatto in passato per alcune delle nostre app più grandi e, in una situazione non interna, è molto utile.

In realtà, ora stiamo progettando il nostro sito Web per avere un "bisogno di aiuto" caratteristica sensibile al contesto e che è stata ben accolta. Lo stiamo integrando in tutto il nostro sviluppo web ora, sia per il nostro sito web aziendale che interno.

Nessun aiuto? Questo va bene per le persone che sono tecnicamente inclini e amano giocare con il nuovo software. Ma se il tuo software verrà utilizzato da persone che non sono esperti di tecnologia, l'aiuto è essenziale. Prendi il tuo esempio di date. Se hai un mercato internazionale, è meglio precisare ciò di cui il programma ha bisogno. Gli americani usano un formato MM / GG / AAAA, ma la maggior parte degli utenti internazionali usa GG / MM / AAAA; è necessario precisare ciò di cui il programma ha bisogno.

Ho lavorato con molti sviluppatori che non avevano assolutamente idea degli utenti finali e del loro funzionamento. Ad esempio, un CTO che ha insistito sul fatto che la sua nuova azienda dovrebbe eliminare la documentazione stampabile senza sapere che i propri clienti stampavano tutti i PDF e la maggior parte degli argomenti della guida ogni volta che veniva aggiornato. Devi conoscere il tuo utente finale e il tuo mercato. Sfortunatamente, troppi sviluppatori vivono in una bolla, circondati da altri sviluppatori.

Gli sviluppatori dovrebbero scrivere aiuto? Probabilmente no. A meno che tu non riesca davvero a pensare come il tuo tipico utente finale, fai delle bozze di note ma lascia che uno scrittore tecnico divida le informazioni tecniche fino al livello di cui l'utente finale ha bisogno.

In un'applicazione recente, non abbiamo fornito assistenza sensibile al contesto. Ciò aveva ragioni tecniche piuttosto che qualsiasi altra cosa (il file di aiuto è essenzialmente un file docbook multilingue che in teoria supporta un aiuto sensibile al contesto, ma non ha funzionato bene). Ha una pagina per ogni finestra / finestra di dialogo nell'applicazione, con tutti i controlli spiegati. Tuttavia, ogni controllo ha anche una descrizione comandi abbastanza completa, che elimina principalmente la necessità di ulteriore aiuto. Ogni finestra di dialogo ha un pulsante di aiuto per visualizzare la pagina specifica della finestra di dialogo. Storicamente, è possibile memorizzare il testo della descrizione comandi nel file della guida, ma ciò non sembra funzionare con i sistemi di guida recenti. E sono comunque archiviati in risorse.

Ma poi, non è un'applicazione per tutti. Poiché il sistema di rete che può essere gestito con l'applicazione è un argomento complesso in sé, esiste comunque una formazione speciale per gli utenti e l'applicazione è stata progettata in modo tale che se si conosce il sistema di rete, si conosce anche l'applicazione. In altre parole, il modello dell'applicazione si allinea al modello utente così bene che non sono necessarie funzionalità di aiuto complete. Questo dovrebbe essere l'obiettivo di qualsiasi sviluppo di applicazioni.

La maggior parte delle informazioni nei file della guida sui controlli non è in realtà più di quanto sia già presente nella descrizione comandi, perché nessuno ha bisogno di più.

Office e Visual Studio hanno risolto il problema in modo piuttosto simile: premendo help si apre la pagina di aiuto per l'intera finestra di dialogo, non per il singolo controllo.

Se hai una parte di una finestra di dialogo che è così complicata da richiedere ulteriori spiegazioni (e dato che non puoi ridisegnarla per renderla più semplice), puoi mettere la spiegazione proprio accanto al controllo. Questo viene utilizzato in molte applicazioni per casi speciali, in modo che il flusso di lavoro non venga interrotto perché l'utente deve cercare ad es. come deve essere scritto un testo specifico.

Non ho mai fornito aiuto sensibile al contesto in un'applicazione, né l'ho visto implementato abbastanza bene in qualsiasi altra applicazione da poterlo mai usare da solo. A mio avviso, lo sforzo necessario per farlo supera di gran lunga il vantaggio.

Nell'ultima applicazione in cui sono stato coinvolto il punto in cui è stata presa questa decisione, nell'applicazione sono stati utilizzati i pallini dei suggerimenti, che mostravano un palloncino di testo quando l'utente passava il mouse su ciascun controllo. Abbiamo anche fornito un manuale convenzionale che era principalmente procedure dettagliate con molti screenshot passo-passo.

Dopo un po 'gli utenti si sono ammalati dei palloncini e li hanno spenti con una casella di controllo che abbiamo fornito, ma sembrava aiutare i principianti a iniziare.

Tutte le nostre applicazioni hanno una guida sensibile al contesto sotto forma di descrizioni comandi (simili ai suggerimenti di Office 2007) per tutte le funzionalità critiche dell'applicazione.

Anche se non offriamo il file di aiuto tradizionale e completo, abbiamo sicuramente una Knowledge Base che aggiorniamo regolarmente. Questa è una raccolta di tutti gli aiuti forniti ai clienti via telefono, e-mail, ecc. Su qualsiasi problema, adeguatamente classificati e facilmente ricercabili. Questo alla fine finisce per essere il miglior aiuto che contiene più o meno ciò che i clienti cercano piuttosto che ciò che noi inizialmente pensa possano aver bisogno.

Mentre alcuni clienti finiscono inevitabilmente per contattarci senza dare un'occhiata alla Knowledge Base, ci aiuta ancora a reinventare la ruota più volte.

Ti do un'opinione personale, non supportata da nessun altro fatto che il mio gusto personale.

Scrivere file di aiuto era utile in passato, dove tutto era nuovo e le risorse online erano scarse. Oggi, la maggior parte degli utenti di computer impara esplorando direttamente. L'aiuto contestuale sotto forma di tooltip è eccezionale e fortemente incoraggiato: fornisce suggerimenti per questo apprendimento esplorativo.

Che dire della documentazione di aiuto con molti link su cui fare clic? beh è apparentemente fantastico, ma immagino usato molto di rado. Nella maggior parte dei casi l'utente può ottenere risposte con una corretta ricerca su Google. Inoltre, questo tipo di documentazione è costoso . Non può essere scritto da uno sviluppatore. Devi assumere o assegnare persone specifiche per questo, con la scrittura tecnica e la chiarezza come competenze pertinenti.

Se dovessi gestire questa decisione, fornirei documenti completi solo per quelle funzionalità che sono molto esoteriche e speciali (direi uniche) per la tua applicazione. Vorrei in ogni caso tendere a un tutorial online, anziché ai file di aiuto contestuali. Questo ha l'ulteriore vantaggio di fornire informazioni su quanto sia difficile utilizzare l'applicazione e quali sono gli hotspot più richiesti (valutando gli hit e le query di ricerca dei referrer nei tuoi documenti online).

Con Tooltips e una capacità del computer generalmente aumentata negli utenti, alcune applicazioni vanno bene senza file di aiuto. Tuttavia, alcune applicazioni necessitano di file di aiuto, sia per informazioni generali sull'argomento che per l'utilizzo dell'applicazione. Ad esempio, in un'app fotografica potresti voler spiegare la compressione jpeg e includere alcuni esempi nel file della guida, anche se l'operazione dell'utente è evidente.

Mi sembra che Microsoft abbia contribuito al declino dell'aiuto sensibile al contesto, nel bene e nel male. Innanzitutto, i sistemi di aiuto in Visual Studio sono, per usare un eufemismo, una seccatura da usare. In secondo luogo, la facilità d'uso del sistema di aiuto di Visual Studio è notevolmente diminuita. Ometterò il rant, ma basti dire che ci vogliono molti più clic e scorre per ottenere informazioni rilevanti nella guida di VS2008. Ciò tende a stabilire uno standard inferiore per i sistemi di aiuto nelle applicazioni.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top