General Archives - Page 9 of 36

Design Thinking in Healthcare

Posted on 20/01/202121/05/2021 by Anteelo Master

Design Thinking, at its core, is a creative process to solve everyday problems with a human-centered approach. While the word ‘creative’ may sound like something do only with designers/artists, the good news is- it’s not. Anyone can implement design thinking. The only thing that you really need is- listen to your customers as people who need your help. Once you understand their needs, their hopes, their fears and the friction they face while dealing with a particular problem- Bang! You are halfway through it.

Let’s hear a story. The story is about a woman named Elisa (yeah! I made that pseudonym). Elisa is an eighty-one-year-old woman suffering from age-related macular degeneration (AMD). When she was told she needs to take an injection in the eye for treatment, she was petrified. And why wouldn’t she? It’s not just any injection on the skin, it’s a needle in the eye. At the age when you are struggling with survival, it’s terrifying to think of ways in which you can go blind.

Apart from this particular case, it’s a fact that many of us dread getting an injection. Diabetic patients go through this painful experience, every day. Sometimes they have to administer these injections themselves, and sometimes they have to deal with a less skilled, less empathetic nurse.

Don’t you think we need a better solution to this? Can’t we develop something which makes this experience less scary? Can we go that extra mile and feel the pain of these patients? Can we somehow make them suffer less than they are already suffering?

An organization called Portal Instruments has now challenged this 160-year-old needle & syringe technology with design thinking. They have created a needle-free computerized injection system which fires a jet of liquid into the human skin. The handheld, low-cost unit is highly precise and accurate. The device is easy to use and its digital health features empower the patients to holistically manage their chronic condition interactively.

Design, particularly in healthcare, is about efficiency, usability, and a better user experience for patients as well as medical practitioners. And Design Thinking is a very powerful approach to solve customer’s problems. So where can you apply design thinking in healthcare?

Design Thinking in Patient Care

Patient care is not just about exchanging pleasantries and moving ahead with the treatment. When you apply Design thinking to this process, you will uncover ways in which care goes beyond the treatment.
A customer empathy map will help you understand your patient’s pain, concerns, fears and go beyond the clinical treatment. For instance, simply by listening to the concerns of expectant mothers, you can help them ease their anxiety. After quality research & brainstorming viable solutions, you can arrive at a proposed solution to help them be better informed about the labor process.

Design Thinking in Clinical Experience

Memorize the last time you were sitting in the emergency-room and recollect your waiting experience. Wait times are difficult to pass. You are in a troubled state of mind. Patients and their families spend a considerable amount of time in waiting rooms, sometimes waiting to be treated and other times waiting to see the doctor.

Design thinking may bring forth innovative ways of helping patients feel comfortable and make their experience bearable. You can start by asking questions and understanding their mindset. Must the patient be left alone while they wait for care? Is there a better way in which family wait time can be utilized? If you can not reduce the wait time, think of ways to utilize it. Once you answer these questions, you’ll be able to elevate the user experience of your users.

Design Thinking in Websites

If you are building a healthcare app/website, then you have to take care of the reliability and accuracy of the information that you provide. A person’s medical records can be critical information while monitoring health patterns or detecting disease symptoms.
Prioritize the most important information & fields for your users. Boil down to basics. Take all age groups into account and design keeping in mind their ailments.
They (might) want more information with less number of clicks, they (might) wish for larger and readable fonts. And while you may get away with frequent ‘small’ updates on social media apps, here it (might) frustrate them.

How to design a great Healthcare Experience

You know why every superhero is veiled behind a mask? Because creators of comic heroes want you to believe that even superheroes are like any other human. Their only superpower is endurance and resilience. They understand people; they want to solve their problems. They put people before anything else.
Much like Spidey! Or Batman.

Design thinking is same. It’s about organizing those mindful scattered ideas that everybody forgot to care about. Design thinking is about subtle differences which make you outshine from the ordinary. Yet it’s not so easy to put yourself in some else’s shoes. It takes a lot of efforts in brainstorming and generating ideas. Then, you should quickly pivot on a prototype and gather user feedback for continuous improvements.

Design thinking has already made it to healthcare. But, as we all are aware of the sad state of product design and innovation in Healthcare, there are still areas where it remains underused, such as patient transportation, the communication gap between doctors and patients, to name just a few. Here’s one approach that might be useful to you-

Research and define the problem statement

If you are dealing in the food business, wouldn’t you start talking to the farmers? So, start with conversations. Talk to patients/families about their problems.
Build customer personas. A persona is an imaginary character that embodies your real customer. Learn about your user’s lifestyle, their goals, their values, the challenges they face. Empathize with your users & their problems.
If you are designing an online appointment experience, you need to involve every single person associated. Right from the doctor to the patient. Even the receptionist. You need to understand their roles and most importantly, where they fit in together. Once you understand their pain points, then you’ll be able to create the experience for patients who need care.

Ideate

Enough talking! Time for some action. Gather all that you have talked and use the outcome of Research phase to generate interesting ideas. Not all ideas will be usable; so try and stay close to ‘potential solutions’. Use techniques like high-level drawings, user-mapping and plot a user’s experience map to arrive at innovative solutions.
For instance, while building a SaaS-based mobile engagement platform for one of our client, our design team took conscious efforts to understand the whole journey- health plan benefits, treatment requirements, appointment details, communication medium, medication instructions etc.

Putting down our ideas on paper helped us a lot in working on user workflows. We were able to visualize a smarter workflow which connects with patients through mobile messaging for more effective communication.

Prototype and iterate

Giving your ideas a shape is crucial to the design thinking process. Otherwise, it will just be castles in the air. Prototyping is something that pushes you into making things tangible so that you keep moving forward.
Prototypes will be a proof of concept of your ‘ideation exercises’. They will help you in demonstrating and validating your concepts and understanding. Moreover, they are important because you would want to test your functionalities in a real environment with real users.

Prototypes need not be beautiful. It can be a black and white template of your colorful understanding. It must answer a simple question- as simple as “How would you like to reach out to your members?”

Depending on your application (web/mobile), prototypes can be interactive or static. What really matters is that they must convey the user experience flow.

The advantage of building a prototype is that it’s something substantial and not just some thought process going on in our mind. Once you have pushed that into a real environment, you can take feedback from users and iterate to simplify functionalities.

Designing for healthcare won’t be a joyride. Unlike social media apps like Snapchat, your healthcare platform will grow slowly. And that’s not your mistake. The user base that you are catering to, is not looking for socializing or entertainment. So the only solution lies in applying design thinking to approach problems.

Before aiming for success, first, offer a service that’s valuable. Offer a service that solves a real problem. Offer a service which makes them forget that they are interacting with a machine.
Let’s build a better healthcare experience. Let’s be more human.

Basics of Espresso

Posted on 19/01/202124/05/2021 by Anteelo Master

Unit testing is an essential part of any development lifecycle. Writing unit test cases can come in handy when we want to make sure that our code still works as expected even after code changes have been implemented.In Android, we have two types of unit tests that we can write:

JUnit Test Cases
Android Instrumentation Test Cases

JUnit test cases are test cases that can run on the JVM. It is preferred to write JUnit test cases as they can run directly on the JVM and are much faster. While writing local unit test cases, if there is any dependency on the Android system, those dependencies can be mocked using a mocking framework like Mockito.

Android Instrumentation test cases, on the other hand, need the Android system to run. They need an actual Android device to run on. They should be used if the test cases rely heavily on the Android system like the Android UI. As they first need to be deployed on an Android device before they can run, they are usually slower than local unit tests.

In this blog, I will talk about how we can write basic Espresso test cases to test the Android UI.

Espresso has 4 main components which are:

Espresso – It is the entry point for any interaction with views (using onView() and onData()). It also exposes certain APIs that are not specifically linked with any view, like pressBack().
ViewMatchers – They are a collection of objects implementing the Matcher <? super View> interface. One or more matchers can be passed to the onView() method to find a view inside the current view’s hierarchy. In case the view that we are trying to match is not present in the view hierarchy, Espresso throws a NoMatchingViewException.
ViewActions – They are a collection of actions (ViewAction) that can be passed as an argument to the ViewInteraction.perform() method to perform some action on the view, such as click().
ViewAssertions – They are a collection of assertions (ViewAssertion) that can be passed as an argument to the ViewInteraction.check() method to assert some state of the view. Most commonly used ViewAssertion is the matches assertion, which uses a ViewMatcher to assert the state of the currently selected view.

A complete list of the available ViewMatcher, ViewAction, and ViewAssertion can be found in this Espresso Cheat Sheet.

Now that we know the basic components of Espresso, let’s see how we can integrate Espresso into our Android projects. Let’s start with setting up our test environment.

It is recommended to turn off system animations on the device on which the tests will be run. This should be done in order to avoid test flakiness. Go to Settings -> Developer Options and turn the following 3 animations off:

Window animation scale
Transition animation scale
Animator duration scale

We can override beforeActivityLaunched() to execute any code that should run before our Activity is created and launched.

We can override afterActivityLaunched() to execute any code that should run after our Activity is created and launched but before any test case is executed.

We can override afterActivityFinished() to execute any code that should run after our Activity has finished.

Methods annotated with @Before annotation are executed after the activity is launched and before the test case is executed.

Methods annotated with @After annotation are executed after the test case is executed and before the activity finishes.

ActivityTestRule rule provides functional testing of a single activity, that which is specified in the ActivityTestRule. This activity will be launched before executing every test annotated with the @Test annotation. ActivityTestRule has 3 constructors:

The activityClass parameter indicates the activity class that needs to be launched before every test.

The initialTouchMode parameter indicates whether the activity should be launched in touch mode.

The launchActivity parameter indicates whether the activity should be launched by default before every test case is executed.

Let’s see how we can pass some data to the activity before any test cases are executed. There are two ways in which this can be achieved.

First, we can use the 3rd ActivityTestRule constructor along with the @Before annotation to achieve this. Passing the launchActivity parameter as false indicates that the activity will not be launched by default. The method annotated with the @Before annotation will be executed before every test case

The second way is to implement the ActivityTestRule constructor and override the getActivityIntent method. The getActivityIntent method returns the custom intent that we build and this intent is then available to the activity under test after it’s launched.

We have seen how to setup Espresso and how simple test cases can be written. I hope this article motivates you to implement Espresso in your Android applications for UI testing.

Employing Automation to test Data Interface

Posted on 17/01/202121/05/2021 by Anteelo Master

Say, you got a DB comprising of huge data with billions of records. You have to showcase it on UI only after making sure that everything you want to represent on UI is accurate and as expected. Incorrect data could impact your business in unknown and serious ways that can lie undetected for months.So, here you might need to plan a new strategy, which should lead to answers of all your questions.One of the finest approach among this strategy should be- to make sure that everything you are showing is validated and verified. This leads to a special type of testing called as Data Interface Testing.

What is Data Interface Testing ??

Before we go ahead with Data Interface Testing, let’s first discuss about data interface. Lots of application in the market are nowadays based on Data Mining or Big Data concept. This helps to streamline the big data and showcase on UI in an adequate manner.

Now, as many people say that there is always some pros and cons for each process. Similarly, even this one has few. One of the biggest one is showcasing huge data. But I have a solution.

There is always a challenge to show the huge data on UI where everything is placed at their respective place with correct data set and correct orientation (if you’re showing the data in graphical representation).

So, the interaction between database and User Interface brings the term Data Interface. And to make sure that it works well both ways i.e. request and response results, we call it as Data Interface testing.

Big Question !!

Can I test this much of data and all of that manually??

Answer is yes, it is possible. But practically not a good way to do the same.

So what …?? Automation ??

Yes.

But what if I don’t have any good knowledge for it ?

Don’t you worry, we got a cheat for you !!! A tool to test data interface automatically, with a very basic knowledge for Automation/coding.

Some Info Regarding this tool
This tool is made to test validation and verification of data between database and user interface. To make this tool useful, one can easily use it on it’s own working environment, by customizing the details in provided file and coding as per their requirements. .

How this tool works ?

With it’s main class, it reads multiple files which further executes the methods written in those properties.

For reference, the source code is mentioned below:

Representing Main Class of Tool

Method written in above class is dependent upon various files. One of them is called as Property_Reader file.

This is a custom made file, which executes multiple methods and brings result for main class.

1. Property_Reader_Method

2. db_property

This file comprises of all properties, which helps in setting up connection with server/DB.

Following are the properties used in this file.

Url=jdbc:presto://10.0.11.198:8080/test/default
UserName=root
Password= 12345
ClassName=com.facebook.presto.jdbc.PrestoDriver

You can change your URL and credentials as per available server(s).
Password can be null too. Depends upon the server details.
For current we are using presto as DB.

3. query_column

This comprises of column name for which data needs to be fetched from DB. For every query there should be a unique query name which must be identical in all property files for that query.

For below mentioned example. “testA_count” is the name of query which is unique from rest of the two but same in other property files for queries with same conditions.

Apart from that, irrespective of number of columns available in expected and actual query, it will only bring data for “Column A” column in the result set.

Same case for others too.

4. query_actual

This property file contains the queries created by developers or fetched through server logs file which are created while accessing the application through UI.

5. query_expected

This property file contains the queries created by testers.

By running the above mentioned code for main class, it will create a new result file every time. This file will comprise of end result for executed queries, having expected and actual result with numbers and pass/fail result.

For Failed Case:

Let’s change the actual query to-

Points to be considered:

Make sure that the query name should always be the same in all expected, actual and column property file.
For every query there should be a unique query name.

Benefits of using this tool are:

Any Structured DB can be used for this eg. Presto, MySQL, MS-SQL etc.
Platform independent. Can be run on Windows/Ubuntu/Linux.
Can be run on a project written in any language.
Doesn’t require any prior coding skills or automation knowledge.
One can easily put the expected and actual test case in respective property files and can have the result set, with complete information.
Can be easily customized as per available resources/requirements

MeteorJS

Posted on 14/01/202121/05/2021 by Anteelo Master

What is MeteorJS?

MeteorJS is a javascript framework to create web applications. It is built on the top of NodeJS and uses MongoDB as a storage layer.

Components of Meteor

There are 5 major components on which MeteorJS is built upon.

BlazeUI

This library of MeteorJS is helpful to give live updates to users. This library is responsible for updating DOM. It is just like AngularJS where in DOM you have to just tell what you want and if there is any update, it will take care of that.

MongoDB

Meteor project comes with MongoDB, without writing any configuration file. It can be accessed from the remote by adding 2 in the Meteor server port. For instance, if Meteor is running at 3000 then MongoDB will run at 3002 port. The MongoDB files are in the .meteor directory of the Meteor project.

DDP

Distributed Data Protocol(DDP), is a communication layer between client and server. It is based on web sockets. Everything that happens between client and server is only through DDP. The client and server do not know each other. Client and server both don’t need to be of Meteor. Meteor clients can talk to other servers who understand DDP and Meteor servers can talk to other clients who understand DDP.

Live Query

It is a communication layer between and server and database. It continuously listens to the database and sends updates to the server if anything happens in the database. So if anything happens in the database, you will get updated results on the screen without hitting the refresh button. In general, it requires a separate implementation for each database.

Benefits of Meteor

1. You can get real-time updates without writing an extra code for it.
2. Packaging system – You can save lots of time by using MeteorJS packages. Many built-in packages can be used as it is. Using packages and writing your package for others is also very easy. Rails developers can think of a gem as a package.
3. Learning curve is low. You need to have command over javascript because MeteorJS uses javascript on both the client and server-side.
4. Meteor itself minified the javascript and CSS in production mode.
5. Meteor automatically syncs the state between client and server.
6. The community of Meteor is very active and supportive.

An Example

Below are the few commands that will install MeteorJS and then it will create the project for authentication.

Installation

$ curl https://install.meteor.com/ | sh

To create an application with name authentication

meteor create authentication

The output of the above command will be-

Run Application

Go to authentication directory – cd authentication

Type command – meteor
Open the browser and go to http://localhost:3000
By executing the above commands you will see something

Add package

meteor add accounts-base
meteor add accounts-password
meteor add accounts-ui

The above 3 commands will add authentication packages

Display buttons on UI
Add below line in authentication.html and comment {{> hello}} line

{{> loginButtons}}

The above line will give you the ‘Sign in’ link on your browser and when you click on that link you will get ‘Sign in Form’ and other links that are required for authentication

Software Metrics for your Product Development

Posted on 13/01/202121/05/2021 by Anteelo Master

Developing a quality software product falls under the realm of software engineering. The ever changing user requirements and harsh project timelines pave way for cost overruns or delays in the delivery schedule. So, bigger the scope of your project, more complex the functionality becomes. With so many factors it is very easy to lose control over the quality processes to develop an excellent product. We know that no engineering is complete without accurate measurements; which further brings us to the point that all measurements are done by applying certain metrics.For this reason we need software metrics for transparent and quality delivery of the product. Because when you measure what you speak about, you have numbers to express your failure or success. You have a calculated expression which shows you where you lacked and places you stood well. In Bob Parsons’ words-‘Anything that is measured and watched, improves.

Now the question arises- which software metrics to use?

One option is to pick a set of predefined metrics. The other one is you can first define the product requirements, discuss with the various stakeholders and then set the required metrics.

For a better understanding, consider an analogy when you are backpacking for an adventure activity. Would you pack a parachute if you are going for kayaking?

Absolutely not.

Instead, you would first decide upon the adventure sport, do a bit of research and accordingly pack your adventure gear. So, if you are going for paragliding, pack your bag with a helmet and a harness.

You can leave the oars behind for the next time.

Defying the law of gravity? It’s okay. But make sure you don’t cause more harm than good in the project. For this reason, it is important to apply the right metrics at the right stage in the product development cycle. As a software development company which builds engaging products.

1. Team Velocity Points

In simple words, team velocity measures the average speed of your team towards achieving its goal during one sprint. The fact that a typical sprint goes on for about 2-4 weeks, calculation of team velocity points proves to be a valid metric to gather the team’s efficiency.

If you want to calculate your team’s velocity, sum up the story points that were completed during that Sprint. To decide the team’s velocity, a three sprint’s average is usually considered.

Why? It’s an industry standard and it determines the project’s pace at which the functionality is being developed. In simple terms, it tracks the velocity of a Scrum team over time. This metric helps in deciding whether the team can take up more work over time or is the team already overloaded and it need to be reduced.

2. Sprint Burndown

Sprint burndown chart is the most effective tracking metric to visualize the health of the project. It helps in reviewing how much work is pending and if the team needs to speed up or slow down. You can also predict the expected completion date of the sprint. A deviation from the expected burndown will send a red flag to the scrum master to take appropriate actions.

For instance, if burndown goes up at any point during the sprint, it reflects an addition to the existing scope. At this time, it’s important for a team to achieve ‘team’s goal’ first before fetching new items from the backlog.

Why? The Burndown chart indicates the progress of work within a sprint. It shows whether amount of work a team is accomplishing every day will lead to a successful sprint completion or not.

3. Release Burnup

Product owners need to evaluate what should be out in the market first based on their discussions with other stakeholders. Release Burnup helps POs to continuously prioritize product backlog based on how the work is progressing.

If the release date is fixed and there has been a few additions to the initial scope, this is an important metric to align scope with the actual release date by either removing low priority backlog items or attempting to increase velocity by taking suitable measures.

Why? The Release Burnup chart indicates whether the sprints are progressing towards a successful project completion in terms of functionality achieved. Also, gives us a projected date of completion of the project.

4. Estimated Cost vs Actual Cost at Completion

Often there are gaps between the estimated cost projection during the start of the project and the actual cost at completion of the project. This metric gives a measurement of what deviations could have led to this difference in the cost.

Although, almost always the project cost goes higher than the expectation (just like we tend to overspend while shopping), this metric helps you understand what could be the possible cause of cost overrun- be it some design error or some changes in the scope of product development.

Why? Helps us understand what cost we had estimated and what cost was incurred. This helps us in improving our planning.

5. Number of major bugs per sprint

The number is an indicator of the overall quality of the product. When you are working in an agile project, it becomes important to put a budget i.e. count on the number of major defects open in a project at any point of time.

How can we stay within the budget? Reduce the count of defects reported.

How can we reduce the number of defects? Do Not Report!

Yes, I’m kidding.

Here is a better solution- focus at the time of planning, look-ahead and clearly define acceptance criteria before jumping on a sprint backlog item.

The priority of resolving any major bug is over and above implementing any new feature. Because if you can’t resolve what your did wrong, you can not pick a new feature.

At the same time, keep a close watch at the number of bugs reported after production release. If you have not been proactive in refactoring and improving quality of your code, chances are you will receive nasty numbers in this metric. This will help you to identify gaps in testing and take corrective measures

Importance of Usability Testing

Posted on 12/01/202121/05/2021 by Anteelo Master

When Lyla was asked if she could interview an author on her colleague’s behalf, she jumped at the opportunity. Lyla was interning with an uptown magazine for a role that deemed her ‘unfit’ for any important tasks such as interviewing a popular author. Getting an opportunity to talk to her favorite author was like a jackpot. She thought she is finally gripping onto a childhood dream. She thought she finally can brag about meeting Paula Hawkins. She wanted to be careful about not screwing this golden opportunity, so she double-checked everything on her list.
Notepad, check. Pen, check. Camera, check. Questions, check. Recorder, check! Oh wait! I have to check for a new update, just in case I am outdated.

She updated her app quickly and reached the coffee shop before time. She was excited, she was anxious. It’s an easy-peasy task, you just have to ask questions, record them and pour it out later– she kept repeating this in her mind.
But the moment Paula Hawkins walked in, she started feeling the breathlessness. Part excited, part nervous, she could feel her palms sweating. After exchanging some pleasantries they kicked off with the interview.

“Shall we start?”
“Yes, of course. Let me just..umm… Start this thing”
*she clicked on the record button and started talking, simultaneously taking notes.*

Unaware of what was happening after she clicked on that little red button, she went on with the interview, taking down notes as per her whims. Ignorant of the new updated feature — which now needed ‘long press and hold to start recording’, she finished the interview, smiling and pleased with herself. But as she looked down, in order to ‘STOP’ the recorder, she lost the fanatic feel of doing a good job!

A little hover over the button said “long press and hold to start recording” which was an obvious slip.
Game over. She probably lost her mind or her job. Or both. But that’s none of our concern. Right? She should have been more attentive.

Lyla is a fake person. She did not meet Paula Hawkins ever. But the incident is real. Only, it happened with an acquaintance and I figured out it wouldn’t be fair to name her. This incident forced me to shine some light on the importance of usability testing and why it’s more important to pay attention to user’s behavior while they interact with the product.

They say, never talk to your users, they hardly know what they want. But they missed out on the summary-

“To design the best UX, pay attention to what users do, not what they say. Self-reported claims are unreliable, as are user speculations about future behavior. Users do not know what they want.”

Usability testing- What is it?

Usability testing is like black-box testing of an application to ascertain if the product built is convenient to use and easy to learn.

These are methods of testing and observing the behavior of the users to find out what works and what doesn’t work. Users are given specific tasks to complete and when they are at work, observers watch their body language, facial expressions, emotions and encourage them to “think aloud” i.e. speak up whatever comes to their mind while using the product. Doing this exercise we can get qualitative and quantitative data and figure out usability issues with a product.

So, why usability testing is important?

Doing usability testing the right way, at right time with the right set of people reduces the risk of building the wrong product; thereby saving time, money and other precious resources. In other words, if done at an early stage when the product is at paper prototyping stage, it finds the problems when they are easy and cheap to fix. And when done on a product which has attained maturity it helps to understand user’s success rate and time spent to complete a task. There are hundreds and thousands of cases when usability testing proved to be a good exercise in terms of ROI.

For example, a slight tweak in design suggested by usability testing for Mac’s UI, the company got 90% fewer support calls.

Need more clarity about why usability testing is a good idea? Here you go-
#1. To check if product meet user’s expectations
#2. Matches business decisions to real-world use
#3. Removes flaws in the product
#4. Allows you to see how successful users are with their tasks
#5. Useful for getting user reactions and feedback about the product

What are the types of data that we can get as a result of our analysis?

Two types of data results received are — quantitative and qualitative. Usability testing is largely a qualitative research technique and is not driven by statistics like surveys where lots of people participate. Usability testing is done using a small set of people, usually five to seven.

Qualitative methods are very useful to test the stress response of the users like their body language, movement of hands, expressions on the face and squinting eyes especially doing a test on a mobile device.

The metrics we get after usability testing can be quantitative as well. For example, time spent on doing a task, success and failure rates and also the efforts, like how many clicks a user needs in order to complete a task.

Is there a need to record all the metrics obtained from a usability testing?

Yes, keeping a record of the metrics is very important. Why? Because usability testing is not just for designers to understand how to make better designs but it is also an important tool to influence the rest of the stakeholders like clients, their sales/support team, project managers, developers, other designers etc.

Every stakeholder involved may have a different point of view for a design decision. Being subjective by nature, design decision often leads to long debates among stakeholders. Most often design decisions are influenced by a person who holds the highest position among fellow stakeholder or has superior oratory skills.

In short, metrics help us in iterating and validating design concepts. It gives objectivity to design debates and it helps in taking fact-based design decisions.

At what phase of the design process usability testing is recommended?

When it comes to usability testing there are two terms often referred by big names of the UX industry (like Jacob Nielsen) and these terms are Summative Test and Formative Test.

These tests are done at different stages of the design process. They are as explained below:
Formative tests are low-fidelity tests (to gain quick insights)-
#1. During the very initial development phase using paper prototypes
#2. It can be done anywhere and a formal lab is not required
#3. It can be done just between a moderator and a participant

The results from a formative test may include-
#a. Users’ comments in the form of “Thinking Aloud” narrative i.e. their emotions, confusion sources and their reasons for actions.

Summative tests are high fidelity tests (to capture metrics)-
#1. These are carried out at the end of the development stage
#2. At this stage usability of a product is validated
#3. This gives an answer to the question “How usable the product is?”
#4. This gives a comparison against competitor products
#5. Conducted in usability labs or remotely using many tools available where users can do the test using their computers or mobile phones

The results from summative tests may include-
#a. User’s success rate to achieve a goal
#b. The time spent on completing a task

How many users are required to conduct the testing?

“Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests you can afford”
Jacob Nielsen

“It is widely assumed that 5 participants suffice for usability testing. In this study, 60 users were tested and random sets of 5 or more were sampled from the whole, to demonstrate the risks of using only 5 participants and the benefits of using more. Some of the randomly selected sets of 5 participants found 99% of the problems; other sets found only 55%. With 10 users, the lowest percentage of problems revealed by any one set was increased to 80%, and with 20 users, to 95%.”
Laura Faulkner

Who among them is right?

It depends on what type of test we are doing and where we are doing it. For example, if we are doing a low-fidelity formative testing we can do away with a small sample size. But if we are doing a summative testing we need a bigger sample size. In the type of testing where we are comparing our site to competitor’s website by using an online tool which is cheap and fast, we can use a large sample size. But we should keep in mind that these online tools like UserTesting or Loop11, they don’t capture metrics. It’s us who has to be aware of how all the participants did it.

So how to prepare a test plan?

That is certainly a good question. You have an inquisitive mind, I must say. But don’t you think that will be too much to digest in one bite?
Still, if you are really into it, give these things a thought-
-Decide what areas to concentrate on
-Determine potential usability issues
-Determine what tasks you want to test

Pace up The Gradle Builds

Posted on 11/01/202121/05/2021 by Anteelo Master

It’s been some time since Google I/O 2017 was released and there are lots of new things for Android developers. We all have to suffer from the Gradle build speed issue. Sometimes it takes ages to build an APK. But in this I/O session, Google team presented some cool tips on how you can speed up your Gradle builds and it looks promising. After listening to the complete session, I decided to extract some cool tips for your reference.

1. Always use the latest Gradle plugin for Android

The tool team is working hard to improve the performance of the Gradle plugin for Android, so it’s better to check the latest build and always keep updating.

2. Don’t use legacy MultiDex

If you are using legacy MultiDex in a device having a lower Android version, then it can impact your app performance. Always try to use the latest version of MultiDex so that it can be supported by all Android versions without impacting the performance of the app.

3. Turn Off multi-build APK

If you are in development phase, then it would be better to disable this as it slows down build time.

You can also set this using Android Studio. For this, open Preferences -> Build, Execution, Deployment -> Compiler settings in Android Studio and add -PdevBuild to the Command-line options.

4. Use only required resources

Resources occupy some space while generating APK file and also impact the build time. If you are in development phase, then let Gradle know to only take care of the required resources. Also, you can set the preference of the device for which you are developing the application.

5. Turn off PNG grinding

PNG optimization is not necessary for the development builds so you can turn it off, as by default it is on. It will definitely speed up the build time.

6. Give Instant Run a try

There is a bad reputation of the instant run, but when it works, it works like a charm. The tooling team has worked on it and now in Android 3.0, it is more stable as compared to earlier versions. So you can give it a try and speed up the build performance.

7. Avoid using dynamic dependencies

Using dynamic dependency version causes Gradle to check for the new version in every 24 hours. So it’s highly recommended not to use the dynamic dependency.

8. Always take care of memory

You should keep your eyes on how much memory you are giving to the Gradle. You can watch this video to know more on Gradle memory setting and Dex in the process.

9. Turn on Gradle caching

Gradle caching is introduced in Gradle version 3.5. It reuses the outputs from the previous build. It can work across the projects and gives a high performance when used with Android Studio 3.0. So let’s give it a try as well.

10. Disable Crashlytics plugin

We generally add crashlytics plugin in Android Studio to find the cause of the issue/crash, but it slows down the build time as it generates new ID every time we generate a build. It’s better to disable this in development builds using below-mentioned code snippet.

Learn: Using DiffUtil with Recycler View Adapter

Posted on 09/01/202121/05/2021 by Anteelo Master

What is DiffUtil?

A utility class that finds the difference between two lists and provides the updated list as an output. We can use this utility class to notify updates to a RecyclerView Adapter.

When the content of our list gets changed, we have to call notifyDataSetChanged for getting the updates but it is very costly. There are so many iterations for getting the job done in the case of notifyDataSetChanged.

As of 24.2.0, RecyclerView Support Library, the v7 package offers a utility class called DiffUtil. It does its job perfectly. It is based on Eugene Myers’ algorithm.

Comparison with notifyDataSetChanged

If you know the implementation of RecyclerView you may also know that below mentioned method will be required to notify the changes to the adapter.

notifyItemChanged
notifyItemInserted
notifyItemRemoved

And their corresponding Range variations

notifyItemRangeChanged
notifyItemRangeInserted
notifyItemRangeRemoved

Their names explain their purpose pretty well. According to the official documentation, they are significantly more efficient than the famous notifyDataSetChanged(). DiffUtil uses these methods to notify the RecyclerView for any changes in the data set

Let’s take a scenario, where we are using some filtration on data. Here we will sort data according to the rating.

DataRepository.class

DiffUtil.Callback is an abstract class that has both abstract and non-abstract methods in it. Let’s take a look at the adapter and callback class first.

RatingAdapter.class

Let’s understand the RatingDiffCallback.class methods.

getOldListSize()– This method will return the size of the old list.

getNewListSize()– This method will return the size of the new list.

areItemsTheSame(int oldItemPosition, int newItemPosition)– This callback method decides whether two objects are representing same items or not.

areContentsTheSame(int oldItemPosition, int newItemPosition)– This callback method decides that two items have same data or not. This method will only be called if the return type is true.

getChangePayload(int oldItemPosition, int newItemPosition)– If areItemTheSame returns true and areContentsTheSame returns false DiffUtil utility calls this method to get a payload about the change.

It is recommended that for a large amount of data in the list, you should do the calculation part in a background thread as it may throw an ANR exception.

Why use DiffUtil?

Here is the performance chart which illustrates that using DiffUtil is better in a case of RecyclerView. These results are based on Nexus 5X with M-

100 items and 10 modifications: avg: 0.39 ms, median: 0.35 ms

100 items and 100 modifications: 3.82 ms, median: 3.75 ms
100 items and 100 modifications without moves: 2.09 ms, median: 2.06 ms

1000 items and 50 modifications: avg: 4.67 ms, median: 4.59 ms
1000 items and 50 modifications without moves: avg: 3.59 ms, median: 3.50 ms

1000 items and 200 modifications: 27.07 ms, median: 26.92 ms
1000 items and 200 modifications without moves: 13.54 ms, median: 13.36 ms

Due to implementation constraints, the max size of the list can be 2^26.

Conclusion

DiffUtil utility class finds the difference between the provided old and new lists and dispatches the updates to the adapter.

CSS3 Flexbox

Posted on 08/01/202121/05/2021 by Anteelo Master

There are many techniques to vertically center elements but all have looked some or the other way, quite hacky as developers have always been looking for an elegant solution to accomplish vertical centering.Ironically, people say CSS is easy but things like doing vertical centering has always made developers go crazy to find one elegant solution to the above problem in contrast to what they need to do for horizontal centering. Thank god, there is flexbox which has lessened the woes of developers.

What is the Flexible Box?

The flexible box layout is an alternative to grid layout in which there is no media query for particular breakpoints. Instead, it’s all about accommodating elements at a limit till which you can accommodate elements and then break it.

Flexible box gives more power and freedom to layout the structure. The child elements inside a parent container can be stacked vertically or horizontally by a difference of only one line of code. Isn’t it cool?

Flexbox layout helps developers in building responsive layouts with less of a worry about stacking things on different viewports and centering of things. Flexbox gives power to developers to lay out content as they want to be with minimal code. For e.g. if a developer wants 2 divs (i.e. A and B) to be horizontally stacked as A and B but vertically stacked as B and A. So, he/she just has to write:

-webkit-flex-direction: column-reverse;
flex-direction: column-reverse;

It’s that simple. Isn’t it cool?

A Glance through flexbox properties

Taking .wrapper as default parent class and .wrapper-list-items as its children

1) Display

Display property of Flexbox is used to tell the browser on how to layout the parent container in the flow of document of web page.
There are two possible display values: flex and inline-flex.

The only difference between the two values is that display:flex makes the parent element behave as if it has display:block property i.e. occupying full width of the web page and display:inline-flex makes the parent container to behave as if it is an inline element.

Display property is used for parent container on which we want to apply flex property and the actual layout is carried out on its child elements.

Code-
//the parent container
.wrapper {
display: flex || inline-flex;
}

2) Flex Direction

Basically, “horizontal” and “vertical” isn’t what the directions are called when we deal with flex.
These are described as main-axis and cross axis. By default, the flex-direction property is set to row and it aligns the flex-item(s) along the main axis.

/*where wrapper represents a flex container*/
.wrapper {
flex-direction: row || column || row-reverse || column-reverse;
}

The flex items are then laid across the main-axis, stacking horizontally from left to right. If the flex-direction property is changed to column, the flex-items would be aligned along the cross axis i.e. top to bottom.

3) Flex-wrap

This property defines whether the child elements should break if there isn’t enough space to accommodate all the child elements and if it’s allowed by making it wrap, then we could also change the direction in which the child elements should wrap.

//where .wrapper represents a flex container
.wrapper {
flex-wrap: wrap || nowrap || wrap-reverse;
}

“Wrap” is a fancy word to say. In simple words, when the available space within the flex-container can no longer house the flex-items in their default widths, it breaks into multiple lines.

4) Flex-flow

The flex-flow is a shorthand property which takes flex-direction and Flex-wrap values.

//wrapper is parent-container
.wrapper {
flex-flow: row wrap; /*direction “row” and wrap the children i.e wrapper-items.*/
}

5) Justify-content

It defines the alignment of the child elements along the main axis of the parent container. It equally distributes space among the child elements if all the child elements don’t occupy 100% space along the main axis of parent container.

The justify content property defines how flex items are laid out on the main axis.

Justify content has 5 values to work upon:-

//wrapper is parent-container
.wrapper {
justify-content: flex-start / flex-end / center / space-between / space-around
}

6) Align-items

This property defines how Flexbox items are aligned according to the cross axis, within a line of a flexbox container. So, if the flex-direction is row by default so the cross axis is perpendicular to the row.
Align-items can take any of the below 5 values:

1) align-items: flex-start; – The Flexbox items are aligned at the start of the cross axis.
2) align-items: flex-end; – The Flexbox items are aligned at the end of the cross axis.
3) align-items: center; – The Flexbox items are aligned at the center of the cross axis.
4) align-items: baseline; – The Flexbox items are aligned at the baseline of the cross axis.
5) align-items: stretch; – The Flexbox items will stretch across the whole cross axis.

Code:
//wrapper is parent-container
.wrapper {
align-items: flex-start || flex-end || center || baseline || stretch
}

So, above are some of the basic properties of Flexbox that I’ve covered which will atleast give you a head-start of Flexbox.

But as the saying goes – ‘With great power, comes great responsibility’, we should have a clear mindset as to when to use Flexbox for our layouts.

Here are some complexities related to using Flexbox-

Don’t use Flexbox for page layout. Flexbox is more powerful for laying out structure of components but not for a full web application. For laying out the structure of the page, it’s still a better practice to use grid system and then we could use Flexible box to layout components and their child elements.

Flexbox has come to make our lives easier, not difficult. We know it’s easy to layout elements inside a flex container but we shouldn’t overuse it if it could be done in more simpler ways. For example- to center text inside a span, we shouldn’t go for flex layout as there are much simpler ways to do it. So why complicate simple things?
Don’t use Flexbox if you need to support older browsers like IE-8 or IE-9 as support for Flexbox is present only on IE-11 and above. So, backward compatibility is a big issue for Flexbox.

Begin now: AWS Cognito

Posted on 07/01/202114/05/2021 by Anteelo Master

Most real-world applications need a user login. However, setting up user authentication and management can take considerable time. And it is like reinventing the wheel every time.Here comes to our rescue a managed service from Amazon Web Services: COGNITO USER POOLS

What is a Cognito User Pool?

Amazon Cognito User Pool makes it easy for developers to add sign-up and sign-in functionality to web and mobile applications. It serves as your own identity provider to maintain a user directory. It supports user registration and sign-in, as well as provisioning identity tokens for signed-in users.

By using Cognito, you can set up your own user sign in, signup flow with MFA. All this without writing a single line of backend code.

And integrated with AWS ecosystem, it opens up a whole lot of possibilities for front end applications as you can connect with AWS S3, AWS App sync, APIs, Analytics, Push notifications, etc.

AWS also provides an SDK: Amplify in order to connect with some of the AWS services. So all you need to do is call SDK methods from your application and voila! it’s done.

So let’s get started with setting up Cognito.

Initial setup

We will be using the User Pools to setup custom login for our application.

User pool is basically the collection of users on your application. You can also add users in different groups, like for a healthcare application, you can create 2 groups: Patients and Doctors which can be used to allow different actions for both types of users.

Let’s first make a user pool by clicking on “Manage your User Pools”.

We’re gonna walk through this process step by step, so enter the Pool name of “App Users” and click “Step through settings”.

The next step is “Attributes”, where we define the attributes that our “App Users” will have.

Here you can select how do you want your users to sign in: using a username, or an email, or a phone number.

Here we will select login using email as their username.

Next Cognito provides a list of standard user attributes which you can select to add in your user details. You can also add any custom attributes if you want.

Next, on Policies, we can select a password policy for the users. Currently, we have selected only a minimum length of password but you can add more conditions also.

We can also select whether we want to allow users to sign themselves up or only admin can add a user. We will cover the differences in the final application flow later depending on the choice made.

Under MFA and verifications, we can enable multi-factor authentication if needed. And we can also select if we want the users to verify their email in order to confirm their account.

So the last important bit for our application is adding a client application which will be using Cognito in order to authenticate its users. We will set the refresh token to 30 days, which means each login attempt will return a refresh token that we can use for authentication instead of logging in every time. We un-click “Generate Client Secret” because we intend to log into our user pool from the front end instead of the back end (therefore, we cannot keep secrets on the front end because that is insecure)

Click “Create App” and then “Next Step” to move on to–Triggers.

We can trigger different actions in user authentication and setup flow which can be configured here. A simple example could be to send the user a welcome message on signing up.

For the scope of this tutorial, we will not be using any AWS Lambda triggers. Let’s move on to the final step: Review.

Here we review all the setup configurations we have made. And hit “Create” to generate the user pool.
Take note of the PoolID from the Pool details tab.
And the app id from the Apps tab. You will need these in your front end application to connect to this user pool.
The last thing left to setup is an identity pool.

Amazon Cognito identity pools (federated identities) enable you to create unique identities for your users and federate them with identity providers. With an identity pool, you can obtain temporary, limited-privilege AWS credentials to access other AWS services. Amazon Cognito identity pools support the following identity providers:

Public providers: Login with Amazon (Identity Pools), Facebook (Identity Pools), Google (Identity Pools).
Amazon Cognito User Pools
Open ID Connect Providers (Identity Pools)
SAML Identity Providers (Identity Pools)
Developer Authenticated Identities (Identity Pools)

In short, we can say that while User Pool is used for authentication and user registration, identity pools are responsible for authorization to allow different users access to different AWS services by assigning them different IAM roles.

Go to Federated Identities and begin the process to create a new identity pool. Give it an appropriate name.

Now under the Authentication providers section, we will add the Cognito user pool that we just created. Copy the pool id and the app client id. And if we wanted to allow Facebook login or any other login, we just need to add the app id in the respective section and that’s all.

On saving the identity pool, you are redirected to the next screen which creates the IAM roles. Here we can assign different roles to authenticated and unauthenticated users to authorize them to access other AWS services like S3, SNS, etc.

We just need to note one more thing that is used in our front end applications, i.e. the identity pool id which can be found at the below location.

This was all for the Cognito setup. With this our backend system to manage users and authentication is complete. We now have a fully functional User authentication and authorization service with the following features and without any code:

Users can sign themselves up
User creation by admin with temporary passwords
Multi-factor authentication
Phone number and email verification
Forgot password
Social login