Tom Whiting

While I sympathize with your position, this line really doesn't work.
Sure, documentation doesn't "write itself", but then again, neither does code. As this stuff is written, it should be documented, not as an afterthought.



so, which is it? Will there be a manual, or will there not be a manual? Please, do clarify.

The types of documentation described previously work somewhat well (though articles are not documentation by any means) for new users, yet these do not relieve the need for a manual of some kind.

Getting started guides, great idea, and could easily be a 'chapter' in the manual, but definitely don't take the place of it.
Inline help, as well, great idea, but this doesn't cover everything at all, and it shouldn't.
Articles, too wordy and opinion based, definitely not documentation.

There needs to be some sort of manual here, which, as already said before (not by me, mind you) would cut down on needs for support , and promote some sort of customer satisfaction. Somewhere a customer can go and say "ahah, THIS is how I do this", whether it's an advanced customer wanting to learn how to change a theme, or a new customer just wanting a step by step guide to creating a new forum. Both of those are just examples, but you still have a major need for documentation here , because the product obviously does not document itself.

That 'right there in front of you' doesn't actually tell you how to change a setting, such as, say, how to disable certain login requirements (capcha, etc), or how to change the site's default theme, and it shouldn't. While it's good to have what's there there, it's not that helpful. THAT is why you need a manual. NOT a 'getting started guide', NOT a help screen @ the top of the page



And is only part of why this thread was created. In fact, that is only a minor part of what I've spent the last week looking for.

Full documentation is the solution to everything here. Sure, developer documentation should be a 'minor' part of this (and, again, not code examples, but actual documentation of what is there), but it's still important to have at least the basics covered.

You know, 14 hours is far too long to just let a ticket go without even bothering to respond to it.
Of course, during that time, I was able to find and handle the issue myself, but if this is the typical 'response time', I'll find somewhere else to take my business.

I'm not an impatient guy, 4-5 hours is reasonable, at least as long as things are submitted during business hours (which this was), but 14 hours is pushing it.
Even better? A second reply took 45 minutes or less. Kinda ironic.

The moral of the story? DON'T keep your customer waiting. If they open a ticket, they deserve a non automated reply, same business day, urgent or not.

You know, 14 hours is far too long to just let a ticket go without even bothering to respond to it.
Of course, during that time, I was able to find and handle the issue myself, but if this is the typical 'response time', I'll find somewhere else to take my business.

I'm not an impatient guy, 4-5 hours is reasonable, at least as long as things are submitted during business hours (which this was), but 14 hours is pushing it.
Even better? A second reply took 45 minutes or less. Kinda ironic.

The moral of the story? DON'T keep your customer waiting. If they open a ticket, they deserve a non automated reply, same business day, urgent or not.

Articles are not a "fantastic way to provide documentation". They are longwinded, opinionated and biased. Of course YOU think they're "fantastic", you're biased, you write them, or rewrite them.

ANY software I pick up, anywhere has a manual, except, well, of course IPB, which, I guess is just too good for proper manuals and documentation.

Games? There's a manual telling me what button does what and where, giving me an introduction to the game itself.
php software? A manual, telling me how to do something, clearly and concisely.
OS ? There's a manual right there.

The point is that this software is entirely too complicated to release without a manual. Sure, the "tips" are great, and the "getting started guide" idea might be great, but the articles do NOT replace the need for a manual, they are wordy, poorly written, and only cover things from one person's perspective.

Take my case, for example. I've been using internet software for years, administrating servers for a bit longer. I'm certainly no dummy when it comes to software, yet when I can't for the LIFE of me figure out certain things, I go looking for documentation. NOT documentation that is written by an end user and wordy, but an official product manual. If I, an experienced user is tempted on day 2 to just call it quits because of a poorly documented piece of software, think of what the average newbie is going to do, and how much FASTER they will. Thankfully, I held out for a week, but, in the end, my time is too precious to spend trying to read wordy articles to figure things out.

Yeah, there's only 3 people that would look at the thing, right.
Again, nobody is talking about a 300 page manual here, and nobody is talking about having to print the thing out. A properly indexed, categorized and written manual can be done as a webpage, or countless other ways. Articles are NOT manuals, they are articles, wordy, opinionated, and don't provide a bit of guidance.

As far as your "examples", yes, F1 help IS as close to a manual as you're going to get, but guess what? Even that is properly categorized, appendicized and developed. The user can quite simply search for the right thing, and it's there, which is more than can be said for this product right now.

The point is that the product needs this. It's big enough that there is a problem if you don't tell a user how to do something, not in an "article", but an actual manual. By not having something like this available, it wastes current, and new customer's time, and certainly doesn't promote customer satisfaction in the least.

Sure, if you want to keep the same customers that don't care about proper documentation, don't put out a manual. Doesn't matter to me any more, as I'm already done wasting my time on a poorly documented program.

Yeah, there's only 3 people that would look at the thing, right.
Again, nobody is talking about a 300 page manual here, and nobody is talking about having to print the thing out. A properly indexed, categorized and written manual can be done as a webpage, or countless other ways. Articles are NOT manuals, they are articles, wordy, opinionated, and don't provide a bit of guidance.

As far as your "examples", yes, F1 help IS as close to a manual as you're going to get, but guess what? Even that is properly categorized, appendicized and developed. The user can quite simply search for the right thing, and it's there, which is more than can be said for this product right now.

The point is that the product needs this. It's big enough that there is a problem if you don't tell a user how to do something, not in an "article", but an actual manual. By not having something like this available, it wastes current, and new customer's time, and certainly doesn't promote customer satisfaction in the least.

Sure, if you want to keep the same customers that don't care about proper documentation, don't put out a manual. Doesn't matter to me any more, as I'm already done wasting my time on a poorly documented program.

Yeah, there's only 3 people that would look at the thing, right.
Again, nobody is talking about a 300 page manual here, and nobody is talking about having to print the thing out. A properly indexed, categorized and written manual can be done as a webpage, or countless other ways. Articles are NOT manuals, they are articles, wordy, opinionated, and don't provide a bit of guidance.

As far as your "examples", yes, F1 help IS as close to a manual as you're going to get, but guess what? Even that is properly categorized, appendicized and developed. The user can quite simply search for the right thing, and it's there, which is more than can be said for this product right now.

The point is that the product needs this. It's big enough that there is a problem if you don't tell a user how to do something, not in an "article", but an actual manual. By not having something like this available, it wastes current, and new customer's time, and certainly doesn't promote customer satisfaction in the least.

Sure, if you want to keep the same customers that don't care about proper documentation, don't put out a manual. Doesn't matter to me any more, as I'm already done wasting my time on a poorly documented program.

I have, multiple times. How many times do I have to say it? Look at the competition, look at their documentation, that is a perfect example of a well written, proper documentation manual, and it's not hard to keep up to date. It's a win/win situation.




I'm not going to continue to log helpdesk request after helpdesk request with garbage such as "how do I do this". That wastes MY time and your time.
Inline help does not do that, yet, and it shouldn't ever.
A "quick start guide" doesn't do that now and shouldn't ever do that
Articles are entirely too wordy for that, and entirely too opinion based.
A flat out manual, properly indexed, properly updated would resolve this.

Since IPB doesn't want to do this (will not) , there's really no further need for discussion. I'm sorry that you can't see the need for it, but that's your problem not mine.
When it comes down to it, the excuses from IPS and IPB have turned me away from the product itself. As I stated in my blog, I'm thankful it was only a $20 investment, because it certainly was a loss, but I'm not going to continue to waste my time trying to figure out where things are at, or how to do this, all because someone doesn't want to write proper documentation.

Which competition??? There's many forum softwares out there.

I have, multiple times. How many times do I have to say it? Look at the competition, look at their documentation, that is a perfect example of a well written, proper documentation manual, and it's not hard to keep up to date. It's a win/win situation.




I'm not going to continue to log helpdesk request after helpdesk request with garbage such as "how do I do this". That wastes MY time and your time.
Inline help does not do that, yet, and it shouldn't ever.
A "quick start guide" doesn't do that now and shouldn't ever do that
Articles are entirely too wordy for that, and entirely too opinion based.
A flat out manual, properly indexed, properly updated would resolve this.

Since IPB doesn't want to do this (will not) , there's really no further need for discussion. I'm sorry that you can't see the need for it, but that's your problem not mine.
When it comes down to it, the excuses from IPS and IPB have turned me away from the product itself. As I stated in my blog, I'm thankful it was only a $20 investment, because it certainly was a loss, but I'm not going to continue to waste my time trying to figure out where things are at, or how to do this, all because someone doesn't want to write proper documentation.

I have, multiple times. How many times do I have to say it? Look at the competition, look at their documentation, that is a perfect example of a well written, proper documentation manual, and it's not hard to keep up to date. It's a win/win situation.




I'm not going to continue to log helpdesk request after helpdesk request with garbage such as "how do I do this". That wastes MY time and your time.
Inline help does not do that, yet, and it shouldn't ever.
A "quick start guide" doesn't do that now and shouldn't ever do that
Articles are entirely too wordy for that, and entirely too opinion based.
A flat out manual, properly indexed, properly updated would resolve this.

Since IPB doesn't want to do this (will not) , there's really no further need for discussion. I'm sorry that you can't see the need for it, but that's your problem not mine.
When it comes down to it, the excuses from IPS and IPB have turned me away from the product itself. As I stated in my blog, I'm thankful it was only a $20 investment, because it certainly was a loss, but I'm not going to continue to waste my time trying to figure out where things are at, or how to do this, all because someone doesn't want to write proper documentation.

While I sympathize with your position, this line really doesn't work.
Sure, documentation doesn't "write itself", but then again, neither does code. As this stuff is written, it should be documented, not as an afterthought.



so, which is it? Will there be a manual, or will there not be a manual? Please, do clarify.

The types of documentation described previously work somewhat well (though articles are not documentation by any means) for new users, yet these do not relieve the need for a manual of some kind.

Getting started guides, great idea, and could easily be a 'chapter' in the manual, but definitely don't take the place of it.
Inline help, as well, great idea, but this doesn't cover everything at all, and it shouldn't.
Articles, too wordy and opinion based, definitely not documentation.

There needs to be some sort of manual here, which, as already said before (not by me, mind you) would cut down on needs for support , and promote some sort of customer satisfaction. Somewhere a customer can go and say "ahah, THIS is how I do this", whether it's an advanced customer wanting to learn how to change a theme, or a new customer just wanting a step by step guide to creating a new forum. Both of those are just examples, but you still have a major need for documentation here , because the product obviously does not document itself.

Nobody want's a "large pdf" here, nobody's ASKING for it. You're right, that's just way too much.
If you think a "large pdf" is the ONLY way to do a manual, you're grossly mistaken. Again, look at how your competition does things, properly. Easy to update, not hard to deal with, and it's all right there.
Your "inline help" is severely lacking, and you can not deny that your proposed "solution" to these problems is not even a solution. Guides aren't going to cover much of anything. Inline help really doesn't cover anything, and articles are a joke.

So, what you have here is an astoundingly large piece of software with no proper documentation at all. You leave users hanging, instead of properly documenting your system, and providing information to your customers. Nice way to keep your customers.

Oh, and this is not accurate at all:

Can't means that it is physically impossible to do. This is 100% inaccurate. What IS accurate is


Which means, of course that you will not do it.

There is a huge difference between the two, and choosing that road shows a great disrespect for your customers, new, and old.

That is not documentation by any means.
Documentation helps the user understand what they're doing (and yes, even developers need that at times), not simply throwing them into code.
Documentation belongs in a manual, well written, well thought out, well presented, not spread out over 50 different articles.
In addition, it's on the company to provide documentation, not the end user.
Articles are opinion based and wordy, documentation is not.

You want to see proper, broken down documentation? Look at your competition. THEY did it right, and they've managed to keep it updated well enough. Examples, and explanation of what should be done, not just random code left for the user to figure out for themselves. Not to mention they've managed to keep it up to date. Easy to read, very well outlined, easy to follow manual.

So, basically, developers are left to help themselves. Nice one. Ignore the people that extend your product and functionality.

And no, that's not the only documentation I was looking for. A "getting started guide" doesn't cover everything though, and barely covers the "getting started", from one person (or group of person's) perspective, which doesn't help much. Sure, it helps a person get 'started' using your product, but what after that? What about when a user wants to change a theme? Of course, there's no 'documentation' for that.

You need real documentation, not just a guide to how to get started from a few people's perspectives. I get that the product is 'new', but you need at least the basic product documentation and howtos up before you release this stuff. Otherwise, you end up dealing with customers that have no idea what's gong on, all because you couldn't write documentation beforehand.

Well, let's hope this one goes a bit better than my last topic, which (seriously) wasn't meant to turn out as a flame war, or start one, but express my concern over what I felt to be a poor support timeframe.

Anyways, it's always good to have full product documentation, somewhere, yet, the links (in the admincp itself) go to support/docs/getting_started/board_gsg.php (on the IPB site) which doesn't exist. Oversight? Maybe the manual's not done yet?

Checking the 'support' dropdown, I see FAQS (which don't cover everything), in the client area, I see a link to a 'knowledge base' which, again, like the FAQS don't cover everything @ all (and it shouldn't).

Maybe I'm missing something here, or maybe the manual for 3.x isn't ready yet?

Nobody want's a "large pdf" here, nobody's ASKING for it. You're right, that's just way too much.
If you think a "large pdf" is the ONLY way to do a manual, you're grossly mistaken. Again, look at how your competition does things, properly. Easy to update, not hard to deal with, and it's all right there.
Your "inline help" is severely lacking, and you can not deny that your proposed "solution" to these problems is not even a solution. Guides aren't going to cover much of anything. Inline help really doesn't cover anything, and articles are a joke.

So, what you have here is an astoundingly large piece of software with no proper documentation at all. You leave users hanging, instead of properly documenting your system, and providing information to your customers. Nice way to keep your customers.

Oh, and this is not accurate at all:

Can't means that it is physically impossible to do. This is 100% inaccurate. What IS accurate is


Which means, of course that you will not do it.

There is a huge difference between the two, and choosing that road shows a great disrespect for your customers, new, and old.

While I sympathize with your position, this line really doesn't work.
Sure, documentation doesn't "write itself", but then again, neither does code. As this stuff is written, it should be documented, not as an afterthought.



so, which is it? Will there be a manual, or will there not be a manual? Please, do clarify.

The types of documentation described previously work somewhat well (though articles are not documentation by any means) for new users, yet these do not relieve the need for a manual of some kind.

Getting started guides, great idea, and could easily be a 'chapter' in the manual, but definitely don't take the place of it.
Inline help, as well, great idea, but this doesn't cover everything at all, and it shouldn't.
Articles, too wordy and opinion based, definitely not documentation.

There needs to be some sort of manual here, which, as already said before (not by me, mind you) would cut down on needs for support , and promote some sort of customer satisfaction. Somewhere a customer can go and say "ahah, THIS is how I do this", whether it's an advanced customer wanting to learn how to change a theme, or a new customer just wanting a step by step guide to creating a new forum. Both of those are just examples, but you still have a major need for documentation here , because the product obviously does not document itself.

While I sympathize with your position, this line really doesn't work.
Sure, documentation doesn't "write itself", but then again, neither does code. As this stuff is written, it should be documented, not as an afterthought.



so, which is it? Will there be a manual, or will there not be a manual? Please, do clarify.

The types of documentation described previously work somewhat well (though articles are not documentation by any means) for new users, yet these do not relieve the need for a manual of some kind.

Getting started guides, great idea, and could easily be a 'chapter' in the manual, but definitely don't take the place of it.
Inline help, as well, great idea, but this doesn't cover everything at all, and it shouldn't.
Articles, too wordy and opinion based, definitely not documentation.

There needs to be some sort of manual here, which, as already said before (not by me, mind you) would cut down on needs for support , and promote some sort of customer satisfaction. Somewhere a customer can go and say "ahah, THIS is how I do this", whether it's an advanced customer wanting to learn how to change a theme, or a new customer just wanting a step by step guide to creating a new forum. Both of those are just examples, but you still have a major need for documentation here , because the product obviously does not document itself.

While I sympathize with your position, this line really doesn't work.
Sure, documentation doesn't "write itself", but then again, neither does code. As this stuff is written, it should be documented, not as an afterthought.



so, which is it? Will there be a manual, or will there not be a manual? Please, do clarify.

The types of documentation described previously work somewhat well (though articles are not documentation by any means) for new users, yet these do not relieve the need for a manual of some kind.

Getting started guides, great idea, and could easily be a 'chapter' in the manual, but definitely don't take the place of it.
Inline help, as well, great idea, but this doesn't cover everything at all, and it shouldn't.
Articles, too wordy and opinion based, definitely not documentation.

There needs to be some sort of manual here, which, as already said before (not by me, mind you) would cut down on needs for support , and promote some sort of customer satisfaction. Somewhere a customer can go and say "ahah, THIS is how I do this", whether it's an advanced customer wanting to learn how to change a theme, or a new customer just wanting a step by step guide to creating a new forum. Both of those are just examples, but you still have a major need for documentation here , because the product obviously does not document itself.

If I were a director of InVision, with the well documented turmoil going on at vbulletin, and a tranche of new versions of stuff here, plus some brand new products, some good strong user documentation would be right near the TOP of my list of things to do,to make it (as far as possible) a 'no brainer' decision to both buy the product if I didn't have a board, and to transfer over to it, if I didn't.

I say that even though I have been very public in my discontent about the lack of support in general (not just documentation) for developers. I think a user manual would be a priority.

Absolutely! For small stuff, you're right, it's an ingenious idea. However, that doesn't remove the need for an all out manual.