Ch # :05

Enhancing the User Experience

--------------------------------------------
Juniper Theatricals ?
Juniper Theatricals want to have a lot of products on their online store, and as a
result they fear that some products may get lost within the website, or not be as
obvious to their customers. To help prevent this problem, we will integrate product
searching to make products easy to find, and we will add filters to product lists
allowing customers to see products that match what they are looking for
(for example, ones within their price range).
The importance of user experience?
Our customers' experience on the stores powered by our framework is very
important. A good user experience will leave them feeling wanted and valued.

Search?
The ability for customers to be able to search, find, and filter products is vital, as if
they cannot find what they need in our site and go somewhere where they can find what they are
looking for much more easily.
There are two methods. what they are looking for:
Keyword search: This method allows customers to search the product
catalog based on a series of keywords.
Filtering: This method allows customers to filter down lists of products
based on attributes, refining larger lists of products into ones that better
match their requirements.
Finding products?
The simplest way for us to implement a search feature is to search the product
name and product description fields. To make the results more relevant, we can
place different priorities on where matches were found;
So, what is involved in adding search features to our framework? We need
the following:
Search box: We need a search box for our customers to type in words
or phrases.
Search feature in the controller: We need to add some code to search the
products database for matching products.
Search results: Finally, we need to display the matching products to
the customer.
Search box?
We need a search box where our customers can type in words or phrases to search
our stores. The best place for this would be in our website's header, so customers can perform their
search from anywhere on the site or store.
Improving searches
We could improve this search function by making it applicable for all types of
content managed by the framework. Obviously if we were going to do this, it would
need to be taken out of the products controller, perhaps either as a controller itself, or
as a core registry function, or as part of the main content/pages controller.
Filtering products
Another useful way to allow customers to better find the products they are looking
for is with filtering. Customers can filter down lists of products based on attributes,
such as price ranges, manufacturer, weight, brands, and so on.
Price range filtering should be simple enough. There are a few different ways in which we can store
filtered results:
In the user's session: This will be lost when the user closes their browser.
In a cookie: This information will stay when the user closes their browser.
In the URL: This would allow the customer to filter results and send the link
of those results to a friend.
In POST data: The information will only be stored for the one instance the
filter is used.
Product attributes
Some attributes are already stored within the product, such as the weight and the
price. However, we still need to store some ranges of these for our customers to
filter by.
We are going to need to create three new database tables to effectively support
product filtering as we have discussed. We will need:
An attribute types table to manage types of attributes; for example, price,
weight, brand, manufacturer, color, and so on
An attribute values table to manage values and ranges of attributes.
Filter attribute types
The attribute types table needs to be able to act as a grouping reference for attribute
values, and also detect if an attribute value should be referenced against the products
table, or the attribute associations table.
Filter options
To display these attributes to our customers, and allow them to click on them to
perform a filter, we need to build a list of attributes, build suitable URLs based
on the attributes, and display them within the product list view.
Displaying these attributes will involve some nested-looped template tags. The first
loop will be to generate headings and empty lists (with suitable template tags within)
for the attribute types. Then we need to insert the loops of values into these.
The simplest way to do this would be to do a query of all of the attribute types,
Let's look at this as a step-by-step process:
1. We query the database for attribute types.
2. We cache the results of this query.
3. The cache is associated with a template tag. (This allows the template engine
to generate a list of attribute types, and for each attribute type, it can build an
empty list, surrounded by template tags, which will eventually contain the
attribute values.)
4. We query the database for all attribute types, ordering by their own order.
(Although the order is their order within their group, this does not matter,
as we filter them out.)
5. We iterate through the results, putting each value into an array for its
corresponding attribute type.
6. For each attribute type, we cache the array, and assign it to a template
tag, allowing each group of values to populate the appropriate list for the
attribute type.
Processing filter requests
With the relevant database structure in place, and functionality available for our
customers to select attributes for which they wish to filter their product viewings,
we need a method to process the request and actually filter the products listing.
Displaying filtered products
Assuming we call our filterProducts() method within the products controller
at some point, we can filter our products list quite easily. In our "products list" page,
for instance, we can simply detect if the filter SQL field is empty; if it is not, we
can replace the list query with the filter query. Of course, we should also swap
our template, to indicate that the results are a filtered subset.
Improving product filtering
As with everything, there is always room for improvement. For the filter feature,
potential improvements include:
Displaying the number of products matching a filter next to it.
Providing wish lists
Wish lists allow customers to maintain a list of products that they would like to
purchase at some point, or that they would like others to purchase for them as a gift.
Creating the structure
To effectively maintain wish lists for customers, we need to keep a record of:
The product the customer desires
The quantity of the product
If they are a logged-in customer, their user ID
If they are not a logged-in customer, some way to identify their wish-list
products for the duration of their visit to the site
The date they added the products to their wish list
The priority of the product in their wish lists; that is, if they really want the
Product.
Saving wishes
a process available to save them into the database. This involves a link or button
placed on the product view, and either some modifications to our product controller,
or a wish-list controller, to save the wish. we may as well add the functionality
into the wish-list controller.
So we will need:
a controller
Wish-list controller
The controller needs to detect if the user is logged in or not; if they are, then it should
add products to the user's wish list; otherwise, it should be added to a session-based
wish list, which lasts for the duration of the user's session.
a link in our product view.
Add to wish list
To actually add a product to our wish list, we need a simple link within our products
view. This should be /wishlist/add/product-path.
Viewing a wish list
As our customers are now able to create their own wish lists, we need to allow them
to view and manage their wish lists.
Controller changes
Our controller needs to be modified to list items in a user's wish list; this involves
detecting if the user is logged in or not, as this will determine the query it must use
to lookup products. In addition to a function to display the list to the customer, we
need to detect if the customer is trying to add a product to the list, or if they are
trying to view the list, though a switch statement in the constructor.
Wish-list view
Although we would need to extend this later, to include a purchase button,
a priority, and quantity, this code would suffice for a basic view to show our
customers their desired products for the time being.
Purchases
The purchases aspect of this feature is the most complicated, as it needs to facilitate
both customers making purchases for themselves, and also others making a gift
purchase for someone.
Gift purchases
The complication of gift purchases is that the purchases need to be stored with the
delivery address from the customer who created the wish list.
Self purchases
Self purchases should be very straightforward to handle. Essentially, all the customer
would be doing is adding their own wish-list product to their own shopping basket,
the only difference being that we must maintain a record that this is from their
wish list up until the point of their order being finalized.
Improving the wish list
There are a number of ways in which we could improve the wish-list feature we
have added to our framework, including:
Multiple lists per customer, allowing customers to maintain separate lists
Garbage collection for session-based wish-list products, ensuring we don't
have useless data in our database
Transferring of session-based wish-list products to user account-based
wish-list products when a user is logged in
Model, as we didn't implement a model with this wish list, and we should do
so to make it easier to extend.
Recommendations
Sometimes, we may find that certain products go hand in hand, or that customers
interested in certain products also find another group of products interesting
Displaying related products on a products page
E-mailing customers who have made certain purchases to inform them of
some other products they may be interested in.
Related products
The simplest way to inform customers of related products from within the product
view is to maintain a relationship of related products within the database and
within the products model, so we could cache the result of a subset of these related
products.
There are a few ways in which we can maintain this relationship of related products:
Within the products table we maintain a serialized array of related.
product IDs.We group related products together by themes, We relate pairs of related products together.
Controlling the related products
If we create a new function within our controller to run our random related products
query, cache the result, and associate the cached results with a template variable,
all we would need to do is call this function from within the product view function,
passing the product ID as the parameter.
Viewing the related products
Related products are now cached and associated with a template variable. We
now need to add relevant mark up into our view product template, to display
related products.
E-mail recommendations
There is only so much we can do for this feature at the moment, as it requires our
customers to have made some purchases, and at the moment, we don't have the
functionality available for customers to make a purchase. However, we can discuss
what would be involved in creating this feature:
Stock alerts database table
We need to store the following information in the database to manage a list of
customers interested in being alerted when products are back in stock:
Customer name
Customer e-mail address
Product
Stock alerts database table
We need to store the following information in the database to manage a list of
customers interested in being alerted when products are back in stock:
Customer name
Customer e-mail address
Product

Giving power to customers

There are two very powerful social-oriented features, which we can implement into
our framework.
Product ratings
Product ratings are quite simple to add to our framework: we simply need to record
a series of ratings between one and five, and display the average of these on the
product view. We can enhance the view by making the rating system a clickable
image, where the customer can click on the number of stars they wish to give the
product and their rating is saved.
Viewing ratings
To display the ratings, we need to alter the content or products query to also perform
a subquery, which averages out the rating.
Product reviews
Product reviews can work as a simple comment form for the products, taking the
name and e-mail address of the customer, as well as their review. Product reviews
can be represented in the same way that we would represent comments on pages or
blog entries, and because we have set up our database to store pages, products, and
other types of content with a reference to a single database table, we can reference
our reviews or comments to any content type.
Displaying reviews/comments
What do we need to do to display reviews and comments?
1. Check to see if there are any comments.
2. Display either the comments or a "no comments" template.
3. Check to see if new comments are allowed.
4. Display either the comments form or a "no comments allowed" template.
Any other experience improvements to
consider?
A fantastic user experience for our customers by no means ends here; there are many
other ways in which we could improve our customers' experience.