Branding Limitations
-
Branding is too limited and the following are a few things I have noticed:
- Page Titles still contain Cloudron e.g. User account creation
- Emails sent to user with "Cloudron" in the subject, "powered by Cloudron" in footer
- In user's dashboard, hovering over fa-user icon user is prompted to "Login with Cloudron credentials"
- "Cloudron account" in a user's profile under App Passwords
- DKIM cloudron._domainkey prefix should be changed, not only for branding but other reasons (obscurity). Why needlessly announce an organization is using Cloudron?
Branding should extend to the above. and anything I have yet to see, especially in an Enterprise setting. It should reflect the name of the organization. Ultimately, the user is creating an account with the organization, and not with Cloudron.
-
-
@girish And I'm about to come with more, though I like also the ideas mentioned here by @nothing .
White labeling could also be desirable for enterprises providing managed services using Cloudron technology who would prefer to hide their secret weapon from competitors. Especially as Cloudron has very unique features making the whole process so easy to manage compare to anything I've seen yet. -
@girish @micmc Thank you for your input.
I might consider an enterprise subscription if this is something Cloudron implements.
In addition to my original post, I think it is confusing to users, who aren't familiar with Cloudron, it is foreign to them, so questions arise during account setup, emails etc. When Cloudron is branded, the user should see the organization name in each of the instances stated above and anything I have missed.
@girish Agreed, it is unnecessary to make it so blatantly obvious, not only to competitors, but security concerns arise. A DKIM record/email header lets everyone know you're using Cloudron and therefore likely running a host of other services. I don't see any need to do this. It is attached to every email.
-
M micmc referenced this topic on
-
I'd like to revive this a bit if possible.
Without pushing this to a full blown white-label solution (this thread is probably more suited for this), there is still this small gap open for enterprises trying to deploy this to users who have no clue about what Cloudron is, and ultimately should not be concerned with this.
so I will limit the scope of my suggestion below to the end-user aka simple "user" in Cloudron (leaving aside all admin related branding).
To this extent I would like to propose the notion of "Brand name" with sole purpose to act as brand placeholder such as this:
This "Brand name" can be used in multiple places, starting with the few mentioned above such as:
+User profile:
+User Dashboard App Tile:
+App Login Page:
You get the idea - It is probably applicable in a few other places.
I see the above as a pragmatic step that I imagine fairly simple to implement (placeholder/env variable), as opposed to things like DKIM (as relevant/important as it is) would possibly require a more complex implementation.
It would be great if this could be of consideration.
-
For the last point about the "Login with Cloudron" button in apps, we have introduced a new environment variable (just last week) in next release - https://git.cloudron.io/cloudron/box/-/commit/daa8a60da282fc3c8bbccd4b2b1a4920c2b06812 . After the release, we have to adjust the apps to use the text in the environment variable. And then, Branding view will set that variable.
-
-
@girish said in Branding Limitations:
@uwcrbc which apps are important to you? We can start with fixing those packages first.
Perhaps also just start with the most used apps too, like Nextcloud and WordPress etc?
-
@jdaviescoates currently, those behemoths are not on OIDC yet... But nextcloud has already been ported to OIDC. Just needs a lots of testing
