Branding Limitations
-
I like the ideas in general. We had a separate email conversation with @micmc who pointed out similar shortcoming of our white labeling aspect.
@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. -
I like the ideas in general. We had a separate email conversation with @micmc who pointed out similar shortcoming of our white labeling aspect.
@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.
-
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?
-
@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?
