Microapp — Microsolutions for tiny world
Microapp = Micro Interaction(s) + Micro Service(s)
To understand the micro app components, we need to first understand micro-interactions.
Micro Interactions are contained product moments that revolve around a single use case — they have one main task.[1] Most appliances and some apps are built entirely around one micro-interaction e.g electrical switches, door bell, water tap etc. We’re surrounded by micro interaction every day, but we hardly notice them. You can have a look at some of the micro interactions [here][2].
The difference between a product you love and a product you tolerate is often the microinteractions you have with it.
Anyway, we are talking about a product/app with a single use case. Single use case doesn’t mean one micro-interaction, it could be one or more than one. Single use case means it only serves one purpose, whether it involves one or many micro-interaction is dependent on the use case. But lesser the number of interaction better would be the experience.
Understanding Microapp Features
Single Usecase : List down all possible use cases. Use cases are not the problems which any microapp solve but the way users will experience the product. For example, we can consider step to register as one of the usecase but how would you use the data collected is not a usecase. There could be a possibility that multiple micro-interaction is a part of single use case.
Defined Boundary : A better understanding of use cases will help you to define the boundary of each business component. If you overlook any use case, it might result in a microapp will be hard to re-use. So be careful while defining a single use case. For example, if registration is taken as usecase, you might feel that building complete user profile is a part of registration but it is not. For example Google and Facebook signin button, it has just one purpose registering users and allowing their users to enter client domain.
Independent App : Microapp should entirely be an independent app. Microapp shouldn’t be dependent on any particular business type, it should ideally fit all *relevant* business types. OTP and email based registrations are two different microapps to handle different business requirements. Business might need a combination of both (OTP and Email) then it is a good idea to design two microinteractions where email is validated first and then phone number or vice versa. Designing an app with both the validations in one interaction would defeat the purpose of microapp and microinteraction as well.
Plugable : Microapp should be as plugable as lego. With minimal efforts microapp should be plugged and start working immediately.
Customizable : UI Customization should be allowed on any microapp, atleast color and theme customization should be present. It is a good to have feature but not a must feature.
Source : http://microapp.in/micro-business-components/
[1]: http://microinteractions.com/what-is-a-microinteraction/
[2]: https://vine.co/tags/microinteractions
