WEEK 12 Development

Front-end

Activity Recommendation Pages

Activity Recommendation - Carousel

Using a card format to represent each activity. These cards are wrapped inside a carousel so users can swipe back and forth between the recommendations easily.

Code-wise, each card's content is wrapped inside a ons-carousel-item tag to mark all the components that are meant to go inside the card as an individual collective. The cards are then wrapped inside a ons-carousel. PHP script has been used to echo the carousel-item so that individual cards populated with information echo'd from the database are generated dynamically.

Activity Recommendation - Specific

The activity recommendation card for a specific activity used to look like this, however it was decided that having a slider range for people to indicate how much they liked/disliked the activity was too confusing because it does not serve any 'real' function that immediately benefits the user.

Hence, the design was updated to contain just the required info. As there are two types of pages (directional and instructional), they each have a different design.

Both display detail of the recommendation retrieved from the database:

• For places: Retrieve the latitude and longitude of the place, display it on a map (using google map API) with the rough direction on how to get to it from user's current location. (Hard coded the start location at UQ and uses google's direction service)
• For activities: Retrieve the title and description of the activity and display three links for instructions on how to complete it.

Login Redesign

As it was decided that instead of requiring users to create an account to login, it would be much more user-friendly to have them enter their name and hit login. This is because having lower entry requirements makes people more receptive to using the app as less things are being required of them.

So, the register page was scrapped and the login was redesigned to only ask the user for their name. Previously, the design of the login screen featured the use of input fields in an underbar style however against the gradient background it is actually very hard to see. Therefore, the input field was changed to a white box that could easily be seen.

The newly designed login page looks like:

Finalising Footer Bar

For a while it was unsure whether or not the app should include a footer bar as we weren't sure exactly what sections would be included in there. However, it was decided that instead of featuring the 'Start' button for the recommendation process on the home page, it could be included in the footer bar as it is global. As we wanted to keep the 'Start' button in the middle, we opted to go with a 3-button footer bar. If a footer bar was going to be put in place, it would only be natural to include a button to take the user back to the home screen. For the last button, we decided to have an explore page to add a more depth to the application and so that would be the last button on the footer. The footer bar is the main and only navigation element in the application.

Back-end

PHP dynamic element Creation

After deciding on what to be mocked within the application for the showcase, the first major functionality to be implemented into the app is dynamically generating interests/ activity categories that the user can select and choose from. It is done by selecting a list of interests retrieved from the MYSQL database and then dynamically create HTML element for each value.

For example:

// SQL statement to retireve a list of interest based on user/ persona id
$sql="SELECT interest FROM interest WHERE userID = $user";
// execute the SQL statement
$rs = mysqli_query($db,$sql);

// loop through each row returned from the results				`
while ($row = mysqli_fetch_assoc($rs)) {
     // dynamically check HTML checkbox through PHP echo
     echo ' <input type="checkbox" name="interest[]" value="'.$row['interest'].'">'.$row['interest'].'<br>';
}

Session storage

Rather than storing every user's info when logged into the app, sessions are used as a temporary storage for username, interest and their inputs for the free time they have and the activity category they feel like doing today.

// check if the username has been stored and get the interest list send from the previous page
if(isset($_SESSION['username'])&& isset($_POST['interest'])){
	// store it into a session called interest
	$_SESSION['interest'] = $_POST['interest'];
}

Initial Database design + Recommendation generation process

With our current design, all recommendations and personas will be stored within a relational database and for each recommendation, it will filter out every activity/ event stored within and select only one that matches their input. The SQL query for the filtering is done through a simple select statement and incorporate IN operator of the recommendation that has any pair of interest and category given.

Database + Recommendation generation refinement and finalisation

Working from the initial schema we had developed, some minor changes had been made so that there are more relationships between each entity. In particular, adding a table called interest and category so that for each recommendation added to the recommendation table there is corresponding category and interest within the parent table.

Furthermore, in order to ensure that the recommendation is personalised to the fullness, additional filtering is added to the SQL query to ensure to take consideration the appropriate time to do the activity (your current hour date(H)) and the time take to complete or go to the activity. (the time you have right now $_SESSION['time'])

date_default_timezone_set('Australia/Brisbane');
						
$sql="SELECT * 
FROM recommendation 
WHERE interestID IN ".$interestSql." AND categID IN ".$categorySql. 
"AND ".$_SESSION['time']." BETWEEN timeRangeStart AND timeRangeEnd 
AND ".date('H')." >= hour(startTimeSuitable) 
AND ".date('H')." <= hour(endTimeSuitable)";