2. OVERVIEW
• The purpose of this application is to build a tool “Where Friends Match Up
Single Friends”
• Anyone having a valid Facebook account can register on Miggly as either
“Single” or “Matchmaker", where “Single” is the one who is looking for the
perfect match and “Matchmaker” is the one who is interested in helping their
other single friends in finding the perfect match
• For “Single Role”, the user should be able to invite their Facebook friends as
their “Matchmaker” and hence to see the “Single” friends of the “Matchmaker”
based on their preferred gender and then to “Say Hi” to the perfect match
• They should be able to create “Dating Games”, which is nothing but asking
questions (a maximum of 5 questions per game) within a group of minimum
two and maximum four singles
• Singles should be able to see their Facebook likes regarding Music,Video, Books
on their profile page and it should be always updating based on the changes on
Facebook
3. OVERVIEW
• For “Matchmaker Role”, the user should be able to invite their Facebook friends
as their “Singles” and hence to “Match Up” those with their other “Single”
friends based on the gender preference
• Matchmaker can also invite their Facebook friends as their “Matchmaking
Helper” and by boosting their network of “Single” friends for “Match Up”
• Matchmaker should also be able to create “Dating Games” for their “Single”
friends
• Matchmaker should get notifications based on their Single’s activities
• Matchmakers should be able to see their “Single” friends on their profile page
based on their “Single Friend’s activity on Facebook”
• Both “Single” as well as “Matchmaker” should be able to upload photos and can
have different custom photos based on their roles
• All the photos should be approved by the administrators before it can be
viewed by others
• Miggly will be using re-marketing emails to get their users back into the system
based on certain criteria; especially when they were not logging in back for a
period of time
4. CHALLENGES
• Allowing the user to register with a valid Facebook login and automatically
logging into Miggly if the user is already logged in to Facebook and has a valid
account on Miggly.
• Always keeping the friends list updated on Miggly with Facebook.
• Handling of different types of Facebook Requests/callbacks.
• Updating the “Relationship Status” changes on Facebook into Miggly.
• For Matchmaker role, to keep their Friends list on profile page always updated
based on the Facebook activity of their friends.
• Identifying the Miggly users when they de-authorize the “Miggly App” from their
Facebook account and to avoid authorization related problems when using
“App Request on Facebook”.
• Identifying the Miggly users who have de-activated their Facebook account; to
avoid sending any message/request to their Non-Existing Facebook account.
• To prevent the un-authorized viewing of content by other users of Miggly.
• To reflect any changes in the profile picture on Miggly emails after the email
delivery was made.
5. CHALLENGES
• Identifying the number of successful logins based on the user’s role to show the
“MigglyTour” without affecting the performance
• Displaying of user’s Facebook likes regarding Music,Videos & Books
• Dynamically displaying of “Notification Messages” on users Home Page & LOVE
Page with multi-language support
• Automatic Allocation of Miggly Badges and the provision to verify the same.
• To approve the photos uploaded by the users
• To manage the “User Reports” and hence to suspend the users’ account if necessary
• Handling of Miggly Emails andTracking
• To bring user back to the system if they are not active for a period of time
• To testing the re-marketing emails to verify the delivery, copy, layout, etc
• Processing of various kinds of request by clicking on the buttons from Miggly emails
• Auto Processing of request followed from Facebook notification/message links
6. SOLUTION
• FACEBOOK LOGIN
• In Miggly, we have implemented a combination of JavaScript & PHP SDK to
connect the users with Facebook and hence to access the system. The login part
was handled by JavaScript SDK and the post request callback was handled via PHP
SDK to complete/validate the login and hence to allow/deny the user to continue
with the application.
• UPDATING FACEBOOK FRIENDS (ALWAYS)
• One of the challenge was to keep the Facebook Friends list updated within the
miggly system. There could be a possible delay in taking the user to his/her home
page as it required to update the FB friends list during every login; depending on
the number of friends they dely could vary. After done with the R&D, we have
provided the best solution which uses the “ETag” information provided by
Facebook that will help us to identify if there are changes in the user’s friends list
on Facebook. This helped us to avoide the checking unwanted and thus to
improve the performance.
7. SOLUTION
• FACEBOOK REQUESTS
• In Miggly, we need to send many kind of requests to user's Facebook
account and most of the request will have certain action/functionality
involved if the user happened to click the link. It was “true” that the FB API
will redirect all request to a single URL and we cannot configure multiple
callback URLs.As a result, it will be verify difficult for the developer / QA to
verify these requests as it would require us to copy /paste the URLs to work
with different platforms
• We have implemented a logic such that the Redirect URLs created on
Facebook will hold a reference that will help us to identify the platform from
which the request was generated. Once the user click the link from their
Facebook account, it will redirect to the callback URL and there our system
will identify the actual platform to which the request belongs to and then
the Miggly System will redirect the request to the correct platform.This
helped us to avoid the copy/paste URLs from Facebook request redirection
and hence to save the developer/QA time
8. SOLUTION
• UPDATING ‘RELATIONSHIP STATUS’ CHANGES
• One of the major role in miggly is “Singles” and it is very important to track any
changes to the users’ Facebook Relationship Status
• It was “true” that there is “NO” direct way of identifying such changes on
Facebook account
• To overcome the situation, we have followed the same “ETag” logic that we have
implemnted to update the friends list
• However, we have enhanced the logic such that any change in the “Relationship
Status” of the user will be updated into Miggly in two ways:
1. During the very next login by the user after the “Relationship Status” was
changed on their Facebook account
2. When one of his/her friend is trying to login to Miggly after the
“Relationship Status” was modified by their friend
• As we used to capture / update the “Relationship Status” in two different ways, it
will make sure that the user’s “Relationship Status” will be immediately updated if
someone happened to see/visit the Miggly profile
9. SOLUTION
• SORTING FRIENDS BASED ON FB ACTIVITY (PERMISSION BASED)
• In Miggy, for Matchmaker role, it was required to sort the friends list on the
users’ profile page based on the Facebook activity of their friends and there
was not direct API available in Facebook to achieve this task
• We have built a custom solution, which will crawl the user's notification (latest
10) and hence to build a sorting index based on the number of occurrence of
their friends
10. SOLUTION
• HANDLING OF ‘MIGGLY APP’ DE-AUTHORISATION
• While using Facebook Apps, it was a challenge to identify the users who were
de-authorized the application from their Facebook account
• This caused a problem when we try to send the messages to the user’s
account using “App Message”
• After doing the R&D we decided to use the FB API’s “De-authorization
Callback” functionality to overcome the situation
• We have implemented the logic such that on receiving the de-authorization
callback, Miggly system will be marking the user’s account and hence to avoid
using the “App Message” while sending any future message to the user’s
Facebook account
• It is noted that the new logic we have implemented will update the user’s
account status across the platforms with the single callback function
11. SOLUTION
• HANDLING OF ‘MIGGLY USERS’WITH DISABLED FB ACCOUNTS
• In Miggly, we are sending various kinds of message / notifications to the user’s
Facebook account
• While sending the message to the user’s Facebook account, there are
exceptional case in which the user might have deleted / disabled their
Facebook account; in such case, Facebook used to through an error message
as the user account does not exists and was caused a problem in completing
the desired action
• We have implemented a new logic that will work as a “PRE Check” to
whether the user’s accounts is valid on Facebook or not.
• If it is found that the user has disabled their FB account, the Miggly System will
show the message to the user to let them know that the other user’s
Facebook account does not exist and also at the same time the other user’s
Miggly account status will be marked so that the user’s account will not be
shown in Miggly until they re-visit the Miggly system again
12. SOLUTION
• PREVENT UNAUTHORISEDVIEWING OF ACCOUNT
• Once of the biggest challenge in any of the web-based application is to
prevent the un-authorized access of other’s data/content by copy/paste URLs
• In Miggly, we have implemented the logic to cross verify to identify whether
the user is authorized to view the particular data belongs to the other user
and if “NOT” the user will be redirected to either his own home page or
other related page; thus completely preventing the un-authorized access of
user’s data and hence to increase the privacy of the user
13. SOLUTION
• SHOWING UPDATED PROFILES ON MIGGLY MAILS
• Miggly delivers a number of emails to its user; these email may contains the
profile images of other Miggly or Non-Miggly users
• For the case of Miggly user; they can change their profile images any time
based on their roles
• In such occurrence, the new image will not be reflected in the emails delivered
in the past
• To overcome this issue, we have created an API to display the user’s profile
image dynamically inside the emails that are generated by the Miggly system;
thus ensuring the latest profile image to be displayed always in emails even if
the delivery happened in the past
14. SOLUTION
• LOGGING IN (BASED ON USER ROLE)
• In Miggly, we have to display a “Tour” based on user’s role during their first
seven login attempt
• This tour is used to help / guide the user the basic functionality of the system
as they are new
• This required us to keep track of the user’s successful login attempt and the
challenge in implementing the system was to ensure that this logic will not
cause any trouble in the performance of the system especially the logging-in
time. We have implemented a login-log system as 1:1 (one row per user) as
we required to query this table during every login
15. SOLUTION
• FACEBOOK LIKES
• In the profile pages of Miggly Singles, we have to display the Facebook likes
regardingVideo, Music and Books and it should always display the latest
information from the users Facebook account
• After the R&D we have implemented a live crawl for reading the latest users’
likes; thus ensuring the data displayed on Miggly to be always updated
16. SOLUTION
• MIGGLY BADGE ALLOCATION
• One of the features of Miggly is “Allocating Badges” to the user based on
their “Role & Activity” and each user role can have a maximum of 21 badges
hence there can be 42 badges per user
• For the better performance, we have decided to approach 1:2 (one user two
rows) i.e.. one row for each role
• This helped us in reducing the number of rows in the main table and hence to
increase the performance of the system
17. SOLUTION
• MIGGLY NOTIFICATION HANDLING
• One of the biggest challenges in Miggly was to handing the various kinds of
messages/notifications displayed in the user's home page and especially in the
love page
• In the love page of the single user, the notification text will be changing based
on the visitor’s role
• To give the optimum performance, we have decided to store only one entry in
the database and then to change the notification text based on the visiting
user's role
• In addition to this some of the notification are not shown to a specific role
(either self, matchmaker or other matchmaker) this become a complex in
retrieving the notifications from the database
• We have implemented a logic to validate the notifications after reading it from
the database and before displaying it in the page based on the user’s role
18. SOLUTION
• PHOTO APPROVALTOOL
• Miggly allows the user to upload photos and it was highly important to screen
the photos before it can be viewed by others
• We have created a tool for photo monitoring and the tool requires
authentication for accessing it
• This tool will list all the photos uploaded by the users based onToday,This
Week,This Month, etc.
• The administrator can approve, warn or suspend the user once after verifying
the same and all is done by a single click
• If the administrator warns the user, an automatic email will be send to the user
and during the 4th warning, the users account will be blocked automatically
• In addition to the flexibility we have provided in this tool, it was built with a
tracking of all administrator activity especially when the warn/suspend the user
for any future audit purpose
• The data is stored in a stats table that can be queried accordingly
19. SOLUTION
• REPORT USERTOOL
• Miggly allows the users to report others profile if they find some data to be
abusive
• We have provided a system for monitoring all user reports so that the
administrator can verify take necessary action to suspend/un-suspend the
users account
• We have also given the search option so that the admin can easily find the
user by simply typing the search words into the search box.
• Also provide a custom filtering option to display the result based onToday,This
Week,This Month, etc.
• In addition to the flexibility we have provided in this tool, it was built with a
tracking of all administrator activity especially when the warn/suspend the user
for any future audit purpose
• The data is stored in a stats table that can be queried accordingly
20. SOLUTION
• HANDLING EMAIL via MANDRILL
• Miggly uses emails for re-marketing purpose and a large number of emails
were send automatically based on the criteria
• It is very important to have a system to track the delivery of the emails and
also to identify the number of users who have opened/read the mail
• After the R&D we have decided to proceed with the MANDRIL with is a 3rd
party service; a free email tracking tool for 12K emails per month
• This tool includes the complete tracking including the deliver and read/unread
status, etc.
21. SOLUTION
• REMARKETING EMAILS
• One of the biggest challenge in Miggly is to bring the user back to the system
when the are idle for a week, month, etc.
• We have implemented automated email (remarketing email) delivery system
with necessary information to increase the possibility of bringing the user back
and these emails will be send automatically via CRON (running of automated
scripts on schedule basis) running on server
22. SOLUTION
• TRAILMAILTOOL
• One of the difficult part while using the re-marketing email was the “wait
time” as the emails will be generated only once the days, weeks, etc. is reached
• We have provided a tool to the client for manually generating all the
remarketing emails by simply inputting the desired user’s email as an input
• The tool also contains an alternate email address that will allow the
administrator to receive the email in a secondary email inbox. This tool
helped the developer/QA to save their time in receiving the email to verify the
layout, copy, body, etc.
23. SOLUTION
• CTA BUTTON REQUEST PROCESSING
• The mails generated from Miggly system will also include CTA (CallTo Action)
buttons
• Once the user clicks the button, the user should be re-directed to Miggly and
hence to complete any action/activity associated with the same
• It was a challenge when implementing the logic such that the user may be
already logged into system with a different role which is NOT associated with
the CTA button action
• We have implemented a logic to automatically switch the users role to the
desired one before start processing any further action hence to the successful
completion of the request
24. SOLUTION
• REMOVE DATATOOL
• During the development/QA it was found very difficult to test various action
as most of the actions were one time activity (example registration)
• As Miggly works completely with Facebook credentials, it was verify difficult to
create Facebook account to check every kind of development/QA activity
• We have suggested a tool that will allow to remove/clean all user related data
from the Miggly system so that to re-use the Facebook account again and
again
• This helped us in saving the developer/QA time very much
25. SOLUTION
• OPTIMISING PERFORMANCE
• During the implementation of Miggly, the a primary goal was to ensure the
optimized performance of the system.
• We have studied / analyzed the system considering various use case and
designed the Database accordingly to avoid the maximum possibility of
reducing the over all load to each and every table
• To achieve this, we have decided to separate the table into two blocks one for
the regular use with the system and the other is to used to store the logs,
which can be used for any stats activity
• We have also used the DBTRIGGERS in the best possible way that will help
us to reduce the Web-Server load
26. SOLUTION
• THE MIGGLY SYSTEM
• The Miggly System was about to change based on the market study and the
other factors involved in the market and the initial requirement was to expect
frequent changes to the system including logic and functionality.
• It was a challenge for the developer to handle this as you can understand the
difficulty in handling frequent changes in any system
• To overcome the situation, we have decided to build a system based on
“Templates & Component” basis so that we can reuse the component by
“Plug & Play” the templates/modules easily from one plays to the other.
• This decision helped us for the maximum possibility of reusing existing
components and hence to avoid too much of reworks
• In other words, it helped us to minimize the rework to at least some level