Dividing an application and naming the parts for team communication [closed]

Question

Let's say we're building a CMS administration site.

This site (roughly basing myself on Orchard CMS here) is split up in parts like "Content", "Navigation", "Blogs".

"Blogs", is then split up again into: "Authors", "Blog entries", ...

These are concepts that are not useful to the end user, but mean a lot to the manufacturer of the application. In day-to-day communication between developers, testers, PM's, in the source code, and so on, these levels need to be named.

Is there any convention concerning these names? Eg. 1st level is Section, 2nd level is Module, ... Is there a reason something should be called a Module vs a Section vs anything else, does one have a heavier connotation than the other?

Answer 1

There is rarely a reason to name these unless the user can manage them. For example, if the end-user can create new sections and modules then it is appropriate to name those levels. But if they are just managing existing sections and modules it is unlikely that the UI needs to give a name to the hierarchal level at all.

To put it another way, containers that the user doesn't manage need not be named. You personally might have classes in your code named 'Section' and 'Module', but there is no reason to display those names on the screen unless there are buttons named 'Add new Section' or 'Remove Module', etc.

As far as what to name these if this is the case, I have not seen any particular literature on the subject, nor does it seem that there is a significant semantic weight to the words to imply one is higher than the other. I have seen them used in both orders (modules in sections and sections in modules).

They are both very generic though; you may be able to provide better context to the user by using names more specific to your domain. If you have Blogs and Articles, perhaps 'Content Type'? If you expose Authors, Categories, and Tags, then perhaps call them 'Views' since they are multiple ways of looking at the same items. Section and Module are very generic, and if you have any way of providing semantic hints about how the hierarchy is organized it would be better to provide names that inform users.