The Reset/Forgot Password page is not mobile respsonsive

5 Comments

  • Ryan McGrew
    Comment actions Permalink

    Hey Carolynn,

    We actually have built rules into our robots.txt to prevent Google (and other bots) from indexing things like the sign in page for example. I'm not a Search Console expert, but do you know if we blocked crawling on those pages as well if Search Console would still flag it? 

    Additionally, for public Help Centers like yours, we actually use a modal on the current page to render this functionality and it fits within the responsive theme that was designed. So unless, you go to the URL directly, you wouldn't see the non-responsive version of the site.

    Thanks!

    0
  • Carolynn Carriger
    Comment actions Permalink

    Hi Ryan,

    What you're saying about blocking crawling sounds plausible. I don't think I've actually done that on any of our articles/pages though so I can't confirm how Google will handle it. I do know that when we retired one of our forums, I was able to go into the Search Console and manually restrict indexing of that forum's pages by inputting the beginning of the URL. That did seem to work so I imagine your solution would too.

    Now the weird thing is that since this is a modal as you describe, I've no idea how Google would be finding this particular version of it to index. But they reported this page (https://support.clickdimensions.com/access/help) as being the issue--clickable elements too close together and font too small to read. 

    Since it is a modal then, if I were to reference the classes (like "modal" and "modal-content") that it uses, in my stylesheet, would my stylesheet be able to overwrite default modal styles? I was thinking of trying that but I took this site over last year and have no idea what modals my predecessor might have put in place. I really don't want to break too much in order to tweak this one thing.

    Thanks!

    P.S. I did have a ticket about this--#5122242--if you want to see my conversation with the agent there.

    0
  • Ryan McGrew
    Comment actions Permalink

    Hey Carolynn,

    We provide a link to that page as part of the modal sign in/up flows so that users with JavaScript disabled can still access that page so that's likely how Google is finding the URL. We prevent crawling from /access/ URLs via the robots.txt. I'm wondering if you temporarily remove the URL via the search console would make a difference in the error being reported. I can work with the engineering team in the meantime to see if we could prevent indexing on the forgot password page as well. I will talk to the responsible team about font and clickable element issues as well. 

    As for the styling of the modal, I'll try to give some advice. There are certain elements like Sign In, Sign up, Forgot Password, etc. that are critical piece of functionality that also need a high degree of security. We don't have things like password harvesters or man in the middle attacks etc. to comprise our customers' and their users' security. Therefore, we don't allow customization of these elements out of the box and load them via an iframe when displayed as a modal. This will limit the amount of tampering possible with these types of elements. Which means unfortunately, that your ability to modify these styles and behavior are pretty limited. I hope that makes sense.

    Thanks!

    0
  • Carolynn Carriger
    Comment actions Permalink

    Hi Ryan,

    Thanks for the update! What you made makes sense, just a couple follow-up questions.

    1. Is there a way to be notified when that indexing change has occurred? Temporarily removing the URL from indexing will last for about 60-90 days so I need to know if I go that route if I'll have to index it again or not.

    2. I understand what you're saying about the styling, and while it makes sense I am still concerned that we don't have access to it and are dependent on your development team keeping up with various requirements. Is there no way that Zendesk could allow us to interact with the styling so we can make sure it's where we need it to be? This seems like a small-scale issue but it indicates that we still are very dependent on your team to keep up-to-date.

    3. Is there a reason why I basically had to have a public ticket here on your forum instead of being able to get this information from your support team on the ticket I opened? You've been super helpful and I appreciate your time, but I am confused why I have such a hard time getting helpful info like this from your support team.

    Thanks!

    0
  • Ryan McGrew
    Comment actions Permalink

    Hi Carolyn,

    1. I'm working with engineering teams on my side to determine timing for this change and how we can get that rolled out. I will report back here once I have more information.
    2. That's partly by design as it allows our authentication, security and abuse teams to maintain a standard implementation and changes that we make can be immediately rolled out to all our customers at once without fear of breaking authentication workflows. The down side is, of course, the lack of customizability for our customers for these things.
    3. There are probably a few things that go into this. First when it comes to things like SEO and customizations around theming, that's not something that our customer advocates are trained on as they're both large subject areas and best practices change frequently. I, myself wouldn't consider myself an expert in this area even though have worked in software for the web for a long time. Secondly we direct customers to our community not as a deflection technique, but because we truly believe in our community of users to help us provide answers to complex questions. Anything we can answer directly in the community can be indexed by google and other search engines and found by anyone else that might be asking similar questions or running into similar issues.

    Thanks!

     

    0

Please sign in to leave a comment.

Powered by Zendesk