Business Analysis

Design

Quality Assurance

Development

Business

Culture

Ivana

<h3 style="margin-left:0px;">Culture, Quality and Culture of Quality</h3>To understand what the Culture of quality represents, let’s break it down into two terms: Quality and Company culture and try to define them first. Then, let’s see how they again fit together and form the Culture of quality.<hr style="margin-left:0px;">Quality is a term not easily definable and mostly based on perspective, since it applies to everything around us. If we take, for instance, the quality of products and/or services in industries like manufacturing and engineering, we can say that Quality is what makes those products/services ‘fit for purpose’, while at the same time satisfying customer/client/end-user expectations. ISO 9000 also defines Quality as the “degree to which a set of inherent characteristics of an object fulfils requirements”.Company culture can be defined as a “set of shared values, goals, attitudes and practices that characterise an organisation”. We could say it represents the personality of an organisation – all the traits that make your company what it is: ways how employees feel about the work they do, how they interact with others, values they believe in, the decisions they make every day, where they see the company going, and so much more.All of those traits collected in an organisation’s culture have a huge influence on the quality produced by the organisation. That is why we strive to instil quality in the company’s culture and create a Culture of Quality.Quality Culture (or Culture of Quality) can be defined as “the opinions, beliefs, traditions and practices concerning quality”. It represents the environment in which the employees follow guidelines, take quality-focused actions, talk about quality, but also see other employees do the same thing. Culture of Quality is also an environment where everyone can feel the quality all around them.<h3 style="margin-left:0px;">The benefits of having a culture of quality</h3>So, now that we know how to recognise the culture of quality, let’s look at all the good things that can come out of having the culture of quality in your company.Companies that focus on Quality and manage it effectively:<ul><li>have lower costs, since quality generates savings (mostly through less reworks needed late in the process), which boosts their profits;</li><li>their brand and reputation enhance;</li><li>their efficiency increases;</li><li>are more successful;</li><li>are more protected against risks;</li><li>survive and thrive (keep on growing).</li></ul>Employees that go above and beyond regarding quality and understand its importance:<ul><li>are more productive and innovative;</li><li>make fewer mistakes (and, accordingly, their companies spend far less time and money correcting mistakes);</li><li>are more engaged;</li><li>better understand their roles (resulting in fewer issues, less wastage and lower costs);</li><li>are more proactive;</li><li>are happier.</li></ul>Companies that make sure their stakeholders’ needs are met and their expectations exceeded:<ul><li>receive fewer complaints;</li><li>instil customer with confidence and loyalty;</li><li>make customers happier;</li><li>get higher customer satisfaction;</li><li>achieve customer delight;</li><li>provide better customer experiences;</li><li>get more referrals and higher customer lifetime value.</li></ul><h3>Ways to create a culture of quality</h3>After seeing what good comes out of implementing the culture of quality, another question is presenting itself – What should we do to get all these benefits? How and where to start with the culture of quality implementation?There is no strict path to follow to create a culture of quality in your organisation. Each organisation is different and will require different tools and techniques. But all of the companies would have the same first step.<figure class="image image_resized" style="width:100%;"><img src="https://undabot-web.s3.eu-central-1.amazonaws.com/media/296df5d6c768f80f4dfc1c3b3724b6d2.jpeg"></figure><h4 style="margin-left:0px;">Evaluate your current company culture</h4>First, through evaluation, define and outline company values. Once you and your company see where you stand with your current culture, you are ready to start the process of improving it by embedding the quality in it.Look at your evaluation with Quality in mind and see if those values speak quality. That will give you a rough idea of what parts you should be focusing on the most.According to the Quality Magazine: “Companies that have achieved the true culture of quality, demonstrate three common traits: leadership commitment, employee ownership, and organisation-wide continuous improvement”.Some of the most important parts of this process of developing a culture that fosters quality are mentioned below and directly feed in the values mentioned above. Each company, during their journey, should decide the way they would implement any of those steps and where their focus will lie, depending on their current culture, their organisation, employees and the work they do.<h4 style="margin-left:0px;">Involve Senior Management</h4>One of the most important aspects of creating a culture of quality is getting everyone involved. That does not just include senior management, but makes them the first ones to get involved. If the top of the company is advocating quality, it is more likely that the employees will follow and take this quality journey seriously.The entire company must embrace a quality mindset in everything they do, including cross-department interactions. This is easiest to accomplish if starting from the top because that gives it credibility and a push for everyone to commit to it.<h4 style="margin-left:0px;">Involve your customers / end-users</h4>As we mentioned at the start, Customers play a big role in defining quality. So, don’t ignore their feedback, but rather use it to improve your culture of quality.Since everything you are doing should be about the needs and expectations of customers and end-users, ask them what their wants and needs are. The easiest way to do that is by using customer experience surveys and asking direct questions often. But also, pay attention during any kind of feedback – meetings, UAT testing, emails, etc.<h4 style="margin-left:0px;">Make your processes well-defined and easy to comprehend</h4>Well-defined processes in the company show all the employees how to carry out their assignments and it makes the work uniform across different teams. If employees understand the activities that make a process and all of it is very well documented, it is much easier to implement it in everyone’s daily routine. That way the employees perform their work without having to be reminded to follow the process guidelines.For a process to become a routine, employees have to be educated on the use of the process and trained in the use of the tools that will help them in their work.Processes that should follow this are not just development and QA, but rather all the processes in the company. Each process defines the minimum set of activities mandated for each project executed in the organisation, making the QA process focus on QA activities and other processes focus on their tasks at hand.<h4 style="margin-left:0px;">Create QA department, if you don't have one</h4>No single tool, test or person can guarantee quality. That also means that the culture of quality is not achievable by a QA team alone. Having a dedicated team or a department will take you closer to it, because your QA department should champion quality within the organisation.That means they will be:<ul><li>providing counsel and guidance on quality matters;</li><li>monitoring quality achievements;</li><li>evaluating and obtaining tools that will improve productivity and quality.</li></ul>If you already have an existing QA department that focuses only on uncovering defects, that is a good start, because their knowledge will be improving quality. But you should still work on modifying their responsibilities to include the ones mentioned above, since that will make a big difference in achieving the required level of quality and helping other employees play their part in it.Additional change you should do regarding your QA department is making them champions of organisational process initiatives. Since their job is to make organisations better at producing outputs that meet the needs and expectations of the stakeholders, there is no one better to advocate for those initiatives.Also, remember that your QA department should be of the same importance as any other department.<h4 style="margin-left:0px;">Train employees in quality culture</h4><figure class="image"><img src="https://undabot-web.s3.eu-central-1.amazonaws.com/media/9f15163244d3dd25682358d27cefc277.png"></figure>Employees need to be involved in the culture of quality in a way that they understand what they should do, how, and also most importantly why. The culture of quality is not made by simply following the rules, but by training everyone to think about quality, own it, care about it and act upon it.Embedding quality in the company means involving everyone (not just developers and testers) and teaching them what their responsibilities are, what the idea behind the culture change is and what the plan for the future is.One other aspect of training employees is asking for feedback. Given the opportunity, employees will adopt a quality mindset if they see their input is valued and their decisions impact the overall work and the company.In addition to the QA team training other employees in quality (process, tools, activities) and management influencing cultural values, teamwork should be encouraged, as well as employees learning from one another.Create a reward system for achieving excellence in qualityThis will be different in any company, depending on their capabilities and wishes, but it is important because it has a great impact on employee performance and motivation.A reward system can include monetary rewards and recognition or praise. The system should define goals and actions so that employees know what is expected from them to receive the rewards/recognition. That way, when the goals are achieved or actions completed, they get the rewards or recognition immediately. Remember, the time aspect of the recognition is very important — “delayed recognition is as good as denied recognition”.If quality is an important issue for a company, the reward system that they design should not emphasize rewarding the quantity of work accomplished by a business unit.<h3 style="margin-left:0px;">Maintenance — once you have it, don’t lose it</h3><figure class="image"><img src="https://undabot-web.s3.eu-central-1.amazonaws.com/media/b3493ef04b773fb3f8f30d07d31d75dd.png"></figure>Once you and your company go through this long process of developing such a culture, don’t forget about it, but rather work on maintaining it.Don’t forget to include everyone in this part of the process as well. Everyone should support the maintenance and contribute to it.The best way to do that is to not stand still and continually drive the improvement effort.So, how to do that? Well, here are some actions you can take:<ul><li>introduce quality metrics and use them to re-evaluate processes and behaviours;</li><li>maintain open and honest communication, ask your employees for feedback and suggestions and use collected information to work towards improvements;</li><li>work on promoting quality and other desired values (through improving accountability, clarifying goals and responsibilities, providing training and support, mentoring, rewarding good performance, engaging employees etc.).</li></ul>And at the end, do not forget:<blockquote>Quality is everyone’s responsibility.</blockquote>(W. Edwards Deming, Father of the Quality)&nbsp;

Culture of Quality - What is it and how to get it?

As a part of our mentorship engagement with Lumen Development, we had an opportunity to host a workshop for students participating in the competition in our offices. The competition consists of designing and developing a mobile or web application and is the biggest one of that type in Croatia.<hr style="margin-left:0px;">Apart from the workshop, Undabot also provides consultations to teams and shares advice and best practices to overcome all the challenges they might be facing.Since the teams are creating products from scratch, we decided to host a “UX 101” workshop to help them understand the process behind creating good products for a specific user group.During the 2.5-hour workshop, we covered the following topics:<ul><li>What is UX</li><li>UX processes</li><li>What is bad UX?</li><li>A group assignment</li><li>What are user interface platform guidelines</li><li>How and where to learn from</li></ul>We finished off with a short quiz on topics discussed during the workshop. The winner received a small gift.<h3 style="margin-left:0px;">1. What is UX</h3><blockquote>“User experience” encompasses all aspects of the end-users interaction with the company, its services, and its products.”</blockquote>&nbsp;We discussed the definition of UX by Don Norman and Jakob Nielsen, the pioneers in this field, and watched a short video of <a href="https://www.youtube.com/watch?v=9BdtGjoIN4E">Don Norman explaining the term UX</a>.One important thing to keep in mind is that there is no “perfect UX”, simply because nothing in life can be perfect. In my opinion, life is easier when you embrace that fact. You can strive for perfection, do the best job you can, but you don’t need to stress too much about it. Our products are used mainly by users of a wide age range, and it is not easy to meet everybody’s needs seamlessly.Don Norman also says: <a href="https://www.youtube.com/watch?v=LTE-v4RzRHs" target="_blank" rel="noopener noreferrer">Focus on Results, Not on Perfect UX</a>.Psychology plays a big part in UX design. It helps understand the users and influence of human behaviour. Design psychology is a combination of social psychology, cognitive psychology, neuroscience, and human-computer interaction that approaches user experience design through the lens of human behaviour.Therefore, we discussed some of the principles and theories behind the design decisions backed by psychological principles. You can read more about each principle and theory on the <a href="https://lawsofux.com/" target="_blank" rel="noopener noreferrer">Laws of UX</a> website.Heuristic Aesthetic-Usability Effect Fitts’s Law Goal-Gradient Effect Hick’s Law Jakob’s Law Miller’s Law Parkinson’s LawPrinciple Doherty Threshold Occam’s Razor Pareto Principle Postel’s Law Tesler’s LawGestalt Law of Common Region Law of Proximity Law of Prägnanz Law of Similarity Law of Uniform Connectedness Law of Symmetry Law of Closure Law of ContinuationCognitive Bias Peak-End Rule Serial Position Effect Von Restorff Effect Zeigarnik EffectColor psychology Maslow’s hierarchy of needs<h4 style="margin-left:0px;">UX vs UI</h4>A crucial thing to explain to someone new to this field is the difference between UX and UI and why they are two completely different things.UX = User experience UI = User interfaceAs defined by <a href="https://www.interaction-design.org/" target="_blank" rel="noopener noreferrer">the interaction design foundation</a>:<blockquote> “User interface (UI) design is the process designers use to build interfaces in software or computerised devices, focusing on looks or style. Designers aim to create interfaces which users find easy to use and pleasurable. UI design refers to graphical user interfaces and other forms—e.g., voice-controlled interfaces.”</blockquote>Simply put, UX is how it works, and UI is how it looks. Together they create an end product.<h3 style="margin-left:0px;">2. UX processes</h3>There are several stages in the UX life cycle. They primarily originate from the design thinking process and are defined in different ways but often overlap. The UX design is an iterative process, not a linear one, so it is not uncommon to go back and forth between some of the phases.<h4 style="margin-left:0px;">1. Product definition</h4>In this phase, the idea behind the product is explored and more clearly defined. This is usually done in collaboration with stakeholders, where the UX designers brainstorm with them and try to grasp the ideas and goals thoroughly.This phase usually includes stakeholder interviews and various sessions, defining the product in terms of what it is, defining who target users are, and their incentive to use the product.Business goals also need to be clearly defined. Concept sketching is also done during these workshops or sessions. Low-fidelity mockups of the product are often created as paper sketches.At the end of this phase, there should be a set of documentation containing the most critical agreed-upon things about the product. What follows is a kick-off meeting with the whole team that will be working on the product. The goals, scope, timeline, and everything connected to the product development are discussed during the meeting.<h4 style="margin-left:0px;">2. Research</h4>The next phase is user and market research, which outcomes should confirm the product’s value on the market and explore whether there is a user base potentially interested in using the product. Establishing the product concept value during this phase, early in the process, can save a lot of time and money.The scope and length of research depend on the complexity of the product, timeline, resources, etc. It can include user interviews to understand the users and competitive analysis to understand the industry, competition and identifying opportunities.<h4 style="margin-left:0px;">3. Analysis</h4>During this phase, insights are drawn from the data collected in the research phase. Designers create user personas that represent different types of users. The most important thing while creating personas is to use actual data and real users, not to develop users we think should use our product. They should represent our real target audience.Besides creating personas, user stories and storyboarding are often done. User stories help identify all the interactions with our product from the users’ perspective. An example of a user story can be, “As a user, I want to register successfully so I can use the product”.<h4 style="margin-left:0px;">4. Design</h4>When the analysis phases are finished, and everything is clearly defined, we move to the design phase. This phase contains different activities such as creating user flows, IA, wireframes, prototypes for the final UI, etc. At the end of this phase, a design system is created, containing components, a colour guide, a typography guide, etc. The design system helps developers implement the design correctly.<h4 style="margin-left:0px;">5. Validation</h4>During this phase, we see whether the design will be suitable for our users. It is usually done when the prototype is finished and can be done with a low-fidelity prototype created with wireframes or a high-fidelity prototype containing the final UI. Besides this, only small parts of the prototype or separate functionalities can be tested, depending on what we want to validate. Testing the prototype before development saves a lot of time and money. Changes are more easily implemented, and the product can be tested again and again until our users, and we are satisfied.&nbsp;Testing can be done with other team members and stakeholders, but testing with real users is the most important thing. It can be done live or online, with many software options available for online testing.We also discussed the most common activities and processes performed during these stages. They depend on the size of the project, the timeline, client needs and are therefore incorporated and chosen in the planning phase.Some of them are:<ul><li>UX Research</li><li>Information Architecture (IA)</li><li>User flows/journeys</li><li>Wireframing</li><li>Prototyping</li><li>Usability testing</li></ul><figure class="image"><img src="https://undabot-web.s3.eu-central-1.amazonaws.com/media/ef0b160cd47aeac0a67dea89904642d7.jpeg"></figure><h3 style="margin-left:0px;">3. Bad UX</h3>What is considered a bad UX? If the users can’t (simply) find what they are looking for or (simply) do what they want with our product, UX must be the problem. We put “simply” in brackets because sometimes UX is good, but the process is long and not so simple, for example, opening a bank account or buying insurance where you need to follow more steps.If our users get frustrated, stop using our product, or need help to figure out how to use it, UX is bad, and we need to reevaluate it.<h4 style="margin-left:0px;">Dark patterns</h4>Dark Patterns are UX/UI interactions created to deceive and mislead users into doing something they don’t intend to do.Some famous examples of dark patterns are Amazon’s deletion of an account that is challenging to find on their website, so users mostly give up and keep their accounts. Another example is Booking.com’s “only one room left”, “you’ve missed a good opportunity”, “the best price in town”, where you can’t be sure if this is true, and the point of using it is to create a sense of urgency with the users, so they don’t hesitate and buy something immediately. These are also often used on different webshops.A list of dark patterns was created by <a href="https://90percentofeverything.com/about/index.html" target="_blank" rel="noopener noreferrer">Harry Brignull</a>, who also coined the term “dark patterns”.<ul><li>Bait and Switch</li><li>Disguised Ads</li><li>Forced Continuity</li><li>Friend Spam</li><li>Hidden Costs</li><li>Misdirection</li><li>Price Comparison Prevention</li><li>Privacy Zuckering</li><li>Roach Motel</li><li>Sneak into Basket</li><li>Trick Questions</li></ul>Read more about <a href="https://www.darkpatterns.org/" target="_blank" rel="noopener noreferrer">dark patterns</a>.<h4 style="margin-left:0px;">How to improve bad UX?</h4><ul><li>understand the reasons behind bad UX</li><li>understand stakeholders’ vision</li><li>understand user goals and expectations</li><li>test, test, and test some more!</li></ul><h3 style="margin-left:0px;">4. Group assignment</h3>Participants formed groups and sketched low-fidelity wireframes on paper in 30 minutes. We gave them a fictional app and asked them to sketch a home screen and one other screen with the listed elements. One of the participants presented their solution, which we then commented on.It was a simple way for them to try out what they were learning about, and everybody was interested in the assignment and actively participated. These assignments are always good in workshops to assess whether the participants understood the matter covered.<figure class="image"><img src="https://undabot-web.s3.eu-central-1.amazonaws.com/media/047e9e5127e5db7ef160a8d3a3306e29.jpeg"></figure><h3 style="margin-left:0px;">5. What are user interface platform guidelines?</h3>Design guidelines are sets of recommendations on how to apply design principles. Designers use them to provide a positive user experience to their users.While designing mobile applications, we use <a href="https://material.io/design" target="_blank" rel="noopener noreferrer">Material Design</a> by Google for Android and <a href="https://developer.apple.com/design/human-interface-guidelines/" target="_blank" rel="noopener noreferrer">Human Interface Guidelines</a> by Apple for iOS. These guide us to use elements known to users, such as dialog box, navigation, buttons, etc., and help to adapt the design to all screen sizes. Using elements from the guidelines helps users, since they are familiar with them and don’t need to think about how to use something. The guidelines also help developers since they already have the code for the most often used elements.Using these guidelines is not a must, but to have good UX and happy users, it is recommended to follow some basic rules. One important thing to add is that following guidelines doesn’t mean that UI will be the same as every other app. There is still freedom in creating exciting and beautiful UI following them.One thing to keep in mind: you don’t have to know these rules by heart. You should read them and understand them, so you will know where to look when you need something.But while designing websites or web applications, these are some of the rules to follow to have good UX:<ul><li>Simplicity</li><li>Visual Hierarchy</li><li>Navigability</li><li>Consistency</li><li>Responsivity</li><li>Accessibility</li><li>Conventionality</li><li>Credibility</li></ul><h3 style="margin-left:0px;">6. How and where to learn</h3>There is a vast amount of information and resources available online to learn from. The number of different resources can sometimes get overwhelming, so we tried to help with our suggestions.Books <a href="https://sensible.com/dont-make-me-think/" target="_blank" rel="noopener noreferrer">Don’t make me think</a> by Steve Krug <a href="https://www.nngroup.com/books/design-everyday-things-revised/" target="_blank" rel="noopener noreferrer">The design of everyday things</a> by Don Norman <a href="https://uxmag.com/articles/100-things-every-designer-needs-to-know-about-people" target="_blank" rel="noopener noreferrer">100 things every designer needs to know about people</a> by Susan Weinschenk <a href="https://www.sciencedirect.com/book/9780123848697/observing-the-user-experience" target="_blank" rel="noopener noreferrer">Observing the User Experience: A Practitioner’s Guide to User Research</a> by Elizabeth Goodman, Mike Kuniavsky <a href="https://www.invisionapp.com/inside-design/about-face-essentials-interaction-design/" target="_blank" rel="noopener noreferrer">About Face: The Essentials of Interaction Design </a>by Alan Cooper, Robert Reimann, David Cronin, Christopher NoesselLinks <a href="https://www.interaction-design.org/" target="_blank" rel="noopener noreferrer">Interaction Design Foundation</a> <a href="https://lawsofux.com/" target="_blank" rel="noopener noreferrer">Laws of UX</a> <a href="https://www.nngroup.com/" target="_blank" rel="noopener noreferrer">Nielsen Norman Group</a> <a href="https://uxdesign.cc/" target="_blank" rel="noopener noreferrer">UX Collective</a> <a href="https://www.coursera.org/professional-certificates/google-ux-design" target="_blank" rel="noopener noreferrer">Google UX Design Professional Certificate</a> <a href="https://uxplanet.org/ux-ui-design-growing-list-of-top-resources-last-update-10-2021-66e053cdb3c4" target="_blank" rel="noopener noreferrer">UX/UI Design Resources</a> <a href="https://humanebydesign.com/" target="_blank" rel="noopener noreferrer">Humane by design</a>Podcasts <a href="https://uxpodcast.com/" target="_blank" rel="noopener noreferrer">UXPodcast</a> <a href="https://xd.adobe.com/ideas/perspectives/wireframe-podcast/" target="_blank" rel="noopener noreferrer">Wireframe podcast</a> <a href="https://www.usersknow.com/vidcasts" target="_blank" rel="noopener noreferrer">Users Know</a> <a href="https://uibreakfast.com/category/podcast/" target="_blank" rel="noopener noreferrer">UI breakfast</a> <a href="https://designdetails.fm/" target="_blank" rel="noopener noreferrer">Design Details</a> <a href="https://userdefenders.com/podcast/" target="_blank" rel="noopener noreferrer">User Defenders</a><h3 style="margin-left:0px;">Conclusion</h3>During this workshop, we scratched the surface of the vast UX field. There is so much more to learn and adapt, but we hope we helped the students with some basic understanding and good points on why it is essential to put their users first and how to do that.&nbsp;They should also keep in mind that if something seems reasonable to them, it doesn’t mean their users will see it as reasonable; that is why testing is one of the most important things to do during this process.&nbsp;We finished the workshop with a group photo, a tour of our offices, goodie bags and a message to contact us if they need more information or help with their projects. We are always open to sharing knowledge about tech topics and <a href="https://www.designrush.com/best-designs/apps" target="_blank" rel="noopener noreferrer">good app design</a>!

UX for beginners - learn the basics, principles and processes

Vedran

The first thing that pops into most people’s minds when someone mentions the term “design” is most likely something visual. The point of this post, however, is that that “visual” aspect is just one (admittedly important) chapter in the wider story about design and, that that particular story includes a few more important chapters that often get overlooked.<hr>Throughout this blog, we’ll try to inspect and analyze the process by which the software solutions get designed, and place the UX/UI design in its rightfully deserved and crucial place within that context.Additionally, and arguably even more importantly, we’ll try to identify another crucial, and often overlooked component of the overall design process — the functional design, and see how we can use this newfound knowledge to “level us up” in regard to our peers and competitors.We’ll start our analysis by finding out *why* the software solutions get designed in the first place.We’re in the business of solving problemsOne of the basic premises that we’ll base our discussion upon is this:Anyone who has a problem (that they are aware of), will be willing to compensate someone for solving that particular problem, where the compensation would be proportional to the individual’s perceived importance of that problemThat is really just a fancy (and admittedly, a bit convoluted) way of saying that the money in any business (including the IT agency business) is typically made by solving customers’ problems and getting compensated for the effort. Note that that statement holds true even if the said customers had no idea that they had a problem until you presented them with the solution in the form of your new product.So if we agree that we make money primarily by solving problems, we then need to figure out what exact problems are we solving for *our* clients?Well, there are two main ones. The first one is fairly obvious, they have a business idea — ie. an idea of how to solve some real-world problems that their potential customers might have (whether they know it or not) and as a consequence, get the compensation from them — but they don’t have any means of embodying that solution it in a form of an IT system such as web or mobile application.Or put in another way, they cannot create a technology-based “idea vehicle” for their business idea by themselves. That particular problem we can obviously easily solve for them and get paid for doing so, but, there is another problem, perhaps one that is not so obvious, but is nevertheless extremely important for our discussion.That second problem is the fact that our clients are typically not technical experts(*), and have rarely (or ever) engaged themselves in the software development projects in any significant depth, but their career paths (or salary bonuses) are more often than not, linked to the success of that software development project.As a consequence, they feel quite like “fish out of water” when it comes to designing and developing the technical idea vehicles(*). And to exasperate the problem further, IT projects in most organizations tend to be of a “revenue-generating” or at least “revenue preserving” kind, and as a consequence, their success is often linked to the career paths of the people involved (those whose projects tend to fail, usually fare worse in the long run than those whose project tend to succeed).And the proverbial “cherry on top” of all that is the fact they know damn well that most IT projects fail, at least to some degree.That’s quite a “pickle” to find oneself in.So, let’s do a quick recap here. What we’ve postulated so far is that we make money by solving our clients’ problems and that our potential clients typically have the following set of these:&nbsp;<ol style="list-style-type:decimal;"><li>They have a business idea (developed to a certain degree) but they have no internal means of embodying that idea into a technical product — ie. they cannot build “an idea vehicle” for their business idea themselves,</li><li>They are aware that they are not experts(*) in the art of defining, designing, and building a technical product, but that the outcome of the product/project they are assigned to will affect their career or their salary/bonuses at least partially,</li><li>They know that the IT project tends to be brittle and more often than not fail for numerous reasons.</li></ol>&nbsp;(*) although some might consider themselves to be technical experts and even can have an actual technical background — unless they can produce a comprehensive a set of functionally complete and consistent requirements themselves (and I have yet to meet a client that can do that) — they still have the same problem.Luckily for them (and us — as we get our money for solving other people’s problems, remember?), all those problems fall well within our area of expertise, provided that we understand the process of how solutions get designed and can use it to our (and our clients) advantage.<h2 style="margin-left:0px;">The “solution space” of an engineering problem</h2>Let’s consider how we’d go about finding a solution for the first problem stated in the previous chapter (we’ll deal with the latter two in the next post as this is a multi-post topic).Let’s restate the problem in a form of a task or an assignment – ie. state what we need to do in order to solve our particular problem:<blockquote>Define, design and develop a “business idea vehicle” that embodies the client’s business idea in form of a IT system that is functionally complete and consistent, visually and ergonomically pleasing and of optimal technical quality for the scenario it would eventually be used in the “real world”</blockquote>That is an engineering problem right there, and a thing with engineering problems is that they always have multiple solutions. So we’ll introduce a new term here, and we’ll use it heavily for the remainder of the argument in this text— we’ll call a set of all possible solutions for an engineering problem a “solution space” for that particular problem.<figure class="image"><img src="https://undabot-web.s3.eu-central-1.amazonaws.com/media/11805b96771464bf527a17a9d4f2903b.png"></figure>Solution space for the “two-bedroom house” problem<h2 style="margin-left:0px;">The design is navigating and molding the solution space</h2>It stands to reason that if there is a number of possible solutions within the solution space of a given problem, and if we typically select and develop just one of those possible solutions, then there must be some way of choosing a particular subset of solutions from that space and even molding that actual space to our liking.Well, there is a way and what I propose here is the following:Any design(*) process is the process of navigating through and/or molding the solution space of the particular problem.or alternativelyThe process of selecting individual solutions form the solution space of a given problem is called (solution) design(*).(*) Note that the term “design” here is used in its broadest meaning and since the term is heavily “loaded” to mean “UX/UI design”, I typically try to use the term “solution design” instead. But I wanted to point out what I believe the design process is — when considered in its most abstract form.We’ll come back to this statement later, but first, in order to understand the position of the design in a wider context of the software development process, we need to define the process itself.Any software (and not just software) development process goes through the following four basic stages or steps: (they can be, and sometimes are, named differently, or decomposed into more fine-grained sub-steps, but for our purpose, this simple flow will do just fine):<ol style="list-style-type:decimal;"><li>Discovery (the process of specifying the “problem” (business idea) in enough detail so that the solution for the problem can be designed. — defines the “what”s and occasionally some of the “why”s),</li><li>Design (the process of selecting the preferred solutions from the solution space of the problem defined in the discovery phase, composed of three components — functional, visual, and technical —defines the “how”s),</li><li>Development (it’s…well, development… and also it’s out of the scope of this post, so we’ll happily ignore it for now),</li><li>Delivery (although there are some connections with the discovery and design stages through the written acceptance criteria, the delivery is also outside the scope of this post, so we’ll ignore it too).</li></ol>There is nothing complicated or particularly enlightening about the process and its steps depicted above, except for one thing, and I’ll state it again, clearly in case you’ve missed it — because it’s extremely important.The design of any technical (IT) solution is not a monolithic process but is rather composed of three distinctive design processes: functional, visual, and technical. Each of those process involves different experts within your organization.<h2 style="margin-left:0px;">We’re all good developers (and UX/UI designers)</h2>At this point we should have a fairly clear idea of why and how we design the software solutions and so now I want to present you with one of the key propositions of this text:We all do the development stage of the software development process more or less equally well, the thing that make each of us different is the solutions we choose to develop.What I mean by it is that the software development market has matured, long gone are the days of the 2010s and inept UIs and untested PHP4 spaghetti code FTP’d to the webroot folder of the default apache installation on a shared hosting account. These days, pretty much everyone has decent internal processes, uses appropriate and modern tech stacks, performs automated testing and CI/CD, and can design and produce industry-standard UIs and the UX that goes alongside them.So if we all do development comparatively well, that leaves us pretty much only with the processes of defining the problem and selecting the solutions from the solution space as the obvious candidates for the things that we might want to develop further within our organization if we want to distinguish ourselves from our peers. And since I’m stating things left and right here, I’ll claim the following is also true:The design phase of any software solution development process, happens for any project in it’s entirety, regardless of whether we, as an organization, are aware (and in control) of it’s individual aspects (functional, visual and technical) or not.So, if we combine the last two premises, what logically follows (at least for me), is:<ol style="list-style-type:decimal;"><li>Design (and especially its functional aspects) is the area where we stand to gain most in the context of our overall competitiveness — since in other areas it’s much harder to offer something different than our competition,</li><li>It makes sense to master the process that makes us individual and raise ourselves above the group of our peers and that also happens regardless of whether we control it or not (with unstable and unreliable results in the latter case).</li></ol>&nbsp;And that neatly brings us back to the opening statements of this post, as for most, the design process is synonymous with the UX/UI design, but what I’ve hopefully demonstrated here is that UX/UI design is just one (very important) part of the overall process of the solution design, and there is another, often neglected one. The functional design.<h2 style="margin-left:0px;">Conclusion and summary (the first one)</h2>The functional design is a topic in itself, and it is very reliant on the skillset of the person performing it (spoiler alert, it’s someone almost but not entirely like a business analyst), and therefore we’ll address it in our next post.To wrap things up for this post, however, we’ll summarize what we’ve established so far, and then we’ll (hopefully) build on that foundation later:<ol style="list-style-type:decimal;"><li>We solve problems for our clients — and that’s how we earn our money,</li><li>The problems we solve are of an engineering kind — since what we build are technology-based “idea vehicles”,</li><li>Every engineering problem has multiple solutions, and the set of all solutions to a given problem composes what’s called the “solution space” for that particular problem,</li><li>Design is the process of navigating and molding the solutions space and has three aspects — functional, visual/ergonomic, and technical,</li><li>We all do development well, what sets us apart is which solutions we choose for development, and that is determined by the design process. Or in other words, the quality and versatility of our design process is what sets us apart from our competition,</li><li>All three aspects of the design process will happen for any development project, regardless of whether we control them or not, the only one we typically control is the visual aspect, in a form of the UX/UI design.</li></ol>If all that holds true then it makes a lot of sense to become aware of the functional aspect of the solution design process and try to understand it and leverage it to our advantage.UPDATED - Check out <a href="https://undabot.com/blog/solution-design-first-part-2-the-functional-design/" target="_blank" rel="noopener noreferrer">The Functional design </a>part 2 now!

solution-design-first-part-one-01.png

Solution design first! Part one.

&nbsp;It probably happened while you were foraging the expanses of the Internet and you came across something like this:<blockquote><a href="https://blog.trikoder.net/software-requirements-specifications-made-somewhat-simple-part-1-7b1949369364" target="_blank" rel="noopener noreferrer">“Given that there is more than one person involved in the development of a given project, and that everyone involved is at least moderately competent and capable of performing their given task — then their ability to clearly communicate the requirements between different actors in the development process is the main thing that will make or break the project.”</a></blockquote>You’ve read it, thought deeply about it, and finally decided that it was one of the most profound things ever written by a human being and that you want in on that sweet, sweet requirements writing action right away.Well, good for you. But we do need to figure out a few things first.<h2>“Can you write?” &nbsp;</h2>You might think that it’s a stupid question to begin with, since you can obviously read and you needed to type something into that search box to even get here. You might also be inclined to point out that besides just being stupid, the question is, at the same time, a superficial one, since the ability to write is something that would obviously be required for a job where you need to document the requirements in some kind of written form.And you’d be right on both accounts if what I was referring to was the basic ability to record your internal monologue in the form of a string of words on a piece of permanent storage. However, I’m not.What I’m talking about here is the level of writing ability where you do just what I described a sentence before, but in a way that is also concise, well structured, grammatically sound, and to top it all off — in a form that is both as easy to read as possible and unambiguous enough to be readily “attachable” to a legally binding document.That is actually not at all easy to do, and I’ll be blunt here — the majority of people I’ve met in my career couldn’t really write their way out of a wet paper bag if their life depended on it. And I’m talking about really smart and otherwise competent people here.By extension and liberal use of statistics, that more likely than not includes you as well.You might argue something along the lines of “but I write on a daily basis — emails and such — and no one seems to be complaining about my writing, you arrogant piece of filth”. I applaud your eloquence, but at the same time, I want to state that your argument is invalid because we’re talking about quite different formats (although you’ve nailed that “arrogant filth” thing right on the head there).The thing is that what most people, at least in my experience, tend to write on a daily basis is mostly short and even very short-form pieces, and those allow for really terrible form, while still being technically readable, simply because your reader’s brain will fill the content holes similar to how it does when you rd smthng wrttn lke ths.The requirements are, however, almost always in medium to long-form and what works for your typical email, simply doesn’t work anymore in that context.Additionally, few mails are ever going to (voluntarily) become an annex to a legal document, and they don’t need to pack nearly as much precise information as a requirement document does. Furthermore, they are usually not a single source of truth for some topic, but rather a part of a conversation — i.e. one of many.My proposition here is that, to write medium to long-form content and still make it digestible to an average reader, you need to write well, not just be able to write. The fact that you can do something relatively effortlessly (write), doesn’t automatically mean that you can do it well.For example, I can swim. I can swim in a sense that if I fall into the water by accident — I won’t drown, and I can and will swim around purely for the purpose of fun. I don’t find swimming that hard.However, when I do jump in, my form closely resembles that of a plucked chicken, and my overall technique is best described as “generally lacking”.In short, my swimming ability is good enough for keeping me alive in the water and even for purposes of pure leisure, but it would be totally inadequate for any advanced task, such as swimming long distances or achieving any kind of speed, etc. If I decided to engage in any of those activities, I’d need to improve my swimming skills considerably.So, you really need to be able to write well. If you can’t, then the first thing you need to do is to learn how to do it. Try with a few single page essays on any topic you’re familiar with, have someone critical (and literate) read it and give you an honest feedback and then go from there.Also, I recommend that you read a good book on the subject — such as, for example, “<a href="https://www.amazon.com/Writing-Well-Classic-Guide-Nonfiction/dp/0060891548" target="_blank" rel="noopener noreferrer">On writing well</a>” (I haven’t read it myself because I’m such a good writer that If I were merely 37 years younger, I’d certainly be considered a child prodigy, but it is truly an excellent book, and you should read it).After you’ve read a book on writing (or even if you haven’t) — just write. There is no other way to get better at it — think of that swimming example — you can read all the books on swimming (and there are many) and watch all the instructional videos on swimming on YouTube, but you&nbsp;will not learn how to actually do it until you get in the water and swim.So, once you’ve learned to write well, we can then move to the next point.<figure class="image"><img src="https://undabot-web.s3.eu-central-1.amazonaws.com/software_requirements_50e8bb8ead.png"></figure><h2>“Do you like to write?”</h2> This is another big one. One that is quite crucial, since, as a requirements writer/architect, you’d be doing a lot of (sic) writing, so you better like it or you’ll hate your job and burn out eventually.This also seems quite obvious, but it goes beyond simply liking the process of expressing yourself through writing. You need to enjoy (or at least not be annoyed by it) the very act of writing, since requirements writing usually requires a lot of rewrites.There is one caveat there, however, and it happened to me as well — liking to write and being able to write well at the same time often also include liking what you have written. This is understandable and almost unavoidable, but unfortunately — in the requirements writing situation, it’s also something you do eventually need to break out of.However well written your requirements are, they are primarily a technical, utilitarian document that should get changed in any of its parts the moment you acquire some new knowledge about the project itself or the context in which it will exist, once it’s built.You are not writing a next great &lt;insert your country name here in adjective form&gt; novel. You are not an artist, but a craftsman first and the writing in the context of requirements documentation is not an art form, but rather a fine craft. If you are really good at it — you can sneak a bit of an art in there and kind of blur the line between the two (think “Tex: the program” by Donald Knuth) but that’s not really the requirement or even a part of the job.However, the pure act of writing is, and since you’ll be doing it a lot, you better enjoy it.If you don’t like to write, you’re out of luck, requirements engineering is not for you and if you still decide to go into it for some reason, you won’t be very good at it and you’ll hate it at the same time(1).If you do like to write, however, then we’re cooking and it’s time to tackle our next topic.<h2>“Do you know the proper technique?”</h2> Finally, we got ourselves an easy one. If you got through the first two, you’re golden.The technique is not that difficult to learn, and there are excellent learning materials available such as “<a href="https://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258" target="_blank" rel="noopener noreferrer">Writing effective use cases</a>” by Alistair Cockburn and “<a href="https://www.oreilly.com/library/view/specification-by-example/9781617290084/#:~:text=Book%20description,very%20short%20iterative%20delivery%20cycles." target="_blank" rel="noopener noreferrer">Specification by example</a>” by Gojko Adzic, just to name a few brilliant ones. But there are many more, including a series of blog posts on the topic of writing software requirements specifications, written by the guy who, if he was 37 years younger, would be considered a child prodigy.However, you do need to know and understand the technique well and not just get quickly acquainted with it and then start breaking the form immediately.Don’t think that just because you can write well and like to write, you can neglect the craft and just “wing it”(2).Always keep in mind that (according to Audemars Piguet — a person whose qualifications include being the master craftsman of the ridiculously precise fine mechanics and most likely being much smarter than me) — ‘To break the rules, you must first master them’.The technique, however, really boils down to understanding and using some standardized forms of writing and structuring the content. Its main benefit is twofold:<ul><li>it provides you with the framework which, if used correctly, will force you to ask yourself and other people questions you might have otherwise overlooked, and&nbsp;</li><li>it assures that the end product would be readable by people other than you — as long as the content you put in is written well and the content itself is of good enough quality to start with.</li></ul>So the technique is comparatively easy (if you can write well) and there are good learning resources available. So if you don’t know it yet — just learn it and we can then move on to the next topic.<h2>“Do you like to learn new stuff (and can you do it quickly)?”</h2> You can’t really write requirements for something you’re ignorant about. Even more so, you cannot really remain ignorant about something you’ve written requirements for.As a consequence, writing requirements for something invariably involves learning the essentials of that something — being, at the same time, fully aware that your knowledge is very spotty, and being able to easily identify knowledge gaps.This fact is even more pronounced if you work for a software development agency, in which case you will often encounter clients from very different domains, and you’ll have to learn the ropes of all those domains quickly, if you want to have any chance of capturing their requirements with any quality — and especially when the client is unable to formulate it’s wishes or ideas well or has a very narrow vision of “what he/she wants”.Let me be clear here, your goal is not to master each and every domain you write requirements for. You will never ever have nearly enough time for that. What you need to be able to do is to quickly identify important bits, figure them out as quickly as possible, and then get to the point where you understand just enough of that domain that the requirements you’re eliciting and wiring down make both business and functional sense to you at every point of their writing. Also, this will allow you to ask precise, exploratory questions in order to identify edge cases and functional gaps — and that is a crucial skill to have as a requirement architect.Remember that you should never, ever produce a set of requirements that doesn’t make functional sense to you. You don’t need to completely understand the business model though, but it also shouldn’t be a complete mystery to you.So, if you don’t like learning new stuff often through the means of, for example, reading non-fiction, engaging in various hobbies, and pursuing knowledge in general, just for the pure joy of learning something new — you probably won’t like this job (and you’re missing out on a bunch of amazing, unbelievable things that happened, will happen or are actually happening around you right now).If that’s the case — you can still make a decent requirement architect, but I’d strongly advise against doing so in an agency setting — but rather in a single industry scenario where you need to learn the basics only once and then update them once in a while.<h2> Conclusion</h2> If the answer to all those questions above is either a sound “yes” (with one or two “not at the moment, but I can and want to learn”) — you’ll be ok. The technique itself is not that hard to learn, and if you do like writing and learning new stuff, then it’s just a matter of learning the techniques and additional polishing of your writing skills.I’ll give you an example of how I feel about this job — it might help you, or it might not, but I’ll tell you anyway, since I like to write.I am, first and foremost, a developer and an application architect, but discovering and documenting requirements is something that I found out I enjoy quite a bit and something that I tend to do more and more as the years go by.It contains a lot of stuff that I like, such as (technical) writing, learning new stuff, discovering edge cases by prying the important information from often uncooperative/confused people, and the end result is fleshing out something that, until that moment, existed only in the minds of those uncooperative/confused people, within their management presentation slides or in someone’s digital equivalent of scrapbook notes.I don’t consider it a fundamentally creative process per se, as I’m not really creating the product for the client or inventing anything at all, but for me, it comes rather close to it.In my eyes, what I do is create and introduce to the world the first material embodiment of that future product/project idea, and, at least to me, that’s pretty cool as well.I liken my role as a requirements architect to that of a good music producer in a recording session, and I think that analogy does hold true. It’s an essential role without which the chain of events, leading from the conception of a product idea and ending in its release into the world, is irrevocably broken and the success is left to chance more than anything else.So the conclusion I’m trying to get across here boils down mainly to these points:<ul><li>Requirements architects are an elusive breed of awesome superhumans</li><li>They play a fundamental and irreplaceable role within the software production process</li><li>I quite like being one</li><li>You might enjoy it too.</li></ul><h3> Addendum</h3> Since it takes all sorts, if that particular combination of doing something while sucking at it and hating it at the same time is exactly what gets you off — then kudos to you (and condolences to the people who’ll be working with you). You actually can do just that, as I’ve done that for at least the first couple of requirements I’ve written professionally — since at that time I had no idea that any techniques existed — but take my advice and don’t do it, it’s an approach that doesn’t scale at all. &nbsp;

So… You’d like to be a requirements architect

So… You’d like to be a requirements architect, eh.png

So… You’d like to be a requirements architect, eh?

Quality product delivery is the goal for every company, so naturally there is a lot of talk about quality assurance, quality control and software testing. Most people think these terms represent the same thing. More precisely, they think that quality assurance and quality control are equivalent to testing, which we would define as exploring the software in order to find bugs.Even though to a small extent this can be correct (in a way that they have the same objective), there is a lot more to it. All the mentioned terms are connected to each other and they actually build on top of each other. In simple terms, Software Testing is a part of Quality Control, and Quality Control is a part of Quality Assurance. So, is it correct to say all of it represents the same thing? No, because Quality Control is more than just testing, just as Quality Assurance is much more than just Quality Control.Let us explore some definitions and explanations on each of them so that we can see the differences and similarities and decide if only one of them is enough to provide a quality product.<h2>Testing</h2>Testing is one of the most important parts of quality assurance and the most known and executed QA activity. As per ISTQB, testing is "the process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects."&nbsp;Basically, testing is a process focused on finding bugs, but also involving the execution of tests.&nbsp;There are different testing types that are performed in order to find as many bugs as possible and execute as many different tests as possible in a definite time period defined by the project timeline, in order to cover all aspects of the software under test.&nbsp;Some of those types include:<ul><li>Functional testing,&nbsp;</li><li>Performance testing,&nbsp;</li><li>Security testing,&nbsp;</li><li>Database testing,&nbsp;</li><li>API testing,&nbsp;</li><li>Usability testing,&nbsp;</li><li>Accessibility testing&nbsp;</li></ul>Tester performs testing manually or automatically (using different automation tools), depending on many factors, including, but not limited to size of the project, complexity of the project, available resources, etc.Testing helps to measure the quality of software and is interested in the improvement of the quality. We can say that finding and fixing bugs increases quality and if fewer bugs are found, it gives more confidence in said quality.<h2>Quality Control</h2><blockquote>Quality control (QC) is defined as “a set of activities whose purpose is to ensure that all requirements are met in the final product.”</blockquote> In order to control quality, we have to measure it and compare it with standards. We do that by using software quality metrics. Also, in order to determine the level of the quality delivered by the final product, we use different quality control activities. Those are deliverable peer reviews (where deliverables are Requirements, Design, Code, Deployment, Test Plan, Test Cases) and testing. Quality control focuses on the quality of the software by:<ul><li>Adopting and implementing activities mentioned above (which include testing);</li><li>Ensuring that all the processes, procedures, etc. &nbsp;designed by Quality assurance are followed correctly;</li><li>Making sure that the deliverables are defect free, acceptable and based on the quality requirements.</li></ul><h2>Quality Assurance</h2><blockquote>Quality Assurance (QA) is “a set of activities for ensuring quality in software engineering processes that ultimately results, or at least gives confidence, in the quality of software products.”&nbsp;</blockquote> Those Quality Assurance activities are: Process definition, Process training, Process implementation and Process audit. Quality assurance focuses on designing processes, procedures, standards, methodologies and making sure they are implemented correctly and continuously improved. Resources, processes and procedures keep the organization focused on goals. In practice, Quality Assurance is usually in charge of:<ul><li>Creating Test Strategy,&nbsp;</li><li>Creating Templates for test documentation (test plans, test cases and bug reports);&nbsp;</li><li>Defining Quality metrics;</li><li>Identifying testing risks and controls;</li><li>Choosing and implementing tools to be used as a support for testing; &nbsp;</li><li>Creating guidelines to be followed for different testing types.</li></ul> Quality Assurance is done throughout the software development process using set resources and processes to help guide the development process in the right direction. In different phases of the process, quality control activities are also performed as a part of Quality Assurance. The goal of quality assurance is to prevent defects, help ensure consistency across different projects in the organisation and to satisfy the customers. Except reaching the goal, QA includes additional advantages like cost reduction (less reworking since guidelines are followed), improvement of employee motivation (more ownership regarding processes is given to the employees), better communication (peer reviews remove some of the hierarchy). Quality Assurance also empowers employees to give feedback and care about quality.<h2>Conclusion</h2>Customer satisfaction is the goal of every company and a way to reach it is through the delivery of a quality product. &nbsp;Quality can be reached only through a combination of proactive and reactive process and introducing QA team into the company ensures exactly that. Quality Assurance team uses procedures and methodologies to prevent defects (QA) and implements procedures during testing in order to discover defects (QC).&nbsp; QA includes QC, but it is also dependent on it because good QA uses QC inputs to correct implemented procedures.&nbsp; Without one of them, we are missing a key ingredient to build Quality as a company’s core value. Use your Quality Assurance team as a stepping stone to promote an approach where “Quality is everyone’s responsibility”. &nbsp;

QA vs. QC vs. Testing - What’s the difference?

Marko 

&nbsp;A JSON API implementation written in Kotlin, supporting your favorite JSON parsers!<hr><h2>What is Izzy?</h2>Izzy is a 🐶. Also, Izzy is a JSON API standard implementation in Kotlin. It’s a library that allows you to plug in your JSON parser of choice, say which types are JSON-API types and it will automagically serialise and deserialise your objects for you from and to JSON API compliant forms. We’ve built it to work together with your favourite JSON parsers, be it Gson, Jackson, or Moshi (in progress) whatever you choose - instead of forcing a parser on you.<h2>How to set it up:</h2>1. Add JitPack or MavenCentral repository to root project <code>build.gradle</code> file:allprojects {
 &nbsp; &nbsp;repositories {
 &nbsp; &nbsp; &nbsp; &nbsp;...
 &nbsp; &nbsp; &nbsp; &nbsp;mavenCentral()
 &nbsp; &nbsp; &nbsp; &nbsp;maven { url 'https://jitpack.io' }
 &nbsp; &nbsp;}
}&nbsp;2. Add a JSON-Parser dependency to app/module level <code>build.gradle</code>Jackson:implementation 'com.undabot.izzy-json-api-android:jackson-adapter:&lt;version&gt;'Gsonimplementation 'com.undabot.izzy-json-api-android:gson-adapter:&lt;version&gt;'3. Register the types you want or need.<ul><li>When you are setting up your instance of <code>Izzy</code>, you need to pass the <code>IzzyConfiguration</code> a list of classes (or just one) you're going to use with Izzy.</li><li>For example, when using <code>Izzy</code> with Jackson, you'd create an instance like this:</li></ul>Izzy( &nbsp; &nbsp;JacksonParser( &nbsp; &nbsp; &nbsp; &nbsp;IzzyConfiguration( &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ArticleResource::class.java, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;PersonResource::class.java &nbsp; &nbsp; &nbsp; &nbsp;) &nbsp; &nbsp;) )4. Let your models extend <code>IzzyResource</code> and annotate them using <code>@Type(“yourTypeHere”)</code><ul><li>relationships must be annotated with <code>@Relationship(“nameGoesHere”)</code></li></ul>@Type("articles") data class ArticleResource( &nbsp; &nbsp;var title: String? = null, &nbsp; &nbsp;var body: String? = null, &nbsp; &nbsp;var created: String? = null, &nbsp; &nbsp;var updated: String? = null ): IzzyResource { &nbsp; &nbsp;@Relationship("coauthors") var coauthors: List&lt;PersonResource&gt;? = emptyArray() &nbsp; &nbsp;@Relationship("author") var authors: PersonResource? = null }5. Add a Retrofit plugin if you use Retrofit (or don’t if you don’t)implementation 'com.undabot.izzy-json-api-android:retrofit-converter:&lt;version&gt;'And you’re ready to be JSON-API Compliant!<h2>Components:</h2><code>IzzyResource</code><ul><li>the base resource class</li><li>ensures your objects has an <code>ID</code>,</li><li>contains <code>meta</code> and <code>links</code> by default if available</li><li>all your resources must extend <code>IzzyResource</code></li></ul><code>JsonDocument</code><ul><li>a wrapper class containing your top-level members: <code>links</code>, <code>meta</code>, and <code>data</code> or <code>error</code></li><li>all <code>Izzy</code> deserialization methods return a <code>JsonDocument</code> from which you can extract the data</li></ul><code>Izzy</code><ul><li>instance of your deserializer to which you pass your Json Parser with Izzy Configuration</li></ul><code>IzzyConfiguration</code><ul><li>configuration of the Izzy Parser. Holds the Classes you'll use with the <code>Izzy</code> (classes annotated with <code>@Type</code>)</li></ul><code>JsonParser</code><ul><li>an interface that wraps popular JSON Parsing libraries - For now, you have modules you can include if you use Jackson and Gson in your project (Moshi on the way...)</li></ul>Custom JsonParserTo implement your own <code>JsonParser</code>, just implement the <code>IzzyJsonParser</code> and <code>JsonElements</code> interfaces and you can use your preferred parserMake sure to add test for it - you can extend existing test classes which will ensure that implementation is valid. (<code>JsonElementsShould</code> &amp; <code>IzzyJsonParserShould</code>)<h3>Annotations:</h3><code>@Type(val typeName: String)</code><ul><li>annotation that associates this class with it’s JSON API type.</li><li>the argument is the JSON API Type of this object.</li></ul><code>@Relationship(val name: String)</code><ul><li>annotation that associates the field with a JSON API relationship.</li><li>Izzy's relationships can be set on both single and Collection based objects.</li></ul><code>@Nullable</code><ul><li>used when field should be serialized to <code>null</code> for <code>null</code> value</li><li>if not added to field, <code>null</code> values will be omitted from json</li></ul><h2>Under the hood</h2>Under the hood, Izzy uses reflection to find your relationships, deserialize them and bind them to the resource.<h2>! Limitations !</h2><h3>Deserialization</h3><ul><li>relationship <code>links</code> are not yet supported</li></ul><h3>Serialization</h3><ul><li>custom attributes naming is not used when attributes are serialized<ul><li>parser is currently using field name directly and not property from <code>@SerializedName</code> or <code>@JsonProperty</code></li><li>e.g. <code>@SerializedName("custom_name") var name: String</code> will be serialized to <code>name</code></li></ul></li><li><code>links</code> serialization is not supported currently on any level</li><li><code>meta</code> serialization is not supported currently on any level</li></ul><h2 style="margin-left:0px;">Example - using Jackson and Retrofit</h2>Define resource modelsimport com.fasterxml.jackson.annotation.JsonProperty import com.undabot.izzy.annotations.Nullable import com.undabot.izzy.annotations.Relationship import com.undabot.izzy.annotations.Type import com.undabot.izzy.models.IzzyResource@Type("articles") data class ArticleResource( &nbsp; &nbsp;// Default values are set because an empty constructor is required &nbsp; &nbsp;@JsonProperty("title") var title: String? = null, &nbsp; &nbsp;// Field will be serialized to `null` if value is `null` at `@Nullable` annotated field &nbsp; &nbsp;@Nullable @JsonProperty("description") var description: String? = null, &nbsp; &nbsp;@JsonProperty("keywords") var keywords: ArrayList&lt;String&gt;? = null, &nbsp; &nbsp;// non-resource object within attributes &nbsp; &nbsp;@JsonProperty("custom_object") var customObject: CustomObject? = null ): IzzyResource() {&nbsp; &nbsp;@Relationship("coauthors") var coauthors: List&lt;Person&gt;? = null &nbsp; &nbsp;@Relationship("author") var author: Person? = null }@Type("persons") data class PersonResource( &nbsp; &nbsp;@JsonProperty("name") var name: String? = null ): IzzyResource() {&nbsp; &nbsp;@Relationship("favorite_article") var favoriteArticle: ArticleResource? = null }
Initialize Izzy parser// Register all resources in Izzy Configuration val izzyConfiguration = IzzyConfiguration( &nbsp; &nbsp;arrayOf( &nbsp; &nbsp; &nbsp; &nbsp;ArtistResource::class.java, &nbsp; &nbsp; &nbsp; &nbsp;PersonResource::class.java &nbsp; &nbsp;) ) val parser = JacksonParser(izzyConfiguration) // or GsonParser when Gson is used // Initialize Izzy with parser val izzy = Izzy(parser)Initialize <code>IzzyRetrofitConverter</code>val izzyRetrofitConverter = IzzyRetrofitConverter(izzy)Add as Converter factory to <code>Retrofit</code> and create your api serviceval retrofit = Retrofit.Builder() &nbsp; &nbsp;.baseUrl("https://undabot.com") &nbsp; &nbsp;.client(okHttpClient) &nbsp; &nbsp;.addConverterFactory(izzyRetrofitConverter) &nbsp; &nbsp;.buildval apiService = retrofit.create(ApiService::class.java)Api service exampleinterface ApiService {&nbsp; &nbsp;@GET("articles") &nbsp; &nbsp;fun articles(): Response&lt;JsonDocument&lt;List&lt;ArticleResource&gt;&gt;&gt;&nbsp; &nbsp;@GET("article/{id}") &nbsp; &nbsp;fun article(@Path("id") id: String): Response&lt;JsonDocument&lt;ArticleResource&gt;&gt;&nbsp; &nbsp;@GET("person/{id}") &nbsp; &nbsp;fun person(@Path("id") id: String): Response&lt;JsonDocument&lt;PersonResource&gt;&gt;&nbsp; &nbsp;@POST("article") &nbsp; &nbsp;fun createArticle( &nbsp; &nbsp; &nbsp; &nbsp;@Body articleBody: ArticleResource &nbsp; &nbsp;): Response&lt;JsonDocument&lt;ArticleResource&gt;&gt; }<h2 style="margin-left:0px;">Contributing</h2>Please take the time to carefully read the following guide. These rules help make the best out of your time, the code reviewer's time and the general consistency of the project.<h2>General rules</h2>All contributions are handled via Pull Requests (PRs). Your PR must target the <a href="https://github.com/undabot/izzy-json-api-android/tree/develop">develop</a> branch. Your PR is required to pass all tests and contain clear description. By making contributions to this project you give permission for your code to be used under the same <a href="https://github.com/undabot/izzy-json-api-android/blob/master/LICENSE">license</a>.<h2>Reporting Issues</h2>A great way to contribute to the project is to send a detailed issue when you encounter a problem. We always appreciate a well-written, thorough bug report. Before creating new issue make sure to go through issue list and look for potential duplicate of your issue. If you find a match in issues list please leave a vote or additional comment to help us prioritize most common issues.Be sure to include in your issue:<ul><li>Descriptive title - use keywords so others can find your bug (avoiding duplicates)</li><li>Steps to trigger the problem that are specific, and repeatable</li><li>What happens when you follow the steps, and what you expected to happen instead. Include the exact text of any error messages if applicable.</li><li>Version of json-api-android used</li><li>Did this work in a previous version? If so, also provide the version that it worked in.</li><li>Device type &amp; OS version where this issue can be reproduced.</li></ul>

Blog categories

Blogs

Culture of Quality - What is it and how to get it?

UX for beginners - learn the basics, principles and processes

Solution design first! Part one.

So… You’d like to be a requirements architect, eh?

QA vs. QC vs. Testing - What’s the difference?

Izzy JSON API parser for Android

Get in touch

Contact us