* Improving Accessibility of Commonly Requested Help

[davidf]

This was prompted by Mike's comments in FH6 program (14725).

Either, there is some form of weird spamming going on dedicated to winding you up (rather than enriching you with all those £1 coins)
Or, there is a systemic problem. I suspect (and, I think, hope) it is the latter.

Genealogists are not necessarily computer experts - which means that they have a totally different point of view to those of us who have (some) computer expertise.

I remember "upgrading" my mother from Windows 3.1 to Windows 95 - and she was lost - totally. She had mechanically learnt the steps necessary to do things without ever understanding what the steps were or why they had to happen. She also thought (logically) that you should keep all your letters in a file called "letters" - trying to sort out what she had done over the phone was not easy - she could not understand why when she printed her letter according to instructions, the printer printed every letter she had ever done on her computer.

Those who develop FH and who support it (which includes those of us who may contribute to The Forum, The Knowledgebase or the New Groups.IO) have to try to look at it from the point of view of someone who can switch a computer on, find the Windows Start button and run a program from its menu entry and nothing more.

There is a confusion of sources of advice and I suspect that to non-computer experts it is impenetrable. I compare this to the way I was guided through starting my latest computer for the first time. A single quick start sheet showing me how to plug it in and switch it on. I switched it on and it told me what to do and set up my Windows 10 environment for me. (OK I then went Linux - but that is my choice!).

I can't remember whether there is a first time "splash screen" for FH; if there isn't one perhaps ① we might suggest it as an enhancement to Calico Pie. The Splash needs to distinguish between first time users and what we might call "reloaders" (for the purpose of this discussion - people reloading onto a new computer or new operating system); probably all that is needed is an exhortation to go to a FirstTime or ReLoader webpage together with the appropriate links. The pages can then be updated without worrying about the stock of installation CDs.

Trying to walk through the process (leaving my computer geek specs off):
At the moment Reloaders have to:

1. discover the FHUG https://www.fhug.org.uk/
2. The top half of the home page offers 5 options
   • The Forum - Got A Question ... You need to register for an account (I can't even frame my question!)
   • Knowledge Base - To check a whole range of How To's (Sounds complex)
   • Downloads ... customisation options (I think I want plain vanilla)
   • Ancestral Sources (What's that, do I need more software, is FH not complete?)
   • And More. . . FHU Mailing list, Wish List ... user requested enhancements (Oh, dear have I bought something that needs enhancing?)
3. If they select the KnowledgeBase, they get to The Knowledgebase home page which points you initially to a whole lot of menus on the left hand side - which are possibly either not-relevant to say "naive reloaders" or not obviously relevant to them.
4. On my Laptop, I have to scroll down ("below the fold") to get to "If you are new to FHUG or to Family Historian, we recommend reviewing Key Features for Newcomers, if you are migrating from another Family History program please see Importing to Family Historian." On my browser "Key Features for Newcomers" is not obviously a link unless I hover over it. I think ② we need to adjust the CSS to make links more obvious. [Edit: 07-02-2020: Shade of blue changed: Thanks!]
5. I cannot see anything of vital use to reloaders!
6. If you get to "Key Features for Newcomers", do reloaders understand the appropriateness of "See Backup and Recovery especially the Backup and Restore Family Historian Settings Plugin for customisations and Windows Registry settings not stored in the Project Structure."

Do ③ we need an early highlighted paragraph on the KnowledgeBase home page saying something like:
If reloading FH on to your computer or on to a new one or a new operating system - please read
and then follow that with the main points of the forum post that you would like to get a £1 for every time you had to say them! It should fit on one screen! [Edit: 07-02-2020: Experimental panel put on home page]

I think the volume of questions on this issue would justify such an approach.

[tatewise]

There is a lot of sense in what you say David, and some you could do by modifying the Knowledge Base pages yourself.
The few of us who update the Knowledge Base do not have enough hours in the day, so be my guest, it is a wiki.

We have recently changed the KB links from orange to the more conventional blue as requested by another user, so they should behave just like any other hyperlinks by becoming underlined and the cursor changing to a pointing hand.

New users who sign up are given the Key Features for Newcomers link and that hopefully comes close to your splash screen idea. Have you looked at Key Features for Newcomers?

One of the things it mentions is the FAQ. Have you ever looked at them, as they answer many of the questions that get repeatedly asked here and in the Mailing Lists.

Helen and I have recently overhauled the Contribute Your Knowledge section, and I have vague plans to overhaul other sections, that have grown like topsy since 2002, so that they become more approachable. You are welcome to join us ~ please!

[davidf]

There is a lot of sense in what you say David, and some you could do by modifying the Knowledge Base pages yourself.
The few of us who update the Knowledge Base do not have enough hours in the day, so be my guest, it is a wiki.

Well I have added a few lines at the top of the home page! (nothing like going for broke!).
We still have an issue as to how easily people find the FHUG Knowledgebase Homepage.
If the pages at the destinations of the links are not appropriate - perhaps they can be edited (rather than bespoke pages created which might duplicate advice) - that reflects the difficulty I had in finding if there was already appropriate advice.

We have recently changed the KB links from orange to the more conventional blue as requested by another user, so they should behave just like any other hyperlinks by becoming underlined and the cursor changing to a pointing hand.

Was that before or after the User Group style sheets were changed? For me a dark blue link against black text is virtually impossible to detect.

New users who sign up are given the Key Features for Newcomers link and that hopefully comes close to your splash screen idea. Have you looked at Key Features for Newcomers?

Ideally I would like the Splash Screen to show on running the install/upgrade programs - some people have great trouble finding things like user group websites.
Yes but I struggled to find the link - ended up using search, and there is a lot of valuable advice on that page. Possibly some editing is required to indicate those things that

• are important for the security/integrity of your data
• are important to understanding the program, and
• you really want to get your mind around before you do too much (and end up having to rework your data)

One of the things it mentions is the FAQ. Have you ever looked at them, as they answer many of the questions that get repeatedly asked here and in the Mailing Lists.

Yes, but I wonder whether it is better to put a specific link to specific FAQs at the end of the page. You get to the end of the page and if you are frustrated because you have followed through all the steps, do you recall that if you scroll back to the top and look in the top left corner you will find a link to all the FAQs? (that is very "systemy thinking"!)

[ColeValleyGirl]

David, you might be interested in the discussion at Contribute Your Knowledge Improvements (16381) which covered a lot of the same ground about how to make the wiki more useful!

[Jane]

David, thanks for helping with the KB. I can change the CSS to bold and underlined, but the previous person was complaining that there was too much bold and underline. See The Knowledge Base (17372). I noticed you have forced bold and underline into the changes you have done, I will leave you all to decide what you want for ALL links. Once decided I can change the CSS. Ideally don't "hard code" the formatting please.

[davidf]

Jane

i think the pendulum has swung back too far (towards discreetness) in the CSS for Links.

If you look at how links appear in say this message with how they now appear in the wiki there is clearly a different level of usability:

FHUG Wiki "showing links"

Screenshot of FHUG Wiki from 2020-02-07 10-03-12.png (22.8 KiB) Viewed 11619 times

I don't have perfect sight, but would argue that the links in the wiki are now verging on the invisible.

This sort of wiki is going to be "link rich" - that is part of the purpose; if you make the links less visible that defeats the purpose!

In my (now initial) post on this topic I was pondering why people are not finding information that is often deep in the wiki and has to be found by following links! Mike was complaining (with some justification) that he was always having to supply the links on this forum - where they show as orange against black text - unlike the wiki (which he is growing infuriated at people not accessing) where it is dark blue against black text.

My (temporary?) hard coding the formatting was partially to make the point and highlight that I think we could benefit from some clear signposting / accessibility of information that is always being asked about in mailing lists and on the forum. (Took a lot of experimenting to do that hard coding!).

I think the wiki needs two formatting changes:

1. More visible links - quite how we reach a consensus I don't know - perhaps I am in a minority - even of one! [Edit: 07-02-2020: Shade of blue changed: Thanks!]
2. (Harder) The ability to put some content in a "standout" format (say a box with a distinct boundary or possibly background shade) to draw readers' attention to it. This must not be over used - and probably won't be because I suspect the wiki does not have this feature - certainly I could not get <span style="background-color: #d3d3d3;"> etc to work - I tried! [Edit: 07-02-2020: contributeyourknowledge:edit_existing_pages#boxes|> Boxes lets you do this!]

[tatewise]

David, presumably you also struggle with Wikipedia and Microsoft that use almost exactly the same style as our wiki?

It is possible to set background colours to text, see contributeyourknowledge:edit_existing_pages#font_colour|> Font Colour.

The style of links on this Forum depend on the User Control Panel > Board Preferences > Style setting.
Some are orange and some are blue depending on user choice.

Jane, might it be possible to mirror the Forum style a user has chosen into the Knowledge Base style?
It is probably out of the question, but thought I would ask anyway. Then each user would probably be happier

Helen has a 'knack' for designing a more intuitively logical sequence to Knowledge Base topics, whereas I focus on the technological implementation techniques to present the information details.
I think our teamwork has made the contributeyourknowledge:index|> Contribute Your Knowledge section much more approachable.
Did you look at that David? What is your feedback? Clearly you did not find the Font Colour advice.

I have been looking at all the miscellaneous advice dotted about the Knowledge Base and pulling it all together into a new main section such as info:index|> FHUG Web Site Usage which also might be a jumping off point for newcomers.
I was planning to ask Helen to apply her 'knack' for designing intuitively logical information to this section.

After that I was contemplating a similar exercise on the how_to:index|> Family Historian section, and the more willing hands, and points of view the better.

BTW: Regarding FAQ, we used to have all the FAQ links at the bottom of each main section, but felt users were never progressing that far to find them. So we moved them to the top to make them more visible, but David prefers them back at the bottom. We could of course do both. There is also the faq:index|> Frequently Asked Questions link in the sidebar.

[davidf]

David, presumably you also struggle with Wikipedia and Microsoft that use almost exactly the same style as our wiki?

Well, it all depends!

I see someone has (today) changed the shade of blue used in the in-text links to be closer to the shade used in Wikipedia and by Microsoft - the effect is to give links a greater contrast to standard text. I think that is an improvement. The links are visible - but not so "in yer face" that the reading flow is significantly interrupted.

Knowledgebase Home page - note change of shade of links in text (to make them more obvious) - the old shade is still used in the side menu.

Knowledgebase Home Page 2020-02-07 13-00-22.png (57.06 KiB) Viewed 11588 times

[davidf]

David,
It is possible to set background colours to text, see contributeyourknowledge:edit_existing_pages#font_colour|> Font Colour.

The style of links on this Forum depend on the User Control Panel > Board Preferences > Style setting.
Some are orange and some are blue depending on user choice.

yes, but try setting the colour of a link in the actual wiki text! (I got in a horrible mess - with the actual code showing in preview). Hence why I ended up only changing the colour of the "New user" bullet point.

[ColeValleyGirl]

I've been mulling over the best way to restructure the KnowledgeBase for a while, and reading up on KnowledgeBase best practice'. I've got some ideas, but they'll be hard to implement with the existing technology... and migration will be a big job (but worth it, I think).

In a nutshell, I think the Landing page should have a prominent search option, and panels for various topics -- something a bit like this: https://www.echoknowledgebase.com/demo- ... ic-layout/ -- it shouldn't be a wall of text but something that people can easily scan to pick out the most likely starting point for what they want to know.

The panels should be ordered so that the most useful ones for newcomers are first in the list (and maybe highlighted in some way): Getting Started with FH, Frequently Asked Questions,...

Other panels could be headlined (not in this order): Install Reinstall and Migrate; Import and Export; Entering Facts; Entering Sources; Working with photos and other media; Navigating the Knowledgebase; Updating the Knowledgebase; Using plugins; developing plugins; etc...

So the landing page is immediately breaking things down into tasks and subtasks.

And there would IMO be nothing wrong in linking to a single subtask from multiple places --- FAQ, Getting Started, whatever -- rather than duplicating information.

Let me think some more about structuring it; I may even play with some software to see what is possible.

[tatewise]

You probably spelt </color> as </colour> which is a mistake I make quite often.
I've changed the colours exactly as per contributeyourknowledge:edit_existing_pages#font_colour|> Font Colour using <color red/yellow> style that not only shades the background yellow, but also makes the underline red, so when you hover on the link the underline becomes blue.

[davidf]

David,
Helen has a 'knack' for designing a more intuitively logical sequence to Knowledge Base topics, whereas I focus on the technological implementation techniques to present the information details.
I think our teamwork has made the contributeyourknowledge:index|> Contribute Your Knowledge section much more approachable.
Did you look at that David? What is your feedback? Clearly you did not find the Font Colour advice.

I can remember when I first started to contribute to the wiki (at the time of the last "To Do List Enhancement Request" discussion) finding it very confusing. I had previously hard coded HTML/XHTML, even once hard coded RTF! I had used Wordpress blogging software and I had used the ZIM personal wiki markup. A little knowledge can be a dangerous thing because stuff does not work the way you expect it to work. So I searched online (www not fhug) for support!

I think there are a number of ways that people approach using software - and all shades in between.

• My mother learnt mechanically; Hold down Ctrl (does not matter which) and press "S" to save; Hold down Ctrl (does not matter which) and press "B" for bold to start emboldening and again to stop. She never made the intuitive link between Ctrl-Control and S-Save, B-Bold etc. And a mouse was just too weird (and with her benign tremor a bit problematic). She only learnt literally what she needed to know and had crib sheets stuck up around her monitor - I don't think she ever "understood" in the way that say Mike "understands". But she managed to write a book and contributed articles to her parish magazine.
• Others just understand what they (think they) need to know and get caught when outside their comfort zone when there are just too many unknown unknowns and framing the question is inhibited by their lack of experience.
• Others are confident to feel their way through using the program and if they get into the same mind warp as the application developers they can find their way through the unexpected - partly because they have an expectation that a facility will be there but also because they can almost intuitively find that facility when they need it. "Often a right click will show you what you want". I think this is where I am (almost) with most applications such as Office Applications (yes), Genealogical Programs (possibly - although I cannot get in the right mind warp for complex expressions), wiki editors (not really but I am confident enough to try and find my way around - making a mess of in[del]ᵮ[/del]ternal links. I have just noticed contributeyourknowledge:edit_existing_pages#boxes|> Boxes! Boxes not "stand outs").
• Others know the program inside out and understand the how and why particular features were developed.

As I said there are then shades in between as people gain confidence/experience or even possibly interest in a program and how it was developed.

I think help should be written for those in the first two "areas" above; the trouble is it is usually written by people in the last two areas!

Writing the technical reference manual is a skill requiring an eye for detail and a structured even pedantic thoroughness. The style is formal and authoritative.

Writing a user manual (and quick start guide, crib sheets, etc.) is a different skill requiring an understanding of work-flows (even informal and "inefficient" ones) and when detail can be safely left out and when it needs to be supplied (possibly as a link). The style is informal and friendly without being patronising.

I think the knowledgebase has tried to be both - and unfortunately failed (as shown by the number or requests for help on things like reinstallation). (Does someone see detailed usage stats? Do people get to say reinstallation advice via a menu option, an in-text link, or via a stab in the dark search?) There have been attempts to unscramble it possibly to address the two different support requirements that I have (maybe simplistically) defined above. However, it is usually unclear whether what you are reading is in the Technical Manual Area or in the User Guide Area.

Might it help to try and develop a basic style guide distinguishing between the needs of say the two audiences I have tried to identify? For instance in a user guide, you want short paragraphs, illustrations (not just for explanation, but also for visual appeal) and understanding of "above and below the fold" and a consistent simple structured navigation. Whilst in a Technical Manual almost everything is subservient to technical accuracy but with access points so readers can jump into the specific areas they need? If people do not feel daunted by the need to write in technical manual style perhaps we might get more contributions to the User Guide pages?

[ColeValleyGirl]

I totally agree about user guide versus technical guide -- and prioritising the user guide aspects. I also wonder if we should distinguish 'best practice guidance' as a third category -- some people want/need to know 'how' without caring about 'why' (or having already made their mind up on 'why') and others might want to discuss 'why' to develop their thinking.

I personally think we should leave matters of opinion either out of the Knowedgebase altogether (and promote the forums as somewhere to come to discuss it) or clearly delineated in their own sections with copious links to external reference material.

Any style guide needs to balance consistency of output versus discouraging input. It may be that we ask people to follow a simple style guide (which we can crib from dozens on the net) but advise them that a more experienced user will 'tidy up' any mistakes if they see them -- get people used to the fact that there's help available to encourage them to contribute.

[davidf]

I totally agree about user guide versus technical guide -- and prioritising the user guide aspects. I also wonder if we should distinguish 'best practice guidance' as a third category -- some people want/need to know 'how' without caring about 'why' (or having already made their mind up on 'why') and others might want to discuss 'why' to develop their thinking.

I think "Best practice guidance" is a useful concept and possibly a third audience/form.

Alternatively is best practice something that might be "insert boxes" in either the user guide or the Technical Manual; the first in the form of "hints"; the second in the form of an explanation as to how fh achieves a particular best practice outcome. If done this way, careful consideration has to be given as to whether an index to "Best practice guidance" is required and how it might be implemented. I don't think our current wiki software can keep some text in one place for editorial purposes, but have it appear in more than one place for different readers. (In old HTML days we would have used Server Side Includes!)

I personally think we should leave matters of opinion either out of the Knowedgebase altogether (and promote the forums as somewhere to come to discuss it) or clearly delineated in their own sections with copious links to external reference material.

Keeping "editorial" separate from "factual content" is I think a good general principle. But sometimes it is difficult to totally leave "opinion" out of say a factual discussion of the two approaches to sourcing!

Any style guide needs to balance consistency of output versus discouraging input. It may be that we ask people to follow a simple style guide (which we can crib from dozens on the net) but advise them that a more experienced user will 'tidy up' any mistakes if they see them -- get people used to the fact that there's help available to encourage them to contribute.

Any style guide should be short and an aid to accessibility rather than a coercive editorial control. Possibly it can be written in the form of "hints for effective wiki content" to get away from the idea of being strict instructions about capitalisation and use of Americanisms!

[ColeValleyGirl]

Except of course we wouldn't call it "hints for effective wiki content" but rather "things to remember when updating the knowledge base" because we want to keep the language simple

[tatewise]

David is correct that we should aim to offer both a User Guide especially for newcomers, and a Technical Reference for those who wish to explore more deeply. Currently, despite various attempts, we probably do neither particularly well.

While talking about 'best practice guidance' I've added a contributeyourknowledge:edit_existing_pages#recommendation|> Font Style > Recommendation that I started to use following the The Knowledge Base (17372) discussion in order the reduce the amount of bold text.

Regarding Helen's ideas for landing page panels, see contributeyourknowledge:edit_existing_pages#table_boxes_combined|> Table & Boxes Combined that I have just constructed and supports hyperlinks as illustrated.

I sometimes wonder whether newcomers (and maybe others) take quite a while to discover the Knowledge Base despite the links on the Forum and Home pages. So maybe some form of landing page panels for the Forum page would be a good idea to highlight the various FHUG resoucres?

Yes this wiki can keep text in one place for editorial purposes and display it in different contexts (just like shared Note records in FH). I can show you some existing examples if you like. See contributeyourknowledge:create_and_manage_pages#shared_page_contents|> Shared Page Contents.

[ColeValleyGirl]

Before we plunge too far into this, I suspect we need to look at our workload over the next few months -- FH7 will hit at some point and soak up time for many users...

[ColeValleyGirl]

Mike, for simple things like font recommendations (when the platform doesn't make them moot) that approach is ok -- but recommending best practice for genealogical research/recording is a million times more complicated -- there are as many opinions as genealogists and we can't represent them all in the knowledgebase.

The table/boxes are the sort of thing I'm thinking about but will be cumbersome unless they're baked into the platform.

And I'm not going to ask Jane at present (FH7 workload) to make major changes to the FHUG website! Let us get the Knowledgebase knocked into better (and more maintainable shape) before we look at new signposts from FHUG.

[tatewise]

Yes, that is why I had not broached the subject of any more restructuring of the Knowledge Base.
I had planned to start in the New Year, but the pending FH V7 has put me off for the moment.

I generally agree with all you say, but not sure what you mean by baked into the platform.

[ColeValleyGirl]

"Baked into the platform" == does not have to be created by hand; you can just say: put a panel of questions here and it appears. I don't know if that's possible in anything Jane would consider using but for example on my website, https://www.colevalleygirl.co.uk/work-in-progress is built by me adding a content page and then telling the platform to include a panel for it automatically on the overview page if it has the right content type/with the right 'tags'.

[davidf]

Before we plunge too far into this, I suspect we need to look at our workload over the next few months -- FH7 will hit at some point and soak up time for many users...

Agreed in one respect!

In another, do we use the intervening months to get the Knowledgebase into "structural shape", so that when FH7 comes along we don't just increase the size and complexity of the rat's nest?

Do we need to think about how we might structure a User Guide for the New Features (based on the teasers that Calico Pie either is or will be putting out) and then populate it as Calico Pie release details and then rapidly iterate as actual user questions start coming in? Might that then form a model for a wider user guide?

(And I hate to say this, but when we start assembling something new, say a "User Guide" and a "Technical Manual", plus/minus "Best Practice Guides", we must resist cutting and pasting between the two "documents" - they are intended to be different in both style and content!)

Do we identify parts of the Knowledge base that are clear "Technical Manual" and plan as to how to update them to allow V6 and V7 users to make continuing sense of them?

[davidf]

Do we want someone (Jane?) to approach Calico Pie and see if they are prepared to build into the FH7 and FH7 upgrade installation programs some form of splash screen which will say direct:

• New users to something like https://www.family-historian.co.uk/NewFH7User.html
• Users migrating from another program to something like https://www.family-historian.co.uk/Welc ... ToFH7.html
• Upgrading users to something like https://www.family-historian.co.uk/Upgr ... &User.html

Then we could work with them to populate those pages with appropriate support and links.

Even better would be to also incorporate the splash into the FH.exe program itself so that it always shows on start - until, you clear the little checkbox! (With a menu option to "Show Welcome Screen")

[LornaCraig]

Can I chip in here with a comment about the (relatively) new index. It's a great enhancement for both old and new users, especailly those who are used to looking things up in a book-style index. However I suspect that even it might sometimes fail to provide a quick route to what someone wants. I've tried to put myself in the position of someone who is familiar with looking things up in an index and has just found FHUG because they want the answer to a specific question.

Take the example of someone who has installed FH on a new computer and now wants to know how to transfer their customisations and database from one computer to another. In that situation they might find the index and look under T for 'Transfer', or perhaps under M for 'Move'. But neither of those are in the index. They probably wouldn't think of looking for 'Migrating' (which is not there either, but if it was they might have found it when looking under M). They might try C for 'customisation' but there is nothing there about transferring customisations. They need to look under I for 'Installation'. But they won't look there because they have already done the installation.

Having failed to find anything promising in the index they will just go to the forums and ask the question there. I can see how it happens.

[ColeValleyGirl]

Davidf, I'm not sure there are intervening months -- at least for people who may be beta testers.

I'd also hate to waste a lot of effort on rewriting the current Knowledgebase if we can start a new one on a better platform -- and any new platform might shape our thinking about how we structure things.

What we might be able to usefully do first is generate the 'style guidance' and some guidelines for what goes into 'user guidance' and 'technical guidance', and maybe knock about some ideas about the top level structure...?

Then when FH7 hits, we might have some idea how to write the new guidance and where is will fit.

[ColeValleyGirl]

Davidf, I would be amazed if FH7 wasn't feature-locked by now!

Lorna, you're right -- you can't find anything in the index unless you happen to know the word it's indexed under!