UI Antipatterns in Android development

We are going to talk about Android design antipatterns in modern development and how a few pixels can ruin your timeline and postpone your delivery.

This article is a bit more for those who stand by our side, as we battle evil and create Android apps,

Seems like those are knights, but they might as well be some people just dressed up funny, abusing horses

might you be a business analytic, quality assurance tester, project manager or product owner or anyone else who has something to do with the decision making when taking on a certain feature.
And especially my favorite if you are a designer.

We are going to go through some of those antipatterns in a series of mini-articles. They are for you to read and understand the underwater currents that a feature may hold, parts of the design that seem harmless while you estimate may cost you more story points than you sprint actually holds.

What is an antipattern?

Startrek officers, trying to refactor an Android App with a bad UI written in MVC and Java

We should have a look on the antipattern definition:

According to the authors of Design Patterns, there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or a bad idea:

1. A commonly used process, structure, or pattern of action that despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones.
2. Another solution exists that is documented, repeatable, and proven to be effective.

Please do note the second part of a definition, there’s always a better and a faster way to achieve a goal in IT, and it’s better if such a solution is implemented before the design is approved or the design was already approved, you still at least estimate such an antipattern as time-consuming and we all know that modifying a design takes less effort than modifying an app.

The first antipattern will always be “IOS like-design in Android”

The second antipattern is a common one and its “Action buttons and a software sliding keyboard on Android”

The third one is almost an antipattern - “Skeletons instead of progress in Android”

In a draft phase — Inconsistent screens in Android — antipattern

To be continued…

Disclaimer, as software development never sleeps some of the antipatterns might lose their antipattern status, the articles are relevant to their publishing date