Search Collections (and Weird Layouts)

[KlaraSchmitt]

On March 5th, we released our new version of search to improve how you, your teams, and your community search and discover relevant content. We've added more content types, private data, faster and more reliable search indexing, a new look, and new ways to refine your search, including search collections across the top of the results page.

Now you have a custom header and you were styling the search page or using CSS to hide our navigation bar, you may encounter some oddities on the search results page. While we strongly recommend not hiding our navigation bar as we use it to place new navigation features, here's a few things to watch out for in your custom header CSS if you're noticing a weird layout.

Styling the Search Page with CSS

Unfortunately, this page is not intended to be styled. If you were able to figure out how to style it in the older version of search, you benefited from a bug that occurred in the custom header. I won’t be explaining how to work around our new version as we’re actually very close to fixing that bug and it would just undo your work all over again. So please stick to the hub site and hub page layout screens when doing CSS for webpage layout purposes.

Search Icon Visible in Your Header

If you were hiding our navigation by placing your custom header on top of it either through absolute positioning, negative margins, flex, and/or use of a z-index, you may need to change your z-index to an even higher number (e.g. 1200) to get the search icon to hide. However, be warned that we’re doing some updates to navigation, which will be coming out at the end of the month and should you want to use the improved navigation, you will need to change your z-index back to 900; otherwise, you may observe the autosuggest from our search bar drop behind your custom header.

If you’re using negative margins like the example above, you may need to adjust them based on the size of your header to compensate for the collections' links.

It can be challenging to get your custom header to look exactly as you want in our interface, but if possible, please try to avoid using negative margins and absolute positioning as both are inflexible layout methods and more likely to break your site styling when we release new features. Unfortunately, try as we do, we cannot always predict the impact of custom styling on new features.

No Collections

If you were hiding our navigation through use of display:none and using absolute or fixed positioning to manage your custom header, then you may not have search collections visible at all. This is because when you hide components using display:none, they do not take up any space, and as such, the beginning of your page content will start much closer to top edge of the page. If you used fixed or absolute positioning in addition to display:none, your header will cover up the top of your page content and in this case, it’s the search collections.

If you change display:none to visibility:hidden, the content you are trying to hide will not show, but it will take up the same amount of space, which will result in a layout more similar to the intended experience of sites that aren't hiding navigation. The caveat for visibility:hidden is that it will not, in fact, hide the content from assistive technologies, so those using screen-readers will still be able to explore that part of your page.

[ANRGIS]

This was an incredibly intrusive release that has essentially broken our current Open Data site as well as the State of Vermont's site without warning. We have set up cards in our Open Data site that searches based on keywords. For instance: search?tags=isothemeboundary,isothemecadastral

datasets?t=keyword1,keyword2

datasets?t=any(keywords)

etc.

With this update, I cannot even browse any of our datasets...

http://anropendata-vtanr.opendata.arcgis.com/ 

There should have been an option to upgrade and doing so, would clone the site to test the functionality before releasing this. It has rendered our site useless and we now will likely have to spend a considerable amount of time with support fixing it.

Steve Sharp

[Anonymous User]

Hi Steve,

Sorry to hear that your site is broken with the new release. The new search has been in beta since the fall and as part of the beta we've pushed folks to clone and test the new features. I'm not sure if you are listed as a site admin, but we work with marketing to send out blasts to site admins ahead of big releases as we did last week. Regardless, we've missed the mark in getting the information to you and I apologize.

In regards to your site, I'm not sure what happened but I think if you remove and add the group from your site's groups manager in the Hub admin it should resolve the issue. I added your group to a test site and some 185 items are appearing in search. Let me know if that doesn't work for some reason.

Best,

Patrick

[Anonymous User]

We just pushed a fix out for this on the backend. Your items should be showing up now: http://anropendata-vtanr.opendata.arcgis.com/search 

For the tagging issue with your category cards, there appears to be a bug for inclusive queries. We are working on a fix and will let you know when it is resolved.

[ANRGIS]

Thank you Patrick, I do see our items showing up in our site now. 

We will wait for some guidance on what to do about the search using inclusive queries. 

[Anonymous User]

The tagging bug should be resolved. Your category cards now all seem to be directing fine, apart from the administrative boundaries card. Replacing the query in the card with http://anropendata-vtanr.opendata.arcgis.com/search?tags=any(isothemeboundary,isothemecadastral) should fix the issue.

[ANRGIS]

They actually went away again and removing the group and re-adding the group fixed it... However there definitely seems to be some instability. 

[Anonymous User]

Might have been a cache issue. If you observe items dropping again, feel free to let us know in case there's a larger issue.

[WillIsaacs]

Klara & Patrick, 

I am an admin and a member of the early adopters and I did not get notification this release was coming. I have a feeling that if ESRI continues down this path with Open Data Hub they are going to have a lot of unhappy customers. We want to brand our websites with our content in our designs. When you bind our abilities to customize our websites (they are ours we pay for them), you prevent us from being able to comply with our web standards, our branding, our presence that we are building and presenting to the public. I understand that you all want to make it better for those who cannot program HTML and CSS but at what cost to the rest of us?  Leave our .navbar's alone, and let us control our own sites and it would be really nice if you limited your z-indexs to something we can hide with our own code. currently the spyglass on the search is over 900. 

Thanks,

Will

[KlaraSchmitt]

Hello William,

Thank you for your input. I'm sorry you didn't get advanced warning. We do try as much as possible to post all upcoming features to our blog. Would you be willing to share where you go for updates and what would be your preferred medium to receive them?

We do understand the need to be able to brand your own Hub, which is why we allow space for a custom header, support CSS/HTML on the homepage, and have a theme builder that applies the theme across the whole app. We try to take up as little real estate as possible on the homepage by only controlling the navigation bar that contains search, notifications and sign in. We are reworking that to make it more minimal, but we're also trying to make it a better Hub experience for collaborators and visitors. For example, a visitor who enters a Hub from Google and lands someplace that is not necessarily the homepage should know who authored the content that they are viewing and find a consistent way to explore other initiatives and content. Our goal is to add more customization to these components (navigation, search collections, etc) and hopefully, this will encourage people not to hide our navigation outright, as doing so can detract from the overall usefulness of Hub.

ArcGIS Hub isn't strictly a website builder (although that is a very popular part of our app); it is a management framework for organizations to collaborate with partners and communities around initiatives relevant to their work through GIS content. This includes publishing content through websites and pages both internally and externally, but also engaging with community participants through events, surveys, and teams. There are many views in our app that currently do not support layout customization, including the search navigation bar, search results, dataset and item detail pages, event registration pages, and profiles. While we apply the theme from the theme builder and a custom header, if present, the reason we do not allow CSS on these views is to limit the likelihood we will break your site when we release new features.

We used to give everyone access to global CSS for the whole app when we were just Open Data, but unfortunately, people would absolute position all kinds of page functionality to get custom layouts. If our app were the equivalent of a static website, this might have been okay, but since we release bug fixes and feature updates nearly every week, we'd often break sites who had customized their layouts too heavily. Obviously, they would not be terribly happy with us because they'd have to adjust their CSS to compensate. With a couple thousand customers, we simply could not predict how people would be using CSS, and therefore, we'd be stuck because we couldn't release anything new without risk of affecting someone's global CSS implementation. This is why, in our app today, you have free rein over anything you want to do in your homepage with CSS, but we save just a tiny slice of the page as a safe zone to add new functionality so that we won't break your layout.

And as was the purpose of my original post, if you had hacked our safe zone (we understand, it happens) and were experiencing oddities as related to your custom header, we wanted to provide some tips that could help you troubleshoot faster in fixing your custom code.