DTCPII Team
Author: Maureen Rottschaefer
Below are screen shots of an anticipated web site for the DTCPII Tool. It is noted that these screen shots were compiled by Maureen without review from Andy and Ivan and show a preliminary suggestion of a design. It is the goal of these screen shots to start a dialogue as to what features that have been anticipated by the team would be found useful by our primary customer, Stuart Faulk, in his role as a professor of OMSE 551.
When a user who is not logged into the DTCPII Tool first navigates to the DTCPII Tool website, they would encounter the Existing Processes page which would allow them to see what processes are available and click through all the existing processes without the need to login. Currently, the order of processes is completely random.
Would other headings be desired in a list of processes? If so, please list.
What would be the desired sort order for a list of processes?
[Andy Phen1]
Andy I’d suggest that the application ‘landing’ page looks slightly different depending on whether the user has been authenticated or not.
If not authenticated, then a ‘search for process specification’ section plus maybe a list of the recent activity…similar to something like the ‘latest projects’ section on the cecs projects home page
If authenticated, then same as above but with an added ‘My Process Specifications’ section.
If authenticated and an admin user, then maybe same as above but with some form of ‘view student activity’ section where the admin can select a student & view their process specifications. So, maybe moving this up-front from the admin section since it is likely to be a common instructor task.
A guest user can click Login where they will be taken to this screen to login to the system. The DTCPII Tool does not have a profile section, but rather just assigns the existing roles of User and Admin to a specified user, therefore the password maps to the OMSE credentials used by a user to access the area of Portland State where the web server for this application lives. No passwords are retained in the DTCPII Tool itself, but the password submitted is authenticated against the OMSE credentials and a session cookie or other method of holding state in a web application is used to hold a role ID value for the logged in user during the current session.[Andy Phen2]
Once logged in, there is an authentication made at the top of each web page that checks the value for the logged in user and then returns the navigation menu applicable to that user's permissioning level.
Once logged in, the Login link changes to a Logout link so that the user can expressly Logout of the system and release the session cookie or other method of holding state in a web application when desired.
Andy: Just to clarify the discussion we had on this today.
If possible, I’d like to see user management work similar to the way the Redmine projects are handled – the user authenticates using their CECS account which is managed via CAT i.e. linux accounts. Role assignment is done via linux not our application.
Will make life easier for the course instructor (familiar mechanism), the student (not another account to remember credentials for), and us (we can skip user management use cases).
An administrative user would see the screen above when logged into the system and navigated to the Administration screen. It is acknowledged that this screen is a little on the messy side in its present form, but it is presented as a possible means of having all necessary features on one screen without needing to click through multiple screens to perform differing administrative tasks.
Andy:
Based on our discussion today around download (vs publish) and given the comments above around user management, maybe we can trim this down to just (a) system maintenance / clean-up tasks and (b) process template management (later functionality – we could hard-code the FAST template initially).
End Andy[Andy Phen3]
It is expected that anywhere that a delete action is being performed, there would be a confirmation of the delete on a subsequent page prior to actually performing the delete request for the specified item or items.
It is expected that anywhere that an add action is being performed, there would be a blank page with no data prepopulated in fields presented to a user.
How would you like the administration screen presented?
Are there additional features you would anticipated being needed on this screen that are not presented?
On the Existing Process screen, when a process link is clicked, the process specification for that item would be shown. It is noted that the process displays would duplicate the features of the existing OMSE 551 process tool. Where a process is being edited, the editable areas on a specific page would display as input boxes to allow for editing of the instance data for that item.
Andy: We didn’t get to this section today but I wanted to provide some feedback / comments on formatting of process specifications and the discussion we had around publish vs download.
In my mind, process specifications are created in a draft state and are not viewable by others until they are published. Publication is a specific user activity and creates a new version of the process specification – and can only happen after the specification is completed and valid according to it’s underlying template.
We do need to talk more about the editing experience – in my mind, it should be guided / constrained by the specification’s template (this is where Stuart sees real value in the existing tool)…but we have some artistic license on the actual editing experience and how we store the data. Hence, the RTF discussion in the past.
Once published, the specification can be downloaded – but all that entails is allowing the user to select a specific format & saving the specification locally (for archiving, printing, distributing as needed, etc.)
We do need to decide on the set of formats we plan to support – possibly it suffices to have just one initially – the single hyperlinked document that Ivan suggested. You could argue that PDF is usually supported anyway via built-in OS / printer drivers.
End Andy[Andy Phen4]
On this specific page, the instance data would include “Communication Process” which is the process name, there would be a field displayed for Process ID which would mimic the format listed under Processes of a three letter extension followed by a hypen and three numbers, and there would be a field displayed for the author, in this case “Maureen Rottschaefer” would display in the field and be editable.
A submit and cancel button would also be included.
Above is a list of a display from the existing OMSE 551 process tool which in its editable form would show editable fields for the fields in the “work products definitions” area. State data, such as the Artifact and Debris work products would not be editable by a regular user. An administrator would need to approach this screen through the administration menu so as to be clear that the administrator is editing state data rather than instance data.
Andy: I think we should rename ‘state’ data to be ‘process template’ data.
End Andy[Andy Phen5]
A non-administrative user would see the navigation menu above when logged into the system. It is noted that the anticipated action for logging in is that after the Login page is processed, the user would be returned to the Existing Processes page.
It is also noted, that it is anticipated that it is possible to pull actual names from the OMSE authentication process. If this is not available, then the Hello message will be changed to reflect the OMSE ID of the logged in user.
Andy: Unlikely we’ll have a name – more likely jut the username (again, think Redmine).
End Andy[Andy Phen6]
______
Ivan’s review:
I agree with most Andy’s comments, however generally I do not feel that we should make design and architecture decisions here. I am guessing that we can change everything later, however my vision for the landing page would be the next three screens. Please notice that they are different depending on user rights and login:
- User not logged in (Guest):
- User (Ivan Dontsov) is logged in:
- Administrator logged in:
Please notice that Administrator will see extra “Delete” column in the first grid and additionnaly Administrator will have link to separate screen to create or edit template which is not required functionality but we probably can include it as nice-to-have feature.
[Andy Phen1]
[Andy Phen2]
[Andy Phen3]
[Andy Phen4]
[Andy Phen5]
[Andy Phen6]