problema ed obittivo

it/Introduzione/03_problem.md

@@ -1,19 +1,20 @@
-#1.3 Problem
+#1.3 Il problema
 
-Most free software projects are developed by volunteers on their free time and don’t receive corporate backing. There is neither budget for dedicated usability tests nor particular usability expertise. Developers and designers decide from their point of view (Nichols & Twidale, 2003; Thomas, 2008). 
-Free software development is famously described as a bazaar by Raymond (1997), a hierarchically flat organization. Especially independent projects are a meritocracy or do-ocracy where people are mainly valued according to their contributions to the project. 
-Open source development is a meritocracy: those who are judged as doing good (read: high quality) work wield power or influence over the community; the maintainers of the code give permission to check in software. 
+La maggior parte dei profetti di Software Libero sono sviluppati da persone volontarie e nel tempo libero e and don’t receive corporate backing. There is neither budget for dedicated usability tests nor particular usability expertise. Sviluppatori e designer devidono dal loro punto di vista (Nichols & Twidale, 2003; Thomas, 2008). 
+Lo sviluppo nel Software Libero è descritto da Raymond (1997) ome un bazaar, una organizzazione piatta, senza gerarchia. 
+Specialmente i progetti indipendenti sono meritocratici o applicano la do-ocracy (democrazia del fare), dove le persone sono in buona parte valutare per quanto contribuiscono al progetto stesso.
+Lo sviluppo Open Source è meritocratico: quelli che sono giudicati per saper fare bene il lavoro (leggi: alta qualità) guadagnano potere o influenza sulla comunità; i mainteiners del codice (chi lo tiene aggiornato ndt) ti danno il permesso di provare il software. 
 Frishberg et al. (2002)
-A problem with the organic and distributed bazaar workflow are the different communication channels, be it mailing lists, IRC (internet relay chat), bug reports, wiki pages and other platforms. 
-Discussion is fragmented between the mailing list and bug reports. These channels need a clearer charter and decision-making system. 
+Un problema con il flusso di lavoro del bazaar, organico e distribuito, sono i differenti canali di comunicazione, sta nelle mailing-list, in IRC (internet relay chat), nei bug reports, nelle pagine del wiki e in altre piattaforme.
+La discussione è frammentata tra le mailing-list ed i bug reports. Quei canali necessitano un chiaro sistema di charter and decision-making system. 
 Benson, Müller-Prove & Mzourek (2004)
-There are many international contributors working on the software. This is not only code of the application itself but also translation, design, website, outreach and more. Already described by Benson, Müller-Prove & Mzourek (2004), we need a clearly defined decision-making process to coordinate all the different efforts going in to designing and developing the product that is the software. 
-The integration of software cannot be achieved by committee, where everyone has to put in their own additions (featuritis again). It must be controlled by dictatorial artists with full say on the final cut. 
+Ci sono molti contributori internazionali sul software. Questo non è solo programmare l'applicazione in sè, ma anche traduzione, design, siti web, outreach e più. Come già descritto da Benson, Müller-Prove & Mzourek (2004), noi necessitiamo un chiaro e definito processoo di presa delle decisioni per coordinare tutte i differenti sforzi mentre si progetta e si sviluppa il prodotto, che è il software. 
+The integration of software cannot be achieved by committee, where everyone has to put in their own additions (featuritis again). Deve essere controllato da dittatoriali artisti che hanno piena parola per dare il taglio finale. 
 Nelson (1990, p. 243)
-And additions not only come from developers but also indirectly from users: 
-Reading dozens of GNOME and Red Hat bugs per day, I find that users ask for a preference by default. 
+And additions Ed aggiunte non arrivano solo dagli sviluppatori ma anche indirettamente dagli utenti: 
+Leggendo dozzine di report bugs di GNOME e Red Hat al giorno, ho trovato che gli utenti chiedono una preferenza di default. 
 Pennington (2002)
-At the same time, multiple interface designers need to agree on their designs. Decisions need to be documented and based on founded claims. It needs to be made clear that interface design is more of a science where research is important than an art that is subjective: 
-If various people work on the same interface, they will need to justify what they do, convince others why their ideas are so great and so on. 
+Allo stesso tempo, multiple interface designers need to agree on their designs. Decisions need to be documented and based on founded claims. It needs to be made clear that interface design is more of a science where research is important than an art that is subjective: 
+Se diverse persone lavorano sulla stessa interfaccia, essi avranno bisogno di giustificare quello che stanno facendo, convincere gli altri che le loro idee sono buone e così via.
 Balazs (2011)
 

it/Introduzione/04_goal.md

@@ -1,7 +1,7 @@
-#1.4 Goal
+#1.4 L' obiettivo
 
-A guide on how to adapt to development structures, do user testing, use available free tools to ease recording and analysis as well as best practices for reporting and fixing usability issues. 
-Nichols & Twidale (2003) suggest conceptual methods like for example involving usability experts and students, creating a usability discussion infrastructure and evangelism. While I highly support that, I want to offer immediately actionable methods who can be carried out by everyone – much like a tutorial. 
+Una guida su come adattare la struttura dello sviluppo, fare user testing, use available free tools to ease recording and analysis as well as best practices for reporting and fixing usability issues. 
+Nichols & Twidale (2003) suggest conceptual methods like for example involving usability experts and students, creating a usability discussion infrastructure and evangelism. While I highly support that, I want to offer immediately actionable methods who can be carried out by everyone – più come un tutorial. 
 The focus is on formative and qualitative testing. Small tests with results based on actual behavior fit best with the fast and distributed development of free software projects. This enables to do quick iterations in design and development while receiving direct feedback on changes. 
 Classic usability testing, observing a person while they use the software, is of course one of the best ways to do assess usability – see 6.10 Watch people use the software. But especially in free software environments lots of other methods are more feasible. 
 The different methods are intended as patterns: Their usefulness depends on the project structure and the person responsible for the testing. They are guidelines and a collection of tips you can apply.