Thanks for these thoughts on the way the log-job button in HelpMaster v15 behaves. You make some good points here. Now that we do have the additional quick-pick template drop-down selection right next to the "Log Job" button, it does make sense to NOT remember the last-used template, particularly now that we have the "Recent Templates" option right there.

We'll re-visit this and see what we can come up with.

In the meantime, if anyone else has a comment on this behaviour, (or anything else), please post and tell us what you're thinking...

I agree that the Log Job button should be able to be locked to a job template like we used to, esp. now that we have the other lists available in the toolbar. Maybe an option in User Preferences can turn ON or OFF the last used template from being used, would cover both functions. We could also make the new permanent "Log Job" template available from "User Preferences" on the "Default Templates" tab?

OK, we've been working on improving the toolbar for logging jobs based on this recent feedback.  Here's what we've come up with.

 

 

 

The big button will log a job based on your default job template  (yes, we've put this option back into the user preferences screen)

The smaller top-button will log a blank job

The smaller lower-button will use the last template you used that wasn't your default template.

 

This should cover everything.  What do you think?  Have we missed something?

Great to see such fast action on this!

The only thing I'd suggest is that the big button logs a Blank Job and the two little buttons would be User Preference and Most Recent. I reckon that would better match their frequency-of-use to their size/position.

The thing is, logging jobs via a template is the best way to get more functionality and efficiency out of HelpMaster, so we figured that by making the largest button the template button, it will encourage best-practice. Both templates, and workflow are core concepts that will receive a lot of attention in future releases so we're keen to promote these concepts via the UI.

The big button can still log a blank job if there is no default template set.

I can only talk on behalf of how we use HMP here and at the moment.

We dug ourselves in to a hole with Job Templates (in concert with a general lack of ownership and maintenance for HMP over a long period). Our jobs logged per day was down around 10 - a fraction of what our 13 staff do; this made reports nearly useless and that was compounded by the issues structure being archaic and bloated and we didn't recognise the problem because the templates were pre-populating these important fields.

We've just gone through a process of culling Job Templates (had 50+) and rebuilding based on our actual needs. (We've also redesigned the Issues and made a fresh management-driven push to "log everything" but that's off-topic). In order to rebuild the templates we have been using Blank Job by default and once we see evidence for the need of a template, we create it. So far we have identified 4 Job Templates and I expect we may get to ~10. It is a matter of diminishing returns. Those 4 templates are covering about 50% of jobs by volume and, again, I expect we may get to 75% by volume.

I (now) regard it as essential to the health of the system that all staff understand how to log a Blank Job and do so with some frequency. Without that, how can they understand what a template does on their behalf? And as an administrator, without a true accounting of jobs, I can't make informed decisions about creating or maintaining Job Templates. This goes to why I find Blank Job so important.

And as I mentioned in the original post, we have found that neither the helpdesk roles or second level support will frequently log the same type of job back-to-back. That means neither the Last Template or User Preference jobs will be used much. I can imagine some situations where they will be useful to us and other organisational structures, so I welcome the buttons, but I'm really very interested in Blank Job.

Just in closing, the proposed design is a step forward in terms of the way we want to use Helpmaster, so even as-is I'm happy.