Task ABRs GUI tasks

Title
ABRs GUI tasks

State
Not started

Time used

Time estimated

Description

/!\ These will be split up in real subtasks later on. For now, they are just dumped here.

Overall, for prioritising, these are all GUI tasks. As such, they cannot be prioritised in regards to if we should have the GUI or not. They can, however, be prioritised in regards to how good a GUI we want.

Known limitations

  1. Last changed date are not shown. With the proper backend integration and graphical guy, 1B to solve. Without graphical guy 2C. Postponed, not essential

  2. Created date is not shown. With the proper backend integration and graphical guy, 1B to solve. Without graphical guy 2C. Postponed, not essential

  3. User creating and last change are not shown. With the proper backend integration and graphical guy, 1B to solve. Without graphical guy 2C. Postponed, not essential

  4. Sortering af objeckter i tree-view. With the proper backend integration and graphical guy, 1B to solve. Without graphical guy 2C. Postponed, not essential in any way

  5. Validate button. With the proper backend integration and graphical guy, 1B to solve. Without graphical guy 2C. Really nessesary for production use, milestone 1

  6. Problems with the xml parsing with Premis-style schemas. This require a lot of understanding of the XML parsing, so 7D, with no guarantee of succes. Postponed, the GUI sort of works now, good enough

Total: 17md

Milestone 1: 2md

Milestone soon: 8md

Milestone later: 7md

Unknown limitations

For unknown limitations, it is, for course, difficult to plan.

It is clear that the first step is to identify the limitation. As this will be identified by the users, the time used here is only the time needed to debrief the user. 1B

To fix the limitation, would take about 2C, as above. Lets assume that there are five such limitations, so that would be 10C.

This one might overlap with one of EABs tasks.

In regard to priority, there will be a lockdown of the GUI. No non-essential tasks will be completed. I guess that one task will be identified as essential, and the rest postponed

Total: about 12md

Milestone 1: 3md

Milestone later: 9md

Collection Menu

  1. A dropdown list of all the collections are not practical.
    1. Perhaps the user should select a collection upon login. That collection is used for everything. Should be changable afterwards. 3C, as there are quite a few UI elements to change. More, if no graphical guy exist.
    2. Perhaps a search field for the collection, or a tree structure. Remembering most used? 3D, since there the design is less clear.

While the list of collections in doms remain below 10 at most, and optimally 5, this will not be a problem. As such, we do not need to fix it right away. Postponed

Gui integration with other systems

There are several ways of integrating with other systems. First, let us consider the different usecases we could have for integrating with other systems

  1. Creating new doms records based on a record from another system. Eg. starting to digitize a cd from the record in Aleph
  2. Supplying additional data, such as files or metadata about an already existing doms record

Creating a doms record is simple. The problem is how the user should designate that he wishes to invoke this functionality.

At the moment, we have chosen to use disseminators. This design works, but in order to do so now, we need to be able to invoke disseminators outside the doms system.

The task can therefor be broken down in two steps

  1. Find the proper design. 4D. 2 guys talking for 2 days will find a design, but many people might be consulted, so D.
  2. Implement the proper design in the GUI. 7B. No matter how it is done, it will probably have to be a change all through the DOMS system. As such, a lot of packages are touched. So 7. Not to unsure about this, as the 7 is somewhat pessimistic, and the uncertainty is in finding the design.

Importing additional data from some source is quite similar to the hotfolder topic in mads ingest. I expect that a lot of the design can be gleaned from the above task, and the hotfolder design, so I estimate this task to be 3C.

Then, for each system that should be integrated with the GUI, the following tasks should be done

  1. Create a java-client for the target system
  2. Create the GUI integration with the java client

I am not comfortable in estimating the first task, as this is very dependent on the target system. The GUI integration should be doable in 3C, if the above design tasks have been completed.

Integration with other systems might prove to be an essential feature if the GUI is to enter production use. Of particular interest, as far as ABR knows, will be Quadriga and Aleph. I fear that this task cannot be postponed for any useful gain

Backend

The current GUI is based on the old miniDoms system. This needs to be ripped out, and replaced with a new backend.

Much of the backend will be the Doms Client, in the OO sense. As such, this work will be done in the Doms Client workpackage, not the Gui workpackage. Still, there will be a lot of joined work, as the GUI is the main client for the doms client package.

Exact interfaces can be established, but because we want an OO architecture in the client, they are not minor or easy to write. Still, I expect the amount of wrapper code that should go on top of the DOMS client to be quite small.

  1. Designing the interfaces. This is a crucial task, but relatively done already. Might already be estimated as part of the Doms Client. 10B. Long time, because several developers need to sit down and discuss the design. B because we already know a lot of it.

  2. Extracting the old code from the GUI, and making a clean interface for the new code. The GUI runs on a Model-View-Controller design, but the interfaces are rather unclear. Extracting the model and making a clean controller interface will be quite timeconsuming. 10C.
  3. Building the Controller-Client glue, to take the place of the Model. This is relatively cheap, as the primary work is in writing the client, but there will be some specialised methods needed by the gui, but not provided by the client. I estimate 12C for this task, several developers working on this, and review.

In order for the GUI to work at all, this task must be completed. Postponing it means postponing the GUI. Unfortunately, it means that the Doms Client need to be completed

Summa

The Gui needs a summa instance that:

These demands seem to indicate that we need a separate Summa instance, just for the GUI. The work on establishing the Summa integration is part of the Summa integration workpackage. In this workpackage, we should only perform the work to integrate the GUI with the Summa instance.

For that, I estimate 3C. The Gui already has a search integration, so the code that needs changing is really limited. We have experts on Summa at hand, and we have a good knowledge of how the GUI works. For this reason, I estimate 3 days. Still, integration and making things run have proven problematic, and we might need more help than expected. So, I estimate an uncertainty of C. One could also estimate someting like 5B instead, if one was more pessimistic.

This task can be postponed. A little tweaking to the current search interface could be sufficient for the initial production GUI. Still, if we already do Summa integration, postponing this will not gain us very much

Speed optimization

It is a known problem that the GUI is slow. It is, in fact, so slow that it might be a problem for users. This seems to be dependent on the server running the GUI, of course, but we do not know how it would scale in a running system.

The project consist of three steps

  1. Identify the cause of the slowness. This might take some time, as we will need to examine details of the working of the GUI. 4C
  2. Gaining understanding of the involved technologies / Designing the solution. This might take some time, in google searches and figuring out what can be done differently. 5C
  3. Implementation. Assuming the above stuff is done, and this is not a trial and error task. 5B.

The GUI is slow, but it is usable. If Maintenance could throw some powerful hardware at it, we could probably make it run in an acceptable speed for a while. As such, this task can be postponed

Deployment

In order for the users to use the GUI, it needs to be deployed in a production environment. This task consist of a number of subtasks

  1. Agreement with IT Maintenance of a proper server. 2A, meeting with a lot of people. This does not include any time used by IT Maintenance to establish the server.
  2. Wrapping the GUI as package for IT Maintenance to deploy. 3B as the GUI framework already does some of this, but we need to be totally sure about what happens.
  3. Agreeing on a support contract. This designates which kind of errors should be handled by whom. 2A, meeting between a lot of people.

This task is basically to put the GUI into production use. It cannot be postponed without postponing the GUI

Sub tasks

Title State Time used Time estimated

Documentation

Progress history

Iteration Time used Status Notes Tasks adressed

Tasks/34/3 (last edited 2010-06-11 08:36:14 by abr)