Jump to content



Invision Community Team
  • Content Count

  • Joined

  • Days Won


 Content Type 



IPS4 Documentation

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog


Everything posted by Rikki

  1. The 'grid' idea is interesting. Know of any other product that does localization with that method?
  2. I just wanted to note that we've improved the error message for this error in 4.5, so users at least won't see a mysterious "-200" message when it happens.
  3. We aren't planning to update FA in this release, no. We don't consider the cost/benefit to be worthwhile at the moment, given that it'd impact backwards compatibility with themes (unless the javascript swap technique is used, which is less than ideal). We'll consider the available options at the time of the next major release.
  4. No need to hold your breath - it's already fixed and merged into the next release ๐Ÿ‘
  5. I've logged an issue for this and we'll look at getting it changed for 4.5 ๐Ÿ™‚
  6. A fix for this was actually merged this past week. It should be included in the next major release (not the next 4.4 point release, since it's a higher impact change).
  7. Platforms that use reverse order do so to show feeds - individual items not related to each other. We do that for the topic listing and for streams. I canโ€™t think of any platforms that actually show conversations in reverse order. Twitter replies, iMessage, WhatsApp, Facebook and Instagram comments - theyโ€™re all in regular chronological order (aside from when โ€˜intelligentโ€™ ordering is employed, such as Facebook showing 'relevant' messages or Reddit sorting by most-upvoted). In fact, the only medium I can think of that uses reverse order is, ironically, good old-fashioned email (and even that depends on your client).
  8. The only app being tested right now is a 'white-label' app for this community. The multi-community test will come later. We're gradually expanding the number of testers, so sit tight ๐Ÿ™‚
  9. Whoops, you're right. Text isn't a 'child' in CSS, so actually I don't think there'd be a way to do this with CSS alone. Sorry for the confusion!
  10. You could actually do this already - add this to your custom.css theme file: .ipsType_richText span.ipsEmoji:only-child { font-size: 48px; }
  11. We anticipate it'll be available with v4.5, or shortly afterwards ๐Ÿ™‚
  12. Luckily, thanks to our work on the native app, we now have a services infrastructure that can register user devices and send notifications - when we feel the time is right. That's an example of the work we're doing on the app feeding back into the main product. You are obviously welcome to voice an opinion, but I feel like we're going in circles a bit. We've explained why we're going this route and why we don't feel PWA should be a sole focus right now, so repeating "but why?" in every reply won't get a different answer at this point.
  13. My personal recommendation is use a password manager, preferably one that stores the encrypted passwords on your own storage (e.g. your own cloud account) rather than a central server. That way you can generate extremely good passwords and maintain a different one for every site without any hassle.
  14. This part alone is enough reason for us to provide an app, I think. Many admins that offer TapaTalk have been itching for a first-party (or even a third-party) alternative. They view TapaTalk as a necessary evil, not something they're legitimately pleased to offer their users. We hope to be different in that regard. Regarding web vs. not web. If web apps on their own were perfect, there'd be no market for TapaTalk, for example - but as you say yourself, there clearly is. The lines are blurring though; the codebase we have for the native app can be transformed into a web app with a little effort. It is, after all, built on a framework originally designed for the web. We will be able to take what we learn from building a new native app, and apply that to the regular web view. Probably not in the 4.x line at this stage, but certainly in the 5.x+ lines. Some of the work may even be directly beneficial. For example, with the new API, we or third-party developers could build entirely new ways of using the Invision Community platform on the web. Finally, we know the app won't appeal to all communities, for various reasons. That's OK. The app won't stifle any potential PWA work (and as I said, it'll actually make it better), so those that don't want to use the app won't lose anything. Those that do will gain a new way of offering their community to users.
  15. We have a fix ready and it should be in the next release ๐Ÿ˜Š
  16. Yes, but we don't do that right now. I just don't want to completely rule it out from ever happening, because doing that tends to bite us later ๐Ÿ™‚ It's not something we have on the roadmap at the moment.
  17. Yes, that's a fair comment. When I use TapaTalk I get much more of a 'platform' vibe from it, as if I'm using TapaTalk first and foremost, and the actual community is secondary to that. We've tried hard to do the reverse and make sure each community feels like it's separate from the others. Right now for example, there's no central login system, central activity feed or central notifications, no cross-promotion of communities and so on (though I can't say those things will never appear - I do think there's justification for some of them). Each community is entirely standalone once you tap into it from the directory.
  18. As with other (currently) supported areas, Downloads will open in a webview inside the app. It's relatively seamless. Yes, you'll be able edit the language using the regular translation tools.
  19. Blogs will certainly be supported too, but in terms of priority it would be lower than, say, Gallery which sees more use. On the plus side though, Blogs are also easier to support than Gallery, so there is that ๐Ÿ™‚
  20. Gallery and Clubs are both high on the priority list. Pages is tricky to do because people do so many custom things with it, whereas a native app needs its views built ahead of time. That said, I'd love to find a way of offering some pre-built views that you can choose for each database. It won't work for every site but it'd hopefully cover the common situations. There is a new GraphQL API that powers the app. While we're building it for the app, in theory any application would be able to use it.
  21. Yes, that'll be a built in option ๐Ÿ™‚You'll also be free to make your own banners/announcements/etc. of course too.
  22. It actually compares pretty favorably to TapaTalk already in terms of features. It's important to note that all user handling is done by your community. We don't handle registrations, login or act as a middle-man. Once the user taps to enter your community, it's all handled by your IPS4 installation via a new API. The only exception to this is push notifications, which for technical reasons must route through our own service from your community. As a side effect of this, it means we aren't offering a global "Invision Account" type service right now. Users will need to register and log in to each community they wish to visit in the app. We hope to offer a premium option for users and/or communities later, but we also don't want to hoist ourselves with our own petard by ruling in or ruling out particular ideas at this early stage. We'll see what the reception to the app is once it's in users' hands and go from there.
  23. Indeed - just like we make custom agreements for larger companies now, I wouldn't want to rule out doing something similar with the mobile apps too. Equally, I don't want people to expect that we'll be offering app source code up for download and modification as a regular product/service; there's simply no way for us to make that work at scale.
  24. I think it's probably unlikely we'll make the source code available as a product. That said, I'm sure we could at least discuss partnerships and see if there's something that would work. Get in touch once it's available ๐Ÿ™‚
  25. Firstly, we don't have firm plans for the white-label approach yet, so take any information about that with a pinch of salt because they will likely change. Modifications wouldn't be possible; what we'd do is build a version of the app locked to your community, with your branding (your own splash screen, name, colors, etc.). You'd then submit this to the app stores yourself, under your name. Once submitted, we can then provide most updates to the app without your involvement (except in a few special situations). Users won't have to download our app and there'd be no 'Invision' branding in it. We anticipate the white-label app being a relatively high-end offering. The app we'll be using for initial testing is essentially a white-label app for our own community here, so you'll hopefully be able to imagine that but for your own community.
  • Create New...