Thoughts on Registration and Configuration
DMP Guru is just a few days from official launch, though I am not sure what that means. This launch date has been scheduled to be shortly after the release of Django Music Publisher 19.11 Epiphany. Which happened earlier today.
I am doubting some of the decisions I made early on. There is no time to do anything about it before the launch, and certainly not without some real feedback after the launch, but here are some thoughts on the whole process of registration and configuration.
There are really only two steps. The first step is user registration. There are two registration forms, one on the home page, that was an afterthought, and one on a separate “Registration” page. There are just two more pages, “About & Contact” and “Terms of Service”. Once either form is filled out correctly (which should be really simple), the user receives a verification email. By clicking on a link in it, the user is verified.
Then they can log in with credentials they just provided. The homepage is now a profile page. Until configured, the DMP instance does not really exist and the demo period has not really started yet. Other than a row in the database, this registration has no side-effects. Any visitor can pretty much come to this point, and I have no doubts so far.
At this point, however, a user can only do two things. Changing a password has no side effects, so it is not an issue, but the fact that the only other option is to configure the DMP instance brings my first doubt.
Required configuration fields include IPI Name number, and that one has two checksum digits. And the smallest valid IPI name number is 199. This will stop most bots and non-music-publishing humans that passed the email validation. I saw it as a feature and protection against spammers, but this is also a cause for doubt.
For some strange reasons, publishers quite often do not know nor have the access to their IPI name number. Surely, they have registered and the clock is not ticking, they may come back at a later point, but will they?
At some point, a user configures their instance properly. For someone with an actual IPI name number, it should be a simple thing. At that moment the process of deployment starts. This process takes time. And brings doubts.
What happens under the hood is that this deployment process is split into several tasks, each with several steps, and a deployment worker (a process, not a human) goes through them one by one. Normally, it takes about one minute to do everything. But in each step, some things can go wrong, usually due to network issues, and the tasks have to be repeated. So, it can take more, in really bad cases, maybe even half an hour.
There is nothing I can do without testing the process in real life with dozens of new users. Some steps are pretty much fixed. If the server can not acquire SSL certificate, then it has to repeat trying until it does. In other cases, it may be possible to make some improvements. A local copy of the code could exist on every host, which would reduce the number of issues during the installation due to network issues, but it would add an additional element to the stack. One more thing that can go wrong.
Anyway, the doubt I really have here is whether to send an additional email when the instance is first deployed. But where do I draw the line? Do I have to do it every time the user changes settings? Every time we upgrade the instance? If I do it that often, must I not enable the option for the user to unsubscribe?
And we have not even come to the point when the user logs in for the first time into their DMP instance. A couple of doubts are related to that moment, actually. At that moment, if the instance has no users, then the user is created with the same username and password as the control panel user. Shall I ever need to have multiple users per instance? If so, is this the best approach?
I thought that with time, the launches and releases would start coming with fewer doubts. It does not seem to be so.