Hi all,
I came up with a document which explains what each user can do on each page
according to their role [1]. This will be used as a reference in the
upcoming effort of showing role based and status based help messages to the
users.
The current sample implementation is to show messages for a single role.
The first exercise will be to show messages to users with multiple roles.
The page based static messages are also going to be incorporated by
converting it to a role based method.
e.g. repos and builds page - - - - appowner,dev - - - - "static message A"
application creation page - - appowner - - - - - - - "static message
B"
isuues page - - - - - - - - - - - appowner,dev,qa,devop - - - "static
message C"
By using this method we don't need to write redundant code to retrieve role
based messages and static messages separately. It is better to have
everything in the same file so that it can be replaced easily. The
important thing here is to have a good JSON file structure.
[1]
https://docs.google.com/a/wso2.com/spreadsheet/ccc?key=0ApOmHe7M-ZSHdHBuS0xUV0xkNGJ6aWhPb3lFeVA0UVE#gid=0
Gayan Dhanuska
Software Engineer
http://wso2.com/
Lean Enterprise Middleware
Mobile
071 666 2327
Office
Tel : 94 11 214 5345
Fax : 94 11 214 5300
Twitter : https://twitter.com/gayanlggd
On Wed, Feb 26, 2014 at 12:26 PM, Ashansa Perera <[email protected]> wrote:
> Hi all,
>
> To start up with the usability improvements by having the contextual
> help[1] for the user, we thought of implementing a module which is capable
> of extracting these help messages ( which are configurable ) based on user
> role and show them up in FE.
> We will be maintaining an application status object as well.
> Managing and using this application status object can be handled as follow
>
> 1. We create a property file to store the help messages for different
> actions and roles.
> ie: appowner.add.members = You can add members to your application
> dev.deploy.application = You can deploy the application and test
> it....
>
> 2. When a user clicks on an application, the appliction status object
> would be created for that application and it will be stored in session.
> We can update the object periodically OR we can keep track of the changes
> done and update those fields.
> Some example status would be
> hasMembers = false
> hasResources = true
>
> 3. We maintain a method to get the role,action, subject ( ie: appwoner,
> add, members) as inputs and return the help message with related app status
>
> 4. FE can call the above method to get the textual help and show them
> according to the status
>
> We are going to have a notification mechanism for the async operations we
> do. Related mail thread is [2]
>
> [1]
> http://app.uxpin.com/9b1de71e37adaefd3706c5384b7abcd53de520fb/6422916#0
> [2] [Architecture] [Appfactory] Integrating minimal wall and notification
> mechanism for Appfactory Users
>
>
> --
> Thanks & Regards,
>
> Ashansa Perera
> Software Engineer
> WSO2, Inc
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
