Criando uma loja de música MVC móvel-Parte 5: O carrinho de compras

Hoje vou concluir o processo de pagamento da versão móvel da MVC Music Store. Este processo apresentará novamente algumas decisões de layout, mas me dará a oportunidade de cobrir recursos específicos para celular relacionados a formulários de entrada.

Parte 1 Criando uma camada de serviço comum
Parte 2 Criando o layout móvel principal
Parte 3 Criando os controladores e visualizações
Parte 4 Criação da página inicial
Parte 5 Projetando as páginas de gênero e álbum
Parte 7 Grande, finalmente

Resumo do carrinho

Quando um cliente adiciona um álbum ao carrinho, é mostrado o c página de resumo da arte. Esta página simplesmente lista todos os álbuns esperando para serem comprados pelo cliente. Isso é bastante normal para um site de comércio eletrônico.

Aqui, decidi fazer um botão Checkout se ajustar à largura do telefone na parte superior da página com altura suficiente para torná-lo um bom ponto de contato. Decidi colocar o botão no topo do conteúdo da página porque os usuários sempre verão. Em geral, eles vão dar uma olhada na lista do carrinho na maioria dos casos e estar no topo significa que podem fazer a compra rapidamente.

Em seguida, alterei a linha do carrinho para exibir uma miniatura do álbum sobre o título. Meu raciocínio é duplo. Primeiro, quero algo que o cliente possa ver para saber o que está comprando. Em segundo lugar, fornece um ponto de contato maior se o usuário quiser revisar os detalhes do álbum.

Em vez de um link de remoção simples, tornei-o um botão bastante grande, novamente para torná-lo um bom ponto de contato. Tenho que admitir que perdi a cabeça aqui. Prefiro fazer desta uma boa imagem em vez de um texto.

Pedido/Registro

Primeiro, deixe-me dizer que esta etapa se desvia do site para desktop. Se você olhar para a versão do desktop MVC Music Store original, ela usa os métodos de scaffolding do MVC BeginForm e EditorForModel. Lembre-se de que sou bastante novo no uso da ASP.NET MVC e ainda estou aprendendo. Eu obtenho a visão de 10.000 pés dos métodos auxiliares XForModel. O que estou lutando atualmente é forçá-los a produzir uma boa marcação. Os modelos padrão são completamente inaceitáveis ​​porque vomitam DIVs em todos os lugares. Depois de descobrir uma boa estratégia para personalizar os modelos, ficarei feliz em postar minha solução, até agora vou me limitar a escrever minha marcação manualmente.

Em vez da biblioteca de validação não obstrutiva do ASP.NET, estou vou substituí-lo pelo plugin de validação jQuery com o qual estou muito mais familiarizado. Também vou usar o plugin jQuery Masked Input para oferecer orientação sobre alguns campos.

Aqui está a marcação da página AddressAndPayment do site móvel. Observe que eu uso um UL em vez de um monte de DIVs para fazer o layout do formulário. Descobri que isso é muito mais flexível do que envolver tudo em seu próprio DIV, um elemento de bloco.

 
 <
 
 formulário 
 
 ação 
 
="@ Url.Action ("
 
 AddressAndPayment 
 
","
 
 CheckOut 
 
")"
 
 método 
 
="post"
 
> 
 
 <
 
 fieldset 
 
> 
 
 <
 
 ul 
 
> 
 
 <
 
 li 
 
> <
 
 etiqueta 
 
 para 
 
="Primeiro nome"
 
> 
 Primeiro nome 
  
 etiqueta 
 
>  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 entrada 
 
 tipo 
 
="texto"
 
 id 
 
="Nome"
 
 nome 
 
="FirstName"
 
 classe 
 
="obrigatório"
 
/>  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 etiqueta  
 para 
 
="Sobrenome"
 
> 
 Sobrenome 
  
 etiqueta 
 
 >  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 entrada 
 
 tipo 
 
="texto"
 
 id 
 
="Sobrenome"
 
 nome 
 
="LastName"
 
 classe 
 
="obrigatório"
 
/>  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 etiqueta 
 
 para 
 
="Address"
>
Address
 
 l abel 
 
>  
 li 
 
> 
 
 <
 
 li 
 
 > <
 
 entrada 
 
 tipo 
 
="texto"
 
 id 
 
="Endereço"
 
 nome 
 
="Endereço"
 
 classe 
 
="obrigatório"
 
/>  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 etiqueta 
 
para
="City"
>
City
label
 
>  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 entrada 
type
="text"
id
="City"
 
 nome 
 
="City"
class
="required"
/> 
 li 
 
> 
 
 <
 
 li 
 
> <
 
 etiqueta 
 
 para 
 
="Estado"
 
> 
 Estado 
  
 rótulo 
 
>  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 entrada 
 
 tipo 
 
="texto"
 
 id 
 
="Estado"
 
 nome 
 
="Estado"
 
 classe 
 
="obrigatório"
 
/>  
 li 
 
> 
 
 <
li
><
label
for
 
="PostalCode"
 
> 
 Código Postal 
  
 etiqueta 
 
>  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 entrada 
 
 digite 
 
="texto"
 
 id 
 
="PostalCode"
 
 nome 
 
="PostalCode"
 
 classe 
 
="ZipCodeMask obrigatório"
 
/>  
 li 
 
> 
 
 <
 
 li 
 
> <
label
for
="Country"
> 
 País 
  
label
>
li
>
<
 
 li 
 
><
input
type
="text"
id
 
="País"
 
 nome 
 
="País"
 
 classe 
 
="obrigatório"
 
/> 
li
>
<
li
><
 
 etiqueta 
 
 para 
 
="Telefone"
 
> 
 Telefone 
  
 etiqueta 
 
>  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 entrada 
 
 tipo 
 
="texto"
 
 id 
 
="Telefone"
 
 nome 
 
="Telefone"
 
 classe 
 
="telefone obrigatório PhoneMask"
 
/>  
 li 
>
<
li
><
label
 
 para 
 
="Email"
 
> 
 E-mail 
  
 etiqueta 
 
>  
 li 
 
> 
 
 <
 
 li 
 
> <
 
 entrada 
 
 tipo 
 
="texto"
 
 id 
 
="E-mail"
 
 nome 
 
="Email"
 
 classe 
 
="requerer d email"
 
/>  
 li 
 
> 
 
 <
 
 li 
 
> 
 Estamos fazendo uma promoção: todas as músicas são 
 grátis com o código promocional:"GRÁTIS"
  
 li 
 
 > 
 
 <
 
 li 
 
> 
 @ Html.Label ("Código promocional") 
  
 li 
 
> 
 
 <
 
 li 
 
> 
 @ Html.TextBox ("PromoCode") 
 
li
>
<
li
><
 
 input 
 
 digite 
 
="enviar"
 
 valor 
 
="Enviar pedido"
 
/>  
 li 
 
> 
 
  
 ul 
 
> 
 
  
 fieldset 
 
> 
 
  
 formulário 
 
> 
 

Esta marcação produz uma forma vertical com rótulos listados acima de cada campo de entrada. Normalmente, para formulários de desktop, eu exibo rótulos à esquerda do campo de entrada porque isso ajuda os usuários a ler o formulário. Mas no contexto móvel, você realmente só tem uma única coluna e ter tudo em uma pilha vertical é o layout ideal.

Existem várias experiências do usuário detalhes que eu quero apontar na imagem. Primeiro, cada campo de entrada tem a largura da tela. Obviamente, isso não é feito normalmente em sites de desktop, mas também é uma prática comum orientar os usuários sobre possíveis comprimentos de entrada com comprimentos de campo variados. Por exemplo, um campo inicial do meio será bastante curto em comparação com os campos de nome e sobrenome.

 $ (
"input"
).focus (
 função 
 (e) {
 $ (
 this 
).css (
"background-color"
, 
"#fff"
); 
}); 
 $ (
 
"entrada"
).blur (
 função 
 (e) {
 $ (
 this 
).css (
"background-color"
, 
"#eee"
).valid (); 
}); 
 

Quando o foco é dado a um campo de entrada, o fundo é definido como branco. Todos os outros campos de entrada exibem um fundo cinza claro para indicar qual campo o usuário está digitando. Eu descobri, usando meu Windows Phone, que muitos aplicativos nativos usam essa fila de experiência do usuário para permitir que os usuários saibam para onde está indo a digitação ou mesmo se eles selecionaram um campo de entrada todos juntos. Fico realmente frustrado ao digitar em um teclado minúsculo apenas para descobrir que nenhum campo de entrada foi selecionado.

Em seguida, um erro de validação é mostrado para o campo Nome. Isso ocorre porque eu apliquei a classe necessária ao campo de entrada e o plugin jQuery Validation executou a validação na entrada quando eu tabulei o campo. Isso ocorre porque o método valid () é chamado quando o usuário deixa qualquer entrada na página, o que invoca as regras de validação aplicadas ao campo de entrada. Eu pessoalmente gosto quando obtenho validação em tempo real em formulários em vez de esperar para enviar o formulário para encontrar erros, então tento aplicar isso às minhas páginas.

Eu optei por não aplicar o código de formato de entrada WAP CSS os campos de entrada. Decidi não usá-los porque ainda não vi esse suporte muito bem em todos os navegadores. Em vez de trabalhar por meio de uma rotina de detecção de recursos do tipo Modernizr, optei por usar soluções confiáveis ​​da jQuery para entrada mascarada, validação etc. Suspeito que os navegadores móveis mais novos suportarão esses recursos usando as especificações do HTML5 e provavelmente voltarei minha atenção para essas soluções antes muito longo.

Eu também usei o plugin de edição mascarada jQuery para fornecer ainda mais orientação para os usuários. Para este formulário, uso máscaras de número de telefone e CEP.

 $ (
".PhoneMask"
) 
.mask (
"999-999-9999"
, {placeholder: 
''
}); 
 $ (
".ZipCodeMask"
 ) 
.mask (
"99999"
, {placeholder: 
''
}); 
 

Eu também quero para apontar outro conforto que descobri no meu HTC Chegue. Quando não estou com o teclado deslizante aberto e o foco é dado a um campo de entrada, o teclado virtual é exibido e o campo de entrada é automaticamente colocado em exibição acima do teclado. Fiquei feliz em ver que o navegador lida com isso automaticamente para nós, porque isso poderia ser um JavaScript complicado. Não posso confirmar que outras plataformas fazem isso, mas suspeito que sim.

Confirmação do pedido

Esta página não é nada especial! Apenas uma bela mensagem de confirmação do pedido.

Resumo

Uau! Agora temos uma versão móvel funcional de ponta a ponta da MVC Music Store. Assim como a desktop MVC Music Store . Este não é um aplicativo 100% completo com recursos, mas um site de amostra razoável que demonstra várias decisões de design que os desenvolvedores e designers devem tomar ao criar uma presença móvel. Essas decisões geralmente transcendem a web e os dispositivos móveis e são puras decisões de experiência do usuário. Mas isso deve servir como uma boa estrutura da web móvel para referência para sites de produção.

Mas espere, tem mais! Isso mesmo, ainda não terminei. Tenho mais uma parcela que apresentará algo especial. Se você tem acompanhado, deve ter notado que há um aspecto fundamental de que o site precisa. Bem, tenho algo planejado para resolver esse problema que espero ajudá-lo a perceber que você não está limitado quando se trata de arquitetar uma solução de web móvel. Você consegue adivinhar o que é? Vou te dar uma dica, volte e leia o entrada da primeira série .