(Design) Page for specific resource

In this issue you need to design how specific resources get displayed, e.g. https://informationportal.helmholtz-metadaten.de/edit/data_format/a4263d28-16ff-4809-bfce-d60ed3402cf9

The separation between a "simple" and "detailed" view is not necessary.

The page should be rendered automatically based on the json object. Therefore it is probably not possible to design the overall form, since this is based on the underlaying method which generates this form. For this issue this means that you need to design everything besides the form. This includes:

1. Back button
2. Place for whom to contact if questions

changed the description

marked this issue as related to #8

mentioned in issue #8

I don't fully understand this @lucas.kulla. So we are going to have a page design for simply showing a single resource. There is a little bit of "around stuff" like the back button and contact info but the center piece of that page is a "resource view" component, right? (This component might be reusable in e.g. the de-duplication part.)

But then you write that we need to design "everything besides the form". Does that mean that you want to move the component which displays a single resource to a separate issue? Or did you want to say that this "resource view" component has to be flexible in the sense that it has to be capable of displaying resources regardless of their structure/schema?

Edit: After reading #8 I assume the answer to my last question here is the latter option?

Should we also talk here about the design of the "editable resource component" (as opposed to the "read-only" one discussed above) since that functionality is mentioned in #8?

There are several json schema form renderers. The ones I know of are not as flexible as you can customize them. Therefore, this is not something where the assignee of this issue has the freedom to customize it and "play" with it. In this way, this problem focuses on everything except the rendered form. Since this issue is not about implementation, I did not see it as a task to create this form component here, this will be done in #8. However, as you wrote, this design needs to be adaptable to any underlying json schema

You mentioned the "editable resource component": we need to figure this out, I think this will be handled mainly by the json schema form renderer.

assigned to @gabriel.preuss

changed the description

For this I would suggest a very simple layout for now. Like shown in the mockup.

The current first implementation of displaying an individual resource as a form looks like this:

That's of course very rough and can be very much improved. @vivien.serve can you already think of a design based on this? Or should we first try to make it a bit prettier and give it a bit more structure? Also, how different should the "read-only view" be compared to the "form-view"? Should the read-only view be simply the disabled form-view or should it be more different like e.g. more compact?

@lucas.kulla @gabriel.preuss

Hey @steinm01 ,

I'm not clear on the process here yet. As far as I understand, only the read-only view is displayed by default, or? Not form-view and read-only view next to each other, as in your example? Can you please specify this again? Because per se, I can easily derive a design from the screenshot. However, if form and read-only view are displayed as above, then in my opinion the read-only view must be displayed much more compactly. Or does the read-only view dynamically shift into a form view when values are adjusted or added?

Hi @vivien.serve, sorry for the confusion. I only put the read-only and form-view side-by-side for the screenshot to show which resource is being displayed in the form-view. @lucas.kulla please share your opinion on this. AFAIK, the form-view will be something that a user with editor rights will be able to switch to via a button. And then they will only see the form-view. The "dynamic shifting into form-view" feature sounds pretty cool, but I am not sure whether that's worth the effort.

Hi @steinm01, thanks for the clarification. I would wait for @lucas.kulla's opinion, but after that I can start with a preliminary structure of the read-only view.

Hi @vivien.serve, @steinm01 , yes, it should be either the read only view or the edit view. Depending on your installation / grants you should see either of these views. If you are allowed to change your view a button would be helpful. (Like Leon said). Default is read only.

Now clear?

Yes, thanks, that helps. But more questions from @vivien.serve :

• How free is the design of the read-only view and of the form view?
  • my answer to this: From a technical POV I can't think of any restrictions. We should be able to implement more or less every design you can think of (within reason of course).
    • @lucas.kulla do you want the read-only and form views to be relatively similar looking? Maybe even have the read-only view only be the disabled form view? Or would it be an option to style the read-only view differently to e.g. make it more compact?
• What did I mean by "I could first make the form-view a bit prettier." in the original post above?
  • I was basically thinking of a design suggestion for the form view, but now that I think about it further, @vivien.serve you probably don't need that from me and it would probably also not be worth the effort.

changed milestone to %ongoing

changed milestone to %Edit ressources

mentioned in issue #76

marked this issue as related to #76

Resource Name

Resource Identifier

Contact

Resource Date

Add a new resource to IP

mentioned in issue #77

marked this issue as related to #77

closed

Done with !66 (merged)