Spencer:
>> sajolida:
>> For the test session itself, I'm a bit worried about having too many
>> placeholders. Like the one on "Configure Encrypted Storage". Every time
>> people will be presented with a placeholder it will bring them out
>> mentally of a pure usage experience that we want to create for the
>> tests; probably require interaction with us to clarify what's going on
>> etc. So I'd try to limit them to the bare minimum.
>>
>> For example:
>>
>> - "Configure Encrypted Storage". I think this will not happened before
>> the first release of this new Greeter, so what about not displaying it
>> for the time being? I suspect that when we will have the code read to
>> put this in place, it will anyway be worth conducting user testing of
>> this change to the Greeter (at least if we move all the persistence
>> settings in the Greeter).
>> - "Take a Tour". Same thing: this will not happened before the first
>> release and we should test this separately once we get there as it's
>> going to be big. Adjust the intro sentence accordingly.
>> - "Help" buttons. These I'm not sure and maybe we can leave them. I
>> think it can be interested to see if people use them. In case they use
>> them, they've already decided to break the pure usage experience to seek
>> for help. Maybe we can explain what they need to know when they click
>> such buttons.
>> - "Restart" button. Is this going to work when I do the tests?
>
> Then what value do you expect to extract from the test? :)
I'm not sure to understand your question...
The idea here is to test the prototype that would replace the same set
of features as the current Greeter (language settings, persistence
unlocking and private settings) because that's the backend
implementation that we have now and the most realistic goal for a first
release.
The "value" (as in "interest") here is to verify how real users interact
with this first set of features, spot the most severe or frequent issues
they face so we can solve them before releasing. The features that are
currently not implemented (guided configuration aka "tour" and
persistence configuration) cannot be tested as they are not implemented
yet but we need to make sure that the fact that they are absent is not a
problem as such while conducting the tests.
The "value" as in "result" will be two folded:
1. A list of the most severe and frequent issues and they frequency of
occurrence.
2. A System Usability Scale (SUS) [1] score. I've never used that but
wanted to try. I'm not sure it's particularly relevant here but
let's see what comes out of this.
[1]:
http://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html
