Good Practices for Creating Power Apps

Throughout this book, we have focussed on the technical elements of creating apps, covering everything from data sources to controls and user interactions. Knowledge of all these topics will certainly help you to get a good grasp of creating apps, but there are many other considerations that should be considered to help you create amazing apps each time, with reduced rework and the frustrations that come with that.

To wrap things up, I’m going to share the key things that I believe should be thought about when creating your apps. This is very subjective, and you may find your own ways of doing things, but this will get you started. We will cover:

• Security – thinking about it sooner rather than later
• Data sources – considering your options before deciding on the one to use
• User journeys – putting yourself in the shoes of your users
• Wireframes – saving yourself time by considering...

Don’t leave security until last

For me, the most important consideration that should be thought about is the security of the underlying data. Too many times I have seen apps created without the necessary thought about what protective measures should be applied to the data.

Is there a risk if any of the data that I’m storing can be seen by other members of the organization? Do I need to lock that data away somewhere that gives me the utmost control over what goes into it? Do I need to configure permissions for each row or record in a table? Or do I need to go lower than that and apply security to a column?

They’re all questions that you need to ask. Secure by design is a key development principle that we should all be working toward. Creating an app and then trying to shoehorn security in afterward is extremely difficult, as I guarantee you’ll need to go back and make some quite fundamental changes. Whether those changes are to the data source itself...

Consider your data source options carefully

One of the great things about Power Apps is that we can use a multitude of different data sources, but we have to be constantly aware of the advantages and disadvantages of each. Personally, I have a method of escalation for my various data sources that helps me to find the right tool for the job.

Excel

Excel is where I tend to start a lot of my developments, although realistically I never consider this as a data source for anything in production. The risk of the file accidentally being deleted, the lack of control over each row, plus issues with a lack of simple data validation carry far too much of a risk for me.

Where Excel does really play a part in my development, though, is for quick and easy modeling of my data structures. Using Excel, I plan out my various tables of data, along with any columns of data that could be included within the table. I don’t worry about relationships at this point, but having my data...

Plan your user journey

So many times, I have seen the user journey neglected by budding app developers. Again, I’ll hold my hands up and say that sometimes I’m so excited by the prospect of what my app could be, that I just dive straight in and start creating. This has then meant that I’ve ended up missing key considerations about what my user journey through the app is going to be.

What I’ve found more useful though is planning the user journey before I start writing. So what does this mean to you as a developer? It means that you need to first consider what the user needs to do to achieve an effect, e.g., my user needs to use the app to create a new entry in a system, or my user needs to use the app to update an existing entry.

Once you have your key activities noted, you can then start to plan how the users achieve that. Keep in mind that you don’t need premium tools for a basic journey; quite often, I just use something as simple as PowerPoint...

Wireframes

Wireframes are an awesome tool for being able to bring your user journey to life, but also for communicating your thinking to your end users. We’ve all heard the saying “A picture paints a thousand words,” and wireframes do exactly that. They allow you to start planning out what screens you will need to achieve the goals defined in your user experience mapping. But now we can delve a little bit deeper and start thinking about how we’re going to lay out the screens.

There are tools out there that allow you to develop wireframes, for example, Figma (figma.com), where Power Apps can read the wireframe and construct the app for you. Alternatively, I commonly use something as simple as PowerPoint, with several rectangles on a slide to articulate where I see various controls being:

Figure 23.3: Wireframe for app layout

If I am planning a canvas app, then I will go as deep as what controls I want and where, and doing it in a software...

Design

Depending on where you are in the world, the importance of design may be the highest priority, or it may be slightly lower. As an example, when I have worked with organizations in Western Europe, the key focus has always been on functionality first and design second. So, as long as it works, making it look shiny is secondary. Here in the UK, we are very quick to judge something based on its appearance, so if the app doesn’t look good, then immediately there’s a negative impression generated. These are very sweeping statements and there will be exceptions to those rules, but the key thing is to be aware of what your users are expecting.

Regardless of whether design is a priority or not, we should never underestimate what a good design can do to our app. If we have something that looks and performs well, then we will build engagement, and a nice-looking app can keep users coming back. This doesn’t necessarily mean that you need to start going out and...

Develop for reusability – remember to use components

Reuse is one of the key concepts of pro-code development and is also an area that I see massively neglected in no-code/low-code environments. This is usually because there are lots of little cottage industries appearing consisting of many organizations, who are all creating apps to solve their own problems. While this is a great thing, there must be a body of people, whether that is a champions network or another group, that can try to break down some of the silos to allow others to see what else is being created.

In Chapter 7, Reusable Controls, we looked at the use of components and reusable groups of controls that can be shared with others. While it’s easy for me to say that you should be creating components, putting them in your component library, and using them globally across your organization, in reality it’s a struggle to get this going from the start. While it’s something that you should...

Updates

As much as we like to think that we’ve delivered a great app and that we’re never going to work on it again, that’s rarely the case. There are always things that we want to improve. There are always new technologies and methods of working that we want to introduce into our app. There are constantly those “It would be good if…” statements that we get from our users once they start using it. None of these are a bad thing, because if users are suggesting enhancements, then they are engaged!

When I’ve instructed courses in the past, evolution and updates for apps are a great topic of discussion. From my personal view, I am all for what I call stabilization of the app, which involves checking where the app has been created, whether it’s working, and whether the processes are running smoothly, and I maybe just carry out some basic maintenance when needed. That being said, what I’m always concerned about is the stagnation...

Summary

While the rest of this book has been very technically focused, this chapter has been very subjective, based on my experience. We have gone through the key areas that I feel all developers should go through when creating apps.

We’ve looked at some of the easy ways in which you can design your apps, by first taking into account the key drivers and requirements for a system. The biggest one for me is always security. Giving some thought to not only the security but also the data model means that I can then choose the right storage platform for my data. Remember that you are not limited to one OR another; quite often you may be able to create a better solution by using one AND another.

We spoke about the user element of the app, from both a user’s journey through the app and their interactions to the overall look and feel. An app may be functional, but users’ first impressions may be worse than if you’d spent some time thinking about the overall...

My final thoughts

We are now at the end of this book, but it is by no means the end of the journey. We have tried to cover as much ground as possible, looking at as many parts of the platform as we possibly can, but there are going to be many more challenges awaiting you. Think of this as passing your driving test. While you’re with the instructor, you’re learning the fundamentals. Once you’re out there on your own driving, then you learn how to drive.

The Power Platform has the potential to help people from all walks of life and all aspects of business, which makes it such an important part of the Microsoft ecosystem. To avoid it or to be ignorant of it is so limiting because everyone should be able to take hold of it and resolve their day-to-day problems. Why should we suffer from poor data when a simple form can help us capture information accurately and effectively? Why should we do the same repetitive tasks when we could automate them? A lot of the time...