Making a Mobile MVC Music Store Part 5: The Shopping Cart
Last Updated -
Today I am gong to complete the checkout process for the mobile version of the MVC Music Store. This process will again feature some layout decisions, but give me an opportunity to cover mobile specific features related to input forms.
Part 1 Creating a Common Service Layer
Part 2 Creating the Core Mobile Layout
Part 3 Creating the Controllers and Views
Part 4 Creating the Home Page
Part 5 Designing the Genre and Album Pages
Part 7 Big Finally
Cart Summary
When a customer adds an album to their cart they are shown the cart summary page. This page simply lists all the albums waiting to be purchased by the customer. This is pretty standard stuff for an e-commerce site.
Here I decided to make a Checkout button fit the width of the phone at the top of page with enough height to make it a nice touch point. I decided to put the button at the top of the page content because uses will always see it. In general they are going to glance at the cart list in most cases and being at the top means they can get on with their checkout quickly.
Next I changed the cart row to display an album thumbnail over its title. My reasoning is to two fold. First I want something the customer can glance at to know what they are buying. Second it provides a larger touch point if the user wants to review the album details.
Instead of a simple remove link I made it a rather large button, again to make it a good touch point. I have to admit I wimped out here I would rather make this a nice image instead of text.
Order/Registration
First, let me say this step deviates from the desktop site. If you look at the original desktop MVC Music Store version it uses the MVC scaffolding methods BeginForm and EditorForModel. Remember I am fairly new to really using ASP.NET MVC and I am still learning. I get the 10,000 foot view of the XForModel helper methods. What I am currently struggling through is forcing them to produce good markup. The default templates are completely unacceptable because they puke DIVs everywhere. Once I figure out a good strategy for customizing the templates I will be glad to post my solution, till now I will stick with writing my markup by hand.
Instead of the ASP.NET Unobtrusive validation library I am going to replace it with the jQuery validation plugin I am much more familiar with. I am also going to use the jQuery Masked Input plugin to offer guidance on some fields.
Here is the the mobile web site AddressAndPayment page's markup. Notice I use an UL instead of a bunch of DIVs to layout the form. I have found this to be much more flexible than wrapping everything in its own DIV, a block element.
<
form
action
="@Url.Action("
AddressAndPayment
", "
CheckOut
")"
method
="post"
>
<
fieldset
>
<
ul
>
<
li
><
label
for
="FirstName"
>
First Name</
label
></
li
>
<
li
><
input
type
="text"
id
="FirstName"
name
="FirstName"
class
="required"
/></
li
>
<
li
><
label
for
="LastName"
>
Last Name</
label
></
li
>
<
li
><
input
type
="text"
id
="LastName"
name
="LastName"
class
="required"
/></
li
>
<
li
><
label
for
="Address"
>
Address</
label
></
li
>
<
li
><
input
type
="text"
id
="Address"
name
="Address"
class
="required"
/></
li
>
<
li
><
label
for
="City"
>
City</
label
></
li
>
<
li
><
input
type
="text"
id
="City"
name
="City"
class
="required"
/></
li
>
<
li
><
label
for
="State"
>
State</
label
></
li
>
<
li
><
input
type
="text"
id
="State"
name
="State"
class
="required"
/></
li
>
<
li
><
label
for
="PostalCode"
>
Postal Code</
label
></
li
>
<
li
><
input
type
="text"
id
="PostalCode"
name
="PostalCode"
class
="required ZipCodeMask"
/></
li
>
<
li
><
label
for
="Country"
>
Country</
label
></
li
>
<
li
><
input
type
="text"
id
="Country"
name
="Country"
class
="required"
/></
li
>
<
li
><
label
for
="Phone"
>
Phone</
label
></
li
>
<
li
><
input
type
="text"
id
="Phone"
name
="Phone"
class
="required phone PhoneMask"
/></
li
>
<
li
><
label
for
="Email"
>
E-Mail</
label
></
li
>
<
li
><
input
type
="text"
id
="Email"
name
="Email"
class
="required email"
/></
li
>
<
li
>
We're running a promotion: all music is
free with the promo code: "FREE"</
li
>
<
li
>
@Html.Label("Promo Code")</
li
>
<
li
>
@Html.TextBox("PromoCode")</
li
>
<
li
><
input
type
="submit"
value
="Submit Order"
/></
li
>
</
ul
>
</
fieldset
>
</
form
>
<
form
action
="@Url.Action("
AddressAndPayment
", "
CheckOut
")"
method
="post"
>
<
fieldset
>
<
ul
>
<
li
><
label
for
="FirstName"
>
First Name</
label
></
li
>
<
li
><
input
type
="text"
id
="FirstName"
name
="FirstName"
class
="required"
/></
li
>
<
li
><
label
for
="LastName"
>
Last Name</
label
></
li
>
<
li
><
input
type
="text"
id
="LastName"
name
="LastName"
class
="required"
/></
li
>
<
li
><
label
for
="Address"
>
Address</
label
></
li
>
<
li
><
input
type
="text"
id
="Address"
name
="Address"
class
="required"
/></
li
>
<
li
><
label
for
="City"
>
City</
label
></
li
>
<
li
><
input
type
="text"
id
="City"
name
="City"
class
="required"
/></
li
>
<
li
><
label
for
="State"
>
State</
label
></
li
>
<
li
><
input
type
="text"
id
="State"
name
="State"
class
="required"
/></
li
>
<
li
><
label
for
="PostalCode"
>
Postal Code</
label
></
li
>
<
li
><
input
type
="text"
id
="PostalCode"
name
="PostalCode"
class
="required ZipCodeMask"
/></
li
>
<
li
><
label
for
="Country"
>
Country</
label
></
li
>
<
li
><
input
type
="text"
id
="Country"
name
="Country"
class
="required"
/></
li
>
<
li
><
label
for
="Phone"
>
Phone</
label
></
li
>
<
li
><
input
type
="text"
id
="Phone"
name
="Phone"
class
="required phone PhoneMask"
/></
li
>
<
li
><
label
for
="Email"
>
E-Mail</
label
></
li
>
<
li
><
input
type
="text"
id
="Email"
name
="Email"
class
="required email"
/></
li
>
<
li
>
We're running a promotion: all music isfree with the promo code: "FREE"
</
li
>
<
li
>
@Html.Label("Promo Code")</
li
>
<
li
>
@Html.TextBox("PromoCode")</
li
>
<
li
><
input
type
="submit"
value
="Submit Order"
/></
li
>
</
ul
>
</
fieldset
>
</
form
>
This markup produces a vertical form with labels listed above each input field. Typically for desktop forms I display labels to the left of the input field because this helps users read the form. But in the mobile context you really only have a single column and having everything in a vertical stack is the optimal layout.
There are several user experience details I want to point out in the screenshot. First, each input field is the width of the screen. Obviously this is not normally done on desktop sites, but it is also a common practice to guide users to possible input lengths with varying field lengths. For example a middle initial field will be rather short compared to the first and last name fields.
$("input"
).focus(function
(e) {
$(this
).css("background-color"
,"#fff"
);
});
$("input"
).blur(function
(e) {
$(this
).css("background-color"
,"#eee"
).valid();
});
When focus is given to an input field the background is set to white. All other input fields display a light grey background to indicate which field the user is typing. I have found using my Windows Phone that many native applications use this user experience queue to let users know where their typing is going or even if they have selected an input field all together. I get real frustrated typing on a tiny keyboard only to find out there was no input field selected.
Next a validation error is shown for the First Name field. This is because I applied the required class to the input field and the jQuery Validation plugin performed validation on the input when I tabbed off the field. This occurs because the valid() method is called when the user leaves any input on the page, which invokes the validation rules applied to the input field. I personally like when I get real-time validation on forms instead of waiting to submit the form to find errors so I try to apply this to my pages.
I chose not to apply WAP CSS Input format code to the Input fields. I chose not to use them because I have not seen this supported very well across browsers yet. Instead of working through a Modernizr like feature detection routine I chose to stick with trusted jQuery solutions for masked input, validation etc. I suspect newer mobile browsers will support these features using the HTML5 specifications and most likely I will turn my attention to those solutions before too long.
I also used the jQuery masked edit plugin to provide even more guidance to users. For this form I use Phone number and Zip Code masks.
$(".PhoneMask"
)
.mask("999-999-9999"
, { placeholder:' '
});
$(".ZipCodeMask"
)
.mask("99999"
, { placeholder:''
});
I also want to point out another creature comfort I discovered on my HTC Arrive. When I do not have my slide out keyboard open and focus is given to an input field the soft keyboard is displayed and the input field is automatically moved into view above the keyboard. I was glad to see the browser automatically handles this for us because this could have turned out to be a bit of tricky JavaScript. I can't confirm other platforms do this, but my suspicion is they do.
Order Confirmation
This page is nothing special! Just a nice order confirmation message.
Summary
Whew! Now we have an end to end functioning mobile version of the MVC Music Store. Just like the desktop MVC Music Store. This is not a 100% feature complete application, but a reasonable sample site demonstrating various design decisions developers and designers must make when creating a mobile presence. These decisions often transcend web and mobile and are pure User Experience decisions. But this should serve as a good mobile web framework to reference for production sites.
But wait, there is more! That's right I am not done yet. I have one more installment that will feature something special. If you have been following along you may have noticed there is a key aspect the site needs. Well I have something planed to solve that problem that will hopefully help you realize you are not limited when it comes to architecting a mobile web solution. Can you guess what it is? I will give you a hint, go back and read through the first series entry.