-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/22/2014 08:55 AM, Máirín Duffy wrote: > Hi folks, > >> On 04/22/2014 07:40 AM, "Jóhann B. Guðmundsson" wrote: >>> Is it safe to assume that research is backup by public >>> usability tests? > > On 04/22/2014 07:55 AM, Stephen Gallagher wrote: >> When I invoke Máirín, I usually find it safe to make that >> assumption, but I'll let her speak for herself on the matter. > > We did tests at Red Hat's office in Boston for RHEL 7. Those tests > were with experienced system administrators looking to install > server targets. They were not looking to install workstations, and > as they stated their typical install process is automated and > involves kickstart; they do not perform attended installs > frequently at all. The summary of results from that test are > available here: > > https://www.redhat.com/archives/anaconda-devel-list/2013-April/msg00011.html > > (posted to https://fedoraproject.org/wiki/Anaconda/UX_Redesign) > > I'm fairly certain based on experience (if you want to question > *that*, we can talk about that in more depth too) that this class > of users: > > - Do not care about the license conditions. They trust that Red Hat > has handled that appropriately for them. > > - Probably do have a preference for command line vs polished apps, > but do not care about this when installing a server. (Generally > the experienced admins favor command line whereas junior admins or > admins that also work on Windows machines prefer polished apps) > > - Do care about full functionality vs. small size / speed. They > make this selection interactively using the software selection / > comps screen in the new anaconda; for day-to-day this is controlled > via the selection of particular kickstarts or recipes in their > automated provisioning systems. > > > We also did tests at DevConf.cz last year. My OPW intern Stephanie > Manuel designed the test with me and Jiri Eischmann, Jaroslav > Reznik, and Filip Kosik among others, did an excellent job running > the tests on-site. I have the videos but I do not have release > forms for the testers who took that test, so I don't think I can > post them - but it is a lot of data and I'm not sure how useful it > would be to post or where I could post it. These users for the most > part had a technical background, but were more workstation-oriented > in installation although they only interacted with the installer > itself. Filip provided the data and the analysis of the results on > that test: > > https://www.redhat.com/archives/anaconda-devel-list/2013-April/msg00018.html > > > > All of the results from the tests were collated into one long issue > list here: > https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Usability_Test_Suggestions > > > > > Some of the choices Przemek suggested don't make sense depending on > the context. E.g., full functionality vs. small size / speed I > think has a different meaning depending on whether you have a > workstation target (which, either way, will include X) or a server > target (which might not necessarily include X.) Same with command > line vs polished apps. > > Everything in our repos is free, so putting the choice in the > installer seems off to me. Our policy (which is complex and > obviously driven by things stronger than the UX) generally leaves > it to users post-install to add encumbered software. I don't > actually see the advantage to the user in changing that. > PackageKit's UI used to have filters I think some were based on > license. Maybe the GNOME software devs would be interested in > having some kind of selection for the type of software offered to > you. Similarly to how some Android app stores work - e.g. show me > only free apps, or you can show me paid apps too. > > > > So to back this up, a lot - what install target are we talking > about, exactly? And what type of users are we talking about? My > guidance as an IXD would be completely different depending on these > things. >
Thanks for the detailed response, Máirín! What I think we're looking for is answers to some of the questions that keep coming up in Fedora Workstation and GNOME. Specifically, there's a contingent of people (myself included) that feels that our existing policy introduces arbitrary difficulty on the part of our users when trying to install software (free or non-free) that is not part of our standard repositories. There are many specific cases here, from the obvious apps/appstores like Chome, Steam, etc. to the less obvious: browser-based web apps. And then of course there are things like the proposed Playground repository and COPR, as well as the potential for other third-party repositories. So one of the key questions here is whether the current policy on essentially hiding (protecting?) the user from these external software sources is truly in keeping with our Foundations, Mission and general project health. If it is not, how do we address the problem in a way that doesn't sacrifice our core commitment to FOSS? One suggestion that came up was to allow people to <handwave>somewhere</handwave> select that they want to accept one or more of: * Software that would be in Fedora if not for packaging guidelines (Playground) * Software that could be in Fedora but is experimental or an alternate version (COPR) * FOSS that can't be in Fedora for legal reasons (RPMFusion-free) * Non-FOSS software (RPMFusion-nonfree, Google Chrome, Steam) I'm not entirely sure where the cmdline-vs-gui or functionality-vs-footprint discussion came from, but that wasn't really part of the initial topic. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNWawgACgkQeiVVYja6o6MkUQCfaa6c5H3q0V0lm1WaIUuGzqFa BkEAnj9xDPPt5VJOOqlQg0MHNgN/j98U =hzxO -----END PGP SIGNATURE----- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
