summary ok

README.md.orig

@@ -0,0 +1,19 @@
+<<<<<<< HEAD
+# UFS
+
+Usability in Free Software
+
+Freedom 4: The freedom to use the program effectively, efficiently and satisfactorily. A guide by Jan-Christoph Borchardt.
+
+http://jancborchardt.net/usability-in-free-software
+=======
+# Usability_in_FS
+
+# UFS
+
+Usability in Free Software
+
+*Freedom 4: The freedom to use the program effectively, efficiently and satisfactorily. A guide by Jan-Christoph Borchardt.*
+
+[Link to web book](http://jancborchardt.net/usability-in-free-software)
+>>>>>>> 1e38a792527c76cf99b5df55eca8769d9ca84f5b

it/SUMMARY.md

@@ -1,12 +1,30 @@
-# Usability in Free Software
+# L'usabilità nel Software Libero
 
-* [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)
-
-* [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)
+* [Riguardo l'autore](introduction/01_Autore.md)
+* [Il testo](introduction/02_Testo.md)
+* [Il problema](introduction/03_Problema.md)
+* [L'obiettivo](introduction/04_Obiettivo.md)
+*
+* [Tu e il progetto](the_project_e_you/00_Tu.md)
+* [Tu sei un designer](the_project_e_you/01_Usability.md)
+* [Tu sei uno sviluppatore](the_project_e_you/02_Developer.md)
+*
+* [ASPETTI DEL PROGETTO](project_aspects/00_project-aspects.md)
+* [Website & informazioni](project_aspects/01_website-e-information.md) 
+* [Applicatione](project_aspects/02_application-itself.md)
+* [Installazione](project_aspects/03_installation.md)
+* [Assistenza](project_aspects/04_getting-help.md) 
+* [Contributi](project_aspects/05_contributing.md) 
+* 
+* 
+* [TECNOLOGIE](technology/00_technology.md)
+* [Test device](technology/01_test-device.md) 
+* [Test object](technology/02_test-object.md)
+* [Recording](technology/03_recording.md)
+*
+* [PARTICIPANTI](participants/00_participants.md)
+* [Familiari, amici, colleghi, coinquilini](participants/01_family-friends.md)
+* [Traveling, rideshare, hostel](participants/02_traveling-rideshare.md)
+* [Luoghi pubblici, at the mall, on the street](participants/03_public-places.md)
 
 

it/participants/00_participants.md

@@ -0,0 +1,7 @@
+#5. Participanti
+
+Definisci il gruppo "obiettivo" del tuo progetto e coivolgi utenti rappresentativi che utilizzino il software.
+Però noi vogliamo capire quanto è usabile il software per le persone normali. Come Benson, Müller-Prove & Mzourek (2004) mettono in guardia: le persone "campione" presenti nella mailing list [e IRC] non sono i tipici utenti, ma hanno più conoscenze in materia.
+It is enough to test con 3–5 utenti per trovare una buona parte dei problemi di usabilità (Nielsen, 2000):
+Nielsen ha anche notato: una dura verità è che zero utenti danno zero suggerimenti < insights>. Quindi trova qualcuno disponibile ed inizia a testare! 
+

it/participants/01_family-friends.md

@@ -0,0 +1,7 @@
+#5.1 Familiari, amici, olleghi e coinquilini
+
+I familiari sono facilmenti reperibili ma molto spesso non sono la scelta migliore per il testing. Nonostante sappiano che cosa stai facendo e sono thus technically inclined or o si sentono obbligati ad aiutarti, mettendosi in una situazione non ideale per il test.
+Gli amici, i colleghi e i coinquilini sono dei buoni collaboratori per il testing, nonostante non siano designer.
+Amici, coinquilini e colleghi che hanno differenti professionalità e dei backgrounds differenti ti danno vari stimoli. <Friends and flatmates likely have lots of different professions and backgrounds, giving you various insights.>
+Il problema con questo genere di gruppi di persone è che non puoi fargli test troppo spesso. Di solito, i partecipanti all'intervista non vengono invitati di nuovo ad un test per i successivi 3 mesi e comunque non puoi farglielo più di 3 volte in totale.
+In caso contrario, diventerebbero "tester professionali dell'usabilità", ovvero chi già sa che cosa vorrebbe vedere o cosa tu vuoi sentirti dire, e quindi non agisce in maniera naturale.

it/participants/02_traveling-rideshare.md

@@ -0,0 +1,12 @@
+#5.2 Viaggiando, rideshare, hostelli
+Testing while traveling Testare mentre si è in viaggio è una gran cosa, perchè incontri tante e differenti persone. 
+C'è un vasto bacino di potenziali partecipanti ai test subito disponibili.
+Non importa se sei in macchina o su un aeroplano o in bus o in treno, in un ostello o ovunque tu sia o con che mezzo tu stia viaggiando 
+<It doesn’t matter if it’s in a car, on a plane, bus or train, in a hostel or anywhere else you are staying or traveling.> 
+Hai solo da iniziare una conversazione con qualcuno. Chiedi se trova interessante fare un test su un software
+Per fare questo tipo di test ha bisogno di portati dietro il portatile con te.
+
+When they agree, just continue with 6.10 Watch people use the software. 
+When you don’t have that much time or the hardware for an interface test, a casual talk already works fine. The best method here is 6.5 Benchmark opinions where you just talk to people about the software they currently use and their experience with it. 
+The problem of people becoming »professional testers« will practically not occur since you mostly see the people you meet while traveling only once. There should be no problem to find 3–5 people with wildly varying professions and technological backgrounds. 
+

it/participants/03_public-places.md

@@ -0,0 +1,9 @@
+#5.3 Public places, at the mall, on the street
+Just chatting up random people at the mall or on the street (while sitting alone on a bench for example) might be off-putting at first but it will most likely be rewarded. Mozilla’s Jennifer Lynn Morrow made a great experience with user testing in the wild: 
+The mall is a fantastic place to find user test participants, because the range of technical expertise varies widely. Also, the people I encountered tended to be bored out of their minds, impatiently waiting for their partners to shop or friends to meet them. 
+Morrow (2011)
+She writes about her encounter and quick user test with a man who never used a computer before: 
+One of the hardest things to relate to Joe is the idea that you must first click in a text field in order to type. 
+Morrow (2011)
+This kind of person would rarely, if ever, come up in a standard usability test where people are recruited based on specific criteria. But they are incredibly insightful because they are not that biased based on previously used interfaces. 
+

it/tu_e_il_progetto/00_Tu.md

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

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

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