If you follow Mattermost, you’ll see the project is improving on a daily basis. The list of community installation guides continues to grow, with additions like Debian, Heroku, and Cloud Foundry.
New integration from the community seem like they’re constantly appearing for systems like Hubot, IRC, and Jenkins. Native apps from the community are taking off as well, with Matterfront and now a Chrome Web App.
We’re constantly upgrading documentation around trouble shooting, upgrading, APIs, and webhooks as well.
We love hearing feedback like this:
But today, this just happened:
When a GitLab Mattermost user has unpleasant experience, it’s the fault of the product team, not the user. It means we haven’t achieved our fast, obvious, forgiving design principle, and we need to get back on track.
By the 0.1% rule of the internet, if one user has a poor experience, probably hundreds more do as well.
There’s several issues related to this:
1) Mattermost needs to default to a single-tenant experience
Currently Mattermost defaults to a multi-tenant setup, and it’s not what everyone expects–it makes much more sense to start single-tenant and offer multi-tenancy than the other way around.
While we’re not able to get that in by Mattermost v1.2 on Nov 16, the new release has added options for supporting single-tenant teams, like being able to list existing teams on the root page for easy access.
This is the start of a sequence of changes we need to make to make the onboarding experience more straight forward.
2) Multi-auth login screen needs improvement
Creating a multi-tenant sign-in UI supporting multiple authentication options is difficult, and we haven’t invested enough in getting the aesthetics right.
Here’s what sign-in looks like with GitLab SSO and email options enabled:
There are some clear things we could have improved here, ticket filed.
3) Turning logging on by default in GitLab Mattermost
Logging is currently off by default in GitLab omnibus and turning it on is in the first step of our GitLab Mattermost troubleshooting guide, so if it’s on by default in future, that could make trouble shooting a lot easier.
There’s already a request from the community for GitLab omnibus to turn Mattermost logging on by default. So if that goes in the next release, probably a significant number of issues would be self-serviced through the existing Mattermost error documentation.
4) Improve Mattermost troubleshooting guide and error messages
We need to it simple to web search for Mattermost error messages and always find a current answer.
This means constantly pulling solutions into the Mattermost trouble shooting guide and making it easy to share those detailed answers. It also means improving our error messages–like for the issue above–to even preempt the need for web search.
5) Improve upgrade and compatibility documentation
After installation, upgrade is the highest priority, so there’s now a step-by-step upgrade guide for getting your Mattermost instance on the latest release.
Moreover, Mattermost changelog and release notes now contain:
- A compatibility section noting any changes to things like minimum requirements, such as browser versions across platforms
- Documentation of any changes to system configuration files as well as changes to the database schema–both of which are automatically upgraded by Mattermost after installation
This is the start.
As Mattermost continues to grow in popularity, there will be more platforms to support, more systems with which to integration, more authentication options to add.
We’re excited to work with the community to shape the future of Mattermost.
Please help us?
We want to make using Mattermost with GitLab a wonderful experience. You can try out the latest release (Mattermost v1.2-RC1) for yourself at https://gitlab.mattermost.com/community
We’d love to hear your ideas, comments, feedback and questions on this thread, or via the feature ideas forum, or via issue reports if you notice anything you feel should be addressed.