Re: [ftr] usability testing tasks, questions, characteristics

On 13 Sep 2017, at 16:54, Shawn Henry wrote:

> On 9/13/2017 9:42 AM, Eric Eggert wrote:
>>
>>
>> On 13 Sep 2017, at 16:35, Shawn Henry wrote:
>>
>>> On 9/13/2017 9:00 AM, Wise, Charlotte wrote:
>>>>  From a usability standpoint, it would be good if we could be 
>>>> consistent in our patterns and I would recommend we try to do that. 
>>>> Why do we use two different models here? Is there a way we could 
>>>> change the secondary page design to accommodate a consistent 
>>>> pattern?
>>>
>>> I *strongly* support that - always have. :)
>>>
>>> (ftr, I was very hesitant about moving the In-Page Contents from the 
>>> right side.)
>>
>> Can I also note that some pages currently have both, a context (same 
>> resource) and a content (in-page) navigation? This is the case in the 
>> tutorials, for example. When we talked about it waaaaaay back, the 
>> consensus seemed to be that we would drop the in-page navigation in 
>> such cases.
>>
>> While I am happy to keep in-page navigations, this means introducing 
>> yet another template very late in the process, which is sub-optimal.
>
> Or, be consistent with *one* template:
> * all pages have in-page navigation on the right, when applicable.
> * some pages have related navigation on the left.

Those are still two templates. One with a left column and one with a 
right column. We already have a template with the narrow column on the 
left and the wide column on the right (read before content/after 
content) in the document flow.

Now we might have:

* Left nav column (narrow), wide content column
* Left nav column (narrow), content column, right in-page nav column 
(narrow)
* Left nav column (narrow), content column, side column (wider)
* Content column, side column (wider)
* Side column and in-page nav column cannot be on one page (mostly 
because the ins-page nav column goes before the content, the side column 
goes after the content), **OR** we can put the in-page navigation in the 
side column if one is present but it will be a bit wider (which is an OK 
compromise for me, but it would then be after the content and I need to 
work with skip links to make it discoverable).

I don’t think we should have the in-page navigation always as a side 
column because it is wasting a lot of space and we usually don’t need 
as much space.

That’s all doable and I’m ok doing it, we just have to be aware that 
this is additional stuff to do, and we need to decide on something.

Eric

>
> ~Shawn
>
>
>>
>> Best, Eric
>>
>>>
>>> ~Shawn
>>>
>>>
>>>>
>>>> Best,
>>>> Charlotte
>>>>
>>>> -----Original Message-----
>>>> From: Shawn Henry [mailto:shawn@w3.org]
>>>> Sent: Tuesday, September 12, 2017 4:38 PM
>>>> To: WSTF <public-wai-eo-site@w3.org>; Wise, Charlotte 
>>>> <cwise@visa.com>
>>>> Subject: Re: [ftr] usability testing tasks, questions, 
>>>> characteristics
>>>>
>>>> Hi Charlotte, a more specific issue below...
>>>>
>>>>> -------- Forwarded Message --------
>>>>> Date: Thu, 10 Aug 2017 12:43:50 -0500
>>>>>
>>>>>
>>>>> I took a first pass at some research questions and tasks (tweaked 
>>>>> from earlier list) and participant demographics for the usability 
>>>>> testing. All open for discussion, of course.
>>>>>
>>>>> Research questions:
>>>>> .    How do people interact with the home page, and the 
>>>>> sub-pages? Where does their focus go and pause? What do they click 
>>>>> on?
>>>>> .    Think-out-loud reactions to the visual design, content 
>>>>> areas, nav, etc.
>>>>> .    Is the all the navigation throughout clear, including 
>>>>> what's available, where they are, where they've already been, 
>>>>> where they can go next. Is the non-primary navigation clear, e.g., 
>>>>> in-page navigation, related pages, etc.
>>>>
>>>> On some pages, the left nav links to related info on other pages.
>>>> On some pages, the left nav is in-page links.
>>>>
>>>> Do users get that? Is it confusing? Helpful?
>>>>
>>>> ~Shawn
>>>>
>>>> <snip rest of message>
>>>>
>>
>>
>>
>> -- 
>>
>> Eric Eggert
>> Web Accessibility Specialist
>> Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)
>>
>>



--

Eric Eggert
Web Accessibility Specialist
Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)