Rikki

1) In your mobileNavBar template, add this just before the closing </ul>:

<li>
  {template="mobileNavigationIcon" app="core" group="global" params=""}
</li>

2) In globalTemplate, find the <header> tag and change it to:

<header class='ipsResponsive_hidePhone'>

@opentype to the rescue 🙂 

If I remember correctly, this is the sort of thing I suggested:

body {
  zoom: 0.9;
}

4.4 used Roboto, 4.5 uses Inter.

Thanks for the feedback; it sounds like a couple of the issues you noted are bugs, so we'll be able to address those as such.

We've been upfront that firstly the app is in its early stages but also that it won't necessarily be ideal for every community. If you have a lot of customization (be it plugins or lots of custom pages) it's probably not going to be the best solution for you. We may devise a solution to that in future but right now it'll be focused on core 'out of the box' functionality.

I'll lock this since you have struck out your first post, but I just wanted to address your points too. 

In 4.5 we've tried to keep headers consistent, so that buttons are where you expect them to be, there's space for additional buttons as each page/app might require, and so that each page/app can extend the data shown in the header without the whole thing breaking down. In 4.4, this was a problem - sure, on perfect example pages, the follow button worked well in the top right. But using a different app where more buttons need to be shown, or even just having a long topic title, suddenly it wasn't so pretty and usable. The new header is designed to be flexible and extensible according to requirements.

It's pretty easy to take one particular page and find criticisms - but remember we are designing a suite where each page might have some shared functionality and some unique functionality. We have to design components that can work well in more than one perfect scenario. 

3 hours ago, Mr 13 said:

You (IPS) can load polyfills only when they are needed and don't waste the traffic for the majority of browsers.

We don't load (many) polyfills ourselves - they are included with libraries that we use. Those libraries will only execute them when needed, but the code is still sent to the browser since we bundle and minify javascript.

Hi Nicholas, what's the name of your site? I will see if I can figure out the error.

None of our own CSS selectors use the .sp prefix - that comes from a third-party library we use. But frankly, the possible overheard for the browser is so negligible that it isn't even worth worrying about,

Apologies again! Update your app to get the latest build and things should be good now. At the time of this post, the app was approved in the Play Store but still pending review in the iOS App Store, but should be available soon. Note that in both stores it's still in the beta process (Beta in the Play Store, TestFlight in the iOS App Store) so you won't see it unless you specifically opt in to the beta.

1 minute ago, BankFodder said:

I don't see what problem Invision have with customer choice

We have no problem with choices - that's why we have thousands of choices in the AdminCP. But every choice, no matter how small it may seem, has a cost in terms of development time, future maintenance, documentation, UI complexity and so on. And that's not even counting the problems with the feature that we've already outlined, specifically that they aren't the same for all users and therefore cannot be relied upon in the way you want them to be.

17 hours ago, Malwarebytes Forums said:

Yes, the code provided by Mr 13 does in fact work @BankFodder . We have implemented it on our forums. I do agree though that making it an option or available to Administrators from within the ACP would be nice. Thank you @Mr 13

Regardless of how one views it Visual cues are sensory cues received by the eye that many people process and understand better than text or menus. 

Referencing a post or ID# seen onscreen without having to copy or quote and paste it would help reduce clutter as well as I would find it difficult to believe that making a handicapped person perform an additional 3 or 4 more clicks to obtain or reference the same thing would meet muster for the Americans with Disabilities Act of 1990 (ADA) 

Designing Software that is Accessible to Individuals with Disabilities
https://www.washington.edu/doit/designing-software-accessible-individuals-disabilities
 

The date in every post provides a direct permalink to the post. Incorrect post numbers based on a user's individual permissions would certainly present more of a usability issue for both disabled and able-bodied users.

It's absolutely fine that some people would like to have post numbers back - we understand people don't always like change - but please let's not try and justify it as being a legal requirement.

Those files aren't obsolete - they are the foundation of our framework. What your tool is finding is polyfills for old browsers that libraries we use (such as jQuery) include. 

2 minutes ago, Paul E. said:

I think this was a surprise to the thread starter, and may be an indicator that the way potentially impacting changes are communicated when announcing the availability of an update could be reviewed.

Just to note, we did list this change in the deprecation section for 4.5. We always recommend reviewing the release notes, especially for major releases.

Even Microsoft will not support IE11 (or legacy Edge) in any way from next year, including in its own products like Teams. Other major sites like Twitter are starting to drop any support too. It won't be long until you'll struggle to use the web on IE11. Technically we have not supported it for a long time, but because we held back on modern CSS features, it still mostly worked. For 4.5, we decided now was the time to press ahead with improvements and drop support ourselves.

By dropping support, we've been able to use newer CSS features that benefit designers (and therefore site owners), simplify our theme (with more improvements to come), and we'll also be able to begin the process of modernizing our javascript.

If your community has a significant percentage of IE11 users due to your audience, you may prefer to stay on 4.4 (though that, understandably, has drawbacks too). If you're just an individual IE11 user, I would strongly suggest using a newer browser - literally any of them would be a better choice. 

Apologies for the problems. I was finally able to diagnose the cause of the login issues, but unfortunately they cannot be fixed until 4.5.2 (and new app builds). That should be available in the next few days. That will solve both the failed logins and the 'invalid redirection uri' error.

The default font changed in 4.5, so that may explain that difference. It was Roboto in 4.4, but 4.5 just uses the system default (Segoe on Windows, SF on Mac, etc.). You can edit your theme settings and switch back to Roboto if you prefer the previous style.

Are you seeing errors in any modern browser?

The variables it is flagging up are valid CSS and don't affect performance.

Thanks for the feedback - it's definitely early stages. We'll be looking to improve performance as time goes on, as well as add functionality. There's only one codebase for both iOS/Android, but that is indeed (currently) separate from the main product. It's very much 'work in progress' right now 🙂 

That's the pagination bar - though on the first page pagination doesn't show. 

If you're working in templates there's also a {truncate} plugin that'll do it for you. Just do {truncate="$content" length="200"}.

I don't think that'd be feasible because the app stores aren't going to pass on referrer info to the app to know which community you tapped from. Maybe some way of quickly adding a community would be a compromise? A 4 digit code or a QR code maybe?

In 4.5 we have a 4px spacing scale and we use variables to apply it. They're named --sp-* where the * is the multiplier. That means the variable --sp-3 will be 12px.

You can either change it to --sp-2 for 8px, or just replace var(--sp-3) with a hardcoded pixel value if you prefer.

It won't be any time soon, if ever - the {theme} tag is still used for non-color settings for example. It'd be preferred to use the CSS variable approach for consistency and potentially future compatibility with new features, but it isn't a huge deal right now.

That said, converting them should be easy in most cases. We did our entire framework in a few steps using find/replace in a text editor.

Is there a reason you're creating text settings to hold rgb values? It'd probably make more sense to make them color fields (so users get a color picker), and then using the automatically-created CSS variable instead.