Application Design Guidelines Follow
This document will go through best practices and guidelines that will help you plan and develop applications using AuraPlayer.
Define your application user experience
When you start designing your AuraPlayer application keep in mind that you are planning a new application, designed for a mobile, tablet or desktop. Today’s UI concepts are much simpler than they used to be when your legacy application was developed. Thus, your new application should not look like your legacy application.
- Define the pages, fields and flows of your application. It is better to start recording the services after you define the flows, and know how your application looks like and which data and field is presented on which condition.
- Decide what is the target device for your application - in most cases it is mobile. However, it can be a tablet, a desktop or a combination.
- Plan for the smallest screen “real estate”. AuraPlayer pages are responsive to the page size. Thus, you should plan for the smallest, and the pages will adjust to bigger screens automatically.
- Plan for simple flows - as explained earlier, the concept of application user experience has changed significantly in the past 20 years - Today applications are built simpler with very focused flows. So, just “copy” the flow from your legacy application will not do the job. Therefore, try to make it simpler than the original. Here are just a few considerations for you to think of:
1. Consider including only the necessary flows in your new application. You may not need to include all flows that appear in your legacy application.
2. Consider building separate and focused flows starting from the hamburger menu.
3. Consider combining fields that appear in different tabs, in the original application, into one page.
4. In many cases, your original application has many tabs with many fields in each of these tabs. You may decide to include only a few fields in one single page in your new application, because it will be simpler for your users.
Define the required services
- Decide on the required services - you do not necessarily start with all services. Just pick the first and/or second flows and decide which services are needed for these flows and what their input/output is.
- Decide whether your service should be full or partial service. Full services on the one hand are more stable, as they always start from the login. But on the other hand you may decide to plan for partial service as well according to your application performance and behaviour.
- Consider using DB services for simple data retrieval. Bringing a list of values (LOV) that do not depend on other LOV selection, and do not include any business logic is a good example for using DB services.
- AuraPlayer service can return output of one table only. If you need to present more than one table, plan for several services for each table separately.
- While you may have security and SSO requirements (as you can see in the next section) the SSO and authentication usually comes at a later stage. So, plan your login page ignoring the final authentication method. This way you’ll be able to start developing your application early. You can always replace the login at a later stage.
Security and Authentication and Single-Sign-On (SSO)
In many cases, the application is using the credentials of your underlying application. So, in such a case you will use your login service and other services by using your standard credentials. But you may need to consider the following as well:
- Authentication using SSO - You may have a requirement to use your organization SSO tool, such as LDAP, Okta, Azure, Amazon, etc. AuraPlayer integrates with any of these tools.
- Captcha - Your application may require to support Captcha in order to confirm a human is working with your application and it is not exposed to DDoS attacks. AuraPlayer integrates with any captcha service. You can see here an example of using google Captcha.
- CSP - CSP is a policy to prevent cross site scripting, and code injection attacks. AuraPlayer Visuzlier supports CSP. So, any application which you develop using the Visualizer is secured. But your own additional code may not be secured. Set the system property APPS_CSP_HEADER = true. It will tell the browser to check and alert for any CSP error. Thus your own additional code will be tested by the browser automatically.