Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
With the OpenEdge Advanced GUI right around the corner (well, coming soon anyway), I thought that it was appropriate to start a discussion on one of those four application pillars - Features. As you may recall, I defined features as those characteristics of the software that aid in usability but are not domain specific. Most features are somehow related to user interfaces - navigation systems, look-up systems, sizing attributes, etc. But there are others: Reporting, security and access, personalization and customization methods, etc. For this discussion, I'll concentrate primarily on the user interface features.
There are a number of subjects that we need to cover in here, so I will likely spin these out through multiple blog entries. And if anyone else has ideas or questions, we can weave them through the process. Here's the most important place to start: To be effective, any feature that you put in your software must meet these rules:
With those rules firmly in mind, let's look at how to think about and design features for your application. It's tempting to jump right in to the particulars of a given feature or a given UI, but here's something I learned many years ago:
There's an important idea buried in that statement. For functionality, we tend to look to customers, domain experts, and direct industry competitors. For features, we should look at prospects and the wider software industry. The applications that we tend to build don't directly compete with Outlook, but we will compete with Outlook for the perception of our software in the user's eyes.
This makes it more difficult to design and implement good application-wide features. We're out of our comfort zone. So here's a method for prototyping and implementing features that I learned many years ago:
Those last points may seem a little harsh, but inconsistency inevitably leads to application degradation. And none of us want that.
That's enough for this first posting on features. We'll follow it up by getting in to the various types of features and how to think about each as you use the new Advanced GUI to build a new application or freshen up your current application.
View all posts from Niel Powers on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.