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

What fields should be displayed on an item's view? #14

Closed
ruebot opened this Issue Aug 18, 2017 · 9 comments

Comments

Projects
None yet
4 participants
@ruebot
Member

ruebot commented Aug 18, 2017

Current fields are:

  • Title
  • URL
  • Host
  • Crawl Date
  • Source File
  • Content Type
  • Server
  • Content Type Served
  • Length
  • Links Hosts
  • Content

Example
screenshot from 2017-08-17 18-20-46

These are the potential fields.

@ianmilligan1 @anjackson @greebie

Feel free to tag others.

@ruebot ruebot added the question label Aug 18, 2017

@ianmilligan1

This comment has been minimized.

Show comment
Hide comment
@ianmilligan1

ianmilligan1 Aug 18, 2017

Member

content_language would be useful too.

Member

ianmilligan1 commented Aug 18, 2017

content_language would be useful too.

@greebie

This comment has been minimized.

Show comment
Hide comment
@greebie

greebie Aug 18, 2017

Seems like we'd want the collection names and owning institutions available as well.

greebie commented Aug 18, 2017

Seems like we'd want the collection names and owning institutions available as well.

@ianmilligan1

This comment has been minimized.

Show comment
Hide comment
@ianmilligan1

ianmilligan1 Aug 18, 2017

Member

Should we change content_type to content_type_norm? i.e. application/xhtml+xml would become just html.

Member

ianmilligan1 commented Aug 18, 2017

Should we change content_type to content_type_norm? i.e. application/xhtml+xml would become just html.

@ianmilligan1

This comment has been minimized.

Show comment
Hide comment
@ianmilligan1

ianmilligan1 Aug 18, 2017

Member

And I would vote to remove server.

Member

ianmilligan1 commented Aug 18, 2017

And I would vote to remove server.

@tokee

This comment has been minimized.

Show comment
Hide comment
@tokee

tokee Aug 19, 2017

What about "all of them"? You might group them into primary and secondary to provide easier overview, but if they are not visible somewhere, they might as well not be in the index.

tokee commented Aug 19, 2017

What about "all of them"? You might group them into primary and secondary to provide easier overview, but if they are not visible somewhere, they might as well not be in the index.

ruebot added a commit that referenced this issue Sep 6, 2017

Address #14; Update item's view
* Remove: server, content_type, content_type_served
* Add: institution, collection_name, collection_number,
* content_type_norm, content_type_norm, links_domains
@ruebot

This comment has been minimized.

Show comment
Hide comment
@ruebot

ruebot Sep 7, 2017

Member

I really think we should persue @tokee's recommendation here.

If we go with two groups (fieldsets) on this, it could work out well. Have the first group be what we have now, and expanded by default. Then second group be all the other fields, or all of the fields, and it is collapsed by default. The real cool thing here is the API win; you'd get all the data for a record. Example with current 0.2.0 setup: http://warclight.archivesunleashed.org/catalog/DkZzgWN3oIuklvt322%2F4Uw==%2F20170131103924.json

So, if we're cool with that, we should do it!

Member

ruebot commented Sep 7, 2017

I really think we should persue @tokee's recommendation here.

If we go with two groups (fieldsets) on this, it could work out well. Have the first group be what we have now, and expanded by default. Then second group be all the other fields, or all of the fields, and it is collapsed by default. The real cool thing here is the API win; you'd get all the data for a record. Example with current 0.2.0 setup: http://warclight.archivesunleashed.org/catalog/DkZzgWN3oIuklvt322%2F4Uw==%2F20170131103924.json

So, if we're cool with that, we should do it!

@ruebot

This comment has been minimized.

Show comment
Hide comment
@ruebot

ruebot Sep 7, 2017

Member

Oh, I stand corrected. I believe the json view already returns everything it has from the looks of it. I'm seeing fields there that I don't have explicitly declared in the item's view.

Member

ruebot commented Sep 7, 2017

Oh, I stand corrected. I believe the json view already returns everything it has from the looks of it. I'm seeing fields there that I don't have explicitly declared in the item's view.

@ianmilligan1

This comment has been minimized.

Show comment
Hide comment
@ianmilligan1

ianmilligan1 Sep 8, 2017

Member

Great on JSON.

If it's trivial to expand to see all fields on an item-level description, I'd say we should implement it. If not, I think having API support would be sufficient.. especially given the granularity of some of the fields, they're probably mostly only useful in aggregate (as opposed to looking at them item by item?).

Member

ianmilligan1 commented Sep 8, 2017

Great on JSON.

If it's trivial to expand to see all fields on an item-level description, I'd say we should implement it. If not, I think having API support would be sufficient.. especially given the granularity of some of the fields, they're probably mostly only useful in aggregate (as opposed to looking at them item by item?).

@ianmilligan1

This comment has been minimized.

Show comment
Hide comment
@ianmilligan1

ianmilligan1 Nov 2, 2017

Member

Given JSON gives all information, we're happy with the default item-level view. We'll make sure to document the JSON view option.

Member

ianmilligan1 commented Nov 2, 2017

Given JSON gives all information, we're happy with the default item-level view. We'll make sure to document the JSON view option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment