Any thoughts on renaming to CDS toolbox? #833
Comments
|
Though question. The tool itself is known as XrmToolBox. Could be difficult to rename it. |
|
Agree. The name change is hard. I think adding CDS clarity to the https://www.xrmtoolbox.com/, this repo, and in the tool itself would help. Lots of anecdotes for PowerApps/CDS folks without a Dynamics / XRM background who don't realize they can use these amazing tools with CDS and model-driven apps. |
|
Got it! I will update descriptions |
|
If anyone cares what I think 😉 - I think the value of the brand XrmToolBox significantly outweighs the "correctness" of renaming it. |
|
After asking the question, I tend to agree with @rappen . While I posed the question as renaming the tool, the root of my question is discoverability of the tool as being something extremely useful for anyone who only knows of CDS & Model-driven terminology and hasn't been in the Dynamics 365 CE / XRM world like the majority of the current users. I do, however, think it would go a long way to help discovery by mentioning CDS everywhere Dynamics 365 Customer Engagement is mentioned. Example: Wordy, I know. I'm not in marketing. Just an example:). |
|
We're all in marketing 😉 |
|
Can you suggest text replacement for splash screen and window title? |
|
@devkeydet, @rappen, @daryllabar I need your help on this one?
|
|
So are you wanting to change it to include CDS? |
|
yes, but I don't know how to include CDS in the naming/description in a smooth and good english way :) |
|
Should it be CDS? CDS for Apps? PowerApps? or anything else? |
|
I would think something more descriptive than CDS simply because many who would benefit from the tool may not be aware of CDS. The PowerPlatform branding is more widely known and we've already seen requests for tools around PowerBI, Flow, etc. |
|
I guess the idea is not to rename XrmToolBox but change description oh the app to let everyone know it is working with CDS and PowerApps. |
|
Sorry, I completely lost track of this discussion. Yes, the point here is to make sure that everyone knows this is a tool that advanced users can use with CDS and PowerApps. Every single week I've pointed this tool out to some model-driven PowerApps and CDS customer to show them the power and control they have with this tool. The generalized response is something like "I would have never known to use this. Why is it still called XRM when Microsoft doesn't use XRM?" My general answer is something like "This is a community tool. We, at Microsoft, have created this side effect with our rebranding. The rebranding was necessary, but it will take time for community tools to adjust to the branding. It will take time for people who only know the PowerApps and CDS terms to connect the dots that XRM tools apply...until those tools are adjusted to make it more clear too." Whether you rename it, change descriptions, etc. We need a way to make sure people understand that if they are a model-driven PowerApps and/or CDS user, this tool is for them too. |
|
I'm not so fond of renaming the tool, but here are some choices if we had to rename it (Please comment or propose new names. Just need to know that the domain name must be available too, so that the website can be updated too, I did not check yet for the proposition below if the domain name is available) :
Anyway, we still need to change description of the application "everywhere". So far, I see these locations:
Please add any location where a change is needed too. As English is not my native langage, if someone could propose replacement text for locations specified, that would be great |
|
I think the rebranding would include the documentation and github instructions. I think a notice to all tool developers would need to be sent out. lots of tools have their own extensive documentation, both inline in their tool and on their sites After my last post on this discussion, I registered cdspowertools.com. All yours if you want it! |
|
I still stand by my last input here - all for improving the description and documentation etc, but all against renaming the toolbox. |
|
If the collective community feels the tool name shouldn't be rebranded, then it shouldn't be rebranded. You're a passionate group with emotional affinity to the brand. So am I. I just happen to have no choice but to call it what Microsoft has rebranded it to on a daily basis. I'm just trying to point out that, as someone who is talking to new PowerApps / CDS customers on a weekly basis, I have learned and have been reminded on a weekly basis through these conversations highlighting this tool that PowerApps/CDS people who are just now joining the party don't know about it and even scratch their heads when I show it to them. They don't connect the "it's for me too" dots until I have to explain it. My goal is simple. More people benefiting from these amazing tools, in the way all of us have throughout the years. So, to me, at a minimum, the "for Microsoft Dynamics CRM/365 CE" needs to be updated if you want people who only know the PowerApps / CDS terminology (which is growing day by day) to realize "this is an amazing tool for me too". As far as I can tell, what I put in quotes or some derivative, is on the splash screen, window title of the app, start page and the About dialog. It's also on the website and GitHub project. Now, what to put instead? Well, "for Microsoft Dynamics CRM/365 CE/PowerApps/Common Data Service for Apps" is clearly too wordy for some of these places and just not intuitive. Perhaps just calling it XrmToolBox in most places and any time what the tool does is described, you include all the things it works with? For example, you could change this: "XrmToolBox is a Windows application that connects to Microsoft Dynamics CRM, providing tools to ease customization, configuration and operation tasks. It is shipped with more than 30 plugins to make administration, customization or configuration tasks easier and less time consuming." ...taking inspiration from https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/data-platform-intro, to this: "XrmToolBox is a Windows application that connects to the Common Data Service for Apps (CDS). Dynamics 365 Customer Engagement (CE) applications, like Dynamics 365 for Sales, Service or Talent also use the Common Data Service for Apps as their foundational data service. XrmToolBox, provides tools to ease customization, configuration and operation tasks for anything built on CDS, including Dynamics 365 CE (formerly CRM) and model-driven PowerApps. It is shipped with more than 30 plugins to make administration, customization or configuration tasks easier and less time consuming." I'm trying here, in the absence of other concrete suggestions, but I don't claim writing as my strongest asset. Hopefully this gets others creative juices flowing about what to do vs what not to do. |
|
I'm on the fence: Xrmtb has its own brand that is extremely strong in the community, and rebranding would be a major effort for both the code and the online content. The big issue here is the success and popularity of the toolbox... which is pretty cool! I see a risk for the toolbox community users. Those still using CRM only may not understand that the Power Platform still means Xrm, so they may not want to use a Power Platform toolset ("But I'm not doing PowerApps!" and "What is CDS?"). Even developers might be confused for the same reasons... "I am working in CRM, not Canvas Apps!" If it opens the doors to more members of the community, that would be great... so that is an argument for rebranding. So if there is a rebranding effort, it would need to be rolled out slowly with LOTS of communication which means a lot of work. @rappen approach might be the best for now: maintain the name while updating the documentation and maybe the landing page to help everyone understand how the Xrmtb is tied to the power platform (some links, updates, etc.). Might be a nice discussion topic for 365 Sat and UG meetings. How Xrmtb helps you with power apps... This allows for some work to be done while gathering community feedback from tool developers and end users. |
|
But the reality is, whether we like it or not, this challenge you are articulating @jamesnovak is already happening. Microsoft rebranded the way Microsoft rebranded. Is it causing confusion in the Dynamics community. Yes. Does everyone like it? No. Do some Dynamics people look at me with a blank face when I tell them that XRM=model-driven+CDS now and you can buy it as a separate SKU? Yup. Do some look at me with a blank face when I say "Dynamics 365 CE first party apps (sales, marketing, customer service, etc.) are model-driven PowerApps built and sold by Microsoft"? Yes. Even Microsoft employees are still getting through the change / rationalization process of understanding this new branding. However, it is what it is. That ship has sailed. To your point, it will take time. I agree with your point that this reality should be incorporated into the decision and timing of XrmToolBox messaging. On the flip side, when I talk to customers who have no interest in Dynamics because they are not ready to displace their existing systems Dynamics 1st party apps could displace, or no idea what Dynamics is, but the concept of what we all used to call XRM absolutely does appeal to them, the new branding really resonates. That's my anecdotal experience. YMMV. It's much easier to talk about the Power Platform vs "Hey, there's this CRM product we have. I know you don't have a CRM need, but let me explain to you why your need is kind of like a CRM need and therefore you can use the extensibility that we've coined as XRM to build your own app that meets your domain specific app needs. Oh, and you have to buy the CRM product to get the platform." So the branding works outside the Dynamics world, in my experience. This is one reason why the branding was changed and we sell it as a standalone SKU. It opens this technology up to a whole new world of customers who would likely never consider XRM because of previous branding. If nothing is done to raise awareness that XrmToolBox is too a tool for that new and growing community of people, I think we've missed out on the potential benefits this tool can provide all those who could benefit from it. If you make changes to reflect the Microsoft branding changes, there is no question you will confuse some. There is no perfect answer here. Change is hard. Forced change that one may not like is even harder. But the Microsoft branding is the branding. My goal here is to encourage some change to help those who don't know about XrmToolBox realize the benefits, without those like me who are trying spread the work about the amazing XrmToolBox having to do it one conversation at a time. I love the idea of getting community feedback through 365 Sat and UG meetings to ensure the collective community opinion is represented here. That's exactly how it should be. Just waxing philosophically on the realities at hand. Naming/messaging is hard. I think this discussion proves that:). |
|
I understand your experiences and I definitely see confusion with gov customers because of the delta between GCC and Commercial. Messaging is tough with new and existing customers in both worlds. Back to branding, how XrmToolBox fits into the Power Platform, and its benefits: it's a powerful tool that demonstrates community support for the Dynamics platform with a large user and dev community of its own. It's built by community members in their spare time, providing loads of value for free. So keeping branding in line with the D365/Power Platform would be great... it's just a matter of how to get there in a realistic way, keeping up with the massive resources provided by Microsoft! @daryllabar @rappen I think you have your next interviewee for the Xrm toolcast! Also, not sure if this discussion counts as issue anymore... |
|
General overall comment: Microsoft hasn't rebranded the SDK, which is what it's based on. I see no need to rebrand until that happens. Update: I just read through all of the comments. Looks like the idea is to add some additional key words so others for whom the XTB would apply would be able to find it and use it, not to change the name from XTB to something else. I have very little "skin in the game" when it comes to changing the documentation/splash screen, and therefore don't really care. At some point int time we should probably really brainstorm what a replacement version of the XTB would look like, and how it would operate. I love me some winforms, but boy, does it make me feel old... |
|
I will just close this issue and start replacing descriptions based on what @devkeydet proposed. |
|
@MscrmTools sorry, don't want to go off-topic from the main discussion here, just wanted to comment that XAML-based UI stacks (such as WPF, UWP and even Xamarin.Forms) have a completely different paradigm than winforms, and are by definition fully composable, stylable, and in general waaay more flexible than winforms. There is no need to use MEF to compose a XAML UI. You can do so by using MVVM and WPF's DataBinding and DataTemplating capabilities. To give you a concrete example, please check my WPF samples which are mainly a big compilation of code samples I've used during my active years in Stackoverflow. Particularily the Nodes Editor and House Plan examples which demonstrate how a dynamic UI can be built on WPF with little to no code referencing or manipulating the UI at all. And btw, with proper infrastructure, you could support both WPF and winforms plugins in a WPF shell, which means that existing plugins wouldn't have to be completely rewritten. |
|
Thanks for jumping in! Is there any easy sample to see that demonstrate injecting assemblies that provides Ui component to display, like we do know with WinForms? |
|
@MscrmTools let me put a quick example together and I'll let you know. BTW it would be worth opening a new issue / discussion for this, so we don't pollute this one with off-topic discussion. |
|
Absolutely |
|
It isn't CDS anymore 🤦♂️
https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/data-platform-intro |
|
I know I know... I will update the terminology as soon as I can |
Given that what we used to call XRM is now model-driven apps on CDS, have you thought about renaming the tool?
The text was updated successfully, but these errors were encountered: