Wireframing / Interface Design

So you’ve come up with an idea. You create a new Activity or Fragment, a layout, some views –similar to this other big App-, so it shouldn’t be wrong, right? Soon you realize that this approach doesn’t scale well.

What if you needed to visualize different ideas without spending time compiling? What if a product manager intends to tell you an idea? Will he code? We wouldn’t expect that from the design team either.

Wireframing is the tool that comes in handy to represent visually your app (or website). Anyone may make a low-detail representation of the intended screen and the user flow. Some say wireframing is the skeletal outline of the app, which is very accurate: You may see that most wireframes are just black lines on a white canvas. Also, this helps in getting feedback about the interface before writing a single line of code.

Most tools these days offer the collaboration feature, where interfaces can be shared across the team or also might be edited collaboratively in real time. Also these tools may vary in terms of features, some will look more like skeletons (or even like hand-written), others with high-resolution (such tools may offer also exporting resources to use right away in your project), some others may implement “click-like” features to navigate the flow as if it were an app, or maybe support large canvases to cover an entire app (navigation flow) in just one screen.

You may find some of these tools (and discipline) with different names, that may have a similar meaning: Wireframes, Mockups, Interface Design, Workflow design, UX Design or Screen Design to name a few.

Last but not least, a very and simple tool is always drawing interfaces using just pencil and paper. Before remote came in as a norm (by the way Hand-Picked was already remote before it was cool), teams used to draw interfaces on paper or whiteboards. I guess it will return in some way in the future but you can already use it by yourself if you have that task. Sometimes it’s kind of refreshing and satisfactory to see how a screen we drew on paper ended up in a final working product.

Note: In many teams the figure of a Product Manager (or Product Owners, or a mixed collaboration with designers) will be in charge of delivering Wireframes as an input for developers. Developers with wireframes and designs (if such Wireframes are low-res) would then be in charge of following that documentation. This doesn’t make this practice something exclusive to Product Managers or Designers. Be it your initiative within an existing project or you creating your own app, you will benefit from wireframing ideas before jumping in to your preferred IDE.

Note 2: Always try to make screens that have one important objective for the user. This will end up with simple to use interfaces that even our grandmas will be able to use (tech-savvy grandmas).

A/B Testing

We start getting serious, we mean business. What am I talking about? For any project, we (plus the stakeholders) will have an objective. Name it, more users, more engagement, more sales, more usage, it won’t matter if the software is for an NGO or it’s profit driven, all the endeavour will have a target to reach.

So in this process, new ideas will come up, and we will decide how to implement them. But, what if the idea has some cons that may happen to hurt the objective? Maybe we need that extra field in the registration screen for marketing purposes (so, more revenue); but will that affect Sign Ups in general with this additional nuisance? (Let’s face it, in mobile each extra field is kind of an effort for the user). How much will it hurt?

In most cases there will be no other chance to try it out (as you may have different public or business than some other studies, it won’t be enough to go and check some 3rd party stats). Here it comes, A/B Testing. This ‘technique’ allows us to release features to a subset of users before applying it to all of them. So in case we see that the feature was successful, we would have a green light to rollout it to all users. To know if it was successful we’ll need to have implemented analytics in the app, something explained next in the article.

In Android A/B Testing could be as simple as toggling features by asking for remote configurations (per user maybe). The backend code may support this or we may use Android utilities like “Firebase Remote Config” and Google Analytics for Firebase. The new Firebase A/B Testing service has it all integrated, so it is also a well suited alternative if our target phones will have all Google Apps.

There are also approaches to take in case of having a Clean Architecture, where we could switch Views the behaviour based on what we configure in Firebase Remote Configuration, which is retrieved from the FirebaseRemoteConfig class. There is a good tutorial about AB Testing in a Clean Architecture project.

Analytics

We’ve talked about A/B Testing as one of the tools to improve and make our app successful. In other cases, to have new ideas, it is precise to know where will those have the most impact. For example, knowing what are the screens or features users use more frequently. Or where users have navigation issues or slow downs.

Integrating an analytics system in the app is of utter importance to have visibility about our app performance (business-wise).

In general, the process involved in most systems is as follows:

• Setup the library for the specific analytics service
• Log events (or screens and information) in particular parts of the app that you need to measure
• Debug events and see reports. Most platforms give flexibility for reporting, even with SQL-like filters.
• Iterate with new events and continue measuring

What services options are there? Google Analytics for Firebase might be the go-to option for Android, but as Google Analytics was first made for Web, it may be missing some points. It is also said that it’s a bit slow to update. Something interesting is that it can log events but also track screens, with integration with what are screens in Android, Activities. For the moment, Google Analytics for Firebase is free without quotas nor paid tiers. Time will tell in the future.

There are also two options that try to innovate in the analytics scene, Amplitude and Mixpanel. Among so many features, both provide incredible visualizations and charts, and advanced querying capabilities.

I want to note something that is not an analytics service per se, but something to govern them all. You will find that if you need to use multiple services, you will have to have your own layer that logs events in those different services. Or at least, to be a bit agnostic of the service, you would prefer to have that layer. Additionally, it will happen that the Product team will have their requirements for analytics and from that point until having those reports in production (with your LogEvent calls in the middle) some mistakes will occur.

So there is where a tool like Avo comes forward. Avo allows Product Managers, Developers and Data Scientists to work together on the same analytics plan. Said simply, while a Product Manager may define what information they require for different events, Avo has the capability to manage ‘branches’ and generate code. Imagine a PM creating a “CONFIRM_PURCHASE” event with some info required like “DATE”, “PRODUCTS”. Well, Avo will generate the method to call: Avo.confirmPurchase(date, products), amazing uh?

Avo might look like something advanced, but it has proven to make the analytics code development easier in large multidisciplinary teams.

There is more…

This second part focused more on the business side of the project. Far from being over, the next part will go back to the code side of things when making Professional Android Apps!

Cover photo: Photo by Alvaro Reyes on Unsplash

Wireframing by hand: Photo by Kelly Sikkema on Unsplash

Have you recently managed to earn an Android Developer Certification? Or maybe just finished your first personal project? Being in charge of an Android app that has gained quite a market share? Or the team has just grown due to upcoming new features to make?

The next decisions and steps to take will have to tackle scalability and make you and your team Android Pros.

This guide is a summary of some tools and aspects the project will have to cover besides Fragments and Views.

Architecture

When an app becomes increasingly complex, with more features and aspects, making changes starts being problematic. Code duplication, newly introduced bugs, difficulty to change parts become common occurrences that hinder progress.

One of the steps for preparing for it, is establishing a good architecture, that takes into account modularity prospects of how much of a scope the project will have.

Is it a card game? Will you have to add different games afterwards? Is it a delivery app? What about adding pharmacies to it? How will you attach prescriptions? Is it a chat app? What about adding payments to it?

We may not predict the future but with some idea of the scope we will be able to think about how to modularize the project.

Also, architecture can take care of possible bugs and stability (for example, if we go the Google route, using their components that take care of configuration changes, stability issues, concurrency, etc), and make testing easier.

You can take a look at Google’s recommendation for apps architecture.

Not taking Google’s as a last word, you can also check out concepts and approach about MVP (Model-View-Presenter) by Netflix.

Modules

While “module” sounds like an abstract concept for separation of concerns or sub-units of code, in Android projects it can be the concrete concept of Modules. Those parts in which an Android Project can be composed of.

We may have one only module for the entire app (not bad if we are just starting and trying out an idea) but it will become more evident the need to divide the code.

Separation of concerns, from a functional or non-functional point of view can both work: We can separate layers (UI, Data, Network, etc), features (Auth, BigFeature1, BigFeature2, Commons, etc) or a mix.

In case of having multiple teams for different parts of the app (imagine a supermarket app where electronics appliances screens are totally different from the groceries ones), different modules may provide a natural separation among teams as well. This is useful as well in remote and distributed teams.

Here a bit more conceptual in-depth presentation about modules.

Demo Apps

The bigger the app, the more it will take to build, it is kind of a fact.

What if we want to (manually) test a part of the app we are working on? What if building takes 15 minutes? This WILL happen, sadly. In this case, modularizing among features may help as you may add mini-apps, maybe called “demos” or feature “Activities”, which will make it possible to have fast cycles for your features development.

In an Square talk they tell about one approach to have fast builds and development with this kind of architecture (video above).

Dependencies

It will become prevalent that different modules, will end up connecting, or said better, depending upon themselves.

Just imagine your “Auth” module being asked for sessions from multiple parts of the app. Dependency Injection will come to the rescue for this and for easier Testing as well.

You won’t see any big Android project without a kind of Dependency Injection applied to it. Currently on Android, Hint is taking the position from Dagger as the recommended standard to follow (pushed by Google).

Testing

Putting the religion aspect aside, more automated Testing will help the project. At least, avoiding to have the same bug twice.

The battery of tests will go from testing code/behavior one class at a time up to end to end tests that follow user paths in the app (for example, from login until saving changes in the app).

There is a Testing Pyramid that graphically explains three testing categories.

Some things we’ll have to consider:

• The need of implementing Dependency Injection in the project is inevitable. (At least, it will help with mocking features that are not meant to be tested in certain Unit Tests. It will also have a performance impact on Testing as well. Let’s avoid accessing the database or network when running a logic test.)
• Small tests should be fast and generally only test Kotlin/Java code. Large tests, may need to run on real devices or emulation. That’s why some companies have phone farms or use services like AWS Device Farm or Firebase Test Lab.

The Fundamentals of Testing (for Android) can be seen here in the Android Developer site.

Another aspect of testing that appears is how much of our app we are testing. This can be reflected by Code Coverage. Nowadays Android Studio has a built-in feature that allows you to run code with code coverage. Use it at your own ‘risk’, do not try to reach 100% without a second thought. Some parts in the code will be much more critical than others, focus on them first.
Android Studio: how to run tests with code coverage.

Continuous Integration

How we can reduce the chances of delivering new bugs into production after making a new bunch of code (new features, fixes, etc)? What about having builds ready for QA? Or.. how will all those tests run when integrating code in our Master branch?

Here is when Continuous Integration takes their role in the project. Basically (but not restricted to) at least all new commits in our main branch (Master? but it could also be made for every feature branch) will trigger a new build. That build will itself be tested, both automatically and manually by our QA team (if we have any, please have one). It may also deliver those builds, making them accessible to anyone interested (QA, ourselves, Product management, etc).

Nowadays Jenkins CI is one of the most used, but some other tools can be used as well, Bitrise, Github Actions or even Gitlab CI.

In general it will be duty of one of the developers (or maybe a delivery manager?) to configure the platform and project with the steps to execute when integrating. Obviously we will want to run tests and make the build. Additionally many actions in this article series will end up running from CI as we want every “health” check for our project to be run automatically.

Check out this practical introduction to Android Continuous Integration.

There is more..

That’s all for this first part of the series. I promise, there is a lot more to cover when making Scalable Professional Android apps!