I have been a webmaster since 1996. I have been through thousands of issues on many different web hosts over the years. I am used to creating subdomains, domain transfers, blah, blah.
So, when I read this blithe statement "It's really very easy!" at http://help.campaignmonitor.com/topic.aspx?t=116
I am appalled at how confusing your make this topic.
Stick with ONE EXAMPLE all the way through.
Then show some OTHER POSSIBILITIES in the same precise sequence.
But, this cannot possibly be correct as written:
"Type in the full domain name your clients will login at. This might be a subdomain on your company site, or it could be a totally separate domain, it's up to you."
IT CANNOT BE A DEFAULT ADDRESS SUCH AS WWW.YAHOO.COM.
THIS HAS TO BE A SEPARATE DEDICATED SUBDOMAIN THAT IS ALREADY SETUP SPECIFICALLY FOR THIS PURPOSE BECAUSE IT HAS A DEDICATED LOG-IN PAGE. THE USER HAS TO KNOW THAT THE SUBDOMAIN IS CREATED FIRST AND THAT IT IS EXACTLY AS WRITTEN BEFORE MAPPING THE CHANGE WITH CAMPAIGN MONITOR.
I could go on with what else is poorly written and confusing about these instructions but I will leave that for later.
Thanks for your feedback. However, it is completely possible to use a default address for your custom domain, it definitely doesn't have to be a dedicated subdomain. We have plenty of customers using a specific full domain which maps to their Campaign Monitor account.
If you do have other suggestions though, please let us know.
My point is all of your FAQ's are written description of "what is possible". And, yes, of COURSE it is possible to use a default web address so that the Client log-in page shows up, I presume, at that address.
But I have looked all over your site and you guys have completely forgotten what these actions LOOK LIKE in practice. NO VIDEOS, not even illustrated text tutorials to DEMONSTRATE the EFFECT of an API in action on an existing website, and no visual demonstration to your new clients of what Mapping a CName to either a subdomain or a default address will produce when this is done.
I am assuming that the log-in page REPLACES the existing page completely with the Client log-in page.
But that is an assumption I have to make because not once anywhere in your documentation do you think to walk the new client through the visual result of Setting up a Custom domain.
Like, I am assuming that any existing content on the front page of a site like www.heylookatme.com will be replaced by the Campaign Monitor log-in page. Which is a different thing, I again assume, from working API functions into an existing website on an already existing index page or in a sub-domain.
This is a huge area of modification of the experience that you guys do not begin to sufficiently document besides YES it can be done, and WOW, it will be so cool if you do it!
A better visual roadmap showing new clients what these actions actually look like and what they should expect ahead of time and HOW TO JUDGE which method will work the best for them. Embedded API (and what it visually produces once enacted), or mapping CName to either sub-domain or default index page (home page) of an un subdomained web url.
Thanks, I appreciate the feedback. Perhaps I misunderstood you, but you did say
"THIS HAS TO BE A SEPARATE DEDICATED SUBDOMAIN THAT IS ALREADY SETUP SPECIFICALLY FOR THIS PURPOSE BECAUSE IT HAS A DEDICATED LOG-IN PAGE. "
which is not actually true.
So far, the common issues people have with custom domains isn't what they will look like (everybody seems to get that part), but how to set it up on their own DNS, which is by far the trickiest part.
We do plan to add more videos and resources in the future though about areas where people do run into more confusion.
As for the API, it really can look like anything at all, since it is totally up to how an individual chooses to use it. See http://www.campaignmonitor.com/api for all the possibilities. Most of our customers using the API don't even let us know, but we do post on our blog and in our resources section about integrations and plugins, so have a browse there to see some examples already.
Thanks for taking the time to respond to my comments and complaints.
But, you still don't seem to have addressed my main issue:
Nothing is clear AHEAD OF TIME. Your applications are set up like this--
Go do it, go try something and then you will see what you get and then you can come back to the Forum and ask us questions about why this didn't work or how can I get something different.
Even in this Forum you just respond like this-- "...which is actually not true." End of discussion. Duuuuhhhhh.
I have given you several opportunities to even specify what DOES happen if a CName configuration is done that points an existing account such as (imaginary example) http://funkymonkeymakesnewsletters.c/send.com to http://www.funkymonkeymakesnewsletters.com
First of All--Without using an API. If a client with that c/send log-in created this mapping as strictly a mapping and nothing more. What do they GET? There is nothing in your regular documentation that says WHAT HAPPENS AS A RESULT!!!!!! Not a single screen capture of the END RESULT.
I just want to see what YOUR application has in mind ahead of time before I go spending hours TESTING to SEE WHAT I get.
I assume that once the mapping is done as the "explanation" page describes and once the DNS change propagates that when the user types www.funkymonkeymakesnewsletters.com into their browser that what they will next find is the Log-in page. Or if I mapped the cname to a subdomain that I must first set up at a website that I have administrator rights and control of....www.mainmonkey.funkymonkeymakesnewsletters.com.
So, tell me Mathew, what happens? Visually, what shows up after this is done?
And your comment in your last reply shows that you have one mindset--the mindset of a man who knows the product backwards and forwards so well that you think showing your API code page is sufficient:
"As for the API, it really can look like anything at all, since it is totally up to how an individual chooses to use it. See http://www.campaignmonitor.com/api for all the possibilities."
I HAVE LOOKED all over your API "examples". I read your entire website and all your FAQ's several days ago before figuring that I must be missing something.
You tech geeks are so wrapped up in code examples you have forgotten to show the rest of us who are not employed by your company the END RESULT in a well illustrated tutorial or video tutorial.
Don't make the initial learning curve so mysterious and deep that not a single API method shows the visual representation of the end result.
Mathew, the code is not what people see. What the code DOES in the resulting page is the key to educating your users.
You talk of "all the possibilities"! The possibilities are not the code, the code is what PRODUCES the possiblities. Now take some money out of your budget and hire somebody who does really good user-friendly documentaries and produce some really specific tutorials that SHOW THE POSSIBILITIES!
Another important question that all of your documentation fails to provide--don't most people want the login page that they are expecting to map into a subdomain or default domain of their choice to LOOK like the existing website? Wrapped inside their own website style or template?
The only way that can happen unless you guys are really dealing with alien technology light years ahead of ours is to do more than simply map the default create send log-in of a client to some website address. Right?
It requires using your API functions to be embedded inside a page that is specifically created to wrap the log-in and other Client concerned functions.
So, unless you have some answer to the contrary, you are missing some clear-as-glass tutorials to explain to people who have never had much experience with designing websites or dealing with standard web issues what all your groovy cool features do for them in a way that is visually explicit.
If you want to grow, you would grow faster by visually exciting the NEW clients with their options and by creating some visual scenarios step-by-step so that someone can watch a five minute video and decide Hey, that's for me. Or, I had NO IDEA that this was what they were talking about when they referred me to all their "API's" until I saw them actually IN USE.
I look at the forums for develpors and I see frustrated people in there asking how they can get more complete information on how to even start using an API...Like what ELSE has to be satisfied besides just inserting some API code.
I am saying it is time for you guys to start getting more user-friendly and assume that most people who sign up for a trial account are not web technicians and that they cannot actually rely on their intuition to show them how to follow up on your "possibilities". Pointing at code samples doesn't hack it as Customer support.
To answer your questions:
* If you setup a custom domain, the only difference is that instead of using your something.c/send.com URL, you will use your custom URL to login to exactly the same account. You type in a different URL, and get to the same login page as before. It is to help with rebranding.
* If you want people to login from your own marketing site, you can just use the login form code which we provide for you, under the customize section. Click "Add a login form to your site" to get started with that, no API or indeed alien technology required.
* Regarding the API, you really do need to be a web technician to use it as it is aimed at developers who have skills and experience in that area. It sounds like that is not your background though.
I've already mentioned that we are planning to add further videos and help, but it won't likely be in the area of the API as that is something much better explained through code samples and existing integrations. There is no visual representation of an API call except how the individual developer chooses to display it themselves.
Developers who use the API are well aware of this, and the requests we get are almost always for more code samples, so that's the area we'll be concentrating on for API documentation.
Thanks again for your comments.