Tom Whiting

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.

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.

Exactly!

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.

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

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?

So, what you're saying is that there will be no documentation here, except for a few things?

I understand the complexity of updating a PDF, but there are other ways to build the same manual, and , honestly, from the advanced user's side of things, a "guide" won't cover much, if anything.

For example, variables, what can and can't be used where? In a "guide", not really practical, but in a full blown, documentation type manual, practical.

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.

Exactly!

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

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.

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.

To be fair, I have no viewed an IPB Admin CP since early 3.0 betas. I'm not sure what was added/removed in terms of the help. So I cannot vouch for what is in the help text, but I believe the idea behind it is a good one.

I have to agree with the OP here... Everything in life comes with a set of instructions, IPB should be no different.

If you educate people properly about your product then you should reduce some of the strain on your support system, you will also reduce the amount of frustrated customers who post there questions here and never get a reply. If you put the hard work in at the start, it will pay off in the future giving you more resources to build more products to make more money... see where i'm going here?

To use the excuse "we have more developer documentation at this time than anything else." is just lame IMO. It goes to show that you didn't do the job properly first time round.

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, what you're saying is that there will be no documentation here, except for a few things?

I understand the complexity of updating a PDF, but there are other ways to build the same manual, and , honestly, from the advanced user's side of things, a "guide" won't cover much, if anything.

For example, variables, what can and can't be used where? In a "guide", not really practical, but in a full blown, documentation type manual, practical.

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?

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.

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.

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.

Developers are not left to themselves. In fact, we have more developer documentation at this time than anything else. :blink:

http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&category=135

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.

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.