Difference between revisions of "Faces Album Management"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 7: Line 7:
Please enter all comments concerning the use cases on the [[Talk:Faces_Album_Management|discussion page]].
Please enter all comments concerning the use cases on the [[Talk:Faces_Album_Management|discussion page]].


As the current state of the spec focuses on R3, earlier states of the spec can be found in the history of this page:
As '''the current state of the spec focuses on R3.5''', earlier states of the spec can be found in the history of this page:
* The [http://colab.mpdl.mpg.de/mediawiki/index.php5?title=Faces_Album_Management&oldid=19288 spec for R2]
* The [http://colab.mpdl.mpg.de/mediawiki/index.php5?title=Faces_Album_Management&oldid=19288 spec for R2]
* The [http://colab.mpdl.mpg.de/mediawiki/index.php5?title=Faces_Album_Management&oldid=24111 spec for R3]


== UC_FAC_AM_01 Create album ==
== UC_FAC_AM_01 Create album ==

Revision as of 14:59, 24 November 2008

eSciDoc Solutions

PubMan:
Overview · Functionalities
Interfaces · Support

Faces:
Overview · Functionalities
Scope · Support

ViRR:
Overview · Functionalities
Scope · Support

imeji
Digitization Lifecycle

edit


Introduction[edit]

NOTE: Albums have been called Study Sets or - technically - Bundles before.
A small glossary for the used terms can be found under Miscellaneous.
Please enter all comments concerning the use cases on the discussion page.

As the current state of the spec focuses on R3.5, earlier states of the spec can be found in the history of this page:

UC_FAC_AM_01 Create album[edit]

Status/Schedule

  • Status: in design
  • Schedule: R2

Motivation

  • The user wants to create an album to save his own selection out of the Faces collection.

Steps

  1. The user chooses to create a new album.
  2. The system displays the edit album mask (the metadate for an album is specified in the Faces Application Profile Album. The owner of the album and his affiliated organisation will automatically be pre-filled as creator for the metadata record assigned to the album.
  3. The user enters an album name.
  4. (Optionally) The user enters additional information about the album: further creators (family name, given name) together with their affiliated organisation and a description of the album.
  5. The user confirms the entries.
  6. The system creates the album with its metadata in the state pending and displays a message (MSG_FAC_AM_01). The use case ends successfully.

Actors Involved

  • Account user

Discussion

UC_FAC_AM_02 Add picture to album[edit]

Status/Schedule

  • Status: in design
  • Schedule: R2

Motivation

  • The user wants to add pictures to one or several of his private albums.

Pre-Condition

  • The user is the owner of at least one pending album.

Triggers

Steps

  1. The user selects one picture for adding.
  2. The user selects one of his pending albums where he wants to add the selected picture.
  3. The system adds the selected picture to the selected album. The use case ends successfully.

Actors Involved

  • Account user

Constraints

  • Each picture can only be added once to each album. This means that it must be visible for the user, which pictures are already in which album and which are not.

Discussion

UC_FAC_AM_03 Remove picture from album[edit]

Status/Schedule

  • Status: in design
  • Schedule: R2

Motivation

  • The user wants to remove one picture from one of his private albums.

Pre-Condition

  • A pending album is selected.
  • The user is the owner of the pending album.

Triggers

Steps

  1. The user selects one picture within the album for removing it.
  2. The system removes the selected picture from the selected album. The use case ends successfully.

Actors Involved

  • Account user

UC_FAC_AM_04 Edit album[edit]

Status/Schedule

  • Status: in design
  • Schedule: R2

Motivation

  • The user wants to edit the details of one of his own private albums.

Pre-Condition

  • A pending album is selected.
  • The user is the owner of the selected album.

Triggers

Steps

  1. The user chooses to edit the selected album.
  2. The system displays the edit album mask.
  3. (Optionally) The user edits the metadata values, adds new metadata values or modifies existing metadata values.
  4. The user confirms the changes.
  5. The system stores the changes and displays a message (MSG_FAC_AM_02). The use case ends successfully.

Actors Involved

  • Account user

UC_FAC_AM_05 Delete album[edit]

Status/Schedule

  • Status: in design
  • Schedule: R2

Motivation

  • The user wants to delete one of his private albums because he doesn't need it any more.

Pre-Condition

  • A pending album is selected.
  • The user is the owner of the album.

Triggers

Steps

  1. The user chooses to delete the album.
  2. The system prompts for a confirmation of the deletion.
  3. The user confirms the deletion.
  4. The system deletes the pending album and displays a message (MSG_FAC_AM_03). The use case ends successfully.

Actors Involved

  • Account user

Discussion

UC_FAC_AM_06 Release album[edit]

Status/Schedule

  • Status: in design
  • Schedule: R2

Motivation

  • The user wants to publish one of his private albums. Afterwards, the album details will be accessible for the public and every account user can view the pictures in it.

Pre-Condition

  • A pending album is selected.
  • The user is the owner of the album.

Triggers

Steps

  1. The user chooses to release the album.
  2. The system prompts for a confirmation of the releasing.
  3. The user confirms the releasing.
  4. The system changes the state of the album to released (it automatically goes to submitted and then to released) and displays a message (MSG_FAC_AM_04). The use case ends successfully.

Actors Involved

  • Account user

UC_FAC_AM_07 Withdraw album[edit]

Status/Schedule

  • Status: in design
  • Schedule: R2

Motivation

  • The user wants to withdraw one of his published albums because the album should no longer be accessible via the collection.

Pre-Condition

  • A released album is selected.
  • The user is the owner of the album.

Triggers

Steps

  1. The user chooses to withdraw the album.
  2. The system prompts for a reason for the withdrawal.
  3. The user enters a reason and confirms the withdrawal.
  4. The system changes the state of the item to “withdrawn” and stores the withdrawal comment. The system displays a message (MSG_FAC_AM_05). The use case ends successfully.

Alternatives

3a. The user canceled the withdrawal. The use case ends without success.

Actors Involved

  • Account user

UC_FAC_AM_08 Export album[edit]

Status/Schedule

  • Status: in design
  • Schedule: R3

Motivation

  • The user wants to export the pictures and/or the metadata of the pictures of one album.

Pre-Condition

  • An album is selected.

Triggers

Steps

  1. The user chooses to export the pictures of an album.
  2. The system displays the export album mask.
  3. The user selected one export format (plain CSV, CSV-file and pictures in ZIP-file, pictures only in ZIP-file, XML-file and pictures in ZIP-file, XML only).
  4. If the user chooses an export format which includes the pictures, the user selects one or more picture resolutions (thumbnail, web resolution 819x1024, original resolution 2835x3543).
  5. The user confirms his selection(s).
  6. The system displays the short version of the faces release agreement.
  7. The user accepts the release agreement.
  8. The system creates the required data in the required export format and puts all files together with the faces release agreement in a zip-file, which is made available for saving for the user. In addition, the system updates the export statistics. The use case ends successfully.

Actors Involved

  • Account user

Alternatives

8.a The user does not accept the release agreement. The use case ends without success.

Additional information[edit]

Further information about an album can be found in the Faces Application Profile Album.

Further Development[edit]

Identified Use Cases[edit]

UC_FAC_AM_09 Share album[edit]

Status/Schedule

  • Status: in specification
  • Schedule: R3.5

Motivation

  • The user wants to share one of his private album with one ore more known Faces users.
  • Sharing an album means that next to the owner of an album also selected users can add and remove pictures from it. Further on, based on a separate permission per album, these users are also allowed to edit the note pad of the album. But they can not edit the album (change the metadata), release, delete or withdraw it.

Pre-Condition

  • One album is selected.
  • The user is the owner of the album.

Triggers

Steps

  1. The user chooses to share the selected album.
  2. The system displays a list with all account users. (Thats not allowed. Either the user enters the exact nickname of the user in a exact search field or an invitation via e-mail will be posted by the system. --Kristina 11:26, 24 November 2008 (UTC)
  3. The user selects one or more users and confirms his selection.
  4. The system adds the selected users (name and affiliated organization) as "further authors" to the album and updates the album metadata. The use case ends successfully.

Actors Involved

  • Account user

Comment

  • Each user has to confirm, that he wants to share an album from another user. --> new UC is needed.
  • Shared authors of an album are not the same as further authors of the album.
  • Based on the new concepts for the "institutional visibility", also pending containers should be able to share. --Kristina 14:30, 18 September 2008 (UTC)
  • It could be happen that more users are adding and removing pictures from the same album at the same time. In this situation, each step only needs a second. Therefore, the system can save always the latest version. It only can happen that the users get confused because pictures are added or deleted without his interaction.
  • If an user try to remove a picture which has been previously removed by an other user, the FW will return an exception which can be handled as an error message. The second case is a bit more complicated. I don't know whether the FW provides something to prevent it. There is anyway the possibility to lock an album when a user is working on and unlock it the operation is achieved. --Bastien 16:06, 3 November 2008 (UTC)
    • --Natasa 17:26, 4 November 2008 (UTC)Here the optimistic locking strategy (provided as default mechanism) may help.
      • If another user wants to edit the same album at the same time, s/he (or Faces solution) has to supply the last modification date of the album in the task-parameters
      • if another user wants to add a member to an older version of an album, then we have to provide the information that the album has been changed in a meantime by another user and /or ask the user to reload the latest version of the album. Once this is done, the image (if added by other user) will be marked as member of the album and will not be possible to add it again (as this is what Faces already takes care of).--Natasa 17:26, 4 November 2008 (UTC)
  • I don't understand why we need the state submitted to share album. --Bastien 16:12, 3 November 2008 (UTC)
I think this is about the user privileges. As so far defined, colaborator roles can only view pending items. --Natasa 17:26, 4 November 2008 (UTC)

TO DO

  1. Extension point: share album (part of UC_FAC_BD_04_View album details)
    1.1 If the album is in state pending and the user wants to share it with one or more other users, include UC_FAC_AM_09 Share album

State submitted is new:

  • Precondition of some Album Management use cases has to be changed to "pending/submitted".

UC_FAC_BD_05 View my albums

  • Marking shared albums and displaying the user names with whom the album is shared
  • Action: remove one or more shared users
  • Displaying shared albums of other users together with their owner and further shared users (in all states)
  • Action: remove one or more shared albums

UC_FAC_AM_02 Add picture to album

  • 2. The user selects one of his pending albums or one of the submitted albums he is sharing.

UC_FAC_AM_03 Remove picture from album

  • Precondition: User is the owner or shared the album.

UC_FAC_AM_04 Edit album

  • Pre_Condition: Album can also be in state submitted.

UC_FAC_AM_05 Delete album

  • To delete a shared album (submitted), the user first has to un-share it (the system changes the state to "pending" through the state "in Revision"). Than it can be deleted.

Further Requirements[edit]

1. Copy an album --> R?

2. Create a new album with the content of several already available albums --> R?

3. Note pad --> R3.5

  • Note pad for each album where the user can save private notes (only visible for himself) in the size of about half a page.
  • When sharing the album, the user can decide, if he wants to share the note pad, too. When he shares it, the other users can read and write it. When not, the other users can not see it anyway.
  • Should be viewable for the owner also after the album has been released.
  • Open points:
  • Will the note pad be handled like a component of the album? Or like detailed metadata (similar the the description)?
As discussed in a meeting with Natasa, Michael, Ulla and me, the note pad can be a separate item (which always stays in the state pending) which will be related to the album. --Kristina 14:23, 18 September 2008 (UTC)
  • Are albums (containers) able to have a component?
Not possible, containers are aggregations and they can not have components.--Natasa 07:39, 19 September 2008 (UTC)

4. Controlled Vocabulary

  • perhaps in a later step, the adding of authors (with their corresponding affiliations) can be based on normed files like in PubMan.