Spanos Group iOS Application

Introduction

Since the launch of the App Store in 2008 and the increase in use of smartphones, most users around the world have been adapting to using Mobile applications more and more on a daily basis. In certain cases mobile application replace websites, for retrieving information or communication purposes.

Requirements

The management team of Spanos Group, wanted to find a new way of communicating with our customers (both new and existing). We decided that a mobile application would provide our customers with a immediate way of discovering our products, manage the products in their fleet and communicate with us. We wanted to approach the creation of a mobile application as an experiment, so we decided to create the initial version in-house and not hire an external agency. The initial version would be enough for us to get valuable feedback on its usage by our users and understand their needs better, allowing us to create the blueprint for a proper MVP (Minimum Viable Product) that could outsourced if needed be.

Mobile Application Features

The mobile application would have four basic sections of functionality:

• a product catalog section, showcasing the machinery that Spanos Group produces in house,
• a section where the user can read our news and be alerted of any urgent announcement (either service bulletin or other important type of news ),
• a user section that would serve as a user dashboard, allowing the customer easy access to their owned machinery and
• a messaging portal that users could interact with either our sales or our service department, allowing both sides to communicate efficiently and effectively.

The last two features would allow us to record and leverage critical information on our Enterprise Resource Planning and Customer Relationship Management systems, enabling us to potentially re-engineer a part of our internal sales and service processes. The major benefit of investing valuable resources to such a project, that is not part of the organisations' core business, is to provide an opportunity to re-think and re-design how certain things are done internally, giving the organisation the opportunity to provide a better value to its customers.

The features would be rolled our progressively and not all at the same time, in order to be able to monitor the response and allow us to develop the features properly and not ship them hastily.

Plans for Android?

We wanted to publish the application on the Apple platform, primarily because of my personal knowledge of the development process of iOS native applications. Being the developer and designer of the application, I would be responsible of creating the blueprint for what the MVP would be, so when the time came to find an Android developer, we could easily communicate our needs and optimise the software development process. Mobile applications, as most software systems, take a long amount of time to create primarily because of their inherrent complexities. Having that in mind, we wanted to start small and take incremental steps to reach our goal. We set a timetable that would work for us and starting designing the application, a step that is almost 100% applicable to both platforms.

Backend and Management Interface

Based on the requirement we set, we knew that we needed a backend server that would sit between our internal systems and our users. We wanted our customers to be able to create a profile, or log in to their profile based on the credentials they had already, send us small or large messages, view our communication history, view their fleet of machinery, etc. This meant that we needed a system to securely manage communication between our users and our internal systems.

We decided to go with a Ruby On Rails API, with a PostgreSQL database, hosted on Heroku, for reasons of cost and practicallity. Since this was going to be a small scale progressive deployment we didn't need to worry about increased traffic or maintaing another infrastructure stack. Again, in this case, the decision to go with Ruby On Rails was made for both reasons of familiarity with the platform as well as actual requirement fulfilment.

In order to allow our internal teams to manage the content that would be pushed to our mobile applications (such as news or push notifications of any kind), we needed to build an web application (or management interface) that would allow us to do so. Since the Ruby on Rails application was running on API mode, I decided to go with a VueJS Single Page Application that would communicate with the RoR API. VueJS is an emerging and very easy platform to pick up, even for junior JS developers, thus allowing us to outsource it in the future if we ever needed. The development time was very small too, making this a project that could very easily be replaced by an application based on React or any type of framework we thought was necessary.

The management interface is a very simple application, allowing the user to log in, create, view, update and delete news items in its first iteration. The application host we selected was Netlify, because of their great pricing (especially their free tier, something that covered our current needs perfectly).

Design

I started designing the application using Sketch and Affinity Designer from the ground up. We decide to design as much of the iconography of the application as possible, to carry on our visual design aspect from our website to the mobile platforms. The initial icons were very basic but servicable, at that would be something that could be impoved in future iterations.

All the screens of the first version were designed from scratch, keeping in mind that we were designing for both platforms. Most of the times the design that you see in an application like Sketch doesn't match the implemented design on the device, but in our case, because of our very minimal design aesthetic, we were able to transfer the design to the device almost entirely.

You can see the end result of the finished in the following images:

Application Status

We are currently in testing and redesigning the application to meet with Apple's new guidelines in order to proceed with publishing the initial version. The backend is actively being developed as well and the management interface is currently re-developed in React.