- Data congestion in the textual UI can be a productivity killer for the software developer (with size limits in the number of characters that will fit). This is because a significant percentage of new application enhancements are being made in mature applications where screen real estate is tight.
- One of the contributors to this result is a design thought that productivity increases when there are less screen navigation steps. This is a traditional truth that still applies, even including browser apps, although less so with speedy client-server apps (especially those with ease of use for layering windows). Another contributor is that many companies suffer from a handfull of small roadblocks that end up requiring developers to pursue less productive work arounds or compromises. Make sure your company isn't one of these or give us an opportunity to discuss this with you. Here are a few initial suggestions and concepts.
- Watch out for restrictions placed on the client UI by desktop admins who don't use the application
- Insure use of a UI design pallette (and that a source code-mod marking standard does not inhibit or prohibit use)
- Revisit the widescreen format and see if your current client software and monitor combinations provide a reasonable result. If so, transition to the new format could be a great medium-term productivity gain with excellent ROI.
- Tangent: If your current client of choice does not have ease of access to PC desktop applications or web services, start keeping track of enhancements that have been derailed or whittled down based on this lack of access (along with time spent)
- Automating build steps - Strategy, tools and/or preferred supplier recommendations
- Make sure delivery of a database change does not require a lot of manual developer work. While manual work can be justified in some cases, RPG application and Db2 data integrity is marbled into the equation on this platform, so this topic needs more depth, stay tuned for more info...
- Here, a suggestion to extend your business application environment to include browser-based (zero footprint) applications for external users without sacrificing UI and DB integration, developer productivity or requiring a comprehensive revamp of existing application architecture
- Consider the likelihood that web application development techniques and capabilities are typically more rudimentary than client-server, even though web applications are the latest thing
- Consider the possibility that there is ongoing promotion of development methods and strategies out in the marketplace that aren't as productive as what you currently have in place
- Seek an IDE that offers a design pallete for the UI
- Consider the significant differences in application and UI layout and flow justified for (non-employee) browser-based users (as opposed to internal applications). The layout of the application for external / browser / casual users must be as simple as possible so that it can be completely self-service and as intuitive as possible. This is most often a totally different equation than that used for internal applications.
- Similarly, be careful when dismissing a productive internal application as obsolete for purposes of evaluating application flow. The guts of the application is a different story but maybe this means that you might first want to build (a smaller) something new in the way it makes most sense for your business and technology mix. And only then later, to examine how your existing application layer logic was used or copied in the process.
- Seek ease of interaction with database(s) in addition to standard connection methods. This may come in the form of IO extensions, such as use of a data structure based on a table column layout (or database file record format). Sometimes this is in the form of an automated copy, like a wizard creating a data set in Visual Studio based on a SQL Server definition. Sometimes it is created via compile-time instance with references specified in source code as in DDS and RPG. And let's not forget that most RPG languages offer RLA (record-level access) and an open data path (ODP) that combine to offer something with a lot more capabilities than a SQL cursor (albeit a lot more proprietary).
- Consider whether you want a development environment that offers snap-in GUI controls (or at least pre-defined ways to specify textual UI data elements) and ability to interact with user data in the programming language out of the box (IO extensions for ease of interaction with the UI). Or whether it makes sense to build your own UI controller that orchestrates
the interaction between layers of your architecture, so that you can be in position to build something that interacts more fluidly with current but rudimentary architectures or with new UI frameworks that are introduced in the future.
- Identify applications really benefiting from browser access and then identify shared foundation components amongst those applications that have an identifiable ROI. Examples of shared foundation components (in a rich programming environment) might be permissions handling and navigation. Build a simple version of these either first or concurrently with the first application chosen (with identifiable ROI). Unfortunately or fortunately, a public audience is quite different than an internal employee audience or a supplier/distributor/partner audience. What this often means is that you have a lot of internal business processes that won't be needed or that will barely resemble (inside or out) something that is built for a casual web user or business partner. Thus, if you don't need to re-use it in the near future, don't spend time and money reorganizing it yet.
- What are good projects to consider first?
- customer service information such as product documentation or orders, open or history (registration might be involved)
- information for sales reps and employees out in the field (html5 capable, tablet-sized on up)
- those benefiting from simple graphs, which can be displayed without 3rd party controls with .NET Framework 3.0 and beyond
- Inquiry and/or Reports in general
- part or all of the browser display can be sized (scaled) at time of printing by the user
- by eliminating the DB update requirement, many challenges are reduced, eliminated or postponed including:
- record locking strategies (concurrency decisions, goals, logistics)
- sizing (or max size) of data elements
- since prevalent access is via SQL techniques and stored procedures, this may be the first instance that the technical staff has to live without RLA (record-level access), thus an inquiry and/or report is an opportunity to get started on something that isn't mission-critical
- Second?
- free-range warehouse activities such as those tracking inventory movement (and enabling use of standard wireless and error (in data stream transmission) detection technologies)
- DDS versus DDL... What does a conversion buy you? When do you really need it? What capabilities will you be giving up or have to find a way to do differently? What kind of things can you do now while you are still using DDS? Answer: variable-length, null-capable data types, extended field/column names using the alias attribute... What can't you do? Db2 for i Row & Column Access Control, Db2 for i Temporal Tables although there is somewhat of a work-around
- The latest RPG programming languages, IBM's free-format is finally fully-baked! Use a conversion utility please LOL
- Please don't use the default RPG/400 to RPG ILE Source Code Syntax Conversion method...
- Examine Linoma's RPG Toolbox instead. Really. Not only does it do conversion to RPG/free from either version and back but it has actual translation options that modernize code. With our apologies to your in-house development staff, please don't let them "save you money" on this one!
- Repackaging of background service type functions into web services
- Piping of your Db2 on i data directly into .net .aspx web pages along with formatting but without programming (including how to display fixed length character fields in dynamically sized columns).
- When might a new, non-zero footprint desktop client be exactly what is needed?
- When the new things you want to do with your 5250 application require interaction with other data elements or feeds already available to/at the PC desktop (level) (OS, permissions or connectivity etc.)
- When you already control the desktop of the user audience
- When it works with or without the application source code
- When it expertly and dynamically transforms textual user interface elements to real event-driven GUI controls
- When it reduces complexity when needing to integrate or interact with other facets of the desktop or network
- When you want to hide or automate cumbersome or repetitive screen navigation through the use of client-side java or vb script, such as when needing to go through a number of steps to switch session companies
- When it secures communications without extra purchases or much work at all
- When it provides a wizard for deploying and updating the GUI handling rules on the PC client in controlled desktop environments
- When it allows customization by adding controls, forms and layouts in high impact areas
- When most of the application is pretty dang great as it sits
- When it participates in the creation of composite applications using also data retrieved from direct database access and web services
|