UI first
Starting new apps from UI
Starting from 2015, my team partners and I always focused to the UI first. We delivered the apps within shorted time and never failed. How it works?
After listening to the client with their idea of how the app should work. We asked the most important question: How should it look like.
Note that there are like million apps on Appstore and PlayStore. When the clients have the business idea, they are more or less visualizing it with similar apps. The question “how it looks like” will drive them back to picture it in mind.
The answer will be like: “the login part is like Google +”, “the posting part is like FB”, “the display part is like …”.
From there, we can work out the idea of how the business likes. It would be in the line of advertising; or in the line of social media … It is 80% on this and 20% on that.
Lets check the real cases.
Case 1:
The client came with an idea of building a world where people can share, like, re-load other posts, list and sell their items among their circles using the credit points that can be traded with real money.
How should it look like? We asked. The answers eventually leaded to somethings like 70% of FB, 10% of G+, 50% of Ebay and 30% of Bitcoint.
Here is the steps we do in our team:
1- We put the above apps together in a table.
2- We break the apps in many components. * Component, not features.
3- We match the components with the apps.
4- We put the components in the new app.
and looks like this as a sample
The table in fact is much longer. It is for the idea.
We allocated 3 developers in this app, and planed it for 2 sprints -4 weeks- . Why only 3? We already built many reusable components. We just worked on the portion of adjustment to match with new app.
Why need 3? We always have 2 developers in same task, the main developer can do up to 90% of the work, the pair developer will do only 10%. This helps that this developer will know what he participated, and can take over when needed.
Why the 3rd person? often he is the PM, who will participate and anticipate for the work to ensure it will be done in time. We found from experience that most developers are inward character. They dont make themselves clear in plain English. They speak programming languages. The PM in general can fill in the gap, reword it, clarify the issues and help solve the hip cut.
Why 4 week delivery? With component development approach. We reuse the components and form the app by lego-put them together. The new app will form by many components with certain changes only. Lets look at the table again before we go to next discussion.
You can use 1 developer to do the new app. It is your call. We just share our experience and approach. It works with us.
Lest go backward to the protocol, server, database and hosting.
Why backward? We dont define data table, api yet. We work them out from the UI.
Lets pick the Remote authentication component. User must input user name and password? We have 2 visible fields, 1 hidden token field and an Rest API Encrypted POST call, that should return something from server. If it fails, then we must go to forgot password or register new user.
The user registration screen will have username, email, password, address, and later bank account, credit card etc for buying/selling items and trading credit/coint. From there we can define our Rest server and data table.
For the hosting, we know this app will have multi users and parallel processing as well as real time transaction. We just need to work out what database support parallel processing. No SAP, no Progress as they are sequential. Perhaps MySQL or MondoDB?
The Hosting system must have load balancing and auto scaling? AWS have both, Azure has LB only. Perhaps AWS?
Case 2:
The client want to have an app that allow carer logins, checks in, picks+locks a job, starts timer, stops timer, does feedback, reports issues, gets patient signed off the job, gets patient rate the performance satisfaction …
Mind you, we never ask “how it works?”. We dont want to understand the business behind, we will never do as much as the client wanted us to. We go to our technique. We asked: “How should it look like?”.
It is 40% of FB, 10% of G+, 60% of carer app …With the client help, we worked out together that the app will have screen with username and password or faceid/finger print login/checkin. A screen of listing jobs that user can pick … we did a few mockup screens with wireframe app. We use the table looks like this
In 4 weeks, we presented to the client a working prototype with dummy data. After made few changes as the client request, after 8 weeks, we presented a working app with real data from a nodejs server with mongoDB. The Rest APIs are derived from the UI working backward. The json database is formed from the data sending to the Rest server. We worked backward from UI here.
It might be worth to explain again. If we dont go from the UI, we will need a long time to understand the client requirement and the business. The fact is, to be able to go to the idea of the app, the client have been in the business for many years. That is why in the old day, developers take real long time to develop a system since they must understand the business idea, then go to do the data tables first, then server, then protocol and finally the UI.
We are in modern time, we dont have to know the business, we just need to know how it looks to the user. We do the UI first, then derive the protocol of what to send and receive to/from server, then form json data tables thru the Rest channel.
The rest server and Json database are portable, we just simply deploy them in the client’s hosting server at later stage.
Currently, we use Fastlane to test and deploy our Android and IOS apps. We use Lighthouse with the Webapp. We use SourceTree as client, server with Bitbucket with pipelines/bamboo for CI/CD. We use Firebase for the Notification and Enterprise deployment. We use Agile and Jira for our team. The bosses might decide to change any or all them later, then we change. The technology is changing anyway.
