Presenting the User Portal idea to the other partners generated different reactions that in general had been quite positive. While on one side it seemed a good idea to have an object like this in order to centralise the management of user identity and details enforcing the security at the same time, it raised some doubts about how convenient could be from a prototype development perspective to create a unified, general profile structure. The major risk here is that it could potentially lead to spend too much effort on extending/customizing the central profile in order to satisfy dynamic requirements proper of a research prototype.
For the above reasons we’ve decided to spend some time in order to design a way that could be flexible enough to accommodate the use cases which actually have an already well defined idea of what the user profile should contain (i.e.: the Personalised News scenario) while leaving room for profile extensions in a way that could be easy to use from both the front-end and the back-end interfaces allowing future integration if desired.
Provided this assumption the User Portal work has been divided in two main parts: the first one focused on the user interface redesign and the second one aimed at improving the extensibility of the stored profile.
While the former is easy to understand the latter pushed us in a direction where the integration of the Beancounter module developed by Pronetics could add a lot of value. Pragmatically this translates into having the user identity and static details seamlessly connected to social network and the related collected social activities. The power of this feature is that the NoTube user profile could be then considered not only composed by an identity, authentication credentials and standard user details but also from a dynamic part that is used and reflected into recommendation services.
In addition to that, again in order to maximize the flexibility, the current vision is that the profile will also incorporate a custom set of details proper of the considered “NoTube application”. In other words: the idea is that every application running on top of the NoTube platform can create an XML-based manifest (using an agreed format) to be trusted and installed in the NoTube user portal. Once a new user would like to register, it will be presented with a list of available applications (the 3 prototypes could be considered candidates) that the user can subscribe by explicitly allowing these applications to access his/her profile details. Once an app is selected, a new tab in the user interface will be added rendering the form the user should complete in order to provide enough custom details for the considered application to run. We called this part of the user profile “application configuration” and the details of the expected parameters are expected to be included in the application’s manifest. The back-end counterpart will simply provide RESTful services to retrieve this “custom package” so that the application logic will be then enabled to make use of the proprietary data in the desired way, in addition to the standard profile.