It was April and we were hired to work in EntrenaPro, a mobile App for iOS and Android where Coaches and Athletes can schedule individual and public sports sessions between more than 40 activities all over Spain.
Going out of a local concert I received a message from my colleague Ahmed, responsible for Mobile development (he loves working until very late night while risking my human relations at equal parts). He had just found the perfect way to get our App done in the tight schedule, and it was called Flutter (Google's new framework to build native apps and be a serious competitor to Facebook's React Native).
We faced that interesting moment (a.k.a. a bit nightmare for you, if you play to be a CTO who cannot write a line of code) in any project where you need to decide which technology will be used. Flutter seemed incredible but we found only two full apps published.
Hello Flutter, nice to meet you.
We found only two full Flutter Apps published when we began. One of them was "Gallery", launched by Google as a visual showcase with no real functions.
When you manage a project and you need to choose between powerful program languages which could bring the same meaning for the user, logic tells you should pick up the more mature one, the one where you find more developers and the one where your team has more experience. When you know this, and you still prefer to choose a brand new technology your team wants to learn to see how far we can go, you can either be a bit crazy or count on someone like Ahmed on the mobile side to challenge logic. And when you know developers like him since many years, you've learnt being crazy is not the same as being responsible and research any corner in the web to find the solution to anticipate the problem that we still don't have, and he'll ask the whole community or even Flutter core about some bugs on its framework.
Being a kamikaze is not the same as being a commander like Hannibal, who said around 218 BC fighting against Rome same as Ahmed could have told me a few months ago while fluttering against the clock.
"We will either find a way or make one". Commander Hannibal 218 B.C.
Here is how everything begins and how we built what I consider the coolest App in flutter.
When we began to draw the App, we read so many articles and comparisons between Google Flutter Apps and Facebook React Native Apps. I found that community talked so sure about is the progress in 2018, but also pending on some good samples.
At that moment, the best sample of Flutter we saw for a whole App was Hamilton Musical. It is cool enough to see accurate information about this show. It includes some text posts, trivia, and even karaoke sliding text, but our need was totally different.
Counting on a team of so passionate, resolute and shocking developers this would sound claim enough to go for a new App, and more than the tight schedule we have, assuming the risks and all our mistakes, I think today we would choose Flutter again to develop an App like ours, and definitely I would choose the same team to do it, and here how we did it.
1. User Experience through mockups
Above this lines we show some of the mockups we built after collecting all the required and validate them with stakeholders. We used Balsamiq to draw low-fidelity mockups on our screens. They should show every aspect of the App, including:
- Two very different roles (Athletes and Coaches) with different options, payments, side menus, and features.
- Geolocated searches for Coaches and Athletes.
- General view for scheduled sports sessions categorized by pending, accepted and cancelled.
- Stripe Connect integration to let every Athlete pay sessions to coach by Credit Card.
- Stripe integration to let Coach pays a subscription to EntrenaPro.
- Sports bonus sold by Coaches where a number of tickets ready to be ticked after any session.
- Real-time updates and notifications for new Session Requests, Acceptance, Cancellations, Payments...
- Calendar picking to filter available time for any professional.
- Rating system with 5-stars, comments and replies
- SuperAdmin Panel to manage dynamic content and posts inside the app, and to check any interaction between roles, payments, and sessions.
2. User Interface design for the App.
Drawing or re-drawing an App is always a challenge for a UX Designer, but I’m happy we began so early testing with users to realise how easy or difficult when using the APP for them. As we have two roles we needed to check everything from the perspective of a person who wants to practise sport in his city (we’ll call him Athlete) and from the person who offers his services as a professional in training, charging athletes per hour (here is the Coach).
So, we are having one App which will depending on your role you will use in one or another way, but when the goal will be finally to agree on a sport session for one specific day and one specific place.
If we dive into details, we could say, every role can do this with EntrenaPro
So let’s start the party.
In terms of UI, working with some elements we designed from scratch gave us a unique touch (a.k.a. a lot of headaches) for the buttons, icons and fields, and we needed to understand Flutter perfectly if we wanted to make it works.
Sketch is the software chosen to give our app the face we desired, and I it gets on well with the Mobile developing team, so their work adapting the UI was superb.
When your colleagues understand the design standards, being ultra-picky makes no sense in terms of slowing a natural progress, (just because the button you want is cherry tomato red instead of Raff Tomato red), specially when sometimes after tests, what user rates best of a design is nice to their eyes and it helps to make the App works good. And by the way, you ask them at the end of the test "Did you see how cool the red button was?" and they reply “Is a tricky question, eh!... there was not any red button, right?”
Here is the sample of how Mobile team adapted the sketch buttons from the sketch mockup (left screenshot) to a real mobile (iOS screenshot at the right)
While using Flutter, the good thing is creating the interface for both devices iOS and Android can be very fast. After adjusting a whole UI with nearly 50 screens, I’m sure mobile team enjoyed we dared him with non-conventional gradient buttons, dropdowns and walkthrough, but I may confess we all would have got more hours of sleeping if we have used more native resources or elements from the shy but interesting flutter gallery.
Recommended by LinkedIn
3. Developing the API
Guys of backend have done a titanic work getting everything working in a complex environment with
APP – REST API - SUPERADMIN PANEL - COACH ADMIN PANEL
To build the soul of EntrenaPro we chose our old friend Laravel, a php-based framework which should be strong enough for our scalable number of users.
We knew to build a Coach Admin Panel which could feed the App in the same way the own App would do it could give us some extra fun (a.k.a. hours of debugging), but considering the strength of php and the reputed skills of the backend team (with the magic of Ahsan, Danyal, Kashif and Van), let's say an error that can be solved in less than an hour, is not an error.
Anyway, every feature should work in the proper way, and if it is well done it is well done, said my old friend Nestor once when talking about code, not about burgers, and when I told this awesome CTO I admire about what we were using, he meant the size of the project should be more than enough to run perfectly with php.
5. Integrating the API
I won’t believe anymore in Robocop or Frankenstein as something remotely possible and I’ll dam every crazy doctor who just plugs some cables and chips to make a humachine (half human half machine) from scratch, and minutes later it stands ups and walks.
How easy it is in the movies to integrate it all, uh?
While backend team were getting API works better and better, and the empty builds showed a fast and smooth flow you simply love life.
You want to believe both API and App will be joined as two small magnet does in a squared centimetre.
As easy as a glove joins your hand, as easy as abc, as easy… enough. So easy.
And then the integration begins, and maybe you didn’t explain as clear as you thought some features of your mockup, and maybe others functions were not that small, and maybe that simple Spanish word you added there made all think that was a static line, not dynamic… and then Robocop stands up and walks like a just born giraffe not as Ussain Bolt.
But once more, we will find the way. So thanks to guys' attitude and long nights in front of a screen, teams got functions to begin to work as expected, and what we see now as a single process where user create sessions, evolves a complex architecture of instructions to consider this role should see this but that role cannot, this user may be invited to practice yoga for free in a park, but not that one who joined the free session yesterday… and as you get to explain yourself better, Robocop begins to move a finger, and then a hand, and then an arm. And you blame yourself to have stopped loving life for some days. (I should blame myself to have done it for any minute even if Robocop explodes, as there will always be alternatives, like there will always be Robocop 2, Robocop 3, Robocop vs Predator, etc…)
Here I present a couple of videos with some of the features we integrated in the APP;
This is how it only takes 30 seconds for a Coach to invite an Athlete for a Yoga session in Madrid.
And here how a Coach creates a Public session to invite anyone to practice pilates in Barcelona tomorrow.
As we built our own calendar with schedule, and we added a multi-week system to let him requests the session up to 5 times.
5. Launching the Beta version
As the non-CTO I am, I should assume I made a million of errors, and as my good friend Rodelgo reminds me:
"It’s not about what you don’t know, man, what knocks you is what you don’t know you don’t know"
Some important decisions a normal CTO should have taken in minutes took me hours and my lack of knowledge in the technical side remains too many times in important decisions you shouldn’t have transmitted to the team. More than being sure or not, it’s about letting others know you have explored the possibilities and you have chosen what you consider the best one. In my position, I saw myself asking my team which ones were the possibilities, and that is not fair.
Once more, I think everyone in the technical side gave his 200% here to get this car runs along the right highway, and the most important, to show there was someone driving.
We're lucky we got our initial version of builds in Android and iOS approved at the first time. And we were a bit less luckier Apple has launched two new phones, so we need to prepare again another 20 screenshots to be used in the Apple Store for new iPhone Xs and 8s, but anyway those are good news. As the App is being used by real users at this moment, we’re getting their answer in a real environment, and the debugging process will be done within next weeks. So we should pay special attention to server answer, to API interaction with a considerable number of real sessions, and to Stripe Connect behavour. And specially, to users, hearing their impressions and feedback. In this sense I am so lucky to count on Johan Barrios to help at these analysis stage.
It will make us so happy if you also download the app and you want to give us any comment to uxdesign@iamperi.com, whatever you like or you don't like about the App.
Pedro Moreno · UX Design · www.iamperi.com