|
| The login screen. All users have a username and a password and there is currently no support for anonymous/public access. Only status information about the system and the online guide is available in the left hand side table of contents. |
| Now we are logged in and the table of contents to the left is populated in different labelled sections. This table of contents is "object driven" and in this case the logged in user is an administrator of at least one issue Process in the system and thus has the "Process admin" section available. The currently selected entry "Settings" is marked in dark grey. The settings panel has three tabs and the first tab is for user related information - username, password and confirmation. Currently the user can change his own username, but that can be confusing to allow and we will probably disallow it. The form also has two readonly fields showing the issue processes that this user has some kind of access to and any categories that this user has been tagged with. Categories is mainly used for the permission model but allows any form of partitioning/tagging for most of the objects in Gjallar. |
| This is the second tab showing personal information like name, three different available "keys" that can optionally be used, primary and secondary email, phone info and general comment. We are planning to optionally synchronize information like this using LDAP but have not done anything like that yet. |
| The last tab which is shown is per user settings for Gjallar and the form is dynamically generated using a model similar to Mewa/Magritte. As can be seen the system has optional tooltips and integrated help, full timezone and date/time format support per user and a number of other options at the moment. Adding more options is very simple. |
| Now we jump down to the Processes entry under the Help section. Each entry on the TOC opens up a Seaside component in the right hand side content area, which is independently scrollable using CSS instead of frames. Since the use "gokr" has access to six different Processes there is a drop down list at the top to choose which Process I wish to see information about and right now "Support" is selected. The yellow mouse-over tooltip can be seen describing the field we are pointing at regardless if you point at the label or the widget, this uses a javascript library and works in all browsers we have tested. It has a lot of options on how to format the tooltip but we opted for a standard yellow single line style. Below the horizontal ruler we can see number of cases ("case" is the term currently used in Gjallar for "issue"), their status which is automatically calculated based on which stage (node) in the workflow graph they are at. Here we see that all six cases are in the initial stage commonly called "Inbox", but the stages and their transitions can have any names. There is always a single start stage shown in red in the graph and newly created cases still sitting there are "New". Then there are multiple "work stages" shown in grey and cases sitting in any of those are "Open". Some of the stages are marked as "end stages", shown in green in the graph. Cases sitting in an end stage is considered "Closed". The workflow graph is directed (all transitions are directed arrows with a source and destination stage) and there can be multiple transitions with the same source and destination (as can be seen from "Analyze" to "Not solved" for example). All validation rules are associated with either stages or transitions. This means that validation of data is not used to restrict the user from saving it - but to restrict movement of the case/issue to another stage. The idea is that we should not make it hard for the user to enter partial data - the only result is that the case is momentarily restricted in how it can be moved in the workflow graph. The workflow graphs in Gjallar are dynamically and automatically generated as GIF images using Graphviz (including autolayout) and cached on the server. |
| Now we have selected a different Process called "Simple" which is one of the out-of-the-box default Processes when installing Gjallar. This Process has the absolute minimal workflow graph possible in Gjallar which consists of three stages and two transitions. |
| Ok, finally time to actually create a case/issue. Since this user has access to more than one Process the dropdown menu at the top selects in which Process this case is to be created. A case only belongs to one Process and can normally not be moved between them. When selecting Process the form below changes - each Process has its own custom case/issue creation Form. This is the default form with one field added at the top - Source, which refers to the person originating the case - which is not necessarily the same as the Reporter - which is the user entering the case into Gjallar. Subject, description and multiple attachments are standard content for all cases in Gjallar and corresponds to what you would be able to enter using a single email to the system instead of using the web UI. At the bottom we see two buttons for creating the case, the second one takes us straight into editing it after creation which might be useful since the creation form typically has less fields to simplify case creation. |
| Here we have selected a different Process - "Development" at the top and in that Process the administrator allows us to optionally add extra "Forms" to the case while entering it. The user has added a form called "Extra comment" and is now considering removing it again. The added Form becomes an extra "tab" in the UI and these extra forms can be added either as an initiative by the user or automatically when the case reaches different stages in the workflow. This means that the information for each case can be partitioned in different forms and decreasing the "noise" when viewing a case. The fields, labels etc of each form is decided by the Process administrator and each Process has typically its own set of available extra forms. |
| The Development Process has a richer case creation form with three more fields: Responsible, Internal and Severity. A case in Gjallar always has a single user as responsible and some Processes allow the case reporter to select the responsible person while creating the case. Other processes typically use "gatekeepers" that guard the Inbox stage of the Process and delegates cases to other users by putting them as responsible and typically moving the case to a different stage. The screenshot shows that Gjallar has the option to use Scriptaculous autocompletion in user selection (and in other fields too) - just typing "P" shows a drop down list of all users in the system with a name beginning with "P", and it will incrementally narrow the selection while typing. The "Internal" field is just a boolean field added by the Process administrator - I have no idea what that can be :). The Severity field is a single selection list of custom values that the Process administrator has created. Such a "list of values" is called a Custom object in Gjallar and Custom objects can either be manually maintained like this short list of severity levels or they can be mirrored into Gjallar from an external source using for example ODBC. This is a very useful integration mechanism minimizing the need for recreating data that already exists in other systems in the organization. The updating of these mirror objects is done periodically by a scheduler in an incremental fashion. |
| The case has been created and we have now moved down to "View cases" and selected case "13" in the "Support" Process. All cases have unique names in the form of a number which is allocated when the case is created. Cases created in an offline laptop gets a prefix unique for that offline installation. This means that case "13" was created on the server (it has no prefix) and was the 13th case created there - regardless of Process. Case "gokr45" would be the 45th case created in the offline installation with prefix "gokr" - which could be a personal prefix or something else. The name of the case never changes. We are currently viewing the third tab in the tab book, Workflow. Here we see the workflow graph for this Process and the current stage for case "13" is marked with a red ring. We can also see what transitions are available to perform right now - they are green and are also available at the bottom below the tab book in the drop down list. Moving a case is very simple, just select transition to make and press "Move". If the user does not have permission to do so the button would be greyed out. At the bottom we see the Note area where Gjallar maintains a threaded discussion about the case. |
| The second tab from the right is the History tab. Here we see all transactions that have been made that affects this case. Each transaction object has ALL information about the modification made (think Prevayler style) so in theory we could rerun all transactions and come back to the current state. This means we have full history by definition and do not depend on any selective logging. Each transaction is timestamped and we can see which user performed it. In this case the UI does not show all information available about the transaction - for example what was the change made to the Description field? An option to show full information might be interesting to add. |
| Clicking on "add note" expands the Note creation form inlined into the note view. The note can be optionally additionally be sent as an email, and that checkbox is automatically checked if the note we are replying to (or the case itself) was in turn created by an email. This means users can use email or the web UI in a mixed fashion to conduct the discussions. An email reply uses a reference number embedded in the subject line to automatically connect as a reply to the correct case or note to maintain the threaded view. |
| Here we add a second note as a reply to the first note. The link "add quoted text" has been used to copy the text in a quoted fashion into this note. |
| After going to Settings and turning on "show notes view options" we have two checkboxes above the notes view determining how the notes are rendered. Now we use a threaded view (indented) with notes on the same thread level sorted oldest first. |
| Here we changed it to non threaded view and newest first, some people prefer to see the latest notes on top. The lack of quoting in the note is a bug. |
| we switch over to the history tab to see that adding notes etc generates transactions. |
| The System information view shows various technical information about Seaside and Magma, what current versions of the major software components we have and the changelog for the software. As you can see there are 25 transactions in the system since the initialization. |
| This shows the Subscriptions of email notifications the user has. A subscription is triggered by a selected set of low level events from a selected subset of the available Processes. This generates a potential list of cases I want to be notified about. The final step is to run that list through a selected case Filter which is a boolean expression of search terms. If any case in the list comes through that search filter the user is notified by email. Email notifications can be digested and the digest interval etc are available as per user Settings. This model means that very fine grained notifications can be created since the Filters can take any field of the case into account. |
| dir |
dir := FileDirectory on: 'c:\squeak\q2\shots'.
dir keysDo: [:name |
PNGReadWriter putForm:
((Form fromBinaryStream: (dir readOnlyFileNamed: name))
scaledToSize: 150@150) onFileNamed: 'thumb_',name]