Best practices | Modules | Module size

When you scan your application to create a Module, you might be tempted to keep things simple: create one Module per screen. However, this approach doesn't make sense for all screens. This topic takes you through important considerations on Module size: when it makes sense to split a Module, and what not to do.

Split Modules

Some applications have loads of controls per screen. And typically, users don't have to go through all of them every time. In this case, we recommend that you split your Module: 

  • Keep a maximum of 20 controls per Module. Your mileage may vary a little, depending on your screen size. But Modules of this size are still fairly easy to understand at a glance and to use.

  • Split the Module according to screen areas or requirements, rather than by "all controls for user workflow A", "all controls for user workflow B", and so on. This gives you the flexibility to mix and match Modules and reuse them to test different workflows. Plus, by splitting the screen into sections, you avoid having duplicate controls in multiple Modules. This keeps your maintenance down.

Let's take a look at the Demo Web Shop screen. Here, you can create separate Modules for each: header, footer, ribbon menu, categories, manufacturers, popular tags, featured products, and so on.

Different sections on a screen

You can split up your Module in different ways:

  • If you're still scanning, scan the same screen multiple times. Each time, only add specific controls.

  • If you already have your Module in Tosca, copy and paste the Module and then delete ModuleAttributes from each Module.

And if you find out that a particular ModuleAttribute might work better in a different Module after all, that's no problem. Just drag and drop the ModuleAttribute onto the other Module.

What not to do

In our example in "Best practices | Modules | Order of ModuleAttributes", we talk about duplicating a Module and deleting a ModuleAttribute from one of the copies. And why that's a bad idea in this case.

So, why isn't splitting that particular Module a good solution?

Generally, you want to avoid creating overly specific Modules with just one or two ModuleAttributes. First, they're not intuitive to use or find, especially if the Module folder structure isn't great. Second, having a large number of tiny Modules complicates your maintenance. As your application changes, it'll be increasingly hard to keep an overview of what you have, what you need, and what goes together.

What's next

If you haven't yet, check out our other best practices articles.