Hi, 
Guest
Pic
Sign In

talk@lists.collectionspace.org

WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org

View all threads

Update on the Location and Movement Upgrade

MF
Megan Forbes
Thu, Feb 23, 2012 8:06 PM

Thanks to everyone who responded to my inquiries about upgrading our
current approach to location and movement tracking. After a great set of
follow-up conversations with Berkeley, SMK, and Walker, I think we have a
front runner for a solution. Unsurprisingly, it's neither of the solutions
proposed in the original email!

Please read through the below and let me know if it accurately captures
what we discussed. If everyone is good with this approach, it will go on
the docket for Release 2.3.

The basics to the upgraded approach:

Outstanding questions:

  • Should records (e.g. cataloging) related to a "hard" saved
    location/movement/inventory record?
  • Do we need to make any complementary adjustments to the storage location
    authority? For example, if a storage location display name is updated,
    should this change be propagated only to new location/movement/inventory
    records, to new records and records under "regular" save, or to all records?
  • Does anyone have a better name than "hard" save?

Thanks everyone for your great input on this issue! Chris - I got your
email after writing this one; I will add some wireframe sketches to the
wiki page.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800
Direct 718 777 6834

Thanks to everyone who responded to my inquiries about upgrading our current approach to location and movement tracking. After a great set of follow-up conversations with Berkeley, SMK, and Walker, I think we have a front runner for a solution. Unsurprisingly, it's neither of the solutions proposed in the original email! Please read through the below and let me know if it accurately captures what we discussed. If everyone is good with this approach, it will go on the docket for Release 2.3. The basics to the upgraded approach: - Keep Location and Movement together as a procedure - Add the Inventory information group to this procedure, draft schema available here: http://wiki.collectionspace.org/display/collectionspace/Inventory+Control+Schema - To support the request that location moves be uneditable once they're entered, we'll add a new type of save that takes a record to un-editable status. This "hard" save will make the location/movement/inventory record and its relationships read only. Location/movement/inventory records may still be saved using a "regular" save, meaning that their data and relationships can be changed, so that the procedure can also be used as a planning tool for future moves. Proposed workflows: http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Upgrade+Option+III+Workflows. Outstanding questions: - Should records (e.g. cataloging) related to a "hard" saved location/movement/inventory record? - Do we need to make any complementary adjustments to the storage location authority? For example, if a storage location display name is updated, should this change be propagated only to new location/movement/inventory records, to new records and records under "regular" save, or to all records? - Does anyone have a better name than "hard" save? Thanks everyone for your great input on this issue! Chris - I got your email after writing this one; I will add some wireframe sketches to the wiki page. Best regards, Megan -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us 718 777 6800 Direct 718 777 6834
J
jblowe@berkeley.edu
Thu, Feb 23, 2012 11:49 PM

Megan,

Ingenious solutions to a thorny problem, thanks!

The workflow "Plan future move for group of cataloging records" (Option
III, Workflow III) might work for the crucial PAHMA special case of
"movable locations" (e.g. "crates") provided that the act of "relating"
cataloging records called for in step 2 could be simplified (automated?)
as "if the Location specified in this L/M/I record is Movable, offer to
relate all the cataloging records with this location". I guess my question
is: for PAHMA, would you suggest that we deployers attempt to customize
this workflow to support this use case?

Regarding the "outstanding questions":

  1. The first question seems to be missing a word or something and I'm not
    sure how to read it. Could you please clarify?

  2. I suggest that both "hard" save and "regular" save need better epithets
    ("regular" requires an interpretation by the user in the context of
    existing defaults, which may not be apparent).  Perhaps a pair of
    (near-)antonymous adjectives (like "hard" and "soft") is called for? How
    about:

open / closed (or perhaps frozen)
editable / permanent (or perhaps indelible)
modifiable / unmodifiable
unlock(ed) / lock(ed)

I do like hard/soft myself -- short, evocative, easily internationalized,
but perhaps too informal.

Regards,

John

Thanks to everyone who responded to my inquiries about upgrading our
current approach to location and movement tracking. After a great set of
follow-up conversations with Berkeley, SMK, and Walker, I think we have a
front runner for a solution. Unsurprisingly, it's neither of the solutions
proposed in the original email!

Please read through the below and let me know if it accurately captures
what we discussed. If everyone is good with this approach, it will go on
the docket for Release 2.3.

The basics to the upgraded approach:

Outstanding questions:

  • Should records (e.g. cataloging) related to a "hard" saved
    location/movement/inventory record?
  • Do we need to make any complementary adjustments to the storage location
    authority? For example, if a storage location display name is updated,
    should this change be propagated only to new location/movement/inventory
    records, to new records and records under "regular" save, or to all
    records?
  • Does anyone have a better name than "hard" save?

Thanks everyone for your great input on this issue! Chris - I got your
email after writing this one; I will add some wireframe sketches to the
wiki page.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800
Direct 718 777 6834

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Megan, Ingenious solutions to a thorny problem, thanks! The workflow "Plan future move for group of cataloging records" (Option III, Workflow III) might work for the crucial PAHMA special case of "movable locations" (e.g. "crates") provided that the act of "relating" cataloging records called for in step 2 could be simplified (automated?) as "if the Location specified in this L/M/I record is Movable, offer to relate all the cataloging records with this location". I guess my question is: for PAHMA, would you suggest that we deployers attempt to customize this workflow to support this use case? Regarding the "outstanding questions": 1. The first question seems to be missing a word or something and I'm not sure how to read it. Could you please clarify? 2. I suggest that both "hard" save and "regular" save need better epithets ("regular" requires an interpretation by the user in the context of existing defaults, which may not be apparent). Perhaps a pair of (near-)antonymous adjectives (like "hard" and "soft") is called for? How about: open / closed (or perhaps frozen) editable / permanent (or perhaps indelible) modifiable / unmodifiable unlock(ed) / lock(ed) I do like hard/soft myself -- short, evocative, easily internationalized, but perhaps too informal. Regards, John > Thanks to everyone who responded to my inquiries about upgrading our > current approach to location and movement tracking. After a great set of > follow-up conversations with Berkeley, SMK, and Walker, I think we have a > front runner for a solution. Unsurprisingly, it's neither of the solutions > proposed in the original email! > > Please read through the below and let me know if it accurately captures > what we discussed. If everyone is good with this approach, it will go on > the docket for Release 2.3. > > The basics to the upgraded approach: > > - Keep Location and Movement together as a procedure > - Add the Inventory information group to this procedure, draft schema > available here: > http://wiki.collectionspace.org/display/collectionspace/Inventory+Control+Schema > - To support the request that location moves be uneditable once they're > entered, we'll add a new type of save that takes a record to un-editable > status. This "hard" save will make the location/movement/inventory record > and its relationships read only. Location/movement/inventory records may > still be saved using a "regular" save, meaning that their data and > relationships can be changed, so that the procedure can also be used as a > planning tool for future moves. Proposed workflows: > http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Upgrade+Option+III+Workflows. > > > Outstanding questions: > > - Should records (e.g. cataloging) related to a "hard" saved > location/movement/inventory record? > - Do we need to make any complementary adjustments to the storage location > authority? For example, if a storage location display name is updated, > should this change be propagated only to new location/movement/inventory > records, to new records and records under "regular" save, or to all > records? > - Does anyone have a better name than "hard" save? > > Thanks everyone for your great input on this issue! Chris - I got your > email after writing this one; I will add some wireframe sketches to the > wiki page. > > Best regards, > Megan > > > > > -- > Megan Forbes > Collection Manager > > Museum of the Moving Image > 36-01 35 Avenue Astoria, NY 11106 > movingimage.us 718 777 6800 > Direct 718 777 6834 > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >
MF
Megan Forbes
Fri, Feb 24, 2012 6:06 PM

John -

Thanks for catching my error on the first question! It should have read:

Should records (e.g. cataloging) related to a "hard" saved record
location/movement/inventory record have any restrictions on deletion?

The movable location question is trickier. When we talked on the phone a
few weeks ago, we talked about basing the movable location workflow on the
idea of movable locations being part of the storage location authority. In
that scenario, if the parent record for a movable location were changed
(e.g. Box A's parent went from Shelf 1 to Shelf 2), the user would then
turn to a batch process to create a new L/M/I record for all objects
associated to Box A.

I am not sure how going directly from the procedural record would work - if
a user created a new L/M/I record, and added a current location of Box A,
where does s/he make the change from Shelf 1 to Shelf 2 for Box A? I am not
at all saying it's not an option, it would just be very helpful to get a
set of workflow steps that show the move of the box itself.

-M

On Thu, Feb 23, 2012 at 6:49 PM, jblowe@berkeley.edu wrote:

Megan,

Ingenious solutions to a thorny problem, thanks!

The workflow "Plan future move for group of cataloging records" (Option
III, Workflow III) might work for the crucial PAHMA special case of
"movable locations" (e.g. "crates") provided that the act of "relating"
cataloging records called for in step 2 could be simplified (automated?)
as "if the Location specified in this L/M/I record is Movable, offer to
relate all the cataloging records with this location". I guess my question
is: for PAHMA, would you suggest that we deployers attempt to customize
this workflow to support this use case?

Regarding the "outstanding questions":

  1. The first question seems to be missing a word or something and I'm not
    sure how to read it. Could you please clarify?

  2. I suggest that both "hard" save and "regular" save need better epithets
    ("regular" requires an interpretation by the user in the context of
    existing defaults, which may not be apparent).  Perhaps a pair of
    (near-)antonymous adjectives (like "hard" and "soft") is called for? How
    about:

open / closed (or perhaps frozen)
editable / permanent (or perhaps indelible)
modifiable / unmodifiable
unlock(ed) / lock(ed)

I do like hard/soft myself -- short, evocative, easily internationalized,
but perhaps too informal.

Regards,

John

Thanks to everyone who responded to my inquiries about upgrading our
current approach to location and movement tracking. After a great set of
follow-up conversations with Berkeley, SMK, and Walker, I think we have a
front runner for a solution. Unsurprisingly, it's neither of the

solutions

proposed in the original email!

Please read through the below and let me know if it accurately captures
what we discussed. If everyone is good with this approach, it will go on
the docket for Release 2.3.

The basics to the upgraded approach:

  • Keep Location and Movement together as a procedure
  • Add the Inventory information group to this procedure, draft schema
    available here:
  • To support the request that location moves be uneditable once they're
    entered, we'll add a new type of save that takes a record to un-editable
    status. This "hard" save will make the location/movement/inventory record
    and its relationships read only. Location/movement/inventory records may
    still be saved using a "regular" save, meaning that their data and
    relationships can be changed, so that the procedure can also be used as a
    planning tool for future moves. Proposed workflows:

Outstanding questions:

  • Should records (e.g. cataloging) related to a "hard" saved
    location/movement/inventory record?
  • Do we need to make any complementary adjustments to the storage

location

authority? For example, if a storage location display name is updated,
should this change be propagated only to new location/movement/inventory
records, to new records and records under "regular" save, or to all
records?

  • Does anyone have a better name than "hard" save?

Thanks everyone for your great input on this issue! Chris - I got your
email after writing this one; I will add some wireframe sketches to the
wiki page.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800
Direct 718 777 6834

Talk mailing list
Talk@lists.collectionspace.org

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800
Direct 718 777 6834

John - Thanks for catching my error on the first question! It should have read: Should records (e.g. cataloging) related to a "hard" saved record location/movement/inventory record have any restrictions on deletion? The movable location question is trickier. When we talked on the phone a few weeks ago, we talked about basing the movable location workflow on the idea of movable locations being part of the storage location authority. In that scenario, if the parent record for a movable location were changed (e.g. Box A's parent went from Shelf 1 to Shelf 2), the user would then turn to a batch process to create a new L/M/I record for all objects associated to Box A. I am not sure how going directly from the procedural record would work - if a user created a new L/M/I record, and added a current location of Box A, where does s/he make the change from Shelf 1 to Shelf 2 for Box A? I am not at all saying it's not an option, it would just be very helpful to get a set of workflow steps that show the move of the box itself. -M On Thu, Feb 23, 2012 at 6:49 PM, <jblowe@berkeley.edu> wrote: > Megan, > > Ingenious solutions to a thorny problem, thanks! > > The workflow "Plan future move for group of cataloging records" (Option > III, Workflow III) might work for the crucial PAHMA special case of > "movable locations" (e.g. "crates") provided that the act of "relating" > cataloging records called for in step 2 could be simplified (automated?) > as "if the Location specified in this L/M/I record is Movable, offer to > relate all the cataloging records with this location". I guess my question > is: for PAHMA, would you suggest that we deployers attempt to customize > this workflow to support this use case? > > Regarding the "outstanding questions": > > 1. The first question seems to be missing a word or something and I'm not > sure how to read it. Could you please clarify? > > 2. I suggest that both "hard" save and "regular" save need better epithets > ("regular" requires an interpretation by the user in the context of > existing defaults, which may not be apparent). Perhaps a pair of > (near-)antonymous adjectives (like "hard" and "soft") is called for? How > about: > > open / closed (or perhaps frozen) > editable / permanent (or perhaps indelible) > modifiable / unmodifiable > unlock(ed) / lock(ed) > > I do like hard/soft myself -- short, evocative, easily internationalized, > but perhaps too informal. > > Regards, > > John > > > > > Thanks to everyone who responded to my inquiries about upgrading our > > current approach to location and movement tracking. After a great set of > > follow-up conversations with Berkeley, SMK, and Walker, I think we have a > > front runner for a solution. Unsurprisingly, it's neither of the > solutions > > proposed in the original email! > > > > Please read through the below and let me know if it accurately captures > > what we discussed. If everyone is good with this approach, it will go on > > the docket for Release 2.3. > > > > The basics to the upgraded approach: > > > > - Keep Location and Movement together as a procedure > > - Add the Inventory information group to this procedure, draft schema > > available here: > > > http://wiki.collectionspace.org/display/collectionspace/Inventory+Control+Schema > > - To support the request that location moves be uneditable once they're > > entered, we'll add a new type of save that takes a record to un-editable > > status. This "hard" save will make the location/movement/inventory record > > and its relationships read only. Location/movement/inventory records may > > still be saved using a "regular" save, meaning that their data and > > relationships can be changed, so that the procedure can also be used as a > > planning tool for future moves. Proposed workflows: > > > http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Upgrade+Option+III+Workflows > . > > > > > > Outstanding questions: > > > > - Should records (e.g. cataloging) related to a "hard" saved > > location/movement/inventory record? > > - Do we need to make any complementary adjustments to the storage > location > > authority? For example, if a storage location display name is updated, > > should this change be propagated only to new location/movement/inventory > > records, to new records and records under "regular" save, or to all > > records? > > - Does anyone have a better name than "hard" save? > > > > Thanks everyone for your great input on this issue! Chris - I got your > > email after writing this one; I will add some wireframe sketches to the > > wiki page. > > > > Best regards, > > Megan > > > > > > > > > > -- > > Megan Forbes > > Collection Manager > > > > Museum of the Moving Image > > 36-01 35 Avenue Astoria, NY 11106 > > movingimage.us 718 777 6800 > > Direct 718 777 6834 > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us 718 777 6800 Direct 718 777 6834
KB
Kim Brasen
Tue, Feb 28, 2012 1:23 PM

Hi Megan,

Your basic assumptions are accurately in line with what we discussed.

Regarding the outstanding questions:

  1. No, we don't think there should be any restrictions to a hard saved Location/movement/inventory record when a related cataloguing record is deleted. To us a location has no meaning without relation to an object.
  2. Our answer to the "b" part of this question would be: Yes, if a storage location display name is updated, this change should be propagated to all records
  3. In a set of wireframes the fabulous Erin Yu has suggested to have an Edit on/off button in this procedure. See this wireframe: http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png  and the PowerPoint attached to this page: http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true . Actually much of the functionality suggested in this set of wireframes is formidably clear.

Cheers,

Kim

Best regards

Kim Brasen

Curator

T +45 3374 8460

Statens Museum for Kunst

Sølvgade 48-50

DK-1307 København K

T +45 3374 8494

F +45 3374 8404

smk.dk http://smk.dk/

Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes
Sendt: 23. februar 2012 21:06
Til: CollectionSpace Talk List
Emne: [Talk] Update on the Location and Movement Upgrade

Thanks to everyone who responded to my inquiries about upgrading our current approach to location and movement tracking. After a great set of follow-up conversations with Berkeley, SMK, and Walker, I think we have a front runner for a solution. Unsurprisingly, it's neither of the solutions proposed in the original email!

Please read through the below and let me know if it accurately captures what we discussed. If everyone is good with this approach, it will go on the docket for Release 2.3.

The basics to the upgraded approach:

Outstanding questions:

  • Should records (e.g. cataloging) related to a "hard" saved location/movement/inventory record?
  • Do we need to make any complementary adjustments to the storage location authority? For example, if a storage location display name is updated, should this change be propagated only to new location/movement/inventory records, to new records and records under "regular" save, or to all records?
  • Does anyone have a better name than "hard" save?

Thanks everyone for your great input on this issue! Chris - I got your email after writing this one; I will add some wireframe sketches to the wiki page.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800 tel:718%20777%206800
Direct 718 777 6834 tel:718%20777%206834

Hi Megan, Your basic assumptions are accurately in line with what we discussed. Regarding the outstanding questions: 1. No, we don't think there should be any restrictions to a hard saved Location/movement/inventory record when a related cataloguing record is deleted. To us a location has no meaning without relation to an object. 2. Our answer to the "b" part of this question would be: Yes, if a storage location display name is updated, this change should be propagated to all records 3. In a set of wireframes the fabulous Erin Yu has suggested to have an Edit on/off button in this procedure. See this wireframe: http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png <http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png> and the PowerPoint attached to this page: http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true <http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true> . Actually much of the functionality suggested in this set of wireframes is formidably clear. Cheers, Kim Best regards Kim Brasen Curator T +45 3374 8460 Statens Museum for Kunst Sølvgade 48-50 DK-1307 København K T +45 3374 8494 F +45 3374 8404 smk.dk <http://smk.dk/> ________________________________ Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes Sendt: 23. februar 2012 21:06 Til: CollectionSpace Talk List Emne: [Talk] Update on the Location and Movement Upgrade Thanks to everyone who responded to my inquiries about upgrading our current approach to location and movement tracking. After a great set of follow-up conversations with Berkeley, SMK, and Walker, I think we have a front runner for a solution. Unsurprisingly, it's neither of the solutions proposed in the original email! Please read through the below and let me know if it accurately captures what we discussed. If everyone is good with this approach, it will go on the docket for Release 2.3. The basics to the upgraded approach: - Keep Location and Movement together as a procedure - Add the Inventory information group to this procedure, draft schema available here: http://wiki.collectionspace.org/display/collectionspace/Inventory+Control+Schema - To support the request that location moves be uneditable once they're entered, we'll add a new type of save that takes a record to un-editable status. This "hard" save will make the location/movement/inventory record and its relationships read only. Location/movement/inventory records may still be saved using a "regular" save, meaning that their data and relationships can be changed, so that the procedure can also be used as a planning tool for future moves. Proposed workflows: http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Upgrade+Option+III+Workflows. Outstanding questions: - Should records (e.g. cataloging) related to a "hard" saved location/movement/inventory record? - Do we need to make any complementary adjustments to the storage location authority? For example, if a storage location display name is updated, should this change be propagated only to new location/movement/inventory records, to new records and records under "regular" save, or to all records? - Does anyone have a better name than "hard" save? Thanks everyone for your great input on this issue! Chris - I got your email after writing this one; I will add some wireframe sketches to the wiki page. Best regards, Megan -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us 718 777 6800 <tel:718%20777%206800> Direct 718 777 6834 <tel:718%20777%206834>
Attached image
CB
Carly Bogen
Tue, Feb 28, 2012 10:38 PM

Hi Kim,

I'm responding on Megan's behalf since she's officially on leave as of
yesterday.

Erin's Edit on/off button is a good solution for an indicator of whether a
record is in a "hard save" or "soft save" state.  However, it would likely
be simply an indicator of the state of a record, and not a working button,
with the "Save" button doing the actual work. When the user clicks "save",
they will be given the option in the save confirmation dialog of using a
"hard save" or a "soft save".

This brings up another question that I would love for implementers to weigh
in on.  This hard or soft save indicator would display on the
location/movement/inventory record itself.  Should there also be an
indicator display in search results?  What about in the list of related
records in the secondary tabs and in the right sidebar? If this indicator
is displayed, should it simply be text, or should it be in the same
green/red format as the indicator on the record itself as shown in Erin's
wireframes?

In my opinion, we would need an indicator in all cases.  For instance, if a
user is looking at the related location/movement/inventory records for an
object in the right sidebar, they would want to know which records show
where an object actually is or was located, and which are planned only.

Thanks!
Carly

__

Carly Bogen

Acting Registrar

MUSEUM OF THE MOVING IMAGE

36-01 35 Avenue, Astoria, NY 11106
movingimage.us  718 777 6800
Direct: 718 777 6841

On Tue, Feb 28, 2012 at 8:23 AM, Kim Brasen Kim.Brasen@smk.dk wrote:

**

Hi Megan,****

Your basic assumptions are accurately in line with what we discussed.****

Regarding the outstanding questions:****

1. No, we don’t think there should be any restrictions to a hard saved
Location/movement/inventory record when a related cataloguing record is
deleted. To us a location has no meaning without relation to an object.
****
2. Our answer to the “b” part of this question would be: Yes, if a
storage location display name is updated, this change should be propagated
to all records****
3. In a set of wireframes the fabulous Erin Yu has suggested to have
an Edit on/off button in this procedure. See this wireframe:
http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.pngand the PowerPoint attached to this page:
http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true.
Actually much of the functionality suggested in this set of wireframes is
formidably clear.****

Cheers,****

Kim****

Best regards****

Kim Brasen**

Curator

T +45 3374 8460****

Statens Museum for Kunst****

Sølvgade 48-50****

DK—1307 København K****

T +45 3374 8494****

F +45 3374 8404****

smk.dk****

Fra: talk-bounces@lists.collectionspace.org [mailto:
talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes
Sendt: 23. februar 2012 21:06
Til: CollectionSpace Talk List
Emne: [Talk] Update on the Location and Movement Upgrade**

Thanks to everyone who responded to my inquiries about upgrading our
current approach to location and movement tracking. After a great set of
follow-up conversations with Berkeley, SMK, and Walker, I think we have a
front runner for a solution. Unsurprisingly, it's neither of the solutions
proposed in the original email!****

Please read through the below and let me know if it accurately captures
what we discussed. If everyone is good with this approach, it will go on
the docket for Release 2.3.

The basics to the upgraded approach:

Outstanding questions:

  • Should records (e.g. cataloging) related to a "hard" saved
    location/movement/inventory record?
  • Do we need to make any complementary adjustments to the storage location
    authority? For example, if a storage location display name is updated,
    should this change be propagated only to new location/movement/inventory
    records, to new records and records under "regular" save, or to all records?
  • Does anyone have a better name than "hard" save?

Thanks everyone for your great input on this issue! Chris - I got your
email after writing this one; I will add some wireframe sketches to the
wiki page.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800 <718%20777%206800>
Direct 718 777 6834****

Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi Kim, I'm responding on Megan's behalf since she's officially on leave as of yesterday. Erin's Edit on/off button is a good solution for an indicator of whether a record is in a "hard save" or "soft save" state. However, it would likely be simply an indicator of the state of a record, and not a working button, with the "Save" button doing the actual work. When the user clicks "save", they will be given the option in the save confirmation dialog of using a "hard save" or a "soft save". This brings up another question that I would love for implementers to weigh in on. This hard or soft save indicator would display on the location/movement/inventory record itself. Should there also be an indicator display in search results? What about in the list of related records in the secondary tabs and in the right sidebar? If this indicator is displayed, should it simply be text, or should it be in the same green/red format as the indicator on the record itself as shown in Erin's wireframes? In my opinion, we would need an indicator in all cases. For instance, if a user is looking at the related location/movement/inventory records for an object in the right sidebar, they would want to know which records show where an object actually is or was located, and which are planned only. Thanks! Carly __ *Carly Bogen* Acting Registrar MUSEUM OF THE MOVING IMAGE 36-01 35 Avenue, Astoria, NY 11106 movingimage.us 718 777 6800 Direct: 718 777 6841 On Tue, Feb 28, 2012 at 8:23 AM, Kim Brasen <Kim.Brasen@smk.dk> wrote: > ** > > Hi Megan,**** > > ** ** > > Your basic assumptions are accurately in line with what we discussed.**** > > ** ** > > Regarding the outstanding questions:**** > > ** ** > > 1. No, we don’t think there should be any restrictions to a hard saved > Location/movement/inventory record when a related cataloguing record is > deleted. To us a location has no meaning without relation to an object. > **** > 2. Our answer to the “b” part of this question would be: Yes, if a > storage location display name is updated, this change should be propagated > to all records**** > 3. In a set of wireframes the fabulous Erin Yu has suggested to have > an Edit on/off button in this procedure. See this wireframe: > http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.pngand the PowerPoint attached to this page: > http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true. > Actually much of the functionality suggested in this set of wireframes is > formidably clear.**** > > ** ** > > Cheers,**** > > Kim**** > > ** ** > > **** > > **** > > Best regards**** > > **** > > ***Kim Brasen***** > > *Curator* > > **** > > T +45 3374 8460**** > > **** > > Statens Museum for Kunst**** > > Sølvgade 48-50**** > > DK—1307 København K**** > > T +45 3374 8494**** > > F +45 3374 8404**** > > smk.dk**** > > **** > > **** > > **** > > **** > ------------------------------ > > *Fra:* talk-bounces@lists.collectionspace.org [mailto: > talk-bounces@lists.collectionspace.org] *På vegne af *Megan Forbes > *Sendt:* 23. februar 2012 21:06 > *Til:* CollectionSpace Talk List > *Emne:* [Talk] Update on the Location and Movement Upgrade**** > > ** ** > > Thanks to everyone who responded to my inquiries about upgrading our > current approach to location and movement tracking. After a great set of > follow-up conversations with Berkeley, SMK, and Walker, I think we have a > front runner for a solution. Unsurprisingly, it's neither of the solutions > proposed in the original email!**** > > > Please read through the below and let me know if it accurately captures > what we discussed. If everyone is good with this approach, it will go on > the docket for Release 2.3. > > The basics to the upgraded approach: > > - Keep Location and Movement together as a procedure > - Add the Inventory information group to this procedure, draft schema > available here: > http://wiki.collectionspace.org/display/collectionspace/Inventory+Control+Schema > - To support the request that location moves be uneditable once they're > entered, we'll add a new type of save that takes a record to un-editable > status. This "hard" save will make the location/movement/inventory record > and its relationships read only. Location/movement/inventory records may > still be saved using a "regular" save, meaning that their data and > relationships can be changed, so that the procedure can also be used as a > planning tool for future moves. Proposed workflows: > http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Upgrade+Option+III+Workflows. > > > Outstanding questions: > > - Should records (e.g. cataloging) related to a "hard" saved > location/movement/inventory record? > - Do we need to make any complementary adjustments to the storage location > authority? For example, if a storage location display name is updated, > should this change be propagated only to new location/movement/inventory > records, to new records and records under "regular" save, or to all records? > - Does anyone have a better name than "hard" save? > > Thanks everyone for your great input on this issue! Chris - I got your > email after writing this one; I will add some wireframe sketches to the > wiki page. > > Best regards, > Megan > > > > > -- > Megan Forbes > Collection Manager > > Museum of the Moving Image > 36-01 35 Avenue Astoria, NY 11106 > movingimage.us 718 777 6800 <718%20777%206800> > Direct 718 777 6834**** > > ** ** > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >
KB
Kim Brasen
Wed, Feb 29, 2012 8:41 AM

Hi Carly,

I wasn't aware that Megan was away already - I'll address you in the future then.

Thanks for your reply. We are in total agreement. As you, we believe we need an indicator in all cases - the exact format is not important to us, as long as the indication is clear.

Cheers,

Kim

Best regards,

Kim Brasen

Curator

T +45 3374 8460

Statens Museum for Kunst

Sølvgade 48-50

DK-1307 København K

T +45 3374 8494

F +45 3374 8404

smk.dk http://smk.dk/

Fra: Carly Bogen [mailto:cbogen@gmail.com]
Sendt: 28. februar 2012 23:38
Til: Kim Brasen
Cc: Megan Forbes; talk@lists.collectionspace.org
Emne: Re: [Talk] Update on the Location and Movement Upgrade

Hi Kim,

I'm responding on Megan's behalf since she's officially on leave as of yesterday.

Erin's Edit on/off button is a good solution for an indicator of whether a record is in a "hard save" or "soft save" state.  However, it would likely be simply an indicator of the state of a record, and not a working button, with the "Save" button doing the actual work. When the user clicks "save", they will be given the option in the save confirmation dialog of using a "hard save" or a "soft save".

This brings up another question that I would love for implementers to weigh in on.  This hard or soft save indicator would display on the location/movement/inventory record itself.  Should there also be an indicator display in search results?  What about in the list of related records in the secondary tabs and in the right sidebar? If this indicator is displayed, should it simply be text, or should it be in the same green/red format as the indicator on the record itself as shown in Erin's wireframes?

In my opinion, we would need an indicator in all cases.  For instance, if a user is looking at the related location/movement/inventory records for an object in the right sidebar, they would want to know which records show where an object actually is or was located, and which are planned only.

Thanks!

Carly

__

Carly Bogen

Acting Registrar

MUSEUM OF THE MOVING IMAGE

36-01 35 Avenue, Astoria, NY 11106

movingimage.us http://movingimage.us/    718 777 6800
Direct: 718 777 6841

On Tue, Feb 28, 2012 at 8:23 AM, Kim Brasen Kim.Brasen@smk.dk wrote:

Hi Megan,

Your basic assumptions are accurately in line with what we discussed.

Regarding the outstanding questions:

  1. No, we don't think there should be any restrictions to a hard saved Location/movement/inventory record when a related cataloguing record is deleted. To us a location has no meaning without relation to an object.
  2. Our answer to the "b" part of this question would be: Yes, if a storage location display name is updated, this change should be propagated to all records
  3. In a set of wireframes the fabulous Erin Yu has suggested to have an Edit on/off button in this procedure. See this wireframe: http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png  and the PowerPoint attached to this page: http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true . Actually much of the functionality suggested in this set of wireframes is formidably clear.

Cheers,

Kim

Best regards

Kim Brasen

Curator

T +45 3374 8460 tel:%2B45%203374%208460

Statens Museum for Kunst

Sølvgade 48-50

DK-1307 København K

T +45 3374 8494 tel:%2B45%203374%208494

F +45 3374 8404 tel:%2B45%203374%208404

smk.dk http://smk.dk/

Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes
Sendt: 23. februar 2012 21:06
Til: CollectionSpace Talk List
Emne: [Talk] Update on the Location and Movement Upgrade

Thanks to everyone who responded to my inquiries about upgrading our current approach to location and movement tracking. After a great set of follow-up conversations with Berkeley, SMK, and Walker, I think we have a front runner for a solution. Unsurprisingly, it's neither of the solutions proposed in the original email!

Please read through the below and let me know if it accurately captures what we discussed. If everyone is good with this approach, it will go on the docket for Release 2.3.

The basics to the upgraded approach:

Outstanding questions:

  • Should records (e.g. cataloging) related to a "hard" saved location/movement/inventory record?
  • Do we need to make any complementary adjustments to the storage location authority? For example, if a storage location display name is updated, should this change be propagated only to new location/movement/inventory records, to new records and records under "regular" save, or to all records?
  • Does anyone have a better name than "hard" save?

Thanks everyone for your great input on this issue! Chris - I got your email after writing this one; I will add some wireframe sketches to the wiki page.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800 tel:718%20777%206800
Direct 718 777 6834 tel:718%20777%206834

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi Carly, I wasn't aware that Megan was away already - I'll address you in the future then. Thanks for your reply. We are in total agreement. As you, we believe we need an indicator in all cases - the exact format is not important to us, as long as the indication is clear. Cheers, Kim Best regards, Kim Brasen Curator T +45 3374 8460 Statens Museum for Kunst Sølvgade 48-50 DK-1307 København K T +45 3374 8494 F +45 3374 8404 smk.dk <http://smk.dk/> ________________________________ Fra: Carly Bogen [mailto:cbogen@gmail.com] Sendt: 28. februar 2012 23:38 Til: Kim Brasen Cc: Megan Forbes; talk@lists.collectionspace.org Emne: Re: [Talk] Update on the Location and Movement Upgrade Hi Kim, I'm responding on Megan's behalf since she's officially on leave as of yesterday. Erin's Edit on/off button is a good solution for an indicator of whether a record is in a "hard save" or "soft save" state. However, it would likely be simply an indicator of the state of a record, and not a working button, with the "Save" button doing the actual work. When the user clicks "save", they will be given the option in the save confirmation dialog of using a "hard save" or a "soft save". This brings up another question that I would love for implementers to weigh in on. This hard or soft save indicator would display on the location/movement/inventory record itself. Should there also be an indicator display in search results? What about in the list of related records in the secondary tabs and in the right sidebar? If this indicator is displayed, should it simply be text, or should it be in the same green/red format as the indicator on the record itself as shown in Erin's wireframes? In my opinion, we would need an indicator in all cases. For instance, if a user is looking at the related location/movement/inventory records for an object in the right sidebar, they would want to know which records show where an object actually is or was located, and which are planned only. Thanks! Carly __ Carly Bogen Acting Registrar MUSEUM OF THE MOVING IMAGE 36-01 35 Avenue, Astoria, NY 11106 movingimage.us <http://movingimage.us/> 718 777 6800 Direct: 718 777 6841 On Tue, Feb 28, 2012 at 8:23 AM, Kim Brasen <Kim.Brasen@smk.dk> wrote: Hi Megan, Your basic assumptions are accurately in line with what we discussed. Regarding the outstanding questions: 1. No, we don't think there should be any restrictions to a hard saved Location/movement/inventory record when a related cataloguing record is deleted. To us a location has no meaning without relation to an object. 2. Our answer to the "b" part of this question would be: Yes, if a storage location display name is updated, this change should be propagated to all records 3. In a set of wireframes the fabulous Erin Yu has suggested to have an Edit on/off button in this procedure. See this wireframe: http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png <http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png> and the PowerPoint attached to this page: http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true <http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true> . Actually much of the functionality suggested in this set of wireframes is formidably clear. Cheers, Kim Best regards Kim Brasen Curator T +45 3374 8460 <tel:%2B45%203374%208460> Statens Museum for Kunst Sølvgade 48-50 DK-1307 København K T +45 3374 8494 <tel:%2B45%203374%208494> F +45 3374 8404 <tel:%2B45%203374%208404> smk.dk <http://smk.dk/> ________________________________ Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes Sendt: 23. februar 2012 21:06 Til: CollectionSpace Talk List Emne: [Talk] Update on the Location and Movement Upgrade Thanks to everyone who responded to my inquiries about upgrading our current approach to location and movement tracking. After a great set of follow-up conversations with Berkeley, SMK, and Walker, I think we have a front runner for a solution. Unsurprisingly, it's neither of the solutions proposed in the original email! Please read through the below and let me know if it accurately captures what we discussed. If everyone is good with this approach, it will go on the docket for Release 2.3. The basics to the upgraded approach: - Keep Location and Movement together as a procedure - Add the Inventory information group to this procedure, draft schema available here: http://wiki.collectionspace.org/display/collectionspace/Inventory+Control+Schema - To support the request that location moves be uneditable once they're entered, we'll add a new type of save that takes a record to un-editable status. This "hard" save will make the location/movement/inventory record and its relationships read only. Location/movement/inventory records may still be saved using a "regular" save, meaning that their data and relationships can be changed, so that the procedure can also be used as a planning tool for future moves. Proposed workflows: http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Upgrade+Option+III+Workflows. Outstanding questions: - Should records (e.g. cataloging) related to a "hard" saved location/movement/inventory record? - Do we need to make any complementary adjustments to the storage location authority? For example, if a storage location display name is updated, should this change be propagated only to new location/movement/inventory records, to new records and records under "regular" save, or to all records? - Does anyone have a better name than "hard" save? Thanks everyone for your great input on this issue! Chris - I got your email after writing this one; I will add some wireframe sketches to the wiki page. Best regards, Megan -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us 718 777 6800 <tel:718%20777%206800> Direct 718 777 6834 <tel:718%20777%206834> _______________________________________________ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Attached image
CH
Chris Hoffman
Wed, Feb 29, 2012 2:41 PM

Hi all,

I really wish we could get some wireframes/mockups on this hard/soft save business though I know the project doesn't have access to that now.  I am concerned that some implementers won't understand the implications until they see what you're all talking about.  I am having difficulties myself.  I'm hoping some of the UCB implementers on this list are tracking this closer.  We are working on some design around moveable containers (crates, boxes) for PAHMA and will be building some functionality to help with those.

What I don't understand on the merged L/M/I screen is what it will look like, not only on the procedure screen itself, but in the Find and Edit search results, and in the right panel (when it's a related record).  Will people know whether it's a Location, Movement, or Inventory record?  Will they be able to look at a collection object and quickly see its current location?  I think those issues are actually more important than the hard/soft save issues.  Maybe others already can foresee this stuff.  I just know that the current approach is very problematic, and now we're actually making it more complex.

Sorry for being a thorn in this.

Thanks,
Chris

On Feb 29, 2012, at 12:41 AM, Kim Brasen wrote:

Hi Carly,

I wasn’t aware that Megan was away already – I’ll address you in the future then.

Thanks for your reply. We are in total agreement. As you, we believe we need an indicator in all cases – the exact format is not important to us, as long as the indication is clear.

Cheers,
Kim

Best regards,

Kim Brasen
Curator

T +45 3374 8460

Statens Museum for Kunst
Sølvgade 48-50
DK—1307 København K
T +45 3374 8494
F +45 3374 8404
smk.dk

<image001.jpg>

Fra: Carly Bogen [mailto:cbogen@gmail.com]
Sendt: 28. februar 2012 23:38
Til: Kim Brasen
Cc: Megan Forbes; talk@lists.collectionspace.org
Emne: Re: [Talk] Update on the Location and Movement Upgrade

Hi Kim,

I'm responding on Megan's behalf since she's officially on leave as of yesterday.

Erin's Edit on/off button is a good solution for an indicator of whether a record is in a "hard save" or "soft save" state.  However, it would likely be simply an indicator of the state of a record, and not a working button, with the "Save" button doing the actual work. When the user clicks "save", they will be given the option in the save confirmation dialog of using a "hard save" or a "soft save".

This brings up another question that I would love for implementers to weigh in on.  This hard or soft save indicator would display on the location/movement/inventory record itself.  Should there also be an indicator display in search results?  What about in the list of related records in the secondary tabs and in the right sidebar? If this indicator is displayed, should it simply be text, or should it be in the same green/red format as the indicator on the record itself as shown in Erin's wireframes?

In my opinion, we would need an indicator in all cases.  For instance, if a user is looking at the related location/movement/inventory records for an object in the right sidebar, they would want to know which records show where an object actually is or was located, and which are planned only.

Thanks!
Carly

__
Carly Bogen
Acting Registrar

MUSEUM OF THE MOVING IMAGE
36-01 35 Avenue, Astoria, NY 11106
movingimage.us  718 777 6800
Direct: 718 777 6841

On Tue, Feb 28, 2012 at 8:23 AM, Kim Brasen Kim.Brasen@smk.dk wrote:
Hi Megan,

Your basic assumptions are accurately in line with what we discussed.

Regarding the outstanding questions:

No, we don’t think there should be any restrictions to a hard saved Location/movement/inventory record when a related cataloguing record is deleted. To us a location has no meaning without relation to an object.
Our answer to the “b” part of this question would be: Yes, if a storage location display name is updated, this change should be propagated to all records
In a set of wireframes the fabulous Erin Yu has suggested to have an Edit on/off button in this procedure. See this wireframe: http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png and the PowerPoint attached to this page: http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true. Actually much of the functionality suggested in this set of wireframes is formidably clear.

Cheers,
Kim

Best regards

Kim Brasen
Curator

T +45 3374 8460

Statens Museum for Kunst
Sølvgade 48-50
DK—1307 København K
T +45 3374 8494
F +45 3374 8404
smk.dk

Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes
Sendt: 23. februar 2012 21:06
Til: CollectionSpace Talk List
Emne: [Talk] Update on the Location and Movement Upgrade

Thanks to everyone who responded to my inquiries about upgrading our current approach to location and movement tracking. After a great set of follow-up conversations with Berkeley, SMK, and Walker, I think we have a front runner for a solution. Unsurprisingly, it's neither of the solutions proposed in the original email!

Please read through the below and let me know if it accurately captures what we discussed. If everyone is good with this approach, it will go on the docket for Release 2.3.

The basics to the upgraded approach:

Outstanding questions:

  • Should records (e.g. cataloging) related to a "hard" saved location/movement/inventory record?
  • Do we need to make any complementary adjustments to the storage location authority? For example, if a storage location display name is updated, should this change be propagated only to new location/movement/inventory records, to new records and records under "regular" save, or to all records?
  • Does anyone have a better name than "hard" save?

Thanks everyone for your great input on this issue! Chris - I got your email after writing this one; I will add some wireframe sketches to the wiki page.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800
Direct 718 777 6834

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi all, I really wish we could get some wireframes/mockups on this hard/soft save business though I know the project doesn't have access to that now. I am concerned that some implementers won't understand the implications until they see what you're all talking about. I am having difficulties myself. I'm hoping some of the UCB implementers on this list are tracking this closer. We are working on some design around moveable containers (crates, boxes) for PAHMA and will be building some functionality to help with those. What I don't understand on the merged L/M/I screen is what it will look like, not only on the procedure screen itself, but in the Find and Edit search results, and in the right panel (when it's a related record). Will people know whether it's a Location, Movement, or Inventory record? Will they be able to look at a collection object and quickly see its current location? I think those issues are actually more important than the hard/soft save issues. Maybe others already can foresee this stuff. I just know that the current approach is very problematic, and now we're actually making it more complex. Sorry for being a thorn in this. Thanks, Chris On Feb 29, 2012, at 12:41 AM, Kim Brasen wrote: > Hi Carly, > > I wasn’t aware that Megan was away already – I’ll address you in the future then. > > Thanks for your reply. We are in total agreement. As you, we believe we need an indicator in all cases – the exact format is not important to us, as long as the indication is clear. > > Cheers, > Kim > > > > Best regards, > > Kim Brasen > Curator > > T +45 3374 8460 > > Statens Museum for Kunst > Sølvgade 48-50 > DK—1307 København K > T +45 3374 8494 > F +45 3374 8404 > smk.dk > > <image001.jpg> > > > Fra: Carly Bogen [mailto:cbogen@gmail.com] > Sendt: 28. februar 2012 23:38 > Til: Kim Brasen > Cc: Megan Forbes; talk@lists.collectionspace.org > Emne: Re: [Talk] Update on the Location and Movement Upgrade > > Hi Kim, > > I'm responding on Megan's behalf since she's officially on leave as of yesterday. > > Erin's Edit on/off button is a good solution for an indicator of whether a record is in a "hard save" or "soft save" state. However, it would likely be simply an indicator of the state of a record, and not a working button, with the "Save" button doing the actual work. When the user clicks "save", they will be given the option in the save confirmation dialog of using a "hard save" or a "soft save". > > This brings up another question that I would love for implementers to weigh in on. This hard or soft save indicator would display on the location/movement/inventory record itself. Should there also be an indicator display in search results? What about in the list of related records in the secondary tabs and in the right sidebar? If this indicator is displayed, should it simply be text, or should it be in the same green/red format as the indicator on the record itself as shown in Erin's wireframes? > > In my opinion, we would need an indicator in all cases. For instance, if a user is looking at the related location/movement/inventory records for an object in the right sidebar, they would want to know which records show where an object actually is or was located, and which are planned only. > > Thanks! > Carly > > __ > Carly Bogen > Acting Registrar > > MUSEUM OF THE MOVING IMAGE > 36-01 35 Avenue, Astoria, NY 11106 > movingimage.us 718 777 6800 > Direct: 718 777 6841 > > On Tue, Feb 28, 2012 at 8:23 AM, Kim Brasen <Kim.Brasen@smk.dk> wrote: > Hi Megan, > > Your basic assumptions are accurately in line with what we discussed. > > Regarding the outstanding questions: > > No, we don’t think there should be any restrictions to a hard saved Location/movement/inventory record when a related cataloguing record is deleted. To us a location has no meaning without relation to an object. > Our answer to the “b” part of this question would be: Yes, if a storage location display name is updated, this change should be propagated to all records > In a set of wireframes the fabulous Erin Yu has suggested to have an Edit on/off button in this procedure. See this wireframe: http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.png and the PowerPoint attached to this page: http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true. Actually much of the functionality suggested in this set of wireframes is formidably clear. > > Cheers, > Kim > > > > Best regards > > Kim Brasen > Curator > > T +45 3374 8460 > > Statens Museum for Kunst > Sølvgade 48-50 > DK—1307 København K > T +45 3374 8494 > F +45 3374 8404 > smk.dk > > > > > Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes > Sendt: 23. februar 2012 21:06 > Til: CollectionSpace Talk List > Emne: [Talk] Update on the Location and Movement Upgrade > > Thanks to everyone who responded to my inquiries about upgrading our current approach to location and movement tracking. After a great set of follow-up conversations with Berkeley, SMK, and Walker, I think we have a front runner for a solution. Unsurprisingly, it's neither of the solutions proposed in the original email! > > Please read through the below and let me know if it accurately captures what we discussed. If everyone is good with this approach, it will go on the docket for Release 2.3. > > The basics to the upgraded approach: > > - Keep Location and Movement together as a procedure > - Add the Inventory information group to this procedure, draft schema available here: http://wiki.collectionspace.org/display/collectionspace/Inventory+Control+Schema > - To support the request that location moves be uneditable once they're entered, we'll add a new type of save that takes a record to un-editable status. This "hard" save will make the location/movement/inventory record and its relationships read only. Location/movement/inventory records may still be saved using a "regular" save, meaning that their data and relationships can be changed, so that the procedure can also be used as a planning tool for future moves. Proposed workflows: http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Upgrade+Option+III+Workflows. > > Outstanding questions: > > - Should records (e.g. cataloging) related to a "hard" saved location/movement/inventory record? > - Do we need to make any complementary adjustments to the storage location authority? For example, if a storage location display name is updated, should this change be propagated only to new location/movement/inventory records, to new records and records under "regular" save, or to all records? > - Does anyone have a better name than "hard" save? > > Thanks everyone for your great input on this issue! Chris - I got your email after writing this one; I will add some wireframe sketches to the wiki page. > > Best regards, > Megan > > > > > -- > Megan Forbes > Collection Manager > > Museum of the Moving Image > 36-01 35 Avenue Astoria, NY 11106 > movingimage.us 718 777 6800 > Direct 718 777 6834 > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
CB
Carly Bogen
Fri, Mar 2, 2012 10:47 PM

Hi Chris,

For this solution, the L/M/I record will look and function exactly the same
way as the current L/M procedure, with one extra information group added.
The record will appear in Find and Edit and in the right sidebar the same
way - users will be able to tell what type of record it is by the ID
number, and can quickly see the current location of an object by visiting
the L/M/I secondary tab for that object.

Hope that helps,

__

Carly Bogen

Acting Registrar

MUSEUM OF THE MOVING IMAGE

36-01 35 Avenue, Astoria, NY 11106

movingimage.us  718 777 6800

Direct: 718 777 6841

On Wed, Feb 29, 2012 at 9:41 AM, Chris Hoffman
chris.hoffman@berkeley.eduwrote:

Hi all,

I really wish we could get some wireframes/mockups on this hard/soft save
business though I know the project doesn't have access to that now.  I am
concerned that some implementers won't understand the implications until
they see what you're all talking about.  I am having difficulties myself.
I'm hoping some of the UCB implementers on this list are tracking this
closer.  We are working on some design around moveable containers (crates,
boxes) for PAHMA and will be building some functionality to help with
those.

What I don't understand on the merged L/M/I screen is what it will look
like, not only on the procedure screen itself, but in the Find and Edit
search results, and in the right panel (when it's a related record).  Will
people know whether it's a Location, Movement, or Inventory record?  Will
they be able to look at a collection object and quickly see its current
location?  I think those issues are actually more important than the
hard/soft save issues.  Maybe others already can foresee this stuff.  I
just know that the current approach is very problematic, and now we're
actually making it more complex.

Sorry for being a thorn in this.

Thanks,
Chris

On Feb 29, 2012, at 12:41 AM, Kim Brasen wrote:

**

Hi Carly,****

I wasn’t aware that Megan was away already – I’ll address you in the
future then.****

Thanks for your reply. We are in total agreement. As you, we believe we
need an indicator in all cases – the exact format is not important to us,
as long as the indication is clear.****

Cheers,****

Kim****

Best regards,****

Kim Brasen**

Curator

T +45 3374 8460****

Statens Museum for Kunst****

Sølvgade 48-50****

DK—1307 København K****

T +45 3374 8494****

F +45 3374 8404****

smk.dk****

<image001.jpg>****

Fra: Carly Bogen [mailto:cbogen@gmail.com]
Sendt: 28. februar 2012 23:38
Til: Kim Brasen
Cc: Megan Forbes; talk@lists.collectionspace.org
Emne: Re: [Talk] Update on the Location and Movement Upgrade****

Hi Kim,****

I'm responding on Megan's behalf since she's officially on leave as of
yesterday.****

Erin's Edit on/off button is a good solution for an indicator of whether a
record is in a "hard save" or "soft save" state.  However, it would likely
be simply an indicator of the state of a record, and not a working button,
with the "Save" button doing the actual work. When the user clicks "save",
they will be given the option in the save confirmation dialog of using a
"hard save" or a "soft save".****

This brings up another question that I would love for implementers to
weigh in on.  This hard or soft save indicator would display on the
location/movement/inventory record itself.  Should there also be an
indicator display in search results?  What about in the list of related
records in the secondary tabs and in the right sidebar? If this indicator
is displayed, should it simply be text, or should it be in the same
green/red format as the indicator on the record itself as shown in Erin's
wireframes?****

In my opinion, we would need an indicator in all cases.  For instance, if
a user is looking at the related location/movement/inventory records for an
object in the right sidebar, they would want to know which records show
where an object actually is or was located, and which are planned only.  *

Thanks!****

Carly****

__****
Carly Bogen****
Acting Registrar****

MUSEUM OF THE MOVING IMAGE****
36-01 35 Avenue, Astoria, NY 11106****

movingimage.us  718 777 6800
Direct: 718 777 6841****

On Tue, Feb 28, 2012 at 8:23 AM, Kim Brasen Kim.Brasen@smk.dk wrote:

Hi Megan,****

Your basic assumptions are accurately in line with what we discussed.****

Regarding the outstanding questions:****

1. No, we don’t think there should be any restrictions to a hard saved
Location/movement/inventory record when a related cataloguing record is
deleted. To us a location has no meaning without relation to an object.
****
2. Our answer to the “b” part of this question would be: Yes, if a
storage location display name is updated, this change should be propagated
to all records****
3. In a set of wireframes the fabulous Erin Yu has suggested to have
an Edit on/off button in this procedure. See this wireframe:
http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.pngand the PowerPoint attached to this page:
http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true.
Actually much of the functionality suggested in this set of wireframes is
formidably clear.****

Cheers,****

Kim****

Best regards****

Kim Brasen****

Curator****

T +45 3374 8460****

Statens Museum for Kunst****

Sølvgade 48-50****

DK—1307 København K****

T +45 3374 8494****

F +45 3374 8404****

smk.dk****

Fra: talk-bounces@lists.collectionspace.org [mailto:
talk-bounces@lists.collectionspace.org] På vegne af Megan Forbes
Sendt: 23. februar 2012 21:06
Til: CollectionSpace Talk List
Emne: [Talk] Update on the Location and Movement Upgrade**

Thanks to everyone who responded to my inquiries about upgrading our
current approach to location and movement tracking. After a great set of
follow-up conversations with Berkeley, SMK, and Walker, I think we have a
front runner for a solution. Unsurprisingly, it's neither of the solutions
proposed in the original email!****

Please read through the below and let me know if it accurately captures
what we discussed. If everyone is good with this approach, it will go on
the docket for Release 2.3.

The basics to the upgraded approach:

Outstanding questions:

  • Should records (e.g. cataloging) related to a "hard" saved
    location/movement/inventory record?
  • Do we need to make any complementary adjustments to the storage location
    authority? For example, if a storage location display name is updated,
    should this change be propagated only to new location/movement/inventory
    records, to new records and records under "regular" save, or to all records?
  • Does anyone have a better name than "hard" save?

Thanks everyone for your great input on this issue! Chris - I got your
email after writing this one; I will add some wireframe sketches to the
wiki page.

Best regards,
Megan

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800
Direct 718 777 6834 <718%20777%206834>****

Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
**

Hi Chris, For this solution, the L/M/I record will look and function exactly the same way as the current L/M procedure, with one extra information group added. The record will appear in Find and Edit and in the right sidebar the same way - users will be able to tell what type of record it is by the ID number, and can quickly see the current location of an object by visiting the L/M/I secondary tab for that object. Hope that helps, __ *Carly Bogen* Acting Registrar MUSEUM OF THE MOVING IMAGE 36-01 35 Avenue, Astoria, NY 11106 movingimage.us 718 777 6800 Direct: 718 777 6841 On Wed, Feb 29, 2012 at 9:41 AM, Chris Hoffman <chris.hoffman@berkeley.edu>wrote: > Hi all, > > I really wish we could get some wireframes/mockups on this hard/soft save > business though I know the project doesn't have access to that now. I am > concerned that some implementers won't understand the implications until > they see what you're all talking about. I am having difficulties myself. > I'm hoping some of the UCB implementers on this list are tracking this > closer. We are working on some design around moveable containers (crates, > boxes) for PAHMA and will be building some functionality to help with > those. > > What I don't understand on the merged L/M/I screen is what it will look > like, not only on the procedure screen itself, but in the Find and Edit > search results, and in the right panel (when it's a related record). Will > people know whether it's a Location, Movement, or Inventory record? Will > they be able to look at a collection object and quickly see its current > location? I think those issues are actually more important than the > hard/soft save issues. Maybe others already can foresee this stuff. I > just know that the current approach is very problematic, and now we're > actually making it more complex. > > Sorry for being a thorn in this. > > Thanks, > Chris > > > On Feb 29, 2012, at 12:41 AM, Kim Brasen wrote: > > ** > > Hi Carly,**** > > ** ** > > I wasn’t aware that Megan was away already – I’ll address you in the > future then.**** > > ** ** > > Thanks for your reply. We are in total agreement. As you, we believe we > need an indicator in all cases – the exact format is not important to us, > as long as the indication is clear.**** > > ** ** > > Cheers,**** > > Kim**** > > ** ** > > **** > > **** > > Best regards,**** > > **** > > ***Kim Brasen***** > > *Curator* > > **** > > T +45 3374 8460**** > > **** > > Statens Museum for Kunst**** > > Sølvgade 48-50**** > > DK—1307 København K**** > > T +45 3374 8494**** > > F +45 3374 8404**** > > smk.dk**** > > **** > > <image001.jpg>**** > > **** > > **** > ------------------------------ > > *Fra:* Carly Bogen [mailto:**cbogen@gmail.com**] > *Sendt:* 28. februar 2012 23:38 > *Til:* **Kim Brasen** > *Cc:* Megan Forbes; talk@lists.collectionspace.org > *Emne:* Re: [Talk] Update on the Location and Movement Upgrade**** > > ** ** > > Hi Kim,**** > > ** ** > > I'm responding on Megan's behalf since she's officially on leave as of > yesterday.**** > > ** ** > > Erin's Edit on/off button is a good solution for an indicator of whether a > record is in a "hard save" or "soft save" state. However, it would likely > be simply an indicator of the state of a record, and not a working button, > with the "Save" button doing the actual work. When the user clicks "save", > they will be given the option in the save confirmation dialog of using a > "hard save" or a "soft save".**** > > ** ** > > This brings up another question that I would love for implementers to > weigh in on. This hard or soft save indicator would display on the > location/movement/inventory record itself. Should there also be an > indicator display in search results? What about in the list of related > records in the secondary tabs and in the right sidebar? If this indicator > is displayed, should it simply be text, or should it be in the same > green/red format as the indicator on the record itself as shown in Erin's > wireframes?**** > > ** ** > > In my opinion, we would need an indicator in all cases. For instance, if > a user is looking at the related location/movement/inventory records for an > object in the right sidebar, they would want to know which records show > where an object actually is or was located, and which are planned only. * > *** > > ** ** > > Thanks!**** > > Carly**** > > ** ** > __**** > *Carly Bogen***** > Acting Registrar**** > **** > MUSEUM OF THE MOVING IMAGE**** > 36-01 35 Avenue, Astoria, NY 11106**** > > movingimage.us 718 777 6800 > Direct: 718 777 6841**** > > On Tue, Feb 28, 2012 at 8:23 AM, **Kim Brasen** <Kim.Brasen@smk.dk> wrote: > **** > > Hi Megan,**** > > **** > > Your basic assumptions are accurately in line with what we discussed.**** > > **** > > Regarding the outstanding questions:**** > > **** > > 1. No, we don’t think there should be any restrictions to a hard saved > Location/movement/inventory record when a related cataloguing record is > deleted. To us a location has no meaning without relation to an object. > **** > 2. Our answer to the “b” part of this question would be: Yes, if a > storage location display name is updated, this change should be propagated > to all records**** > 3. In a set of wireframes the fabulous Erin Yu has suggested to have > an Edit on/off button in this procedure. See this wireframe: > http://wiki.collectionspace.org/download/attachments/30540280/LocationMovement.pngand the PowerPoint attached to this page: > http://wiki.collectionspace.org/pages/viewpageattachments.action?pageId=30540280&metadataLink=true. > Actually much of the functionality suggested in this set of wireframes is > formidably clear.**** > > **** > > Cheers,**** > > Kim**** > > **** > > **** > > **** > > Best regards**** > > **** > > ***Kim Brasen******* > > *Curator***** > > **** > > T +45 3374 8460**** > > **** > > Statens Museum for Kunst**** > > Sølvgade 48-50**** > > DK—1307 København K**** > > T +45 3374 8494**** > > F +45 3374 8404**** > > smk.dk**** > > **** > > **** > > **** > > **** > ------------------------------ > > *Fra:* talk-bounces@lists.collectionspace.org [mailto: > talk-bounces@lists.collectionspace.org] *På vegne af *Megan Forbes > *Sendt:* 23. februar 2012 21:06 > *Til:* CollectionSpace Talk List > *Emne:* [Talk] Update on the Location and Movement Upgrade**** > > **** > > Thanks to everyone who responded to my inquiries about upgrading our > current approach to location and movement tracking. After a great set of > follow-up conversations with Berkeley, SMK, and Walker, I think we have a > front runner for a solution. Unsurprisingly, it's neither of the solutions > proposed in the original email!**** > > > Please read through the below and let me know if it accurately captures > what we discussed. If everyone is good with this approach, it will go on > the docket for Release 2.3. > > The basics to the upgraded approach: > > - Keep Location and Movement together as a procedure > - Add the Inventory information group to this procedure, draft schema > available here: > http://wiki.collectionspace.org/display/collectionspace/Inventory+Control+Schema > - To support the request that location moves be uneditable once they're > entered, we'll add a new type of save that takes a record to un-editable > status. This "hard" save will make the location/movement/inventory record > and its relationships read only. Location/movement/inventory records may > still be saved using a "regular" save, meaning that their data and > relationships can be changed, so that the procedure can also be used as a > planning tool for future moves. Proposed workflows: > http://wiki.collectionspace.org/display/collectionspace/Location+and+Movement+Upgrade+Option+III+Workflows. > > > Outstanding questions: > > - Should records (e.g. cataloging) related to a "hard" saved > location/movement/inventory record? > - Do we need to make any complementary adjustments to the storage location > authority? For example, if a storage location display name is updated, > should this change be propagated only to new location/movement/inventory > records, to new records and records under "regular" save, or to all records? > - Does anyone have a better name than "hard" save? > > Thanks everyone for your great input on this issue! Chris - I got your > email after writing this one; I will add some wireframe sketches to the > wiki page. > > Best regards, > Megan > > > > > -- > Megan Forbes > Collection Manager > > Museum of the Moving Image > 36-01 35 Avenue Astoria, NY 11106 > movingimage.us 718 777 6800 > Direct 718 777 6834 <718%20777%206834>**** > > **** > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > **** > > ** ** > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > ** > > >
Empathy v1.0   2025 ©emwd.com
Documentation