* narrative reports use italics for children's data

[Linda Reinfeld]

I use narrative reports a lot to check my sentences and data. For all of the narrative reports (Individual Narrative, Descendants by generation and ancestors by generation), the data for the children is written in italics. I would very much like not to have that data in italics, but I don't know how to turn it 'off'.

Thanks

[AdrianBruce]

I don't know how to turn the italics off (I can't find any setting in v6 for that) but I thought it might be useful to explain what I think is the reason why those entries are different. Basically, if you ask for a two generation report (say), the children are an extra, third, generation. To highlight this, their text is in italics.

Not sure that I'd have done it quite like that because you seem to get pretty full details for the children instead of just names and vital dates, say, so it does look a bit in your face.

[tatewise]

Linda, currently there is no option to turn off those italics.
You could report that problem to Calico Pie via http://www.calico-pie.com/osticket/open.php but don't expect a quick fix.

[Linda Reinfeld]

Adrian & Mike -

Thanks for the reply. I have created a ticket.....

Linda

[jmbsupreme]

Just started with FH, and found the same thing, which was annoying.

But if you simply ask the report to cover more generations than you actually need, the last generation is no longer italicised, which is a reasonable work around.

But I agree I can't really see why the italics are necessary anyway.

[Linda Reinfeld]

Thanks for bringing this up again. I had forgotten I wrote a ticket about this. There certainly is NO reason for the italics...

I checked the status of my ticket. I don't understand:
I wrote the ticked on 2 Feb 2021.
Received an email acknowledging the ticket.
Received a 2nd email saying: I have logged your request for consideration by the developers. Closed by Ros with status of Responded 12/02/2021 8:12 AM

Does this mean the tiket is closed? and nothing more will happen?

Linda

[tatewise]

Does this mean the ticket is closed? and nothing more will happen?
Certainly, the ticket is currently inactive. It is not clear whether anything will happen. That is up to CP.
However, you can reactivate the ticket by posting a reply and perhaps asking what the developers decided.

[davidf]

Looking at the support ticket input screen, we are not asked to describe what we are looking for so it is possible that a "support request" will be interpreted as an "enhancement request" - which "developers will consider" - presumably when thinking about a "new functionality" release as opposed to a "bug fix" release? If that was the case, I can see why the ticket was closed.

A support ticket could, in my understanding, be one of (or a mix of!):

1. A request for usage support - which will be either directly answered or which will result in a reference to support material (either CP documentation or FHUG documentation).
2. A bug report - which you would expect to be acknowledged as a "bug" or a justification for why FH works that way ("not a bug but a feature")
3. An enhancement request - which they could either take on board directly or suggest that a "Wish List Request" is raised on the FHUG forum

Should we therefore in the narrative make it very explicit what sort of support ticket we are opening?

[LornaCraig]

....Received a 2nd email saying: I have logged your request for consideration by the developers. Closed by Ros with status of Responded 12/02/2021 8:12 AM

Does this mean the tiket is closed? and nothing more will happen?

I think the key word in their reply is 'consideration'. They don't regard it as a bug but they will 'consider' whether they think they should introduce an option to display normal text instead of italics. It doesn't sound like a high priority.

In response to a ticket I raised at the weekend, about something I regard as a bug, they replied "Thank you. I have logged all of that, and it will be passed to the developers for investigation. " This makes it sound a bit more likely that something will be done, but even in this case the ticket was closed. Somehow I feel it shouldn't be closed until they have done the investigation!!

[ColeValleyGirl]

I suspect closing the ticket means that it's no longer in the ownership of the frontline support team and is being tracked elsewhere by the developers, not that nothing else will happen (although the developers may subsequently decide to do nothing). And we only find out about development decisions when a new release appears.

[tatewise]

Yes, it is not a particularly user-friendly system when it comes to providing feedback about the progress of tickets.

[ColeValleyGirl]

Yes, it is not a particularly user-friendly system when it comes to providing feedback about the progress of tickets.

We are reprising a discussion we've had at least once before. First line support is about helping people use the product and learning about bugs and difficulties users have had. It isn't about keeping users apprised of development intentions (including progress on bug fixes). One a user knows that something has been passed to development, first line support has done its job.

As CP never reveal their development intentions in advance of a new release, it's not a surprise (is it?) that the progress on bugs and new features isn't reported back to a user until they're released (or sometimes about to be released).

[davidf]

First line support is about helping people use the product and learning about bugs and difficulties users have had. It isn't about keeping users apprised of development intentions (including progress on bug fixes). One a user knows that something has been passed to development, first line support has done its job.

Yes, but ...

It is where the line is drawn between "support" and "development".

You could have an auto responder that acknowledges all tickets and forwards them to "development". I think we might recognise that that involves very little "support" - and would not encourage users to help CP in "learning about bugs and difficulties users have had".

There surely has to be some level of triage visible to the user and feedback as to the three (?) possible reasons for a support ticket that I surmised previously:

1. A request for usage support - which will be either directly answered or which will result in a reference to support material (either CP documentation or FHUG documentation).
2. A bug report - which you would expect to be acknowledged as a "bug" or a justification for why FH works that way ("not a bug but a feature")
3. An enhancement request - which they could either take on board directly or suggest that a "Wish List Request" is raised on the FHUG forum

I appreciate the possible difference between "consideration" and "investigation" - but that is relying on users to read the appropriate meaning into those words?

[tatewise]

It is reasonable for CP to play its cards close to its chest for enhancement requests.
However, bug reports would benefit from more open feedback about whether they are or are not a bug and whether they are likely to be fixed soon or considered for much later, i.e. the results of the 'investigation'. As it stands, users are often left in the dark about the nature of the 'investigation' and the outcome.

[ColeValleyGirl]

Tbh, for a user, there's little useful difference between a bug or an enhancement request:

• Both are variants of 'this programm doesn't work the way I think it should work'.
• Both go to development and vanish from first line support's to-do list.
• Visibility of further progress on both mostly only comes when a fix/enhancement does/does not appear in a forthcoming release.

What help would it be to know whether something ends up classified as?

• A bug -- won't fix
• A bug -- should fix one day, but it doesn't affect many users
• An urgent bug -- fix asap
• An easy bug -- quick win in the next release
• A totally insane enhancement request
• Not that !*!*! user again!
• Good idea but too hard to implement
• Quick win enhancement that fits in with our product strategy
• Good idea but a lot of work; put it on the ideas board for the next major release
• Understand the attraction, but not in line with our strategy
• Niche requirement, not worth the effort
• .... fill in your own categories here

(I am not suggesting that there is a formal classification system that contains all those classes explicitly but having been responsible for implementing ITIL-compliant 1st-2nd-3rd line support processes in at least three organisations, I can assure you they exist informally, and translate to a formal classification structure that those in the know can read like a book).

CP do sometimes inform a user that a bug will be fixed in the next release (presumably if it's high enough priority or easy enough to do).

If you're assessing whether to move to FH and a particular bug or feature is a show-stopper for you, and CP don't say it will be fixed in the next release, you can make your decision on that basis. If you're an existing user, in the same circumstances, you can decide whether to put effort into a workaround, not use the "offending" facility or start looking around for an alternative. How does the difference between 'consideration'/enhancement and 'investigation'/bug help in those decision-making processes?

[ColeValleyGirl]

As it stands, users are often left in the dark about the nature of the 'investigation' and the outcome.

What would you do with the info?

[AdrianBruce]

...
We are reprising a discussion we've had at least once before. First line support is about helping people use the product and learning about bugs and difficulties users have had. It isn't about keeping users apprised of development intentions (including progress on bug fixes). One a user knows that something has been passed to development, first line support has done its job. ...

You beat me to it. IIRC, Network Rail was ITIL compliant with 1st, 2nd and 3rd level support. In our case, I was 2nd level support - not all of it! - so could take the outstanding bugs to the customers' representatives but even that meant that the signaller at Blaenau Ffestiniog who raised the fault wouldn't get our reports - but Birmingham(?) Control's rep would.

[Mark1834]

To be fair though, Network Rail and the CEGB are not quite the same thing as CP, where first line is Martin and Ros and second line is probably Simon.

Does it make a difference that the overwhelming majority of FH users are using it voluntarily for their hobby, not as something they can't change that comes with their paid job, so perhaps feel a little bit more of a community rather than just customers?

To be fair, I find the current support system generally satisfactory. Depth and quality of initial responses can vary, but so do the quality of our "bug" reports - from genuine show-stopping issues to misunderstandings of how a feature works and "and I wouldn't design it that way" comments.

[ColeValleyGirl]

Does it make a difference that the overwhelming majority of FH users are using it voluntarily for their hobby, not as something they can't change that comes with their paid job, so perhaps feel a little bit more of a community rather than just customers?

Yes, it does; and (as you point out) the size disparity between CP and the big organisations that Adrian and I worked for also makes a difference. It's easier for a large organisation to keep users (or at least users' managers) informed -- they can justify the overheads involved. Would it be the best use of Martin/Ros/Simon's time to keep users informed about progress or lack of progress on bugs? Especially since multiple users might have reported the same bug...

Not long after retiring from 'big' IT, I overhauled the support processes for a start-up web software business. The founder (great ideas guy and software developer, no idea about support) had implemented an open ticket system, where every licenced user could see and contribute to every 'trouble ticket'. It was mayhem. Users who hadn't been affected by a bug still felt the urge to expound on how it should be dealt with (because they all knew how to run a start-up software company, of course) and to complain if the ticket hadn't been updated every week. And many tickets devolved into the same bunch of users re-designing the product. (I do wonder how they found the time, and why they weren't spending it on their own businesses!)

The ticket system soaked up resources, monitoring it (in case anything that was actually useful was said) and updating it (correcting inaccuracies as well as reporting progress or the lack of it). And the users who were affected by bugs were getting worse service, because any useful updates risked getting lost in all the noise, and the support team (company founder plus me) weren't getting time to actually address the problems. Developers (in the Netherlands, Ukraine, Poland, Egypt, the Philippines and a few other places I can't remember -- it depended where the relevant software expertise was cheap at the time) added to the problem by updating the tickets for their own benefit...

Fast forward a year. Closed first line ticket system (tickets only visible to/updateable by the user who had raised them and the support team); separate development work tracking system. Founder and I could stop doing support -- it could be handled by a backroom 'product expert' and a succession of Dutch interns managing the routing of tickets (and addressing the very simple ones as they gained experience). (As an aside, the product expert was also responsible for user documentation). The process from the customer viewpoint was well documented -- including when they would or would not get updates (basically, when a fix was imminent and not before, and timetables were never promised) -- a very simple support SLA. By the time I ceased to be involved, customers included the White House, United Nations, the United States Senate, and various Universities....

If I was to change anything about the CP ticket system, it would be to do some expectation setting for users.

[LornaCraig]

If I was to change anything about the CP ticket system, it would be to do some expectation setting for users.

While reading your post I was thinking on exactly those lines. Outside the world of IT support systems the word 'ticket' could mean all sorts of things. When a ticket is first raised the user gets an automated response including "You can view this ticket's progress online here: ...." To the uninitiated this creates the impression that they can follow the progress of the issue they have raised, right through the process of consideration to the decision on what, if any, action will be taken. Consequently when the ticket is closed it creates the impression that the whole issue has been closed.

In fact what they can follow is just the progress of the ticket (in an IT support meaning of the word) through an initial acknowledgement followed by (usually) it being "passed on to the developers". A small change in the wording of the automated response when a ticket is first raised might make all the difference to expectations.

[tatewise]

Yes, I agree with Laura. The ticket system is very much being viewed from the perspective of the support team rather than that of the customer/user. Sadly, I find this attitude in many walks of life where the vendor is inward looking rather than putting themselves in the position of the customer and considering their needs. We used to run a restaurant and the customer needs always came first whenever we could afford to.

[ColeValleyGirl]

We used to run a restaurant and the customer needs always came first whenever we could afford to.

(Emphasis mine).

So, your finances came first, and then the customer needs.

Re customer needs, I'm still wondering about this:

As it stands, users are often left in the dark about the nature of the 'investigation' and the outcome.

What would you do with the info?

A statement at the outset that "items referred to the developers are not being disregarded, but may be addressed in a future release" would be honest and accurate. What else do you need?

[tatewise]

I had to add the afford to rider as otherwise we would have gone out of business, which from our customers' perspective would also not have satisfied their needs. We were successful in business for 13 years (which is not bad for a small family restaurant) and only closed for life balance reasons.

IMO when an issue raised by a ticket has a blanket response such as it is being considered or investigated by the developers, then some form of feedback on the outcome would be courteous, even if it is that no action is proposed.

Even when a bug gets fixed there is no response to the ticket and if it is only minor then there is no specific mention in the V7 Updates release notes.

[ColeValleyGirl]

Mike,

Exactly the point I was making -- you had to stay in business in order to serve your customers, which meant using your limited resources wisely.

some form of feedback on the outcome would be courteous, even if it is that no action is proposed.

Except it might be months or years before the outcome is known. I'm going to guess there are features in V7 for which the seeds were sown by user support requests in versions 4 or 5... And as I pointed out somewhere above, it's rarely a black-and-white decision about whether to do something. You might not intend to fix Bug A, but then major Bug B comes along in the same section of code, and Bug A gets fixed almost by accident. Or you do a complete rewrite of that piece of code to introduce new functionality and Bug A becomes irrelevant. What do you tell the user and when? And more importantly, what practical use is the information to them?

Even when a bug gets fixed there is no response to the ticket and if it is only minor then there is no specific mention in the Whats New release notes.

My experience is that I've been asked to test fixes to bugs I've reported some days in advance of their release, and I know the same applies to others.

[LornaCraig]

A statement at the outset that "items referred to the developers are not being disregarded, but may be addressed in a future release" would be honest and accurate. What else do you need?

I think it just needs expanding slightly to say
"The issue has been referred to the developers so this ticket will be closed. Items referred to the developers are not being disregarded, but may be addressed in a future release."

This makes it clear to the user that although the ticket might be closed the subject matter remains open for investigation/consideration. That would remove a source of misunderstanding.

I understand that, for the various reasons Helen has given, it would often not be practical to give updates on the progress of the investigation/consideration unless and until CP want a particular bug fix tested by the user who raised the issue.