introduzione

it/Introduzione/01_about-the-author.md

@@ -0,0 +1,10 @@
+##1.1 Riguardo l'autore
+
+Questo manuale è il risultato di un ampio e profondo coinvolgimento sia con il software libero che con il concetto di usabilità. La maggior parte delle cose che ho imparato arrivano da due progetti FOSS, Free and Open Source Software.
+
+1. Nextcloud (formalmente ownCloud), una piattaforma web per dati ed appllicazioni personali, vagamente simile a Dropbox, Google Apps e iCloud. Io mi occupo della "user experience", l'esperienza utente, in molti campi: nella progettazione delle interfacce (interface design), nella programmazione  (frontend coding), nella ricerca riguardo l'utente e la comunità. 
+2. Diaspora, un social network decentralizzato, approssimativamente simile a Facebook e Twitter. E' ancora il progetto più grosso, dove io costruisco la sequenza di lavoro (workflow) per il design della UX (user experience), del testing e la gestione del gruppo di esperienza utente. 
+
+Nell'inverno 2010 I interned at relevantive in Berlin e ho fatto test utente nel laboratorio, in macchina e a piedi. Faccio anche parte di OpenUsability. 
+Ho lavorato come interaction design per Cardapio, un menù e launcher simile al menù di avvio di Windows e Spotlight di Mac OS. 
+Nell'estate 2009, ho lavorato con Charline Poirier di Canonical sui test di usabilità per Shotwell prima che diventasse l'applicazione di default per le fotografie in Ubuntu. I risultati sono pubblicati nel mio blog. 

it/Introduzione/02_about-this-document.md

@@ -0,0 +1,9 @@
+##1.2 Questo testo
+
+Questo documento ha l'obiettivo di essere coinciso ed allo stesso tempo di includere le informazioni essenziali che io trovo importanti per lavorare su progetti di design. Rather than theory and analysis of the current state, che è ancora ampiamente discussa, io voglio fare una lista dei metodi che si possomo mettere in campo perchè questo è quello che vedo come lacking in questo momento. 
+Non è una strada completa o fissa nella sua forma, incoraggio a mandare il proprio feedback e farsi coinvolgere nell' evoluzione del testo. 
+Come referenze, ho usato fonti disponibili con licenza libera, così chiuunque è lha la possibilità di leggere di più da quegli stessi documenti che ho usato. Ed anche rendere omaggio agli autori che hanno reso disponibile il loro materiale alla comunità, come fanno gli sviluppatori di software open e free. 
+Il sottotitolo è una citazione alle quattro libertà del Software Libero. (Stallman, 1986). 
+
+Questo documeto è rilasciato con licenza Creative Commons Attribuzione-CondividiAlloStessoModo:
+You are free to share and remix the work as long as you attribute Jan-Christoph Borchardt as the author and distribute the resulting work under a similar license. 

it/Introduzione/03_problem.md

@@ -0,0 +1,19 @@
+#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_goal.md

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