In this learning content, we will be deciding on the components that are the cornerstone of software and each of which corresponds to a module in Kuika, focusing on the analysis document prepared within the scope of the I Have an idea application. These components are
While deciding on these components, we will make use of the analysis document, read the paragraphs in the analysis document, and fill in the component headings.
Let's start the process with Interfaces.
The main purpose of the I Have an Idea project is to create an application that will enable the improvement of internal processes and flows by increasing the creativity and initiative of staff in different departments. Hence, in this project, the need for screens that enable transactions to be made for the personnel working within the company emerges. Therefore, it may be necessary to create user interfaces that will enable the registration and update of personnel. In this context, it will be necessary to realize the screen designs that will carry out the saving, listing, updating, and deleting operations for the personnel. We have realized this process in detail in the Designer 1 course.
When we continue to read the beginning of the analysis document, we foresee that it may be necessary to create screens under the interface heading where ideas will be created, and listed, showing idea details, and enabling the execution of idea update and deletion operations. As we will understand from the rest of the analysis document, we observe two different viewing needs when viewing ideas. At this point, we estimate that there is a need for both an area where users can see the ideas they have created and an area where other users can view their ideas. At this point, we realized that it is inevitable that employees will need to register and log in to the application to create their ideas. However, we do not have information about the authorization mechanism to be used on the login screen. Our alternatives include Kuika Sign in, Google Sign in, and Microsoft Authentication Library, or MSAL for short. It will be necessary to read the rest of the analysis document to reach a clear answer between these options.
At this point, there is a need that emerges in the continuation of the analysis document. In this direction, we may need a profile screen to keep information about the logged-in user. We will need to use the KUser table, one of the system tables provided by Kuika when registering the personnel to the system. At this point, it may be necessary to add the KUser ID in the personnel table to create the relationship between the KUser table and the personnel table while data modeling. The tables in the Datasources module in Kuika that start with the letter K represent the default system tables offered by Kuika. If we take a closer look at the system tables, through the system tables, information such as user name information, role information, user role mappings, Device ID information based on the user name in mobile applications, notification messages sent if notifications are used, and the status of users reading notification messages can be kept in the database.
Let's proceed by continuing from the data model title. Let's create the framework of the tables we will need within the scope of the data model.
We need a personnel table for the personnel who will request ideas within the application. In the personnel table, we need the ID of the table, the personnel registration number column, the personnel name and surname column, the personnel e-mail, the KUserID column to establish a relationship with the KUser table, the personnel image column, the Status column containing the current working status information of the personnel, a Personnel Title column containing the title information of the personnel, and the Created Date column containing the registration date of the personnel in the system in case we can use it in the future. In addition to these columns, a staff Department column is needed to keep the department information of the staff. However, associating this column with a Department table we will create will produce healthier results.
Therefore, it will be necessary to create a Department table with a table ID and Department Name information.
Another table we need under the data model heading is the Idea table. Under this table, we need the ID that the table has, the Idea Owner column associated with the personnel table, the idea description column that contains the idea descriptions, and the Created Date column to keep the date when the ideas were added. In addition, the IdeaLike column containing the vote information of the idea is needed. Associating this column with a table containing the voting information of the ideas will enable us to build a healthier structure. Therefore, it is necessary to create an IdeaLike table. For the IdeaLike table, we need the Id column of the table, an IdeaId column associated with the IdeaTable, a PersonnelId column to associate personnel with the votes of ideas, and a Created Date column to keep the date information on the date when the votes are added ready to be used in a scenario that may need to be used.
In the following sections of the analysis document
By developing the application in a fast and flexible way, the process of visibility, voting, and realization of employees' ideas will be supported, thereby increasing the overall performance of the company and employee satisfaction.
In the context of this sentence, the concept of a company emerged in the document. This led to the need to answer the question of whether there is one company or more than one company.
In the scenario where we will decide to proceed with a single company, there is no need to keep additional company information for the personnel, while in the scenario where more than one company is involved, the need to keep company information for the personnel will arise.
In line with the project scope, we decided that proceeding with a single company meets the project needs. In this scenario, there is no need to create a company breakdown for employees, so there is no need to keep company information in the employee table.
Let's proceed with the Scope section in the analysis document.
With our inferences from the Scope section, we can first assume that the user interfaces will be divided into two as Web and mobile. At this point, we will expect the Registration screens to be designed as both web and mobile. In the same direction, we expect the profile screen, which shows information about the logged-in user, to be designed as both web and mobile. Within the scope of the mobile application scenario, Apple Sign-in can be added to the login options of our application.
The need to make a data modeling for the Comment structure, which is a structure we encountered for the first time in the Scope section, emerged. For this, let's create the framework of a table called Idea Comment. In this table, we need an ID column for the table, an IdeaID column associated with the Idea table, a StaffID column associated with the Staff table, a CommentDescription column containing the comment text, and a Created Date column to hold the date the comments were added.
In line with what we read in the rest of the analysis document, we can think that the user can view the ideas created by the user on the user profile screen and the ideas created by other users on the Listing screens.
In the rest of the analysis document, we view the idea category field encountered while creating ideas. In this direction, we need an idea category table.
In the idea category table, we can infer that the table needs an ID column and a CategoryName column.
After we prepare the idea category table, we will need to add a category column to the idea table that we have previously scoped, and we will need to associate the relevant column with the idea category table.
In the rest of the document, we see that the title of the ideas is needed. We will need to add the idea Title column to the idea table. However, to add images of the ideas, we need to add the idea image column to the idea table.
For the item in the analysis document; Ideas are sorted by popularity and relevance
In the idea listing screen, it will be necessary to show the number of likes of the ideas as well as the idea fields. Again, it will be necessary to add the sort by number of likes option to the listing screens for sorting by popularity level. Alternatively, we can add sorting by letter order to the interface.
We are also expected to create a Dashboard screen that lists the total number of ideas in the application, the number of ideas created by the logged-in user, and the latest ideas.
We have done the analysis reading of the items presented in Phase 1. We will discuss the analysis reading of the topics covered in Phase 2 in detail in our Builder 2 curriculum.
We evaluated the topics covered in Phase 1 in detail from a Builder/developer perspective. We will continue the development process for the screens created from a design perspective in the Designer 1 curriculum and technically verify this learning content in the continuation of this curriculum.
We will advance the workflow processes discussed as Phase 2 in the Builder 2 curriculum.
In this learning content, we will be deciding on the components that are the cornerstone of software and each of which corresponds to a module in Kuika, focusing on the analysis document prepared within the scope of the I Have an idea application. These components are
While deciding on these components, we will make use of the analysis document, read the paragraphs in the analysis document, and fill in the component headings.
Let's start the process with Interfaces.
The main purpose of the I Have an Idea project is to create an application that will enable the improvement of internal processes and flows by increasing the creativity and initiative of staff in different departments. Hence, in this project, the need for screens that enable transactions to be made for the personnel working within the company emerges. Therefore, it may be necessary to create user interfaces that will enable the registration and update of personnel. In this context, it will be necessary to realize the screen designs that will carry out the saving, listing, updating, and deleting operations for the personnel. We have realized this process in detail in the Designer 1 course.
When we continue to read the beginning of the analysis document, we foresee that it may be necessary to create screens under the interface heading where ideas will be created, and listed, showing idea details, and enabling the execution of idea update and deletion operations. As we will understand from the rest of the analysis document, we observe two different viewing needs when viewing ideas. At this point, we estimate that there is a need for both an area where users can see the ideas they have created and an area where other users can view their ideas. At this point, we realized that it is inevitable that employees will need to register and log in to the application to create their ideas. However, we do not have information about the authorization mechanism to be used on the login screen. Our alternatives include Kuika Sign in, Google Sign in, and Microsoft Authentication Library, or MSAL for short. It will be necessary to read the rest of the analysis document to reach a clear answer between these options.
At this point, there is a need that emerges in the continuation of the analysis document. In this direction, we may need a profile screen to keep information about the logged-in user. We will need to use the KUser table, one of the system tables provided by Kuika when registering the personnel to the system. At this point, it may be necessary to add the KUser ID in the personnel table to create the relationship between the KUser table and the personnel table while data modeling. The tables in the Datasources module in Kuika that start with the letter K represent the default system tables offered by Kuika. If we take a closer look at the system tables, through the system tables, information such as user name information, role information, user role mappings, Device ID information based on the user name in mobile applications, notification messages sent if notifications are used, and the status of users reading notification messages can be kept in the database.
Let's proceed by continuing from the data model title. Let's create the framework of the tables we will need within the scope of the data model.
We need a personnel table for the personnel who will request ideas within the application. In the personnel table, we need the ID of the table, the personnel registration number column, the personnel name and surname column, the personnel e-mail, the KUserID column to establish a relationship with the KUser table, the personnel image column, the Status column containing the current working status information of the personnel, a Personnel Title column containing the title information of the personnel, and the Created Date column containing the registration date of the personnel in the system in case we can use it in the future. In addition to these columns, a staff Department column is needed to keep the department information of the staff. However, associating this column with a Department table we will create will produce healthier results.
Therefore, it will be necessary to create a Department table with a table ID and Department Name information.
Another table we need under the data model heading is the Idea table. Under this table, we need the ID that the table has, the Idea Owner column associated with the personnel table, the idea description column that contains the idea descriptions, and the Created Date column to keep the date when the ideas were added. In addition, the IdeaLike column containing the vote information of the idea is needed. Associating this column with a table containing the voting information of the ideas will enable us to build a healthier structure. Therefore, it is necessary to create an IdeaLike table. For the IdeaLike table, we need the Id column of the table, an IdeaId column associated with the IdeaTable, a PersonnelId column to associate personnel with the votes of ideas, and a Created Date column to keep the date information on the date when the votes are added ready to be used in a scenario that may need to be used.
In the following sections of the analysis document
By developing the application in a fast and flexible way, the process of visibility, voting, and realization of employees' ideas will be supported, thereby increasing the overall performance of the company and employee satisfaction.
In the context of this sentence, the concept of a company emerged in the document. This led to the need to answer the question of whether there is one company or more than one company.
In the scenario where we will decide to proceed with a single company, there is no need to keep additional company information for the personnel, while in the scenario where more than one company is involved, the need to keep company information for the personnel will arise.
In line with the project scope, we decided that proceeding with a single company meets the project needs. In this scenario, there is no need to create a company breakdown for employees, so there is no need to keep company information in the employee table.
Let's proceed with the Scope section in the analysis document.
With our inferences from the Scope section, we can first assume that the user interfaces will be divided into two as Web and mobile. At this point, we will expect the Registration screens to be designed as both web and mobile. In the same direction, we expect the profile screen, which shows information about the logged-in user, to be designed as both web and mobile. Within the scope of the mobile application scenario, Apple Sign-in can be added to the login options of our application.
The need to make a data modeling for the Comment structure, which is a structure we encountered for the first time in the Scope section, emerged. For this, let's create the framework of a table called Idea Comment. In this table, we need an ID column for the table, an IdeaID column associated with the Idea table, a StaffID column associated with the Staff table, a CommentDescription column containing the comment text, and a Created Date column to hold the date the comments were added.
In line with what we read in the rest of the analysis document, we can think that the user can view the ideas created by the user on the user profile screen and the ideas created by other users on the Listing screens.
In the rest of the analysis document, we view the idea category field encountered while creating ideas. In this direction, we need an idea category table.
In the idea category table, we can infer that the table needs an ID column and a CategoryName column.
After we prepare the idea category table, we will need to add a category column to the idea table that we have previously scoped, and we will need to associate the relevant column with the idea category table.
In the rest of the document, we see that the title of the ideas is needed. We will need to add the idea Title column to the idea table. However, to add images of the ideas, we need to add the idea image column to the idea table.
For the item in the analysis document; Ideas are sorted by popularity and relevance
In the idea listing screen, it will be necessary to show the number of likes of the ideas as well as the idea fields. Again, it will be necessary to add the sort by number of likes option to the listing screens for sorting by popularity level. Alternatively, we can add sorting by letter order to the interface.
We are also expected to create a Dashboard screen that lists the total number of ideas in the application, the number of ideas created by the logged-in user, and the latest ideas.
We have done the analysis reading of the items presented in Phase 1. We will discuss the analysis reading of the topics covered in Phase 2 in detail in our Builder 2 curriculum.
We evaluated the topics covered in Phase 1 in detail from a Builder/developer perspective. We will continue the development process for the screens created from a design perspective in the Designer 1 curriculum and technically verify this learning content in the continuation of this curriculum.
We will advance the workflow processes discussed as Phase 2 in the Builder 2 curriculum.
