In this post we will talk about the problems related to new tools migrations, and how Oracle APEX could help us in this process. Particularly, we will explore the process of information migration from an Excel to an APEX interactive web application.
Our tools are becoming obsolete. What could we do to fix this situation?
Frequently, clients or employees ask themselves why a company is using obsolete or inefficient tools. Sometimes, this could be produced by a lack of knowledge on possible alternatives to our current tools, but usually this is produced due to companies don’t want (or don’t know how to) deal with a process: migration.
Reasons for that are diverse, but the cause is repeated in most cases is the learning curve of these new tools: Both to adapt to the company needs, and to teach users how to use it.
How we could facilitate users the learning of a new tool?
The element that most help transition of users from one platform to another is pretty obvious, and with no doubt, is the familiarity of the new user to the application. But what is less obvious is to know what means familiarity to our users. Generally is true that keeping a similar graphic interface and workflow to the previous tool can help. Still, we are risking making the same mistakes that were happening in the previous tool, and that we are trying to fix with a new solution.
At this point, is important to investigate most common tools on market, in order to know what tools could our user know. Even if these tools may have a different functionality than our tool, is important to see how they deal with edition and visualization of information, as well with the navigation, since these elements usually are common to most applications. The main idea is not to repeat same ideas, but to know what other tools the user may be using as well.
Oracle APEX tools to help with migration process
In other post we have seen how to adapt the “Productivity Apps” to our needs. Now, the question we want to give answer is: How well does APEX adapt to our needs? We will give answer to this question with a practical example: A migration from an Excel file (the process would be similar for a JSON export from a DB), to a web application, where several users will be able to work concurrently.
For this example, at the time of creating the application, we will choose the option “From file”.
After loading the file, the program will show us following screen:
Here we can choose if we wish to create a new table on DB (as we can see APEX detects automatically the name of columns reading the name of Excel headers), or to store date on an existing table. In our case, since we are creating the applciation from scratch, we will select the first option. If we would have the information disseminated in several Excel, we could make an importation to the new table of that data later. In that case, we would be required to make a mapping of that data, where we will decide what Excel column correspond to which table column:
After loading the information, APEX detects automatically what could be the functionalities required by the type of table created, and will make a predesign of the pages which could answer to those functionalities. It will also make a list of other suggested functionalities:
Of course, we will have all the freedom to edit these pages once created. Also we can make small editions on those pages, without the need to work directly on code, from an interactive menu. For example, the edition of the “Dashboard” page would be as follows:
So, in three easy steps, we would have migrated our Excel sheet to be used as DB web-application. The final result is a friendly user interface, that looks like other web pages with similar functionalities, and that has a minimum learning curve.