Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI sync semantic kompakkt and kompakkt Metadata #42

Open
Grizzly127 opened this issue Jun 11, 2024 · 31 comments
Open

UI sync semantic kompakkt and kompakkt Metadata #42

Grizzly127 opened this issue Jun 11, 2024 · 31 comments

Comments

@Grizzly127
Copy link
Contributor

Grizzly127 commented Jun 11, 2024

Metadata next to the object

I noticed that the information for the object view are very different in kompakkt and sk. In terms of what kind of information you can see and especially the “Persons and Institutions”/“Related agents” section. This issue is to discuss and decide which information is important here and how we decide to make it consistent in kompakkt and sk?

sk right now:
Bildschirmfoto 2024-06-07 um 12 42 20
kompakkt right now:
Bildschirmfoto 2024-06-07 um 12 41 41

“Related agents” sk:
Bildschirmfoto 2024-06-06 um 18 29 12
“Persons and Institutions” kompakkt:
Bildschirmfoto 2024-06-06 um 18 29 32

@lozanaross @ZetOE

@Grizzly127 Grizzly127 changed the title Ui UI sync semantic kompakkt and kompakkt Metadata Jun 11, 2024
@Grizzly127
Copy link
Contributor Author

Grizzly127 commented Jun 12, 2024

Upload Metadata

We should also discuss how the Upload of the Metadata should look like, it is also very different:

kompakkt:
Bildschirmfoto 2024-06-12 um 15 26 01
sk:
Bildschirmfoto 2024-06-12 um 15 25 22

persons in kompakkt: (also it is not clear what is mandatory and what not, you have to give a contact person for example, but it is not clear to the user, that this information is needed)
kompakkt:
Bildschirmfoto 2024-06-12 um 15 28 05
sk:
Bildschirmfoto 2024-06-12 um 15 30 54

@lozanaross @ZetOE

@lozanaross
Copy link

Metadata next to the object

I noticed that the information for the object view are very different in kompakkt and sk. In terms of what kind of information you can see and especially the “Persons and Institutions”/“Related agents” section. This issue is to discuss and decide which information is important here and how we decide to make it consistent in kompakkt and sk?

Thanks Senya, this is a good issue to resolve. I think we should aim to align this part of the presentation thus:

  • We need to order Licenses, Persons and Institutions & External Links in SK in the order as they are in Kompakkt & then we can add all other SK data (like Creation) below.
  • We need to rename Related agents in SK to 'Related persons and institutions'
  • We need to rename Persons and institutions in Kompakkt to 'Related persons and institutions'
  • When the user opens the dropdown for that field, the should see in both apps the roles for e.g. Rightsowner / Creator styled in the same way - I propose we use the SK styling for that as it's a bit more logical, the pill design doesn't make sense as these elements are not buttons to be clicked. The difference would be though that in SK the names are also hyperlinked because they are links to WB, in Kompakkt the names will not be links. In addition, we should add the address like so "Contact address: [email protected]" (for people) and "Contact address: Germany, 10785 Berlin, Stauffenbergstr. 41-42" (all in one line, independent of how the order is entered by users in WB vs Kompakkt). If users don't add an address in WB, this will simply be invisible in SK.

Can you make two new mockups based on the above and paste one here for Kompakkt changes & one also in SK / Gitlab issue for the SK changes that need to be made there.

@lozanaross
Copy link

Upload Metadata

We should also discuss how the Upload of the Metadata should look like, it is also very different:

Thanks for this comment @Grizzly127 - I think we should vote which option we like better - a vertical or horizontal wizard and align both to the same style. @HeyItsBATMAN @ZetOE - what's your opinion here?

I personally I like the "horizontal" style of the SK version a bit better (the other long scroll thing somehow seems endless and might put users off of exploring all options), but perhaps it's also a matter of making the data a bit more lean for Kompakkt (I think in SK we already reduced it a lot, so nothing to cut here, but perhaps we can also add some new bits here especially when it comes to possibility to add new people, or new things in the database if they are not already findable with the search option). If there is less data entry fields, then maybe the long scroll is also not so bad.

By making the data more lean, I mean for example all these fields under General Information:

Statement
Object type
Tags
Discipline

We don't have these in SK, and I wonder what's their function and how many people use them? @HeyItsBATMAN @ZetOE do you have any remarks here - I feel like I've never seen tags or discipline being used as navigation / exploration filters, so what are they for?

If we go through all metadata fields one by one and identify if some can be cut, then perhaps you can try a redesigned mockup @Grizzly127 that puts Kompakkt's structure in something that looks more like SK? Or vice versa. If the Kompakkt's structure is simplified, we can try to put SK's wizard into the long form scroll.

@HeyItsBATMAN
Copy link
Collaborator

I think we should vote which option we like better - a vertical or horizontal wizard and align both to the same style. @HeyItsBATMAN @ZetOE - what's your opinion here?

I'm strongly in favor of the SK style. The long scroll of Kompakkt really complicates things, and also makes it unnecessarily difficult to see what's missing.

Statement
Object type
Tags
Discipline

@ZetOE can probably tell more about the purposes of each of those. But I think the design of SK can be applied to Kompakkt even without removing fields.

@Grizzly127
Copy link
Contributor Author

Grizzly127 commented Jun 18, 2024

Update Metadata next to the object

Thanks Senya, this is a good issue to resolve. I think we should aim to align this part of the presentation thus (...)

The order for the information next to the object in kompakkt is now this:
License - Related persons and institutions - External links
Bildschirmfoto 2024-06-18 um 15 20 18

Can we align the information options with the title above and use a 32px padding right and left of the information card?

In kompakkt we need to change the license information like this then it is the same like in sk:
Bildschirmfoto 2024-06-18 um 15 20 40

before I continue to make the Related persons and institutions information looking good, just one question for the Contact address information. Is there for every person/institute behind their role? (That means that it sometimes is repeated) or is there one information for who is the contact person/institution?

one person with two roles:
left: contact address repeated, right: role as contact person with address
Bildschirmfoto 2024-06-18 um 15 26 00

one person and one institution having a role:
left: one person and one institution have a role and contact addresses, right: the institution functions as contact person
Bildschirmfoto 2024-06-18 um 15 26 49

@lozanaross

@lozanaross
Copy link

@Grizzly127 As discussed today, the cases when the same person or institution have more than one role, the roles can be listed on one line with a comma or & sign, eg: Rights owner & Creator: Lozana Rossenova ... The address info is then listed below (only once).

Also from discussion today with @Grizzly127 & @vmalieske - Next button will be used as is currently in SK & Kompakkt - so it only progresses to the next stage in the stepper wizard and not through individual metadata. To check the different metadata sections, users can navigate via the sidebar. The Next button will be titled "Finalize" and will be greyed out until the users complete at least the 3 mandatory fields, then it will be possible to progress to the final step in the stepper. We will also test the inclusion of a "Save" button in the bottom area of the wizard, so that users feel more secure they won't lose their metadata if they don't immediately finish the upload.

cc @HeyItsBATMAN

@Grizzly127
Copy link
Contributor Author

Grizzly127 commented Jul 17, 2024

Decision for displaying the persons and institutions next to the object:
Bildschirmfoto 2024-07-17 um 16 06 57
If a person or institution has more than one role, it can be listet with a comma.
and under every person or institution you can find a contact address.
Let's make a gap of 8px between name and address and 16px between the information.
Bildschirmfoto 2024-07-17 um 16 16 26

@vmalieske @lozanaross

@Grizzly127
Copy link
Contributor Author

Upload Metadata

This is my suggestion for the design for the upload formular:

  • Change the title "Edit object" to our H2 font, open sans, 16px, bold
  • the order of the information options is adjusted to the order we defined for the information next to the object now.
  • the symbol at the option titles is the same now for every option, but the optional information gets a title to be separated from the mandatory information
  • the arrow symbol for the mandatory information is in the pink color as long as it is not filled out
  • the buttons on the bottom are for navigating the stepper and therefore they are disables as long as the mandatory information is not filled out. We changed the right button from "Next" to "Finalize" to clarify that it is not to guide the user through the information options
  • under everything that you can fill out there ist a save button to make the user feel save to keep their metadata.
  • I also used a grid for the design, let me know if it is already important to make the adjustments that detailed, then I can give more information about the measurements @lozanaross @vmalieske
Bildschirmfoto 2024-07-17 um 17 05 05 Bildschirmfoto 2024-07-17 um 17 04 25 Bildschirmfoto 2024-07-17 um 17 06 35 Bildschirmfoto 2024-07-17 um 17 06 50 Bildschirmfoto 2024-07-17 um 17 07 05 Bildschirmfoto 2024-07-17 um 17 07 16 Bildschirmfoto 2024-07-17 um 17 07 39 Bildschirmfoto 2024-07-17 um 17 07 52

Finalize upload

  • use the H2, open sans, 16, bold for the Metadata header
  • gap between elements: 16px
  • should we also add the roles that you gave the persons here?
Bildschirmfoto 2024-07-17 um 17 08 07 Bildschirmfoto 2024-07-17 um 17 10 46

@lozanaross @vmalieske
cc @HeyItsBATMAN

@Grizzly127
Copy link
Contributor Author

Grizzly127 commented Jul 17, 2024

Update for Metadata next to the object

to make it look better, we could decide to make it look more like a table, the roles have always the same space (length of 120px) and are separated through a new line, therefore the persons or institutions always start at the same position and it looks cleaner. And then no gap between the person and the contact adress.
What do you think?
Bildschirmfoto 2024-07-17 um 17 38 43

@lozanaross @vmalieske

@HeyItsBATMAN
Copy link
Collaborator

should we also add the roles that you gave the persons here?

Sounds like a good idea to me. In general, we could include the information of all required fields here (on the finalize page), and re-use the design/component from the detail page for this?

@Grizzly127
Copy link
Contributor Author

Good idea, then we would have it in the same way like next to the object here:
Bildschirmfoto 2024-07-17 um 17 37 08

@lozanaross
Copy link

@Grizzly127 see my comment in Gitlab, i think the Grid presentation is a bit confusing. I think it would look better if we keep all roles on one line, separated by a comma, but maybe we move the contact name to a new line to avoid awkward gaps.

@lozanaross
Copy link

@Grizzly127 & @HeyItsBATMAN - one more question regarding the metadata upload form - are all the fields really the same between Kompakkt and SK - so icluding creation & the related properties like software, technique, etc? Perhaps it's worth thinking about a slightly alternative way to add these because in SK they are coming from Wikibase, in Kompakkt they can be entered manually, so the entry fields cannot be exactly the same as in SK.

@Grizzly127
Copy link
Contributor Author

@Grizzly127 & @HeyItsBATMAN - one more question regarding the metadata upload form - are all the fields really the same between Kompakkt and SK - so icluding creation & the related properties like software, technique, etc? Perhaps it's worth thinking about a slightly alternative way to add these because in SK they are coming from Wikibase, in Kompakkt they can be entered manually, so the entry fields cannot be exactly the same as in SK.

Right now, this is the Creation part for kompakkt:
Bildschirmfoto 2024-08-02 um 13 18 41

and this for semantic kompakkt:
Bildschirmfoto 2024-08-02 um 13 18 50

How do the fields look like if the information is coming from Wikibase? I'm not sure if I have seen it somewhere yet.
@lozanaross

@lozanaross
Copy link

@Grizzly127 The Wikibase entries have the magnifier glass because it's only allowing search of existing entries. In Kompakkt I think you can just enter plain text? Or can you also search existing entries? Not sure, but probably you don't need the magnifier glass there. And maybe "Program" in Kompakkt can also be renamed Software to keep it more similar to SK. It also looks like creation is mandatory in Kompakkt, but it's not in SK, so that can be something further aligned. What fields are mandatory, what not, etc.

vmalieske added a commit to vmalieske/Repo that referenced this issue Aug 2, 2024
- update licence view
- update persons and institutions

regarding issue Kompakkt#42
@Grizzly127
Copy link
Contributor Author

@Grizzly127 The Wikibase entries have the magnifier glass because it's only allowing search of existing entries. In Kompakkt I think you can just enter plain text? Or can you also search existing entries? Not sure, but probably you don't need the magnifier glass there. And maybe "Program" in Kompakkt can also be renamed Software to keep it more similar to SK. It also looks like creation is mandatory in Kompakkt, but it's not in SK, so that can be something further aligned. What fields are mandatory, what not, etc.

okay, then there will be just small differences:
semantic kompakkt:

  • there is the magnifier glass because you can search through wikibase entries
  • is the equipment field also connected to Wikibase? @lozanaross
Bildschirmfoto 2024-08-05 um 15 46 33

kompakkt:

  • no magnifier glass, because you can only enter plain text
  • Creation is not mandatory in kompakkt (it just turned read, when you clicked on it to add something. The fields "technique and software" were mandatory to add a creation though, I would suggest not to have this two mandatory like in sk)
Bildschirmfoto 2024-08-05 um 15 46 40

@lozanaross
Copy link

lozanaross commented Aug 6, 2024

@Grizzly127

Great, thanks, to the questions below:

  • there is the magnifier glass because you can search through wikibase entries
  • is the equipment field also connected to Wikibase? @lozanaross

Equipment is added to Wikibase, but it's a free-text field, so the user can just add anything here and it's saved as plain text (not data) in Wikibase, this is a compromise because we didn't want to limit what kind of equipment users can enter. It's somewhat similar to what would happen in Kompakkt I assume.

kompakkt:

  • no magnifier glass, because you can only enter plain text
  • Creation is not mandatory in kompakkt (it just turned read, when you clicked on it to add something. The fields "technique and software" were mandatory to add a creation though, I would suggest not to have this two mandatory like in sk)

Yes, this sounds good to me.

Additionally as discussed today, you may need to consider some additional templates that specify how users add new 'entities' in Kompakkt itself, which wouldn't exist in SK because we don't need it for WB.

@Grizzly127
Copy link
Contributor Author

Metadata persons and institutions kompakkt

first suggestion for the form for adding persons and institutions:

  • you have one search field, where you can either look for persons/institutions that already exist. If they exist you can choose them and all the fields below are filled out automatically by the already given information. If the person/institution doesn't exist the user keeps typing in their name and fills out the information below manually. (similar to when you write an email and the program know the email address and can fill it out or you can keep typing in the address if it is a new one)
  • if you fill it out for a new person/institution, you can choose between person and institution and then choose which contact information should be given.
Bildschirmfoto 2024-08-06 um 16 23 18 Bildschirmfoto 2024-08-06 um 16 15 47 Bildschirmfoto 2024-08-06 um 16 18 49

@lozanaross

@Grizzly127
Copy link
Contributor Author

Related physical objects

Let's discuss if we need this option or if we keep it minimal.
For example the user can only type in a name of an object and adds an external link to more information and resources

Bildschirmfoto 2024-08-06 um 16 29 49

@lozanaross @HeyItsBATMAN @ZetOE

@Grizzly127
Copy link
Contributor Author

Metadata Persons and Institutions

We realized that sometimes it is not clear to the user that it is mandatory to add Rightowner and Creator.
I am working on it to make it more clear. This is the first idea:
The two roles are mentioned, but in red, as long as no person or institution is allocated.
As soon as both are allocated, the Save button becomes usable. Other roles appear when they are added.
Bildschirmfoto 2024-08-22 um 12 30 37
Bildschirmfoto 2024-08-22 um 12 30 44
Bildschirmfoto 2024-08-22 um 12 31 27

@lozanaross @ZetOE

@lozanaross
Copy link

lozanaross commented Sep 3, 2024

@Grizzly127 comments below:

Metadata persons and institutions kompakkt

first suggestion for the form for adding persons and institutions:

  • you have one search field, where you can either look for persons/institutions that already exist. If they exist you can choose them and all the fields below are filled out automatically by the already given information. If the person/institution doesn't exist the user keeps typing in their name and fills out the information below manually. (similar to when you write an email and the program know the email address and can fill it out or you can keep typing in the address if it is a new one)

Not sure if this can actually work with out Angular framework - @vmalieske can you confirm? If yes, great.

  • if you fill it out for a new person/institution, you can choose between person and institution and then choose which contact information should be given.

Question - will the form dynamically adjust if a person is chosen vs institution? E.g. if a person is chosen we only need Email address & Phone; if instittuion - maybe only physical address? If the form stays exactly the same, do we really need to make a distinction between person / institution? We could also get rid of this extra tick box if nothing else is determined by it.

Additionally, let's adjust the text to: "Email address" and "Phone number" (with spaces). Can we get rid of "Note" - why do we need it? Let's reduce complexity as much as possible.

The rest of the form looks good. Not sure if we need to add the email address in the Section that says "Creator" / "Rightsowner" below the "Add" button. The name should be just enough & the contact info - if it's available - will simply be displayed in the object page. That should be enough I think. It will make it easier to be compatible with SK as well.

@lozanaross
Copy link

@Grizzly127 comments below:

Related physical objects

Let's discuss if we need this option or if we keep it minimal. For example the user can only type in a name of an object and adds an external link to more information and resources

I am in favor of keeping this more minimal - what do you think @HeyItsBATMAN @ZetOE? For me just a title of the object, link to Wikidata or another external link would be sufficient.

I think the link text should be more description, e.g.:
"Add link to external source information about the physical object, e.g. Wikidata, or institutional website"

Users should be able to add more than one link.

What other information is otherwise added via Kompakkt? @Grizzly127 can you provide a bullet list below and we can discuss line by line if we can get rid of it all, or we keep a few. It's important to check how much is this feature actually used in the current version of Kompakkt before replicating all of it, I think.

@Grizzly127
Copy link
Contributor Author

What other information is otherwise added via Kompakkt? @Grizzly127 can you provide a bullet list below and we can discuss line by line if we can get rid of it all, or we keep a few. It's important to check how much is this feature actually used in the current version of Kompakkt before replicating all of it, I think.

If the user adds a related physical object the following information can be filled out:

  • General Information with Title, Description and Collection:
Bildschirmfoto 2024-10-01 um 14 33 51
  • Place:
Bildschirmfoto 2024-10-01 um 14 28 28
  • a new person can be added:
Bildschirmfoto 2024-10-01 um 14 29 06
  • same with an institution:
Bildschirmfoto 2024-10-01 um 14 29 51
  • External identifiers with Type and Value:
Bildschirmfoto 2024-10-01 um 14 31 11
  • External Links with Description and Value:
Bildschirmfoto 2024-10-01 um 14 30 52
  • Bibliographic References with Value:
Bildschirmfoto 2024-10-01 um 14 32 12
  • Other with description and Value:
Bildschirmfoto 2024-10-01 um 14 32 31
  • Metadata files:
Bildschirmfoto 2024-10-01 um 14 33 06

@lozanaross @ZetOE

@vmalieske
Copy link
Contributor

Persons and Institutions

Unfortunately, I haven't got as far as I wanted to, but this is my current state:

  1. You can search for existing persons and institutions at the same time, and the corresponding values are entered in the form. There are no fields for prename and name in the mockup. They are not really necessary if you add existing persons/institutions, but maybe it is irritating if you have to write the name to add in the input field for the search? What do you think?

image
image

  1. The checkboxes for persons and institutions are used to indicate which fields are required, depending on whether they are persons or institutions. When a person or institution is selected, the corresponding checkbox is automatically activated.

image
image

@lozanaross @Grizzly127 @ZetOE

@vmalieske
Copy link
Contributor

vmalieske commented Dec 3, 2024

One question about the creation-data when adding more than one dataset.
In semantic kompakkt it looks like that:
image

Every field has its own card. Should it be that way or should every field be in one card like that:
image

And creation date can be just one, right?

@lozanaross @HeyItsBATMAN @Grizzly127 @ZetOE

@HeyItsBATMAN
Copy link
Collaborator

Creation date can only be one.
I think separate cards make more sense here because they can then be deleted one by one.
But then on the Entity detail page, they can probably be grouped together?

@Grizzly127
Copy link
Contributor Author

  1. You can search for existing persons and institutions at the same time, and the corresponding values are entered in the form. There are no fields for prename and name in the mockup. They are not really necessary if you add existing persons/institutions, but maybe it is irritating if you have to write the name to add in the input field for the search? What do you think?

I think it can work like this for the user, it works like this on other platforms as well. And we reduce the number of input fields. If we get the feedback that it is confusing, we can still change it.

  1. The checkboxes for persons and institutions are used to indicate which fields are required, depending on whether they are persons or institutions. When a person or institution is selected, the corresponding checkbox is automatically activated.

And if it is a new person, the user can choose if it is a person or institution, right?

Three small things:

  • on top it says that there needs to be a person as rights owner and contact person, but it is rights owner and creator, isn't it?
  • Rights owner not written together for the tick-boxes.
  • There is a mistake in the last sentence: You muSt (nur ein S) specify at least one agent for each of theSe (S statt R) roles.

@lozanaross @ZetOE @vmalieske

@Grizzly127
Copy link
Contributor Author

Corrections for current metadata form Part 1

General Information

  • For me it's not clear what a statement is
  • What is meant with object type? are there examples for what an object type is?
  • Tags often appear two or three times in the dropdown:
Bildschirmfoto 2024-12-17 um 13 22 08
  • I would say "Separate tags with commas or by pressing Enter/Return." and "Separate disciplines with commas or by pressing Enter/Return."
Bildschirmfoto 2024-12-17 um 13 14 52

Licence

  • I think the licence part is okay, maybe we can add a user information here as well like "Select a license that suits your object best." or that fits the way other users are allowed to use it.

Persons
General Information:

  • we could already call it "Related persons" here
  • on the first look it looks like there is no General Information, maybe we can leave this out and only display the name.
  • "You are adding onto an existing person" and the name needs to be differentiated. It looks the same, but one is a user information and the other is the persons name, I think it needs to look different.
  • The sentence "You are adding onto an existing person" is in general a bit confusing. I know that it is meant that the user is able to add new information to a person and then the new information is also saved at the data base connected to the person. But I think the user doesn't understand this concept here. Maybe we just leave this out, the user can see in the form that there is already an email address for example. This information is only interesting in the Contact section and there we have another user information.
Bildschirmfoto 2024-12-17 um 13 25 47

Role Selection:

  • Better only say: "Select at least one role"
  • Right now it is not clear that the user needs to select one Rights owner and one Creator in the end. The text in the beginning says one Rights owner and one Contact Person, which is not correct. The Persons section stays read if no Rights owner or no Creator is selected, but apart from that there is no information about why the form is not complete. The institution part becomes blue no matter what roles are selected.
  • In the end there needs to be one Rights owner and one Creator, no matter if it is a person or institution, right?
  • maybe we can already integrate the part from the new form below the persons and institutions part (second picture)?
Bildschirmfoto 2024-12-17 um 14 09 36 Bildschirmfoto 2024-12-19 um 11 06 27

Contact

  • "You can choose an existing contact reference or attach a new one." This is the concept I talked about before. I'm not sure if it is a common concept for the user. Maybe we can just have the fields filled out where there is already information and if there is more than one e-mail address for example, it can be shown with a dropdown.
  • If "New E-Mail address" is selected, the field is empty and ready to type something in.
  • Phone number (separated)
  • For what is the notes field? Can we leave this out?
Bildschirmfoto 2024-12-17 um 14 10 07 Bildschirmfoto 2024-12-17 um 14 10 21 Bildschirmfoto 2024-12-19 um 12 37 40 Bildschirmfoto 2024-12-19 um 12 41 14

Institutions

  • same notes like in the persons field (look above)
  • What is "additional"? Better Additional information? Additional notes?
Bildschirmfoto 2024-12-17 um 14 16 10

@lozanaross @vmalieske @ZetOE

@Grizzly127
Copy link
Contributor Author

Corrections for current metadata form Part 2

Dimensions, Creation and External Identifiers

  • I wondered if we need the + button or if the fields should always be open immediately
  • Here the required fields are grey and not red with a star like in other parts of the form (e.g. Creation). I think it's because all fields are required here, but we should keep it consistent.
  • I wondered if we should have a "Add" button here? Also to have the feeling of saving the inputs for the user.
Bildschirmfoto 2024-12-19 um 13 07 02
  • Is "Software" the better word for "Program"?
Bildschirmfoto 2024-12-17 um 14 38 46

External Links

  • The Description field is here the "Link label", maybe it is not required and the user can choose if he wants to display the URL or and display text as a link.
  • The Value field should be more like: "Please enter a valid URL" and then it needs to be checked if it is a valid URL
  • Mark required fields consistently
Bildschirmfoto 2024-12-17 um 14 52 02

Bibliographic References

  • "Value" is also weird here. Maybe the field can also be called "Bibliographic reference"
  • Mark required fields consistently
Bildschirmfoto 2024-12-17 um 14 55 34

Other

  • We need to find another term here, "additional information"/"additional notes"?
  • Does Description and Value fit here? Or more an empty text field for notes?
  • Mark required fields consistently
Bildschirmfoto 2024-12-17 um 14 58 52

Metadate Files

  • Gap between the description sentences is too big
  • the data type in the middle looks weird. We can delete it, since it is already behind the name or we need to add headings like in the upload part
  • the delete button is not in the middle
Bildschirmfoto 2024-12-17 um 15 04 21 Bildschirmfoto 2024-12-17 um 15 04 47

Notes:

  • Gap between "Bibliographic references" and the number is too big
Bildschirmfoto 2024-12-17 um 15 10 24

@vmalieske @lozanaross @ZetOE

@Grizzly127
Copy link
Contributor Author

Corrections for current metadata form Part 3

Physical objects
General Information:

  • keep required fields consistent
  • What is meant by Collection? Real world collection the object is from?
Bildschirmfoto 2024-12-17 um 15 11 36

Place:

  • Is "Place" the right word? Is "Location" better?
  • keep required fields consistent, "Name" is now red here, but the other fields also have a star and are not red.
  • The text says that the user needs to fill in name OR geopolitical area OR a specific address, but all fields are with a star, that is confusing
  • What is a geopolitical area, is it a use case to use this field?
Bildschirmfoto 2024-12-17 um 15 32 07

Persons

  • See notes for (related) persons before
  • For what are the roles here? Are they connected to the physical object then? Is Data Creator fitting for a physical object?
Bildschirmfoto 2024-12-17 um 15 39 55 Bildschirmfoto 2024-12-17 um 15 41 57

Notes:

  • here the gap is also too big:
Bildschirmfoto 2024-12-17 um 15 44 58

@vmalieske @lozanaross @ZetOE

@Grizzly127
Copy link
Contributor Author

Corrections for displaying metadata in the object view

  • too many different font sizes
  • the additional notes look a bit lost here, should we mark it as a note?
Bildschirmfoto 2024-12-18 um 15 09 54
  • the street name and city needs to be changed for institutes
  • the gaps between the header and content is too big and I feel like it is not always the same size.
Bildschirmfoto 2024-12-18 um 15 10 18 Bildschirmfoto 2024-12-18 um 15 10 30

Physical object information

  • Place is not working correctly, if I fill out every field in the form, only the address is shown here and not the location name or geopolitical area
  • the G is cut for bibliographical references
  • gaps are here too big and not always the same size as well
  • I would not make a gap between the others information
  • I'm still thinking if we should use the collapse function for every detail again or if it is better to only expand physical objects and then there is every information at once with headers (see example below)
Bildschirmfoto 2024-12-18 um 15 24 11 Bildschirmfoto 2024-12-18 um 15 24 19 Bildschirmfoto 2024-12-18 um 15 24 27

Example:
Bildschirmfoto 2024-12-19 um 14 47 02

@vmalieske @lozanaross @ZetOE

HeyItsBATMAN added a commit that referenced this issue Feb 25, 2025
* Broken state, with the following migration steps:

```bash
npm i --lockfile-version 3 --frozen-lockfile
ng update @angular/{cdk,cli,core,material}@15
ng update @angular/{cdk,cli,core,material}@16
ng update @angular/{cdk,cli,core,material}@17
ng generate @angular/material:mdc-migration
ng update @angular/material@17
ncu -u
```

▸ Remove Browserslist configuration files that matches the Angular CLI default configuration.
  Migration completed (No changes made).

▸ Remove exported `@angular/platform-server` `renderModule` method.
  The `renderModule` method is now exported by the Angular CLI.
  Migration completed (No changes made).

▸ Remove no longer needed require calls in Karma builder main file.
  Migration completed (No changes made).

▸ Update TypeScript compiler `target` and set `useDefineForClassFields`.
  These changes are for IDE purposes as TypeScript compiler options `target` and `useDefineForClassFields` are set to `ES2022` and `false` respectively by the Angular CLI.
  To control ECMA version and features use the Browerslist configuration.
UPDATE tsconfig.json (1550 bytes)
  Migration completed (1 file modified).

▸ Remove options from 'angular.json' that are no longer supported by the official builders.
  Migration completed (No changes made).

** Executing migrations of package '@angular/cdk' **

▸ Updates the Angular CDK to v15.

      ✓  Updated Angular CDK to version 15

  Migration completed (No changes made).

** Executing migrations of package '@angular/core' **

▸ In Angular version 15, the deprecated `relativeLinkResolution` config parameter of the Router is removed.
  This migration removes all `relativeLinkResolution` fields from the Router config objects.
UPDATE src/app/app-routing.module.ts (2163 bytes)
  Migration completed (1 file modified).

▸ Since Angular v15, the `RouterLink` contains the logic of the `RouterLinkWithHref` directive.
  This migration replaces all `RouterLinkWithHref` references with `RouterLink`.
  Migration completed (No changes made).

** Executing migrations of package '@angular/material' **

▸ Updates the Angular Material to v15.

      ✓  Updated Angular Material to version 15

** Executing migrations of package '@angular/cli' **

▸ Remove 'defaultProject' option from workspace configuration.
  The project to use will be determined from the current working directory.
  Migration completed (No changes made).

▸ Replace removed 'defaultCollection' option in workspace configuration with 'schematicCollections'.
  Migration completed (No changes made).

▸ Update the '@angular-devkit/build-angular:server' builder configuration to disable 'buildOptimizer' for non optimized builds.
  Migration completed (No changes made).

** Executing migrations of package '@angular/cdk' **

▸ Updates the Angular CDK to v16.

      ✓  Updated Angular CDK to version 16

  Migration completed (No changes made).

** Executing migrations of package '@angular/core' **

▸ In Angular version 15.2, the guard and resolver interfaces (CanActivate, Resolve, etc) were deprecated.
  This migration removes imports and 'implements' clauses that contain them.
UPDATE src/app/guards/authenticated.guard.ts (417 bytes)
UPDATE src/app/resolvers/profile-page-resolver.ts (684 bytes)
  Migration completed (2 files modified).

▸ As of Angular v16, the `moduleId` property of `@Component` is deprecated as it no longer has any effect.
  Migration completed (No changes made).

** Executing migrations of package '@angular/material' **

▸ Updates the Angular Material to v16.

      ✓  Updated Angular Material to version 16

  Migration completed (No changes made).

** Executing migrations of package '@angular/cli' **

▸ Replace usages of '@nguniversal/builders' with '@angular-devkit/build-angular'.
  Migration completed (No changes made).

▸ Replace usages of '@nguniversal/' packages with '@angular/ssr'.
  Migration completed (No changes made).

▸ Replace deprecated options in 'angular.json'.
UPDATE angular.json (3643 bytes)
  Migration completed (1 file modified).

** Executing migrations of package '@angular/cdk' **

▸ Updates the Angular CDK to v17.

      ✓  Updated Angular CDK to version 17

  Migration completed (No changes made).

** Executing migrations of package '@angular/core' **

▸ Angular v17 introduces a new control flow syntax that uses the @ and } characters.
  This migration replaces the existing usages with their corresponding HTML entities.
UPDATE src/app/pages/static-pages/contact/contact.component.html (2021 bytes)
UPDATE src/app/pages/static-pages/privacy/privacy.component.html (13002 bytes)
UPDATE src/app/pages/static-pages/consortium/consortium.component.html (1491 bytes)
  Migration completed (3 files modified).

▸ Updates `TransferState`, `makeStateKey`, `StateKey` imports from `@angular/platform-browser` to `@angular/core`.
  Migration completed (No changes made).

▸ CompilerOption.useJit and CompilerOption.missingTranslation are unused under Ivy.
  This migration removes their usage
  Migration completed (No changes made).

** Executing migrations of package '@angular/material' **

▸ Updates Angular Material to v17.
    Cannot update to Angular Material v17 because the project is using the legacy Material components
    that have been deleted. While Angular Material v16 is compatible with Angular v17, it is recommended
    to switch away from the legacy components as soon as possible because they no longer receive bug fixes,
    accessibility improvements and new features.

    Read more about migrating away from legacy components: https://material.angular.io/guide/mdc-migration

    Files in the project using legacy Material components:
     - /src/app/app.module.ts
     - /src/app/components/actionbar/actionbar.component.ts
     - /src/app/components/auth-dialog/auth-dialog.component.ts
     - /src/app/components/grid-element/grid-element.component.ts
     - /src/app/components/metadata/entity/entity.component.ts
     - /src/app/components/metadata/institution/institution.component.ts
     - /src/app/components/metadata/person/person.component.ts
     - /src/app/components/navigation/navbar/navbar.component.ts
     - /src/app/dialogs/confirmation-dialog/confirmation-dialog.component.ts
     - /src/app/dialogs/edit-entity-dialog/edit-entity-dialog.component.ts
     - /src/app/dialogs/entity-rights-dialog/entity-rights-dialog.component.ts
     - /src/app/dialogs/entity-settings-dialog/entity-settings-dialog.component.ts
     - /src/app/dialogs/explore-compilation-dialog/explore-compilation-dialog.component.ts
     - /src/app/dialogs/explore-entity/explore-entity-dialog.component.ts
     - /src/app/dialogs/forgot-password-dialog/forgot-password-dialog.component.ts
     - /src/app/dialogs/forgot-username-dialog/forgot-username-dialog.component.ts
     - /src/app/dialogs/group-member-dialog/group-member-dialog.component.ts
     - /src/app/dialogs/password-protected-dialog/password-protected-dialog.component.ts
     - /src/app/dialogs/register-dialog/register-dialog.component.ts
     - /src/app/dialogs/reset-password-dialog/reset-password-dialog.component.ts
     - /src/app/dialogs/upload-application-dialog/upload-application-dialog.component.ts
     - /src/app/pages/admin-page/admin-page.component.ts
     - /src/app/pages/collaborate/collaborate.component.ts
     - /src/app/pages/explore/explore.component.ts
     - /src/app/pages/profile-page/profile-page.component.ts
     - /src/app/services/dialog-helper.service.ts
     - /src/app/services/progress-bar.service.ts
     - /src/app/services/query-action.service.ts
     - /src/app/services/snackbar.service.ts
     - /src/app/wizards/add-compilation/add-compilation-wizard.component.ts
     - /src/app/wizards/add-entity/add-entity-wizard.component.ts
     - /src/app/wizards/add-group-wizard/add-group-wizard.component.ts

UPDATE package.json (2569 bytes)
✔ Packages installed successfully.
  Migration completed (1 file modified).

!!!After running 'ng generate @angular/material:mdc-migration'!!!

** Executing migrations of package '@angular/material' **

▸ Updates Angular Material to v17.

      ✓  Updated Angular Material to version 17

  Migration completed (No changes made).

* Broken state, but compiles, with the following changes:

- downgraded bson to 4.7.2
- moved from angular "browser"-builder to "application"-builder
- used newer syntax to define angular material theme
- adjusted some style imports

* Update to Angular 17.3, migrate to standalone components & new control flow syntax

* Run Control Flow Migration: `ng g @angular/core:control-flow`
* Run Standalone Migration: `ng generate @angular/core:standalone`
* Update `tsconfig.json` and `angular.json` to match more closely to Angular 17 examples
* Update browserlist and move it to `package.json`
* Remove `src/common` folder and instead include `kompakkt-common` as a github dependency

* Compiling, but broken Angular Material

* Fix Angular Material Styles

* Fix AM Styles Part 2

- Add fixes for Angular Material issues with explore entity/compilation styles
- Delete own comments

* Style Changes #40

- remove the history button from the filter options in kompakkt and add it to the navigation bar like in semantic kompakkt
 --> VE: Removed login and registration button from actionbar, removed actionbar from home-page
- add the New Object and for now for kompakkt also the New Collections button to the navigation bar
- change the fontsize from the button to 14
- if possible change also the search options to font size 14
- in semantic kompakkt it also says "Search for objects and compilations", but we don't have the "compilations" here, only in kompakkt, so better write here "Search in objects" and in kompakkt better "Search in objects and collections" (or depending from the toggle function of the Objects and Collections)
- align the search options with the logo at the navigation bar
- gap between buttons, history button and "Profile"/"Logout": 8px

* UI Design #40

Object options:
- make sure the icons are size 24x24
- font: Open Sans, size: 14
- trash bin color: E91E63
- the title of the object should also be the same font and font size.

Fix licence size

* UI Design #40

Login and Register
- Remove Login and Register from actiobar
- The font for the "Cancel" and "Create new account" is wrong, change it to Open Sans
- The "Cancel" button is orange, it should be pink: E91E63.
- Same with the accent color of the input fields
- Colors in Login-Dialog

* UI Design: object view bar #40

- gap between the icons: 16px, the rest stays 8px.
- Since we changed the navigation bar, the "History", "New Object" and "New Collection" button can be removed here.
- Move everything to the right to make it the same like in semantic kompakkt.
- change the color to blue for the "Annotate" and the "Publish" button. Colorcode: 00AFE7
- make sure the font of the buttons is Open Sans and size 14px.
- We are using an "Annotate" button in semantic kompakkt, so replace the Annotate icon with the button.
- The three icons under the picture description also are integrated in the option bar now to make it similar to semantic kompakkt.
- Align the navigation bar and the option bar (both with 24px gap from the right)

* UI Design: Upload Process + Object view

Upload Process:
- Change the color of the "Reset" button here in kompakkt to the pink color, right font for whole overlay
- fix text in finalize-settings

Object view:
- icon for collection-choice
- nested menu for existing collections

* Change text of actionbar

* Update Visibility Settings

First changes from #40

* Update Metadata next to object

- update licence view
- update persons and institutions

regarding issue #42

* Update Metadata

- change Ui from akkordeon to sidenav (like in semantik-kompakkt)
- change first style issues with the new sidenav-content

* Update meta-data

* Update Metadata (related agents)

* Finish related persons and institutions

* Fix bug when removing persons or institutions

* Update metadata (creation) WIP

* Update metadata

- add creation
- add links
- add additional component for agents
- update entity-Component

* Update Metadata

- add link-component in new format
- add biblioRef-Component iu new format

* Update metadata

- add physical object to metadata-form
- extract general information in separate component

* Update agents

- add searchfunktionality for prename and name
- add funktionality for updating existing users
- fix style issues in agent-card

* Update agents & creation

agents:
- add tabs for persons and institutions
- add translations for agent-forms

creation:
- update creation card output --> show every tuple together
- update creation(card) style

* Update metadata

- extract externalids
- extract dimensions
- update biblioRef output
- extract general

* Update General

- extract general information in separate component
- fix issues in autocomplete of tags --> selecting tag and adding tag at the same time, it was possible to add empty tags, input-value was not empty after selecting or adding a new tag

* Update physicalEntity

- add necessary forms for physical entity
- update agent-form to save agents in physicalEntity
- update general-form to save and output correct values
- delete code-validation for place

* Update Metadata

- update output for all metadata
- physicalEntity is set now
- everything will be saved in the digitalEntity
- extract list of roles in component --> output of agents is now in the list-component

* Small fixes

- dialog when closing edit-entity-window
- change text in add-entity-window when there is no back just cancel
- set required fields for digitalEntity and physicalEntity
- delete unneccassery code
- set colored headline for invalid physical object
- update validation for physical object

* Update agents

- fix issue when setting agents to update --> form in physical object will not be set

* Update agents

- fix issue when changing tabs

* Update metadata

- extract card data of optional data in global component
- adding a pipe for key mapping of objects

* Minor Updates

- Rename sentences when not in the right format
- highlight active metadata-tab
- fix small visual issues

* Update metadata

- update translation files to right format
- update style issues in agents, dimensions, externalIds, biblio reference, metadata and physical object
- change creation date in material-component datepicker
- setup edit-mode on biblio reference
- setup different card options for dimensions and biblio reference
- add service for metadata communication between different components

* Fix display issues

* Update entity-settings-dialog.component.scss

* Update entity-settings-dialog.component.scss

* Pull request changes

- replace *ngIf with @if and *ngFor with @for (only in the metadata)
- merge agent-communication.service in metadata-communication.service and delete it (maybe there is another place, but I didn't find an apropriate yet)
- delete unneccassary code
- delete objects-Method and take valuePairPipe from angular instead (maybe custom pipe could be deleted but don't know how exactly)
- add correct typings

* Remove MapKeyPipe in favor of @if/@else inside of HTML template

* Set Observables as properties instead of getters in AgentListComponent

---------

Co-authored-by: Kai Niebes <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants