Interações entre comando de jogo e controlo remoto

Muitas experiências de interação são partilhadas entre comando de jogo, comando remoto e teclado

Crie experiências de interação nas suas aplicações Windows que garantam que a sua aplicação é utilizável e acessível tanto através dos tipos tradicionais de entrada de PCs, portáteis e tablets (mouse, teclado, toque, entre outros), como dos tipos de entrada típicos da experiência de 3 metros da TV e Xbox, como o gamepad e o comando remoto.

Consulte Design para Xbox e TV para orientações gerais de design sobre aplicações Windows na experiência de 10-foot.

Visão geral

Neste tópico, discutimos o que deve considerar no seu design de interação (ou o que não deve considerar, se a plataforma cuidar disso por si), e fornecemos orientações, recomendações e sugestões para construir aplicações Windows que sejam agradáveis de usar, independentemente do dispositivo, tipo de entrada ou capacidades e preferências do utilizador.

Em suma, a sua aplicação deve ser tão intuitiva e fácil de usar no ambiente de 2 pés como é no ambiente de 10 pés (e vice-versa). Apoie os dispositivos preferidos do utilizador, torne a interface clara e inconfundível, organize o conteúdo de forma a que a navegação seja consistente e previsível, e ofereça aos utilizadores o caminho mais curto possível para o que pretendem fazer.

Otimize tanto para experiências de 2 pés como de 10 pés

No mínimo, recomendamos que teste as suas aplicações para garantir que funcionam bem tanto em cenários de 2 pés como de 10 pés, e que todas as funcionalidades são descobríveis e acessíveis ao gamepad e ao comando remoto da Xbox.

Aqui estão outras formas de otimizar a sua aplicação para utilização tanto em experiências de 2 pés como de 10 pés e com todos os dispositivos de entrada (cada uma liga para a secção apropriada deste tópico).

Gamepad e controlo remoto

Tal como o teclado e o rato são para o PC, e o toque é para o telemóvel e o tablet, o gamepad e o comando remoto são os principais dispositivos de entrada para a experiência de 10 pés. Esta secção apresenta o que são os botões de hardware e para que servem. Em XY foco de navegação e interação e Modo Rato, vais aprender a otimizar a tua aplicação ao usar estes dispositivos de entrada.

A qualidade do comportamento do comando de jogos e do controlo remoto que obtém de imediato depende do suporte dado ao teclado na sua aplicação. Uma boa maneira de assegurar que a sua aplicação funcione bem com um gamepad/comando remoto é garantir que ela funcione bem com o teclado no PC, e em seguida testar com o gamepad/comando remoto para identificar os pontos fracos na sua interface.

Botões de hardware

Ao longo deste documento, os botões serão referidos pelos nomes indicados no diagrama seguinte.

Como podes ver no diagrama, há alguns botões suportados no gamepad que não são suportados pelo controlo remoto, e vice-versa. Embora possa usar botões que só são suportados num dispositivo de entrada para acelerar a navegação na interface, esteja ciente de que usá-los para interações críticas pode criar uma situação em que o utilizador não consegue interagir com certas partes da interface.

A tabela seguinte lista todos os botões de hardware suportados pelas aplicações Windows e qual o dispositivo de entrada que os suporta.

Suporte de botões incorporado

UWP mapeia automaticamente o comportamento existente da entrada do teclado para gamepad e controlo remoto. A tabela seguinte lista estes mapeamentos incorporados.

*Quando nem os eventos KeyDown nem KeyUp para o botão B são tratados pela aplicação, o evento SystemNavigationManager.BackRequested será disparado, o que deverá resultar numa retronavegação dentro da aplicação. No entanto, tens de implementar isto tu próprio, como no seguinte excerto de código:

// This code goes in the MainPage class

public MainPage()
{
    this.InitializeComponent();

    // Handling Page Back navigation behaviors
    SystemNavigationManager.GetForCurrentView().BackRequested +=
        SystemNavigationManager_BackRequested;
}

private void SystemNavigationManager_BackRequested(
    object sender,
    BackRequestedEventArgs e)
{
    if (!e.Handled)
    {
        e.Handled = this.BackRequested();
    }
}

public Frame AppFrame { get { return this.Frame; } }

private bool BackRequested()
{
    // Get a hold of the current frame so that we can inspect the app back stack
    if (this.AppFrame == null)
        return false;

    // Check to see if this is the top-most page on the app back stack
    if (this.AppFrame.CanGoBack)
    {
        // If not, set the event to handled and go back to the previous page in the
        // app.
        this.AppFrame.GoBack();
        return true;
    }
    return false;
}

As aplicações do Windows na Xbox One também suportam pressionar o botão Menu para abrir menus contextuais. Para mais informações, consulte CommandBar e ContextFlyout.

Suporte a aceleradores

Os botões aceleradores são botões que podem ser usados para acelerar a navegação através de uma interface. No entanto, estes botões podem ser únicos para um determinado dispositivo de entrada, por isso tenha em mente que nem todos os utilizadores poderão usar estas funções. Na verdade, o gamepad é atualmente o único dispositivo de entrada que suporta funções de acelerador para as aplicações Windows na plataforma Xbox One.

A tabela seguinte lista o suporte a aceleradores incorporado no UWP, bem como o que pode implementar por si próprio. Utilize estes comportamentos na sua interface personalizada para proporcionar uma experiência de utilizador consistente e amigável.

XY foca navegação e interação

Se o seu aplicativo suportar uma navegação de foco correta para teclado, isto traduzir-se-á bem para comando de jogo e telecomando. A navegação com as setas é atribuída ao D-pad (assim como ao stick esquerdo do comando), e a interação com os elementos da interface é atribuída à tecla Enter/Select (consulte Comando e controlo remoto).

Muitos eventos e propriedades são usados tanto pelo teclado como pelo gamepad—ambos disparam eventos KeyDown e KeyUp, e só navegam para controlos que têm as propriedades IsTabStop="True" e Visibility="Visible". Para orientações sobre design de teclado, veja Interações com teclado.

Se o suporte ao teclado estiver implementado corretamente, a sua aplicação funcionará razoavelmente bem; No entanto, pode haver algum trabalho extra necessário para suportar cada cenário. Pense nas necessidades específicas da sua aplicação para proporcionar a melhor experiência possível ao utilizador.

Problemas com o foco de depuração

O método FocusManager.GetFocusedElement irá indicar-lhe qual elemento tem atualmente o foco. Isto é útil em situações em que a localização do foco visual pode não ser óbvia. Pode registar esta informação na janela de saída do Visual Studio da seguinte forma:

page.GotFocus += (object sender, RoutedEventArgs e) =>
{
    FrameworkElement focus = FocusManager.GetFocusedElement() as FrameworkElement;
    if (focus != null)
    {
        Debug.WriteLine("got focus: " + focus.Name + " (" +
            focus.GetType().ToString() + ")");
    }
};

Existem três razões comuns pelas quais a navegação XY pode não funcionar como espera:

• A propriedade IsTabStop ou Visibilidade está mal definida.
• O controlo que ganha foco é na verdade maior do que se pensa—a navegação XY analisa o tamanho total do controlo (ActualWidth e ActualHeight), não apenas a parte do controlo que renderiza algo interessante.
• Um controlo focável está em cima do outro — a navegação XY não suporta controlos sobrepostos.

Se a navegação XY ainda não estiver a funcionar como espera depois de corrigir estes problemas, pode apontar manualmente para o elemento no qual quer obter foco usando o método descrito em Substituir a navegação predefinida.

Se a navegação XY estiver a funcionar como previsto mas não for apresentada uma indicação visual de foco, pode dever-se a um dos seguintes problemas:

• Alteraste o modelo do controlo e não incluíste um indicador de foco. Define UseSystemFocusVisuals="True" ou adiciona manualmente um visual de foco.
• Moveste o foco ao chamar Focus(FocusState.Pointer). O parâmetro FocusState controla o que acontece ao visual de foco. Geralmente, deves definir isto para FocusState.Programmatic, que mantém o foco visual visível se já estava visível antes, e oculto se já estava oculto antes.

O restante desta secção detalha os desafios comuns de design ao utilizar a navegação XY e oferece várias formas de os resolver.

Interface Inacessível

Como a navegação de foco XY limita o utilizador a mover-se para cima, para baixo, para a esquerda e para a direita, podes acabar com cenários em que partes da interface ficam inacessíveis. O diagrama seguinte ilustra um exemplo do tipo de layout de interface que a navegação de foco XY não suporta. Note que o elemento no meio não é acessível usando um gamepad ou controlo remoto, porque a navegação vertical e horizontal será priorizada, e o elemento do meio nunca terá prioridade suficiente para receber foco.

Se por algum motivo não for possível reorganizar a interface, use uma das técnicas discutidas na secção seguinte para sobrepor o comportamento padrão de foco.

Sobrepor a navegação padrão

Embora a Plataforma Universal do Windows tente garantir que a navegação com D-pad/stick esquerdo faça sentido para o utilizador, não pode garantir um comportamento otimizado para as intenções da sua aplicação. A melhor forma de garantir que a navegação está otimizada para a sua aplicação é testá-la com um gamepad e confirmar que cada elemento da interface pode ser acedido pelo utilizador de forma lógica para os cenários da sua aplicação. Caso os cenários da sua aplicação exijam um comportamento não alcançado através da navegação de foco XY fornecida, considere seguir as recomendações das secções seguintes e/ou sobrepor o comportamento para colocar o foco num item lógico.

O seguinte excerto de código mostra como pode substituir o comportamento de navegação do foco XY:

<StackPanel>
    <Button x:Name="MyBtnLeft"
            Content="Search" />
    <Button x:Name="MyBtnRight"
            Content="Delete"/>
    <Button x:Name="MyBtnTop"
            Content="Update" />
    <Button x:Name="MyBtnDown"
            Content="Undo" />
    <Button Content="Home"  
            XYFocusLeft="{x:Bind MyBtnLeft}"
            XYFocusRight="{x:Bind MyBtnRight}"
            XYFocusDown="{x:Bind MyBtnDown}"
            XYFocusUp="{x:Bind MyBtnTop}" />
</StackPanel>

Neste caso, quando o foco está no Home botão e o utilizador navega para a esquerda, o foco move-se para o MyBtnLeft botão; se o utilizador navegar para a direita, o foco irá para o MyBtnRight botão; e assim sucessivamente.

Para evitar que o foco se mova de um controlo numa certa direção, use a propriedade XYFocus* para o apontar para o mesmo controlo.

<Button Name="HomeButton"  
        Content="Home"  
        XYFocusLeft ="{x:Bind HomeButton}" />

Usando estas XYFocus propriedades, um pai de controlo pode também forçar a navegação dos seus filhos quando o próximo candidato a foco está fora da sua árvore visual, a menos que o filho que tem o foco use a mesma XYFocus propriedade.

<StackPanel Orientation="Horizontal" Margin="300,300">
    <UserControl XYFocusRight="{x:Bind ButtonThree}">
        <StackPanel>
            <Button Content="One"/>
            <Button Content="Two"/>
        </StackPanel>
    </UserControl>
    <StackPanel>
        <Button x:Name="ButtonThree" Content="Three"/>
        <Button Content="Four"/>
    </StackPanel>
</StackPanel>

No exemplo acima, se o foco estiver em Button Dois e o utilizador navegar para a direita, o melhor candidato ao foco é Button Quatro; no entanto, o foco é movido para Button Três porque o elemento pai UserControl obriga-o a navegar quando está fora da árvore visual.

Caminho com menos cliques

Tente permitir que o utilizador realize as tarefas mais comuns com o menor número de cliques. No exemplo seguinte, o TextBlock é colocado entre o botão Play (que inicialmente recebe o foco) e um elemento comumente utilizado, de modo que um elemento desnecessário é colocado entre tarefas prioritárias.

No exemplo seguinte, o TextBlock é colocado acima do botão Play . Simplesmente reorganizar a interface para que elementos desnecessários não fiquem colocados entre tarefas prioritárias vai melhorar muito a usabilidade da sua aplicação.

BarraDeComandos e MenuDeContexto

Ao usar uma Barra de Comandos, tenha em mente a questão de percorrer uma lista como mencionado no Problema: elementos da interface localizados após uma longa rolagem de lista/grelha. A imagem seguinte mostra um layout de interface com o CommandBar no final de uma lista/grelha. O utilizador teria de descer completamente pela lista/grelha para chegar ao CommandBar.

E se colocares o CommandBaracima da lista/grelha? Enquanto um utilizador que desceu a lista/grelha teria de voltar a subir para chegar ao CommandBar, exige ligeiramente menos navegação do que a configuração anterior. Note que isto assume que o foco inicial da sua aplicação está colocado ao lado ou acima do CommandBar. Esta abordagem não funcionará tão bem se o foco inicial estiver abaixo da lista/grade. Se estes CommandBar itens forem ações globais que não precisam de ser acedidos com muita frequência (como um botão de Sincronização ), pode ser aceitável colocá-los acima da lista/grelha.

Embora não possas empilhar os itens do CommandBar verticalmente, colocá-los contra a direção de deslocamento (por exemplo, à esquerda ou direita de uma lista que se desloque verticalmente, ou no topo ou fundo de uma lista que se desloque horizontalmente) é outra opção que podes querer considerar se funcionar bem para o layout da tua interface.

Se a sua aplicação tiver um CommandBar cujos itens precisam de ser facilmente acessíveis aos utilizadores, pode querer considerar colocar esses itens dentro de um ContextFlyout e removê-los do CommandBar. ContextFlyout é uma propriedade do UIElement e é o menu de contexto associado a esse elemento. No PC, quando clicas com o botão direito num elemento com um ContextFlyout, esse menu contextual aparece. Na Xbox One, isto acontece quando carregas no botão Menu enquanto o foco está nesse elemento.

Desafios de layout da interface de utilizador

Alguns layouts de interface são mais desafiantes devido à natureza da navegação por foco XY, e devem ser avaliados caso a caso. Embora não exista uma única forma "certa" e qual a solução que escolher dependa das necessidades específicas da sua aplicação, existem algumas técnicas que pode empregar para criar uma excelente experiência televisiva.

Para compreender melhor isto, vejamos uma aplicação imaginária que ilustra algumas destas questões e técnicas para as ultrapassar.

Segue-se uma aplicação imobiliária imaginária que mostra uma lista de casas disponíveis para venda, um mapa, uma descrição de uma propriedade e outras informações. Esta aplicação apresenta três desafios que pode ultrapassar utilizando as seguintes técnicas:

• Rearranjo da interface
• Focar no envolvimento
• Modo rato

Problema: Elementos da interface localizados após uma longa lista/grelha a deslocar

A ListView das propriedades mostradas na imagem seguinte é uma lista deslocável e muito longa. Se não for necessário envolvimento no ListView, quando o utilizador navegar até à lista, o foco será colocado no primeiro item da lista. Para que o utilizador aceda ao botão Anterior ou Próximo , deve passar por todos os itens da lista. Em casos como este, em que exigir que o utilizador percorra toda a lista é doloroso — ou seja, quando a lista não é suficientemente curta para que esta experiência seja aceitável — pode querer considerar outras opções.

Solutions

Rearranjo da interface

A menos que o foco inicial esteja no final da página, os elementos da interface colocados acima de uma longa lista de scroll são normalmente mais facilmente acessíveis do que se estiverem colocados abaixo. Se este novo layout funcionar para outros dispositivos, mudar o layout para todas as famílias de dispositivos em vez de fazer alterações especiais na interface só para a Xbox One pode ser uma abordagem menos dispendiosa. Além disso, colocar elementos da interface contra a direção de deslocamento (ou seja, horizontalmente para uma lista que rola verticalmente ou verticalmente para uma lista que rola horizontalmente) aumentará ainda mais a acessibilidade.

Concentração no envolvimento

Quando é necessário o envolvimento, o conjunto ListView torna-se um alvo de foco único. O utilizador poderá contornar o conteúdo da lista para chegar ao próximo elemento focável. Leia mais sobre quais controlos apoiam o envolvimento e como os utilizar no Focus engagement.

Problema: ScrollViewer sem quaisquer elementos focáveis

Como a navegação de foco XY depende de navegar até um elemento de interface focável de cada vez, um ScrollViewer que não contenha elementos focáveis (como um com apenas texto, como neste exemplo) pode causar um cenário em que o utilizador não consiga visualizar todo o conteúdo no ScrollViewer. Para soluções para este e outros cenários relacionados, veja Focus engagement.

Problema: Interface de rolagem livre

Quando a sua aplicação requer uma interface de deslocamento livre, como uma superfície de desenho ou, neste exemplo, um mapa, a navegação com foco XY simplesmente não funciona. Nesses casos, pode ativar o modo rato para permitir que o utilizador navegue livremente dentro de um elemento da interface.

Modo de rato

Como descrito na navegação e interação de foco XY, na Xbox One o foco é movido através de um sistema de navegação XY, permitindo ao utilizador mudar o foco entre controlos, movendo-se para cima, baixo, esquerda e direita. No entanto, alguns controlos, como o WebView e o MapControl, requerem uma interação semelhante ao rato, onde os utilizadores podem mover livremente o ponteiro dentro dos limites do controlo. Existem também algumas aplicações onde faz sentido o utilizador poder mover o ponteiro por toda a página, tendo uma experiência com comando/controlo remoto semelhante ao que os utilizadores podem encontrar num PC com um rato.

Nestes cenários, deve solicitar um ponteiro (modo de rato) para toda a página, ou num elemento de controlo dentro da página. Por exemplo, a tua aplicação pode ter uma página com um WebView controlo que usa o modo rato apenas dentro do controlo, e a navegação de foco XY no resto da aplicação. Para pedir um ponteiro, pode especificar se o quer quando um controlo ou página está ativado ou quando uma página tem foco.

Para apps XAML e web alojadas em execução na Xbox One, o modo de rato está ativado por defeito para toda a app. É altamente recomendado que desligue esta opção e otimize a sua aplicação para a navegação XY. Para isso, defina a Application.RequiresPointerMode propriedade para WhenRequested que só ative o modo rato quando um controlo ou página o solicite.

Para fazer isto numa aplicação XAML, use o seguinte código na respetiva App classe:

public App()
{
    this.InitializeComponent();
    this.RequiresPointerMode =
        Windows.UI.Xaml.ApplicationRequiresPointerMode.WhenRequested;
    this.Suspending += OnSuspending;
}

Para mais informações, incluindo código de exemplo para HTML/JavaScript, veja Como desativar o modo rato.

O diagrama seguinte mostra os mapeamentos dos botões para gamepad/comando remoto em modo de rato.

Use a propriedade RequiresPointer num controlo ou página para ativar o modo rato nela. Esta propriedade tem três valores possíveis: Never (o valor padrão), WhenEngaged, e WhenFocused.

Ativar o modo rato num controlo

Quando o utilizador ativa um controlo com RequiresPointer="WhenEngaged", o modo rato é ativado no comando até que o utilizador o desligue. O seguinte excerto de código demonstra um simples MapControl que ativa o modo rato quando ativado:

<Page>
    <Grid>
        <MapControl IsEngagementRequired="true"
                    RequiresPointer="WhenEngaged"/>
    </Grid>
</Page>

Quando um controlo está em modo de rato, os seus controlos aninhados também estarão em modo de rato. O modo solicitado pelos seus filhos será ignorado — é impossível que um pai esteja em modo rato mas uma criança não esteja.

Além disso, o modo solicitado de um controlo só é inspecionado quando ele tem foco, por isso o modo não muda dinamicamente enquanto estiver focado.

Ativar o modo rato numa página

Quando uma página tem essa propriedade RequiresPointer="WhenFocused", o modo rato será ativado durante toda a página quando esta recebe foco. O seguinte excerto de código demonstra como atribuir esta propriedade a uma página:

<Page RequiresPointer="WhenFocused">
    ...
</Page>

Desativar o modo rato para conteúdo em ecrã inteiro

Normalmente, ao mostrar vídeo ou outros tipos de conteúdo em ecrã inteiro, vai querer esconder o cursor porque pode distrair o utilizador. Este cenário ocorre quando o resto da aplicação usa o modo rato, mas deves desligá-lo quando mostras conteúdo em ecrã inteiro. Para isso, coloque o conteúdo em ecrã inteiro isoladamente Pagee siga os passos abaixo.

1. No App objeto, defina RequiresPointerMode="WhenRequested".
2. Em todos os Page objetos exceto no ecrã Page completo, defina RequiresPointer="WhenFocused".
3. Para o ecrã completo Page, defina RequiresPointer="Never".

Desta forma, o cursor nunca aparecerá ao mostrar conteúdo em ecrã completo.

Foco visual

O foco visual é a borda ao redor do elemento da interface que atualmente está em foco. Isto ajuda a orientar o utilizador para que possa navegar facilmente na sua interface sem se perder.

Com uma atualização visual e inúmeras opções de personalização, os programadores podem confiar que um único indicador de foco funcionará bem em PCs e Xbox One, bem como em quaisquer outros dispositivos Windows que suportem teclado e/ou comando à distância.

Embora o mesmo visual focado possa ser usado em diferentes plataformas, o contexto em que o utilizador o encontra é ligeiramente diferente para a experiência de 10 pés. Deve assumir que o utilizador não está a prestar total atenção a todo o ecrã da TV e, por isso, é importante que o elemento atualmente focado esteja claramente visível para o utilizador em todos os momentos, para evitar a frustração de procurar o visual.

Também é importante ter em mente que o visual de foco é exibido por predefinição ao usar um comando de jogo ou comando à distância, mas não um teclado. Assim, mesmo que não o implementes, aparecerá quando executares a tua aplicação na Xbox One.

Colocação visual do foco inicial

Ao lançar uma aplicação ou navegar até uma página, coloque o foco num elemento da interface que faça sentido como o primeiro elemento sobre o qual o utilizador agiria. Por exemplo, uma aplicação de fotografias pode colocar foco no primeiro item da galeria, e uma aplicação de música que navega até uma vista detalhada de uma música pode focar no botão de reprodução para facilitar a reprodução musical.

Tenta colocar o foco inicial na região superior esquerda da tua aplicação (ou no canto superior direito para um fluxo da direita para a esquerda). A maioria dos utilizadores tende a focar-se primeiro nesse canto porque é aí que o fluxo de conteúdo da app geralmente começa.

Tornar o foco claramente visível

Um visual de foco deve estar sempre visível no ecrã para que o utilizador possa retomar de onde ficou sem procurar o foco. Da mesma forma, deve haver sempre um item focável no ecrã — por exemplo, não use pop-ups apenas com texto e sem elementos focáveis.

Uma exceção a esta regra seria para experiências em ecrã inteiro, como ver vídeos ou visualizar imagens, caso em que não seria apropriado mostrar o visual de foco.

Revelar foco

Revelar o foco é um efeito de iluminação que anima o contorno de elementos focáveis, como um botão, quando o utilizador move o foco do gamepad ou teclado para os mesmos. Ao animar o brilho em redor da borda dos elementos focados, a função de Revelar o foco oferece aos utilizadores uma melhor compreensão de onde o foco está e para onde se desloca.

O foco de realce está desativado por padrão. Para experiências de 10 pés, deve optar por ativar o foco, definindo a propriedade Application.FocusVisualKind no construtor do seu aplicativo.

    if(AnalyticsInfo.VersionInfo.DeviceFamily == "Windows.Xbox")
    {
        this.FocusVisualKind = FocusVisualKind.Reveal;
    }

Para mais informações, consulte as diretrizes para Reveal focus.

Personalização do visual de foco

Se quiseres personalizar o visual de foco, podes fazê-lo modificando as propriedades relacionadas com o visual de foco para cada controlo. Existem várias dessas propriedades de que pode tirar partido para personalizar a sua aplicação.

Pode até optar por não usar os visuais de foco fornecidos pelo sistema, desenhando os seus próprios usando estados visuais. Para saber mais, consulte VisualState.

Sobreposição de Descarte de Luz

Para chamar a atenção do utilizador para os elementos da interface que está a manipular com o comando de jogo ou telecomando, o UWP adiciona automaticamente uma camada de "fumo" que cobre áreas fora da interface de popup quando a aplicação está a correr na Xbox One. Isto não exige trabalho extra, mas é algo a ter em conta ao desenhar a interface. Podes definir a LightDismissOverlayMode propriedade em qualquer FlyoutBase para ativar ou desativar a camada de fumo; por defeito é Auto, o que significa que está ativada na Xbox e desativada noutros locais. Para mais informações, consulte Modal vs light dismiss.

Focar no envolvimento

O foco de envolvimento destina-se a facilitar a utilização de um comando de jogo ou de um controlo remoto para interagir com uma aplicação.

Quando a propriedade IsFocusEngagementEnabled num objeto FrameworkElement é definida para True, marca o controlo como requerendo o envolvimento do foco. Isto significa que o utilizador deve pressionar o botão A/Select para "ativar" o controlo e interagir com ele. Quando terminarem, podem carregar no botão B/Back para desligar o controlo e sair dele.

Armadilhas de foco

A armadilha de foco é o que acontece quando um utilizador tenta navegar na UI de uma aplicação, mas acaba "preso" dentro de um elemento de controlo, tornando difícil ou até impossível sair desse elemento.

O exemplo seguinte mostra uma interface de utilizador que cria aprisionamento do foco.

Se o utilizador quiser navegar do botão esquerdo ao direito, seria lógico assumir que só teria de carregar duas vezes no botão direito do D-pad/stick esquerdo. No entanto, se o Slider não exigir envolvimento, ocorreria o seguinte comportamento: quando o utilizador pressiona para a direita pela primeira vez, o foco muda-se para Slider, e quando pressiona novamente para a direita, o manípulo do Slider move-se para a direita. O utilizador continuava a mover a maçaneta para a direita e não conseguia chegar ao botão.

Existem várias formas de contornar este problema. Uma é desenhar um layout diferente, semelhante ao exemplo da aplicação imobiliária em XY focaliza navegação e interação, onde reposicionámos os botões Anterior e Próximo acima do ListView. Empilhar os controlos verticalmente em vez de horizontalmente como na imagem seguinte resolveria o problema.

Agora o utilizador pode navegar por cada um dos controlos pressionando para cima e para baixo no D-pad/stick esquerdo, e quando Slider tiver foco, pode pressionar para a esquerda e para a direita para mover a alavanca Slider, como esperado.

Outra abordagem para resolver este problema é exigir o envolvimento no Slider. Se definires IsFocusEngagementEnabled="True", isto resultará no seguinte comportamento.

Quando Slider requer foco de atenção, o utilizador pode aceder ao botão à direita simplesmente pressionando duas vezes para a direita no D-pad/stick esquerdo. Esta solução é ótima porque não requer ajustes na interface e produz o comportamento esperado.

Controlos de itens

Para além do controlo Slider, há outros controlos que pode querer requerer envolvimento, tais como:

• ListBox
• ListView
• Vista de grelha
• FlipView

Ao contrário do controlo Slider, estes controlos não retêm o foco de interação no seu interior; contudo, podem causar problemas de usabilidade quando contêm grandes quantidades de dados. Segue-se um exemplo de um ListView que contém uma grande quantidade de dados.

Tal como no Slider exemplo, vamos tentar navegar do botão no topo até ao botão inferior com um comando/controlo remoto. Começando com o foco no botão superior, pressionar para baixo no D-pad/stick coloca o foco no primeiro item do ListView ("Item 1"). Quando o utilizador pressiona para baixo novamente, o próximo item da lista recebe o foco, não o botão em baixo. Para chegar ao botão, o utilizador tem de navegar por todos os itens do ListView primeiro. Se contiver ListView uma grande quantidade de dados, isto pode ser inconveniente e não proporcionar uma experiência de utilizador ideal.

Para resolver este problema, defina a propriedade IsFocusEngagementEnabled="True" em ListView para exigir engajamento nela. Isto permitirá ao utilizador saltar rapidamente o ListView simplesmente pressionando para baixo. No entanto, não poderão percorrer a lista nem escolher um item a menos que o ativem pressionando o botão A/Select quando estiver focado, e depois pressionando o botão B/Back para desligar.

ScrollViewer

Um pouco diferente destes controlos é o ScrollViewer, que tem as suas próprias particularidades a considerar. Se tiver um ScrollViewer com conteúdo focável, por padrão, navegar até ao ScrollViewer permitirá que percorra os seus elementos focáveis. Tal como num ListView, tens de percorrer cada item para navegar fora do ScrollViewer.

Se o ScrollViewer não tiver conteúdo focável — por exemplo, se só contiver texto — pode definir o IsFocusEngagementEnabled="True" para que o utilizador possa interagir com o ScrollViewer utilizando o botão A/Select. Depois de iniciarem, podem percorrer o texto usando o D-pad/stick esquerdo, e depois carregar no botão B/Back para desengajar quando terminarem.

Outra abordagem seria configurar IsTabStop="True" no ScrollViewer para que o utilizador não tenha de interagir diretamente com o controlo — pode simplesmente colocar o foco nele e depois deslocar-se usando o D-pad/stick esquerdo quando não existem elementos que possam receber foco dentro do ScrollViewer.

Padrões de engajamento do foco

Alguns controlos causam o enclausuramento de foco com frequência suficiente para justificar que as suas definições padrão exijam o envolvimento de foco, enquanto outros têm o envolvimento de foco desativado por padrão, mas beneficiam de ser ativados. A tabela seguinte lista estes controlos e os seus comportamentos padrão de engajamento de foco.

Todos os outros controlos do Windows não resultarão em alterações comportamentais ou visuais quando IsFocusEngagementEnabled="True".

Resumo

Pode criar aplicações Windows otimizadas para um dispositivo ou experiência específica, mas a Plataforma Universal Windows também permite criar aplicações que podem ser usadas com sucesso em vários dispositivos, tanto em experiências de 2 pés como de 10 pés, independentemente do dispositivo de entrada ou da capacidade do utilizador. Usar as recomendações deste artigo pode garantir que a sua aplicação seja tão boa quanto possível tanto na TV como no PC.

Artigos relacionados

• Design para Xbox e TV
• Introdução ao dispositivo para aplicações Windows