User Functionality Part 3: Building a Common Account Area
If the framework knows who I am, where do I go to manage my account?
Until this point, the individual applications had been the things users interacted with. The framework existed largely behind the scenes, providing the infrastructure that made those applications work.
User accounts changed that relationship.
The framework now had something that users needed to interact with directly.
That led to the idea of a common Account page.
Rather than having each application create its own account page, the framework could provide one place where a user could see their account and the functionality available to them across the website.
This might sound like a relatively small interface decision, but it reinforced an important architectural principle.
The account belongs to the user, not to the application.
If I use the Publications application and then move to the Marketplace, I shouldn't suddenly become a different user. My identity should follow me.
The Account page therefore became a natural part of the framework rather than an application feature.
But once I had somewhere for the user to manage their account, another question appeared.
What should appear on that page?
This was where the idea of capabilities became particularly useful.
The framework could provide the common account structure, while individual areas of the website could expose the things that a user was able to manage.
For example, someone who had access to the Publications functionality could eventually see:
Manage My Publications
Someone using the Marketplace could eventually see:
Manage My Marketplace Business
These weren't intended to be arbitrary application menu items. They represented capabilities belonging to the user's account.
That distinction mattered.
The framework could provide a consistent vocabulary for what a user could do, while the applications remained responsible for implementing the functionality behind those capabilities.
At this stage, I deliberately didn't need every capability to be finished.
It was enough to establish the structure.
In fact, the account page could show a capability as Coming Soon while the underlying application functionality was still being developed.
That turned out to be useful because it allowed the architecture to be established before every part of the system was complete.
It also made the Account page a kind of map of the platform.
Instead of asking a user to remember which application contained which functionality, the account area could eventually become the central place from which they managed the things that belonged to them.
There was another benefit too.
Because the Account page was framework-owned, its presentation didn't need to be recreated by every application.
The framework could provide the common layout, navigation and account experience, while applications supplied their own functionality where appropriate.
Once again, I was finding that the framework wasn't simply about sharing code.
It was establishing shared concepts.
There was now a shared concept of a user.
A shared concept of authentication.
A shared concept of an account.
And increasingly, a shared concept of what a user was able to do.
That was a significant change from where the project had started.
I had originally wanted to avoid changing the same header in several applications.
Now I was designing a common identity and account experience across the entire website.
And, as usual with this project, one decision led naturally to the next.
If the framework was going to own user accounts, it also needed to establish that the person creating an account actually controlled the email address they had provided.
That would lead to the next stage of the project: email verification.
Comments
Post a Comment