tu e il progetto

it/Introduzione/03_Problema.md

@@ -0,0 +1,20 @@
+#1.3 Il problema
+
+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)
+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)
+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)
+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)
+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/03_problem.md

@@ -1,19 +0,0 @@
-#1.3 Problem
-
-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. 
-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. 
-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. 
-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. 
-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. 
-Balazs (2011)
-

it/Introduzione/04_Obiettivo.md

@@ -0,0 +1,8 @@
+#1.4 L' obiettivo
+
+Una guida su come adattare la struttura dello sviluppo, fare user testing, usare gli strumenti disponibili gratuitamente per ease registrare ed analizzare al meglio possibile, come buone pratiche per rendicontare ed aggiustare i problemi di usabilità. 
+Nichols & Twidale (2003) suggerisce metodi concettuali per, per esempio coinvolgere esperti dell'usabilità e studenti, creando una infrastruttura per la discussione sull'usabilità e diffonderla (evangelism). Sebbene io supporti questo approccio, voglio invece offrire metodi da mettere in pratica anche subito, che possono essere adottati da ognugno - più come un tutorial.
+The focus is on formative and qualitative testing L'attenzione è sul testing qualitativo e formativo. Small tests with results based on actual behavior calzano meglio con lo sviluppo rapido e distribuito dei progetti FOSS. Questo permette di fare veloci iterazioni nel design e nello sviluppo mentre ricevi feedback diretti sui cambiamenti.
+Il classico test dell'usabilità, osservare una persona mentre usa il software, è di certo una delle migliori vie per avere una idea riguardo all'usabilità, – leggi 6.10 Guarda le persone usare il software. Ma specialmente nell'ambiente del free software un sacco di altri metodi sono più flessibili. 
+I differenti metodi sono intesi qui come schemi (pattern): la loro utilità dipende dalla struttura del progetto e dalle persone responsabili dei test. Essi sono delle linee guida ed una collezione di (tips) che si possono applicare. 
+

it/Introduzione/04_goal.md

@@ -1,8 +0,0 @@
-#1.4 Goal
-
-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. 
-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. 
-

it/SUMMARY.md

@@ -1,12 +1,12 @@
 # Usability in Free Software
 
-* [About the author](introduction/01_about-the-author.md)
-* [About this document](introduction/02_about-this-document.md)
-* [Problem](introduction/03_problem.md)
-* [Goal](introduction/04_goal.md)
+* [Riguardo l'autore](introduzione/01_Autore.md)
+* [Il testo](introduzione/02_Testo.md)
+* [Il problema](introduzione/03_Problema.md)
+* [L'obiettivo](introduzione/04_Obiettivo.md)
 
-* [The project e you](the_project_e_you/00_the-project-and-you.md)
-* [You are a usability person](the_project_e_you/01_you-are-a-usability-person.md)
-* [You are a developer](the_project_e_you/02_you-are-a-developer.md)
+* [Tu e il progetto](tu_e_il_progetto/00_Tu.md)
+* [Tu sei un designer](tu_e_il_progetto/01_Usability.md)
+* [Tu sei uno sviluppatore](tu_e_il_progetto/02_Developer.md)
 
 

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 You are a usability person
+
+If you’re a usability person looking for a project to improve, don’t pick any project but one useful to you. 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). You should be committed to the project and know it inside out. 
+The other developers are volunteers as much as you. Just jump in and do your best, your work will be appreciated. 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. 
+Many free software developers already know about usability and the importance of it but don’t know how to improve it. A big issue in working with them is a lack of trust (Andreasen et al., 2006, p. 309). That is why you have to openly communicate your findings and methods. Ideally educate the developers about testing methods and common usability problems so they are enthusiastic about it themselves. 
+The earlier you do testing, the better. No developer likes throwing away lots of his code, especially those working in their free time. And this shouldn’t be the issue holding the software back from being more usable. Communicate your findings early and often (Reitmayr, Balazs & Mühlig, 2006). 
+

it/tu_e_il_progetto/02_Developer.md

@@ -0,0 +1,10 @@
+#2.2 You are a developer
+
+Awesome that you read this! This document should give you ideas and provide you with methods on how to improve the usability of your software. Even if there is no designer on your project, you can use many of the research methods yourself. 
+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). 
+To learn more about general usability and develop an eye for issues, these blogs should go in your feed reader: 
+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. 
+