Rikki
-
Content Count
24,115 -
Joined
-
Days Won
69
Everything posted by Rikki
-
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 🙂
-
Automatically enlarge emojis, if on their own line.
Rikki replied to DaffyDuck's topic in Feedback and Ideas
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! -
Automatically enlarge emojis, if on their own line.
Rikki replied to DaffyDuck's topic in Feedback and Ideas
You could actually do this already - add this to your custom.css theme file: .ipsType_richText span.ipsEmoji:only-child { font-size: 48px; } -
We anticipate it'll be available with v4.5, or shortly afterwards 🙂
-
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.
-
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.
-
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.
-
We have a fix ready and it should be in the next release 😊
-
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.
-
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.
-
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.
-
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 🙂
-
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.
-
Yes, that'll be a built in option 🙂You'll also be free to make your own banners/announcements/etc. of course too.
-
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.
-
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.
-
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 🙂
-
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.
-
Yes they are true native apps (check out the Questions section above, there's a bit about the technology). Addons will open seamlessly in a webview inside the app 🙂 We'll show off how that works in more detail later.
-
Ads are certainly on our priority list - we know they're important to many communities. That said, getting the basic functionality spot-on is key first, otherwise ads would be a moot point!
-
I'm excited to reveal that we are making Invision Community native apps for iOS and Android! For the past few months, our staff has been using an internal test build right here on our community. Now we are ready to widen testing to a larger pool of customers. Information on how to become a tester is at the end of this post. But first, let's take a look at the app itself. Technology Preview We have a lot of exciting plans for the Invision Community app. We wanted to take full advantage of a clean slate and build a brand new experience that embraces a native app's interfaces. While the app is unmistakably Invision Community, it features new ways of interacting with your content. We want the app to help shape the future of Invision Community, and we're asking for you to help. What we are opening up for testing today is a technology preview. This slim app covers the essentials with a view to much more expansion later. The technology preview is locked to our community. The app we will release will be a 'multi-community' app; a directory of communities users can browse and save. We’ve taken this approach because the app stores have clamped down on ‘template’ apps, and the cost involved in building and maintaining a separate app per-community won’t be an option for many of our customers. A multi-community app is a great approach for most: simple setup, minimal cost, still fully-featured, and a great way for new users to find your community too. What The App Does For the initial phase of this technology preview, discussions are the main focus which is the foundation of every Invision Community. Also available are profiles, streams, search and notifications - including (at last!) push notifications. Any areas that the app does not currently support will open seamlessly in a web view within the app. As we build new functionality into the app over time, users will encounter fewer of these hybrid views. Your feedback will allow us to target the highest priority areas during the technology preview phase. RPReplay_Final1568062287_1.mp4 Pricing Note: The information below outlines our current intentions, but may change as we finalize the app's release to app stores. The good news is we intend for the app to be free to both our customers with active licenses and their end-users. In time, we will offer a premium option to communities. This funding will secure the app's long-term future. The premium option could enhance their listing in the directory, or provide special functionality when users use that community in the app. Availability We intend to release the app alongside the next significant point release of Invision Community, expected to be 4.5. Communities will need to upgrade to this version to allow their users to use the app. Questions? Why not a PWA (progressive web app)? Invision Community 4.4 already supports several PWA features. However, until iOS supports Push Notifications (and other features) in PWAs, we don't feel they are a fully-rounded solution to using communities on a phone. Building native apps allow us to experiment with new interfaces and approaches. As PWA support improves in the years to come, we'll feed what we learn back into the main product for the benefit of all users. Why now? Those with a long memory will recall that we've had a few attempts at providing an app in the past that weren't successful. We are great at building apps with web technologies but creating native apps ourselves wasn't sustainable. Enter React Native. React Native is an open-source technology for building native apps. React Native allows teams to build native apps using web technologies, but crucially, React Native doesn't build hybrid apps. They are compiled into real native apps - not browser wrappers, but native buttons, text, dialogs, animations and more. A year or so ago, we started experimenting with React Native to see if it might be a viable approach for us. And it was. Finally, there was a technology that enabled web engineers to build delightful cross-platform native apps. As we can build native mobile apps using the technology we are familiar with allows us to incorporate mobile app development into our existing processes. Why just forums? Invision Community is a large, fully-featured platform, and building the entire platform in a native app from the get-go didn't seem to be the best approach. Instead, we've focused on the most active area of most communities - forums - with other areas still supported in the app via webviews. Over time, additional features and tools will be built into the app so that it eventually reaches feature-parity with the web version. We'll take feedback from our customers to determine which areas to support next. How will I add my community to the app? The next significant point release of Invision Community (expected to be 4.5) will have app support built-in. Including your app in the directory will be as simple as enabling the feature in your AdminCP and configuring a few options. Is the app ad-supported? There are no ads of any kind in the app right now. We may include ads or allow communities to run their own ads as a premium option in future. Can I get a white-label version for my community? We aim to offer a white-label option in the future. Will my plugins work in the app? Probably not. We're intentionally building the app to work with standard Invision Community features and apps right now. If your plugins add new UI elements or change the functions that users interact with it's likely they will not work with the app. What about themes? Themes won't work in the app because the app doesn't use HTML. However, some branding/customization will be available via the AdminCP, and we may expand upon this in future. Have other questions? Let us know in the comments, and we'll answer them! Sign Up For Testing For the next stage of our testing process, we will be inviting several customers to try the app and provide feedback/bug reports. As part of the sign-up process, we'll ask for some information about your own community. We'll use this to select further testers once we begin testing of the 'multi-community' version of the app later. The answers you provide will not affect your chance of testing the app on our community. Interested in joining the testing group? Click here to sign up. RPReplay_Final1568062287_1.mp4- 163 comments
-
- 53
-
-
-
-
Absolutely - and we did this with a compromise. Make a preview tool available for those few customers who have valid edge cases, without adding Yet Another Button in a prominent location for all our other customers. Every extra button or toggle we add to a page increases the complexity for users a little bit more, mostly unnecessarily. We try to consider all users and balance functionality with simplicity as much as we can.
-
Honest reason it's located where it is: we do not feel it has sufficient usefulness for most sites and most users to justify giving it a more prominent location next to the submit button. We made it a customizable toolbar button so that it's available for those few edge cases where you could argue it's useful, without it being a fundamental part of the editor UI.
-
We can't set a fixed height on images because images need to remain responsive (i.e. scaling with the browser window). For that reason, we set a width and a ratio, and calculate the height using JS. You are correct that on very slow connections, the JS can take a second or two to execute and add the placeholder, but even without lazy-loading, images would also 'jump' as the browser downloads them and inserts them into the page. This is unfortunately a trade-off, but for those on slow connections lazy-loading should ultimately be a benefit since their browser isn't having to load a bunch of images they aren't seeing yet.
-
Each site can set their own defaults here, so it'd depend on the site you're using. This is already the case (in fact, we're looking at simplifying the process a little bit because there's too much customization, which is confusing).
