Related to http://www.simpledesk.net/forum/index.php?issue=1.0
The help tab would be left in such a mode however it would need to be diverted to a manual on SD instead of SMF.
When NOT in helpdesk-only mode, it would be easy enough to add a new area to the help section for SD, even if it was just to point them to the manual on SD.
*nods* Whatever works, I don't really mind, as long as we do something with it.
So, $64,000 question. Are we building a help area into SMF or pointing them somewhere here?
Either way a hook has to be bolted into SMF somewhere.
I think we should build it into SMF.
*nods* So do I.
So, basically, if the helpdesk is enabled, it adds a section to the Help tab. If it's in standalone, it removes all other help sections.
Correct?
What about personal messages? Should the help section for those be left intact in standalone mode if they're not disabled?
We'll also need content for these pages.
QuoteSo, basically, if the helpdesk is enabled, it adds a section to the Help tab. If it's in standalone, it removes all other help sections.
I'd say so. Note that if bbcode is still enabled, standalone shouldn't nuke that either, ditto for smileys.
Quote
What about personal messages? Should the help section for those be left intact in standalone mode if they're not disabled?
Yes - if the function is still enabled, leave the help in.
See also topic (http://www.simpledesk.net/community/documentation/sds-inbuilt-help-section-644.0.html) in Doc Team's board about this.
Note there's two issues here, one for writing the content and one for writing the code that drives it.
I'd also be in favour of tweaking the content to suit permissions and configuration if possible, e.g. no need to show the recycle bin notes to folks who don't have permission to see it.
OK, IDEAL question time.
You guys have been using the helpdesk by now. What didn't make *immediate* sense to you?
What needs more explanation? What did you need help with? What about your users?
These are the things that need help areas on. Once we have a list of what actually needs to be covered, we can start writing.
I've always felt that the main screen is rather... well, if not confusing, at least intimidating to new users. I found myself wondering what the (up to) 4 different grids were for, and what would happen to a ticket that could theoretically show up in more than one grid.
The ticket itself is pretty good, though I still think the "Reply with quote" and "Reply with ticket" buttons are misplaced.
The meaning of a "private" ticket should be spelled out in no uncertain terms.
When first installed, and there's no "Roles" created, the purpose of the role templates could be more obvious.
Much of this isn't necessarily things that need a help screen... I'm just jotting down what pops into my head. :)
QuoteI've always felt that the main screen is rather... well, if not confusing, at least intimidating to new users. I found myself wondering what the (up to) 4 different grids were for, and what would happen to a ticket that could theoretically show up in more than one grid.
Would it be better to hide more of the areas then?
Regular users should only see 2 blocks (with staff/with user), staff up to 4 (assigned to me/new/with staff/with user)
QuoteThe ticket itself is pretty good, though I still think the "Reply with quote" and "Reply with ticket" buttons are misplaced.
I don't remember you saying about them being moved though...
QuoteThe meaning of a "private" ticket should be spelled out in no uncertain terms.
Smart mode sort of deals with that. It would be relatively trivial to build lists of who can see what.
QuoteWhen first installed, and there's no "Roles" created, the purpose of the role templates could be more obvious.
I actually thought that was one of the more obvious things about it, but I'm not sure what else you could do with it...
Quote from: Arantor link=issue=2.com2823#com2823 date=1276559097
QuoteI've always felt that the main screen is rather... well, if not confusing, at least intimidating to new users. I found myself wondering what the (up to) 4 different grids were for, and what would happen to a ticket that could theoretically show up in more than one grid.
Would it be better to hide more of the areas then?
What I wish is that the different grids could be given a subtle color coding to help distinguish them from each other. I know in the paradigm of SMF, and themes, that's not necessarily possible. (User defined?)
Quote from: Arantor link=issue=2.com2823#com2823 date=1276559097
QuoteThe ticket itself is pretty good, though I still think the "Reply with quote" and "Reply with ticket" buttons are misplaced.
I don't remember you saying about them being moved though...
It came up a long while back, and I could sense that there was strong feelings about their placement, so I dropped it.
Quote from: Arantor link=issue=2.com2823#com2823 date=1276559097
QuoteThe meaning of a "private" ticket should be spelled out in no uncertain terms.
Smart mode sort of deals with that. It would be relatively trivial to build lists of who can see what.
On that one I'm talking more about the help files, or how-to files... or FAQ. There should be a section that spells out why it is the way it is.
Quote from: Arantor link=issue=2.com2823#com2823 date=1276559097
QuoteWhen first installed, and there's no "Roles" created, the purpose of the role templates could be more obvious.
I actually thought that was one of the more obvious things about it, but I'm not sure what else you could do with it...
Perhaps just some big angry looking text that only displays when there's no roles, saying something like "There are no roles created yet. Use one of the three templates above to create your first Permissions Role!"
QuoteWhat I wish is that the different grids could be given a subtle color coding to help distinguish them from each other. I know in the paradigm of SMF, and themes, that's not necessarily possible. (User defined?)
Well, that's one of the fine lines we have to walk; either we make it customisable and more flexible, or we make it fit with the forum theme that's in use. We talked about this a lot in the early days and came to the conclusion to make it use the same basic code as the Curve theme so other themes would fit in more or less seamlessly; amongst other things that's a major reduction in support requests ;)
QuoteOn that one I'm talking more about the help files, or how-to files... or FAQ. There should be a section that spells out why it is the way it is.
Agreed. That's ultimately what this is about.
QuotePerhaps just some big angry looking text that only displays when there's no roles, saying something like "There are no roles created yet. Use one of the three templates above to create your first Permissions Role!"
That's not particularly hard to implement.
I would actually like to see this changed to be a link from the help section to a manual here on SD. I have a feeling the help section as it currently exists will soon be scrapped anyways. I'd rather not spend a lot of time adding a section to it if the whole thing is going to be ditched soon after.
I tend to agree.
Perhaps a '(?) Help' link on the top of the helpdesk that opens a JS popup with some text and a link to a manual over here? For non-JS users, have a custom page with that text and link.
That does sound like the best option, I originally agreed with B when i 1st read this topic.
Can this be changed to a future version until someone takes it on?
As SD evolves so would the manual anyway... its not a must have at the moment IMO I could be wrong of course
Well, SMF's help area is now gone, so that leaves the question open again about what we do with this, but a guide here rather than in SD itself would be better given how SMF has changed.
This I actually thought about after SMF's change... I don't really like the new format so much but I do get that it's much easier to maintain and streamline the help docs that way, so I thinking opening in a new tab/window to the docs here would be best. The popup isnt a bad idea though it has that 1 extra click.. {click-popup, click-go to SD}
I should note how much discussion there was about SMF doing it, and it wasn't entirely well received - on the theory that mods might, for example, extend the help area, except that none ever did, and I think we would have been one of the first, if not actually the first, to expand the help section with information.
What it needs, though, is someone to actually sit and write said content, which was the problem in the first place - but if that's going to be the case, it really needs more of the team to make a decision about whether they're going to do that or not. Either way, I'm thinking this issue should be closed and discussion moved to the team boards about how to approach it, since either way it's not going to directly expand SMF's help area.
I'm willing to help with the helps docs whichever way we decide to go.
High quality technical writing is an art.
True... its something I can do if I choose to (though most times I choose not to :P )
Quote from: tfs link=issue=2.com3486#com3486 date=1300672181
High quality technical writing is an art.
No argument from me. My branch of tech writing usually covers the nuts and bolts of implementation rather than making it understandable for users ;)
I knew a few people who wrote that stuff back in the 80's and 90's, when even a new mouse would come with a 200 page technical manual. :) The entire industry has since died.
The reason it's died is because computing is no longer the province of technical people as it was back then; it's now firmly in the hands of the 'common man', which means technical writing just goes over their head (or they think it does, anyway)
As time goes on, I sort of wonder what the point is in writing documentation, actually. I look at my iPad and I realise that apps don't contain much in the way of help files or documentation because they drop you straight in, but sufficient care was given to the UI/UX that it's immediately usable and doesn't need much explanation - the same is true of SMF in general (most of the support topics are not fundamental 'how do I use it' type topics, even for advanced things, but for technical support and how to configure it in specific ways)
I get the feeling that SD is in a similar boat, actually.
Which is why I'm willing to help... I doubt it needs to be too technical especially from a user standpoint and admin just needs to wrap their head around setting it up right.
Well, the default settings are reasonably sane and suitable for a 'typical' installation, and while it's not necessarily a work of UI/UX genius, it is certainly less cumbersome than many systems I've seen and used. The biggest thing I see being troublesome to explain is private tickets.
What would be good is to produce an outline of the documents needed and maybe we can put something together once we have a framework of what's needed?
I wrote an install doc a while ago over in the Documentation Helpers section. It's a start. I do enjoy writing documentation. It makes me feel like I'm contributing, since I can't contribute on the PHP side.
OK, I went back and re-read the discussion that SMF had about what they did, and some of it more directly applies to us. We are pretty much one of the only mods that ever even bothered to think about it, but the arguments they made are about cases where you have the help area outside the forum, well it's not accessible outside an internal network for example - the company I used to work for wouldn't have allowed it, for example.
So there's that argument in favour of putting it back into the software itself.
Just as a note about myself and the way I used the SMF help system when I first found SMF... I didn't. :) Never used it one time. It seemed so much easier to just dive in and learn it by doing it.
I would have much preferred a knowledge base/FAQ type of material at hand and searchable. Not the WIKI that we talked about last year, but an actual FAQ and knowledge base with good search functions.
What occurs to me is that this FAQ and KB would presumably fit into the proposed KB feature and be installed on a fresh install as a 'how-to' guide.
From what I see:
User POV is rather straight forward especially if they are only in 1 role and 1 dept
- Multi-Depts just requires them to think a little especially if they have different roles in different depts.
Staff POV should be fine as well, considering you'd more likely train your staff to use your Helpdesk
SD Admin, of course this you would only grant to someone you trust.
Site owners should find the ACP fairly well documented, otherwise they'll have to come here and let us know and from there we can get a better understanding of what really needs to be in the docs/faq... we can then work towards pushing that in a future version, especially if we're adding this in the KB system.
In which case, I suspect we should bump this to a later version and make it part of the KB feature then.