Use Case: Low Software Maintenance
New and revised technology requires software revisions to match them, but MAE isolates various technologies into different components and abstracts them for your applications. By using MAE, your software maintenance is limited to functional bug fixes, not technology mismatches.
Your development team has deep accumulated technical debt because technology upgrades require recoding.
In each of the above cases you are faced with a development task that doesn't add new functionality, but just lets you keep up with the latest technology change. How do you substantially reduce your development maintenance load?
MAE was designed to separate types of technology, but make them readily available to the applications that needed them. An interface is defined between the technology and the app. If the technology changes, the separate technology piece is the only software requiring change - the apps remain unchanged because they continue to use the existing interface.
In addition to MAE reducing/eliminating software maintenance, you can extend the paradigm further: when you need to use more technology that is evolving, you can isolate that technology into your own MAE component for your apps to interface with; any revisions to that technology will only require software updates to your MAE component for that technology; your apps can remain unchanged.
After migrating your software to MAE, your development team will spend more time on new features rather than a backlog maintenance updates.
Does this solution look like a fit for your organization? Reach out to HanoverSoft at +1 (919) 270-6712 or info@hanoversoft.net to discuss.
Before writing your software, collect your requirements ahead of time to ensure you don't find out about new requirements when you're almost done.
The requirements can be broken down into use cases. Those use cases inform the test plan.
Before undertaking your development endeavor, it is wise to devise a plan. What needs to be developed? What resources (people, time, assets) will be needed? What is the timeline for how the project progresses? What can be done simultaneously versus what depends upon other prior step completion?
When you create the screen layout, you provide users with clear input controls and display organization. You can take advantage of UI controls such as buttons, pull-downs, click hotspots, data uploads, collapsable regions, and links to other web-accessible resources. UI controls are typically displayed as a group; when using UI controls, you will need to ensure all inputs are answered (as input validation) before taking action when the user clicks on a button to process the inputs; also keep in mind that values for inputs arrive asynchronously, so an input at the bottom of the form may be answered before an input at the top; if you need to control that flow, then don't display inputs until you're ready for the user to respond to them.
Note that you can use UI records to great effect: Each record can have empty, named regions which may in turn be used to display another UI record. And when a parent record is cleared from the display, all sub-records are cleared as well. This unleashes the power of the single page app; you don't need to keep switching web pages when you can update regions of your starting page so easily.
From the use cases, you create the test plan. Determine critical paths through the program to cover each use case. Make sure your test plan includes each new critical path in your new MAE app.
You will need your single page app's start page with the filename /usr/mae/html/channel.html. The channel name appears in the URL and is often the name for the app.
For sub-page content that will end up in /usr/mae/html/record/, create .ui files which readily convert to .html files using genmae. When our .ui file includes user controls that send messages back to your app, genmae will generate the appropriate HTML and ensure the message is received and your app's callback is called; otherwise, it could be ignored.
If you have any static images, you can store them in the ImageLib database table or put them in /usr/mae/html/images. For sub-page HTML content that refers to images in the filesystem, consider the URL document root to start at /usr/mae/html. Use the ImageLib class to reference the image, pull it into the Image class, and render it using the UserDevice class.
Given all your assessment, planning, and design, develop your software for MAE. See Developing a New App.
You will need documentation and training for your users.
If you choose to make your documentation web-accessible, consider creating wiki pages in /usr/mae/html/doc/ which can be converted to HTML (a future release will allow conversion to PDF and possibly other formats), which can be displayed to the user. See Simple Text Formatting to review wiki formatting; see wiki2doc for details about conversion to HTML or other formats.
MAE is not limited to applications with user interfaces; there are many non-UI uses for it as well, such as IoT Data Collection, Log Data Collection, REST API server, and much more.