In this second post of my blog series about Design Considerations When Building Cross Platform Applications, I’m focusing on what most people typically consider the only design consideration: Visual Design and User Experience. Usually when a product company is beginning to plan out a new product, the team goes through phases during which they start to innovate and scrutinize the idea, followed quickly by a design and/or prototype phase. This period is the starting point because it is really what helps the product managers – and in the long run the customers – visualize the product’s potential and how a user may use it. Some of the factors that are taken into account during this time period are the overall cosmetic design (including product consistency, simplicity and customization) and user interaction flow. While the designer begins to dig into the idea to put some parameters around the product, he must consider the company’s logos and colors as well as its current and future product suite. It is very important that each application delivered by the product company has a similar look to it so the user feels that consistency across all products in the suite.
In my experience at SuperConnect thus far, this approach rings true. We began our company with one designer and have been lucky enough to work with several others over our short lifespan. The result was initially a collection of various design approaches starting with a more web-centric design on a mobile device and evolving to the very clean and concise design we now use in our products. We see the consistency that a full-time designer and thought leader can provide to a suite of products that are meant to drive enterprise mobility. The catch, as there is always a catch, is that while our products may reflect the comprehensive and hard work of our team, customers still want to make their mark when deploying applications to the enterprise. To help our customers use SuperConnect products in a way that will accommodate and enhance their own brands, we have taken the approach of the 80/20 rule. We’ve built strict templates within our applications that guide the customer’s administrators to follow our designer’s ideas and plans, but still provide a bit of customization. One example lies in our Connections application where we provide a unique look at the employee directory by allowing the customer to specify what data is displayed in the application. Our design provides an interface where the administrator can customize which data fields are displayed within different areas of the application based on specific templates that were defined by the designers. In the end, our design remains intact because we don’t allow the customization of font (color, size or type), the layout of the fields themselves or the locations of images within the app. However we do allow the administrator to choose which data field should be displayed in the various locations on those templates. (See image below for a layout example.)
The application field customization is clearly defined within our online interface, but the mystery, or special sauce if you will, lies in how we can provide such a mechanism and port it across the Android, iOS and Mobile Web (mWeb) platforms. We created an architectural approach to provide all of the necessary data to the rendering engine on each of the platforms to display the user interface elements that the administrator has defined for their organization’s roll out of Connections. Our design uses a simple grid-like mapping to span across all devices, but it can be applied in a native-like manner. In Android and iOS, we use the respective interface designers to provide generic rows and columns to define how the interface could be laid out. For mWeb, we use a combination of <DIV> tags and CSS to render the optimal design for the various mobile web browsers on the market today. Our application then utilizes a set of metadata tables to define where data fields will reside within those grids based on how the administrator has mapped data fields to application fields, and then to the user interface templates.
One of the key takeaways that came from how we defined the solution for user interface customization was limiting it to very specific parameters. We could have chosen to allow administrators to define the styles, colors, fonts, etc. of all data elements in the application, but doing so could negatively impact the average user’s opinion of Connections, and potentially of the full SuperConnect product suite, if the design doesn’t appeal to him. In the end, the visual design of an application is likely to draw a user back to the application time and time again. Our goal is to provide the customer a bit of their own branded look and feel while not losing the appealing elements created through our designers’ hard work. If an end-user were to dislike our applications due to the design, he may be less likely to come back and use them again in the future. Because our application may not be viewed as “critical” as it doesn’t provide services like banking, trading or health care where users often stick with a product out of necessity, we must have an experience that the user wants to keep coming back to. After all, a user at one of our customers today may be a decision maker at a future potential customer.
Stay tuned for my next post on Design Considerations where I’ll talk about application architecture.