[0/3] Help for GUI

  Add per-page help link to GUI.
The link is extracted from the menu file and added to the menu.
Currently only implemented for 'ipfire' and 'ipfire-rounded' themes.

Tim FitzGeorge (3):
  Help for GUI - ipfire theme code
  Help for GUI - Help links
  Help for GUI - help link style

 config/menu/10-system.menu                    | 11 +++++++
 config/menu/20-status.menu                    | 13 ++++++++
 config/menu/30-network.menu                   | 20 +++++++++--
 config/menu/40-services.menu                  |  6 ++++
 config/menu/50-firewall.menu                  |  8 ++++-
 config/menu/60-ipfire.menu                    |  1 +
 config/menu/70-log.menu                       | 33 ++++++++++++-------
 config/menu/EX-apcupsd.menu                   |  1 +
 config/menu/EX-guardian.menu                  |  1 +
 config/menu/EX-mpfire.menu                    |  1 +
 config/menu/EX-samba.menu                     |  1 +
 config/menu/EX-tor.menu                       |  1 +
 config/menu/EX-wlanap.menu                    |  1 +
 html/html/themes/ipfire/include/css/style.css |  8 +++++
 html/html/themes/ipfire/include/functions.pl  | 19 +++++++++--
 15 files changed, 107 insertions(+), 18 deletions(-)

--
2.26.1
  

Hi Tim,

Thank you very much for submitting these patches.

I am afraid that I must say that I oppose these changes.

This has recently been discussed on the community portal and although I still have not made my mind up entirely, I think this not helpful to anyone:

* We do not have documentation for everything for a start
* There is never this “just read one sentence and you suddenly will be an expert” thing this kind of promotes

Should we not rather link the wiki somewhere in the footer and encourage people to start reading the whole thing from the start before they do something?

What is your rationale to implementing this?

Best,
-Michael

> On 15 May 2020, at 22:39, Tim FitzGeorge <ipfr@tfitzgeorge.me.uk> wrote:
> 
> Add per-page help link to GUI.
> The link is extracted from the menu file and added to the menu.
> Currently only implemented for 'ipfire' and 'ipfire-rounded' themes.
> 
> Tim FitzGeorge (3):
>  Help for GUI - ipfire theme code
>  Help for GUI - Help links
>  Help for GUI - help link style
> 
> config/menu/10-system.menu                    | 11 +++++++
> config/menu/20-status.menu                    | 13 ++++++++
> config/menu/30-network.menu                   | 20 +++++++++--
> config/menu/40-services.menu                  |  6 ++++
> config/menu/50-firewall.menu                  |  8 ++++-
> config/menu/60-ipfire.menu                    |  1 +
> config/menu/70-log.menu                       | 33 ++++++++++++-------
> config/menu/EX-apcupsd.menu                   |  1 +
> config/menu/EX-guardian.menu                  |  1 +
> config/menu/EX-mpfire.menu                    |  1 +
> config/menu/EX-samba.menu                     |  1 +
> config/menu/EX-tor.menu                       |  1 +
> config/menu/EX-wlanap.menu                    |  1 +
> html/html/themes/ipfire/include/css/style.css |  8 +++++
> html/html/themes/ipfire/include/functions.pl  | 19 +++++++++--
> 15 files changed, 107 insertions(+), 18 deletions(-)
> 
> --
> 2.26.1
>
  

Hi Michael,

On 16/05/2020 10:35, Michael Tremer wrote:
> Hi Tim,
>
> Thank you very much for submitting these patches.
>
> I am afraid that I must say that I oppose these changes.
>
> This has recently been discussed on the community portal and although
I still have not made my mind up entirely, I think this not helpful to
anyone:
>
> * We do not have documentation for everything for a start

Actually, it's not too bad.  The only menu items (out of 72) in the core
that I couldn't find help for are:

Status / VPN: Net-to-Net Statistics
Firewall / Firewall Groups
Firewall / Blue Access
Firewall / OpenVPN Roadwarrior connections log

Status / Qos Graphs			*
Status / Modem Status
Status / Atm-status
Network / Network configuration		*
Firewall / UPnP
IPFire / Help				*
Log / Open VPN Log			*

and at least four of those (*) don't appear to exist.  There might well
be pages for some of these which I didn't see when I was adding the links.
There are also four pages which obviously require further work:

Status / Entropy
Status / Connections
Status / MDstat
Network / URL Filter

> * There is never this “just read one sentence and you suddenly will be
an expert” thing this kind of promotes
>
True.  But in the extreme this could be argued to say that IPFire
shouldn't provide any information in the wiki unless it's much more
detailed than the current wiki.  Where do you draw the line?


> Should we not rather link the wiki somewhere in the footer and
encourage people to start reading the whole thing from the start before
they do something?

I think the best place for this is either on the download page or in the
installer, so they get prompted to read the wiki before they start playing.

I suspect putting a link in the footer wouldn't help many people.  If
they can't find the wiki on the website they're probably not going to
find it in the GUI footer.

>
> What is your rationale to implementing this?

I was following the discussion in the community, and several people
seemed to be in favour of the idea. And to quote 'This suggestion has
been made plenty of times. I would be happy to accept patches, but so
far nobody wanted to work on it.'

So I submitted the patches.

I understand that there are two sides to the argument.  Having the wiki
pages linked as help will be beneficial to some people and will just get
other people into a mess quicker when they try to do something they
don't understand - but having a link to the wiki page may help some of
this latter group to realise that they don't understand and need to
learn more.

Which is going to be of most benefit to most people?  I think for me,
having the help links would be preferable, but that's for me, with my
skill set and personality.

Tim

>
> Best,
> -Michael
>
  

Hi,

> On 18 May 2020, at 21:18, Tim FitzGeorge <ipfr@tfitzgeorge.me.uk> wrote:
> 
> Hi Michael,
> 
> On 16/05/2020 10:35, Michael Tremer wrote:
>> Hi Tim,
>> 
>> Thank you very much for submitting these patches.
>> 
>> I am afraid that I must say that I oppose these changes.
>> 
>> This has recently been discussed on the community portal and although
> I still have not made my mind up entirely, I think this not helpful to
> anyone:
>> 
>> * We do not have documentation for everything for a start
> 
> Actually, it's not too bad.  The only menu items (out of 72) in the core
> that I couldn't find help for are:
> 
> Status / VPN: Net-to-Net Statistics
> Firewall / Firewall Groups
> Firewall / Blue Access
> Firewall / OpenVPN Roadwarrior connections log
> 
> Status / Qos Graphs			*
> Status / Modem Status
> Status / Atm-status
> Network / Network configuration		*
> Firewall / UPnP
> IPFire / Help				*
> Log / Open VPN Log			*
> 
> and at least four of those (*) don't appear to exist.  There might well
> be pages for some of these which I didn't see when I was adding the links.
> There are also four pages which obviously require further work:
> 
> Status / Entropy
> Status / Connections
> Status / MDstat
> Network / URL Filter
> 
>> * There is never this “just read one sentence and you suddenly will be
> an expert” thing this kind of promotes
>> 
> True.  But in the extreme this could be argued to say that IPFire
> shouldn't provide any information in the wiki unless it's much more
> detailed than the current wiki.  Where do you draw the line?

Yeah, I suppose I give up this argument.

*Some* documentation is better than nothing and people who generally know what they are doing will probably benefit.

>> Should we not rather link the wiki somewhere in the footer and
> encourage people to start reading the whole thing from the start before
> they do something?
> 
> I think the best place for this is either on the download page or in the
> installer, so they get prompted to read the wiki before they start playing.

I suppose nobody reads the manual before they buy anything.

I also do not want to scare anyone away by claiming that IPFire is “for experts only”. It isn’t.

> 
> I suspect putting a link in the footer wouldn't help many people.  If
> they can't find the wiki on the website they're probably not going to
> find it in the GUI footer.

I still cannot my head around it why this is a problem.

We have search that will find the right page, if you put in the keyword that you will find on top of the page you are currently looking at.

And the wiki has exactly the same hierarchy than the web UI. How can this go wrong?

>> 
>> What is your rationale to implementing this?
> 
> I was following the discussion in the community, and several people
> seemed to be in favour of the idea. And to quote 'This suggestion has
> been made plenty of times. I would be happy to accept patches, but so
> far nobody wanted to work on it.'
> 
> So I submitted the patches.

I appreciate it, but it would have been nice if we could have had the discussion first and come to a conclusion that everyone can live with.

Plenty of people have commented on this. There have been some further threads on the topic - or rather slight spin-offs - and suddenly there was absolute silence. I do not value the opinion of people very much when they only have that to give and are not willing to put any leg work in.

In this case: Everyone wants better documentation, but only one(!) person is actually editing it and improving it gradually. It is absolutely not okay for a group of 10 people to tell that one person what they expect them to do.

Therefore I personally feel that we are quite far away from what we can actually do here.

-Michael

> I understand that there are two sides to the argument.  Having the wiki
> pages linked as help will be beneficial to some people and will just get
> other people into a mess quicker when they try to do something they
> don't understand - but having a link to the wiki page may help some of
> this latter group to realise that they don't understand and need to
> learn more.
> 
> Which is going to be of most benefit to most people?  I think for me,
> having the help links would be preferable, but that's for me, with my
> skill set and personality.
> 
> Tim
> 
>> 
>> Best,
>> -Michael
>> 
>