MyProfiles Lesson 2 - App Functionality

INTRODUCTION 

This lesson will dive into the functionality the app will have.

This app will be a website that has a search box and search button on the home page.  If a user enters a term or name in the box and then click search a results list will appear underneath the search box on the screen.

We are limiting results to the first 50 records.  We are bootstrapping and cannot afford to waste resources.  Most searchers will not go past the first page on search engines which are usually 30 to 30 records.  We'll have a note on the limits and reasoning.

We'll put the records in an interface that allow the user to hit a forward or backward arrow to sit through records.  The interface will also allow them to jump to a block.  A block will be 10 records.

When you design interfaces think of how you use similar things.  You can even go to a site and note your habits and wishes.  Odds are you do not like a boat load of information at once or for things to take too long.  If it does you try some other search terms.  This is user behavior.  When you design you want to design with that in mind.

Google was the first site to show simplicity sells.  Unlike other search engine's landing pages Google's page simply had a search box and a menu item or two and ended with the copyright and attribution in the footer.  People loved not getting bombarded with too much just to find something.  It was too distraction.  Google's page still maintains that simplicity and they are still the top engine.

Our landing page is also simple.  Other than the search box, search button and footer data is a menu item that says, "Account".

When the user clicks the Account menu item a pop-up box will offer social login for Google, Microsoft or Facebook.  We could add more but these three covers most people, especially English speakers in the USA, our target.  You can do research on your target and tailor to them to streamline your design and costs.  Studies show that social login gets more signups and returns because of ease of functionality.  Try to always think of your target and how they will potentially use your app. 

We target busy people who could easily be multitasking while at our site.  We have to make things useful and quick for that reason alone.  This helps us in not overloading our workload with uselessness.

The popup will have the social login.  We could put a line to Register if they never had.  Sometimes this is futile because people can actually forget they signed up and duplicate accounts happen.  One reason developers have the "Register?" is that it reduces function calls.  Our free tier is generous and the pay tier for calls to Firebase Functions are pretty low and affordable, so we won't ask users the Register question.  

We can simply check if the login credentials they've chosen is in our datastore.  If so then they already have an account and we send them to the Admin page, if not we send them to our Registration process.  The registration process gets permission from the social network to use the credentials and request access to the email so that we can send emails regarding their account.  

A plus in using social login is the amount of work we do not have to do.  If they forget their password the social network handles that.  The security the social networks have helps us stay more secure.  We also do not have to go through the email validation process since the social network did that already.  We save coding time and resources.

The Admin page is broken into sections.  We use a tabbed interface.  There will be an Account Info, Social Links, Money Links and Tags section.  User inputs their data and save it.  Each section has mostly input fields.  We valid input via code to make sure it isn't hacker tricks or ill-formed.  The Account information section has a Delete Account button.

Each button has processes as do the input fields.  We use App Scripts to handle the functionality and make even backend calls if needed.

Each Buttons or Section will get its own detailed lesson.  The final code will be mentioned in a lesson when it represents the final code of a feature.  The Search makes read only calls.  The Admin make CRUD which stands for Create, Read, Update, Delete.  There will be at least one API call for each CRUD function.  Some like read can get more than one since we can go to read several records or one record by ID or a record by some other value or key.  Keys are data that gets you to specific data faster.

In our code each function will be an API endpoint. With Google Firebase Functions each endpoint is a separate, single block of code that will execute and return data or/and a server status message.  We handle calling endpoints to send or receive information with App Scripts which is written in Typescript a structured JavaScript. 

The Firebase Functions endpoint code blocks as well as the App Script code will be in the lessons.  A section could have a string of lessons.  For Example, the Social Links Section will have a lesson for each CRUD, the tags could have just one lesson since it only does a Read function.

 The Test site at the location: 

https://myprofiles.aicodeprojects.com 

will be where the final code can be tested.  

There will be other projects that will also have a subdomain for testing.  Only the SaveMyProfiles is made into a live production website located at:

https://www.savemyprofiles.com  

There are no lessons for this project, and it uses different code platforms for its Firebase frontend and backend.  Live production sites are real sites on the internet that are for customers to use at will.  It's a business website in our case.

 

BTW:  Since we are trying to get people to DIY with their own projects from these lessons it will be text and not video based.