project and tecnology

it/Tu_e_il_progetto/00_Tu.md

@@ -0,0 +1,9 @@
+#2. The project & you
+
+To work on the usability of a project you don’t need specific usability expertise – just the passion to learn and apply it. This is well described in the UX Advocate program started by David Siegel of Canonical and promoted by Allan Day of GNOME. Although it unfortunately didn’t gain enough traction, the motivations behind it are very true: 
+To be a UX Advocate, you don’t need to be able to create pixel-perfect mockups in Inkscape or have an HCI degree. All you need is love – you have to love an open source project and the people who use it, and you need to be patient, persistent, and persuasive. Of course, if you have some background in user experience, that would be tremendously helpful, but it’s unnecessary; it’s far better for an open source project to have a novice UX Advocate than none at all. 
+Siegel (2010)
+A UX Advocate doesn’t need to be a developer. They don’t even need to be a usability expert (though they can be on their way to becoming one). What they do need is the time, energy, and inclination to champion user experience. A UX Advocate can triage and prioritize UX bugs, and they can research design problems. They can even do user testing. 
+Day (2010)
+This document is exactly for making that as easy as possible. 
+

it/Tu_e_il_progetto/01_Usability.md

@@ -0,0 +1,7 @@
+#2.1 Tu sei una persona per l'usabilità
+
+Se sei una persona che ha a cuore l'usabilità alla ricerca di un progetto da migliorare, non prendere su un progetto a caso, ma scegline uno che sia utile per te. Independent free & open source software is about scratching one’s own itch (Raymond, 1997) so you should do it in a similar fashion as a user representative (Nichols & Twidale, 2003). Dovresti essere uno dei committenti del progetto e conoscerlo dal di dentro. 
+Gli altri sviluppatori sono volontari come te. Devi solo saltarci dentro e fare il tuo meglio, il tuo lavoro sarà apprezzato. In contrast and as an advantage to paid usability work there is no constraint set by clients as to how the test should go. You can freely assess which methods you use and how many (or rather few) participants you interview. 
+Anche un sacco di sviluppatori di Software Libero conoscono i concetti dell'usabilità e la sua importanza, ma non sanno come apportarvi dei miglioramenti. Un grosso problema lavorando con loro è a lack of trust (Andreasen et al., 2006, p. 309). Che è il motivo per cui devi comunicare apertamente le tue scoperte e metodi. Idealmente istruire gli sviluppatori sui metodi di test e suoi comuni problemi di usabilità li rende entusiasti della cosa.
+Prima riesci a fare il testing meglio è. Non c'è sviluppatore che ami buttare via pacchi del suo codice, specialmente quello scritto lavorando nel proprio tempo libero. And this shouldn’t be the issue holding the software back from being more usable. Comunica cosa hai scovato presto e spesso. (Reitmayr, Balazs & Mühlig, 2006). 
+

it/Tu_e_il_progetto/02_Developer.md

@@ -0,0 +1,10 @@
+#2.2 Sei uno sviluppatore
+
+Bello che ci stai leggendo! Questo testo dovrebbe darti delle idee e fornirti qualche metodo su come migliorare l'usabilità del tuo codice. Anche se non ci fossero designer nel tuo progetto, potresti utilizzare anche da solo alcuni metodi di ricerca. 
+One of the most important things in usability is that […] the product should target people whom [you] consider to be clueless newbies (Trudelle, 2002). Everything should be as clear and self-evident as possible (Krug, 2008). You already know the interface inside out and probably even designed it. Hence you tend to either overlook or simply not notice issues (Johansson, 2005). 
+Per imparare qualcosa di più sull'usabilità ed allenare l'occhio agli errori, questi blog dovreebbero finire nella tua lista delle letture: 
+Jakob Nielsen’s Alertbox: The guru of web usability, usability testing and low-cost usability methods. 
+Little Big Details: The small interface details which are rarely noticed but help so much. 
+UX Myths: The most common user experience misconceptions and why they are myths. 
+Lukas Mathis’ ignore the code: He writes at the intersection of software engineering and user interface design. 
+

it/project_aspects/00_project-aspects.md

@@ -0,0 +1,8 @@
+#3. I vari aspetti del progetto
+
+Dal cercare informazioni sul sito web e scaricare il software fino ad installarlo ed effettivamente ad usarlo, è importante testare ogni parte.
+Gli utenti non sono solo le persone direttamente interessate ad usare il software ma anche, per esempio, le persone interessate a prendere informazioni dal sito web, contributori disposti ad aiutare o i sysadmin che lo stanno hostando. 
+Specialmente nel Free & Open Source Software, ci sono specifici casi "di informazioni"(ndt) che appaiono più spesso che nel software proprietario. Ad esempio, come fare la configurazione su un proprio server quando si tratta di un'applicazione web. 
+Oppure come contribuire al progetto, concetto centrale del Software Libero. 
+Inoltre, il supporto è gestito principalmente dagli sviluppatori, piuttosto che da un team di supporto specifico.
+Le traduzioni sono gestite da volontari e potrebbero essere mancanti, come i test degli utenti distribuiti su scala mondiale e la disponibilità di altre persone a testare il software in diverse lingue. Leggi _6.11 Richieste di test.

it/project_aspects/01_website-e-information.md

@@ -0,0 +1,12 @@
+#3.1 Website & informazioni
+
+Quando per la prima volta sentiranno parlare del vostro progetto, andranno a cercate il sito internet.
+Molti progetti fanno l'errore di progettare il sito web come un portale per sviluppatori e utenti esperti.
+Dovrebbe avere piuttosto le informazioni per le persone che non hanno mai sentito parlare del software prima. Includere brevi e comprensibili informazioni su ciò che è il vostro progetto.
+I progetti di Software Libero hanno spesso un wiki o utilizzano il sistema di gestione del progetto come loro sito web. Questo è esattamente l'errore «portale per gli sviluppatori». Anche una pagina molto nuda con solo alcune informazioni, screenshot, download e link di aiuto è meglio di una piattaforma in cui tutte le informazioni combattono per emergere e le cose veramente importanti sono sepolte.
+Quando il sito principale di un'applicazione web è anche il fornitore del servizio stesso, è necessario offrire le azioni rilevanti come Registrati e Accedi (logup e login). Soprattutto queste due domande devono essere fatte il più semplice possibile e testate accuratamente perché devono essere "sconfitte" ancora prima di utilizzare l'applicazione stessa.
+Con un sito web idealmente è possibile fare un test utente, leggi _6.10 Guarda le persone che utilizzano il software. Potete farli passare attraverso tutto il processo:
+1. Trovare informazioni sull'applicazione sul sito web
+2. Download & Installazione (in alternativa Registrazione & Accesso per applicazioni web)
+3. Uso dell'applicazione
+

it/project_aspects/02_application-itself.md

@@ -0,0 +1,7 @@
+#3.2 L'applicazione stessa
+
+Questo è di certo il maggior impatto del tuo lavoro.
+Indipendentemente dal fatto che il software sia un'applicazione web o che sia disponibile come applicazione desktop per più piattaforme, per distribuzioni di Software Libero (GNU-Linux), Mac OS e Windows - è necessario testarle tutte se possibile. Con gli utenti di quel sistema operativo specifico come partecipanti è possibile vedere come le persone hanno familiarità con diversi concetti di interazione  e come gestiscono diversamente l'applicazione.
+Oggi sempre più persone hanno lo smartphone e hanno bisogno lì che il software sia disponibile - sia per Android, iOS, webOS, MeeGo, Windows Phone 7 o BlackBerry. La regolazione dell'interfaccia web è la via più facile in quanto non ci sono probabilmente capacità per lo sviluppo di applicazioni dedicate. Se si utilizzano protocolli aperti, è possibile consigliare il software di terze parti (come facciamo nel client Nextcloud per WebDAV su mobile). In questo caso è necessario testare come funziona e se ci sono più client raccomandarne uno solo - il migliore.
+La verifica delle funzionalità di base può essere eseguita in anticipo. Ad esempio, un'interfaccia web può essere visualizzata in diversi browser dal sito di testing Browserling.
+Semplicemente è importante, quanto l'usabilità dell'applicazione stessa, notare che quando il sito web e l'installazione non sono abbastanza semplici, le persone non andranno lontano.

it/project_aspects/03_installation.md

@@ -0,0 +1,10 @@
+#3.3 Installazione
+
+Come maneggiano le impostazioni gli utenti avanzati e potenziali amministratori del tuo software?
+E come se la cava un utente normale con il processo di installazione?
+Per le applicazioni web, le persone che installano il software sui server di solito sono un target completamente diverso dagli utilizzatori.
+Nonostante questo, i termini tecnici dovrebbero comunque essere ridotti al minimo, come le opzioni che non sono immediatamente necessarie o scontate e che quindi possono essere considerate come default.
+Nei sistemi operativi liberi (come in Debian,Ubuntu e Mint ndt) è possibile installare un pacchetto sul tuo pc direttamente dal repository.
+Molti tutorial descrivono passo passo come aggiungere un PPA (personal package archive) ai repository di default o come prendere una applicazione da GIT (software per il versionamento di altro software) e compilarla.
+Anche le persone non nerd possono facilmente ottenere il tuo software attravaerso queste guide e you have to cater your installation process to them as well. 
+

it/project_aspects/04_getting-help.md

@@ -0,0 +1,7 @@
+#3.4 Assistenza
+
+Non importa quanto bene riuscirai a fare il tuo lavoro, le persone risconteranno sempre problemi, avranno domande, troveranno bug.
+Per loro deve essere semplice riportare e descrivere il problema e ricevere una risposta da te o dagli sviluppatori, il tutto in una piattaforma facile da usare.
+Molti progetti di free software usano Bugzilla per il tracciamento degli errori - questo ha una interfaccia davvero rugginosa e un cumbersome processo di registrazione per fare il report del problema (Nichols & Twidale, 2003). Uno strumento molto più comodo per fornire supporto ed anch'esso in software libero è Shapado che permette alle persone di segnalare un bug anche senza registrarsi.
+Idealmente una piattaforma per l'assistenza dovrebbe essere sempre inclusa nel tuo software.
+

it/project_aspects/05_contributing.md

@@ -0,0 +1,12 @@
+#3.5 Contributi
+
+Un aiuto è sempre ben accetto ed importante per il Software Libero.
+Persone che contribuiscono al progetto sono necessarie e dovrebbe essere facile salire a bordo. Fosse per scrivere codice, progettare, tradurre, scrivere la documentazione, comunicare o raccogliere le donazioni. Abbassare le barriere per incoraggiare la partecipazione è essenziale.
+Idealmente dovrebero esserci alcuni »junior jobs« o veloci opportunità per le nuove persone ad iniziare a mettere le mani nel codice (Çetin et al., 2006). Per questo che ha bisogno di segnare tutti i bugs e le cose da fare tasks accordingly, guarda anche _7.4 Riconoscere i difetti? paper cuts. 
+I differenti canali di documentazione e comunicazioni hanno bisogno di essere evidenti e facilmente accessibili.
+Per i programmatori, il repository è impostante, per i traduttori lo sono i file o la piattaforma di traduzione online, per altri può essere la mailinglist o la chat in IRC.
+La classica mailing list o il canale IRC non sono molto incoraggianti per persone che non le hanno mai usate prima.
+Per continuare ad usare quei canali di comunicazione, che qualunque rpogrammatore, anche "stagionato" è abituato ad usare, ma anche offrire ai nuovi arrivati una interfaccia facile, ci sono due buone soluzioni FOSS nel web:
+OnlineGroups offre mailing lists con una interfaccia web.
+Per persone che non sono familiari con le mailingliste questi possono usarle facilmente dal browser.
+Le persone non necessitano così di un client specifico, ma basta integrarlo o linkarlo nel sito web.

it/technology/00_technology.md

@@ -0,0 +1,10 @@
+#4. Tecnologie
+
+Portati dietro sempre una penna ed un pezzo di carta ed annota gli errori che scopri. Questo può capitare quando tu stesso usi il software (_6.1 Dogfood_), nei test utenti (_6.10 Osserva le persone usare il software_) o quando ne parli con altre persone (_6.5 Raccogliere opinioni_). 
+Per essere capace di assegnare la giusta priorità ad un problema, puoi segnarti quanto sono frequenti e persistenti (Nielsen, 2005b). Leggi _7. Registrazioni_. 
+Non c'è davvero molto altro da fare che: 
+1. Testare i dispositivi: The hardware you test the software on, either your own or that of the participant. 
+2. Testare l'oggetto: ovvero il software stesso: l'applicazione per web, desktop o dispositivo mobile. 
+3. Registrazioni: se vuoi rivederti le interviste più tardi. Per problemi di privacy e autorialità è meglio farlo solo quando ne hai davvero necessità, se ever.
+If you want to review the interview later. Because of privacy issues and paperwork it’s best to only do this only when really needed, if ever. 
+

it/technology/01_test-device.md

@@ -0,0 +1,9 @@
+#4.1 Test del dispositivo
+
+Come già detto in _3.2 Applicazione_ è importante testarla su differenti dispositivi. Specialmente quando il progetto è una applicazione per il web, necessiti la sicurezza che funzioni bene su schermi sia grandi che piccoli, come sui touchscreen di smartphone e tablet.
+Quando non possiedi direttamente un dispositivo specifico, è abbastanza facile al giorno d'oggi trovare persone che lo usano regolarmente. 
+Lasciare che le persone usino l'hardware a cui sono abituale ha il vantaggio di non essere distratti dai problemi che sono propri di quello specifico hardware o del suo sistema operativo. 
+Diventare pratico di uno specifico hardware ti farà perdere del tempo. Dovresti sempre considerarlo quando incontri dei problemi.
+Getting accustomed to your device will waste some time. You always have to consider that when issues come up. 
+Quando usi il tuo solito dispositivo, invece, devi avere una installazione pulita del software che stai testando, quindi per esempio spegni tutti i tuoi plugin e add-on quando testi la tua applicazione nel browser.
+

it/technology/02_test-object.md

@@ -0,0 +1,9 @@
+#4.2 Test dell'applicazione
+
+Quando testi una specifica applicazione assicurati di avere l'ultima versione, aggiornata, e che sia quella principale (master branch _ndt_)
+Avere qualche nozione dello strumento usato dagli sviluppatori per gestire le versioni del loro codice può aiutare molto. Per esempio GIT.
+Potrai sempre ottenre la più recente versione in sviluppo, checkout le nuove funzioni e analizzare le loro performance mentre ancora le stanno sviluppando.
+Nel caso delle applicazioni per il web, dovresti ospitare (host) una singola installazione (an instance) del software od organizzarti per averla installata. Prepara le credenziali d'accesso (user account) in caso le persone siano scomode a registrarsi.
+Per testare una apllicazione sul tuo proprio hardware, il meglio è farlo su una installazione nuova. Quindi tu puoi dire ai partecipanti che non possono fare danni qualnque cosa facciano ed essi saranno più rilassati nonostante non siano abituati ad usare quei dispositivi.
+For testing a desktop application on your own hardware, it is best if you set up a fresh installation. Then you can tell the participants that they can’t break anything and they will already be more relaxed even though it is unfamiliar hardware. 
+Quando si fanno test invece con l'hardware dei partecipanti, è più facile incontrare gli errori che natulmente accadono durante il processo di scaricamento, installazione ed approccio al nuovo software.

it/technology/03_recording.md

@@ -0,0 +1,9 @@
+#4.3 Registrazioni video
+
+Reistrare i test sull'usabilità o le interviste per poterle citare durante le presentazioni del lavoro (_ndt_) è una routin standard per le agenzie di design ed usabilità. I partecipanti necessitano di firmare esplicite informative per dare il consenso all'utilizzo di quei video.
+Nei progetti indipendenti di Software Libero, le registrazioni video dei partecipanti sono davvero rare perchè creano un sacco di lavoro per fare poi solo una presentazione.
+In independent free software projects recording participants is rather useless because it creates much work just for presentation. Since we concentrate on small test sets with quick iterations this creates too much overhead. There should be no personal data or images and just recording of issues. 
+Also, reviewing the recordings afterwards uses up twice the time. It can be useful for longer tests though so here are some tools: 
+Pongo is a picture-in-picture recording tool for free operating systems. Originally started by Andreas Nilsson, I used and improved upon it during the Shotwell tests. Unfortunately it is only a command-line tool at the moment. 
+DeskScribe is a click-tracking application which creates a click map similar to but not as good as ClickHeat mentioned in 6.13 Monitor users. When you test a desktop application it might still be useful. 
+