From: Jon Murphy <jcmurphy26@gmail.com>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/3] Help for GUI
Date: Tue, 09 Jun 2020 19:05:50 -0500 [thread overview]
Message-ID: <6050ABAD-F0DC-4D5C-81EA-5639333B596E@gmail.com> (raw)
In-Reply-To: <mailman.125.1590157028.797.development@lists.ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 8714 bytes --]
Where did this end up? Is it OK to move forward?
I don't mind creating wiki pages for the missing items if someone can point out what needs to be created.
Jon
>
> Message: 1
> Date: Fri, 22 May 2020 14:19:48 +0100
> From: Michael Tremer <michael.tremer(a)ipfire.org>
> To: Jonatan Schlag <jonatan.schlag(a)ipfire.org>
> Cc: Jon Murphy <jcmurphy26(a)gmail.com>, "IPFire: Development-List"
> <development(a)lists.ipfire.org>
> Subject: Re: [PATCH 0/3] Help for GUI
> Message-ID: <B1130640-0C7D-4CCF-9F32-34751B90E8B3(a)ipfire.org>
> Content-Type: text/plain; charset=utf-8
>
> Hey,
>
>> On 21 May 2020, at 19:51, Jonatan Schlag <jonatan.schlag(a)ipfire.org> wrote:
>>
>> Hi,
>>
>>
>> 16.05.2020, 11:28 -0500 Jon Murphy:
>>> My opinion: This encourages people to look at the wiki and gets them
>>> pointed in the right direction. This is much better than a new user
>>> firing off a quick question to the Community. Most anything that is
>>> encourages people to get interested in IPFire is a good thing.
>>
>>
>> I do not know if it will encourage people, but if a person wants to
>> learn to find the starting point for a certain topic, is much easier.
>>
>>
>>
>>>
>>> There are very few people that will read the whole wiki from the
>>> start (not sure how many wiki pages?). Especially reading something
>>> that is technically difficult.
>>
>> I think nobody requests or requested that everybody have to read the
>> full wiki. From my experiences, it is just better to read and learn
>> before doing things. Try and error is also ok, but then nobody should
>> expecting that somebody helps, when they get into trouble. There is
>> also a learning effect in finding the solutions on yourself.
>
> I suggested that. People cannot start somewhere in the middle.
>
> You will have to learn how to set up a network somewhere from the start. Ironing out mistakes is getting more difficult the larger it grows. Plenty of companies therefore struggle with their technological debt.
>
> I am not suggesting that reading our wiki will prevent you from making those mistakes, but it is at least a place where you will learn how to avoid making some of them. And that won?t fit into only a single paragraph.
>
>> I also see your point that people might not read stuff that is
>> technically
>> difficult or hard to understand, but sometimes there is no way to avoid
>> this. Learning new things can be hard and sometimes you have to read.
>> Even links to the right wiki page will change nothing concerning the
>> need that some people have to read a lot. The only thing that gets
>> improved is that people have not to find the right place to start. They
>> will have to read not more and not less.
>>
>>>
>>> I?ll use myself as an example. Right now I am trying to learn a
>>> little about SIP and Asterisks and FreePBX. I tried reading various
>>> pages of Asterisks (or FreePBX) and it is over my head. So I try a
>>> few things on my Asterisks box, watch a video, read a little, try
>>> some thing than rinse & repeat. (And Yes I realize asterisks is not
>>> the same as IPFire).
>
> This is a completely different thing though.
>
> I sometimes bake things. Literally nothing can go wrong there. It is not dangerous, it won?t cost me a fortune when I lose customer data (as a company) and so on.
>
> Security is so invisible and so difficult to understand for many and that is what makes the difference for me.
>
>>>
>>> I did the same with IPFire (and IPCop) many years ago. It works very
>>> well for me.
>>>
>>> Anything that makes it super easy to find a way to the wiki is a good
>>> thing!
>>>
>>>
>>>
>>>> From: Jon Murphy
>>>> Sent: Saturday, May 16, 2020, 11:10 AM
>>>> To: development-request(a)lists.ipfire.org,
>>>> development(a)lists.ipfire.org
>>>> Subject: Re: [PATCH 0/3] Help for GUI
>>>>
>>>>
>>>> Oops? maybe my bad?
>>>>
>>>>
>>>>> ------------------------------
>>>>>
>>>>> Message: 3
>>>>> Date: Sat, 16 May 2020 10:35:00 +0100
>>>>> From: Michael Tremer <michael.tremer(a)ipfire.org>
>>>>> To: Tim FitzGeorge <ipfr(a)tfitzgeorge.me.uk>
>>>>> Cc: development(a)lists.ipfire.org
>>>>> Subject: Re: [PATCH 0/3] Help for GUI
>>>>> Message-ID: <6390F8AE-998D-489E-A983-1A875E2761F2(a)ipfire.org>
>>>>> Content-Type: text/plain; charset=utf-8
>>>>>
>>>>> 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
>>
>>
>> So a few pages are missing, but from my point of view, it is better to
>> have a context-sensitive help for 90% of the pages as for 0%.
>>
>>>>> * 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?
>>
>> I do not think that this promotes this. Maybe, but theses people then
>> did not understand how things are working. Like written above, the need
>> to read and also the amount people have to read will not change. When
>> they do not understand this, I currently have no idea how to solve this
>> issue.
>>
>> The real improvement I see here is, that people find the right entry
>> point to the wiki. They're also people who have a lot of knowledge and
>> for them, a link to the corresponding wiki site is a usability
>> improvement. Context-Sensitive Help is a nice feature for all people
>> who know how to use it. People who know, when they did not understand
>> the page where they were redirected, that they have to read more. Or
>> that they have to understand more of the context/technologie/ whatever.
>>
>> So to sum up what I try to explain:
>> We should accept features which improving the usability for a lot of
>> people. We should not drop these features because some people have a
>> way to learn which does not work. We will not change these people,
>> whatever we will do. So I vote to accept this improvement, but I still
>> have some questions left.
>>
>> @Tim could you send a Screenshot how this will look? I cannot imagine
>> such things from code
>>
>> @Michael:
>> I also like the Idea that the wiki is linked in the footer.
>> The guys at nextcloud have something like this:
>>
>> https://user-images.githubusercontent.com/5169868/58201395-fa749000-7ca2-11e9-96de-e0e2dbcb8836.png
>>
>> Maybe we could create a website similar and pointing the users to right
>> directions in the web interface itself?
>
> Yes, we could do something like this.
>
> -Michael
>
>>
>> Greetings Jonatan
>>
>>>>>
>>>>> What is your rationale to implementing this?
>>>>>
>>>>> Best,
>>>>> -Michael
>>>>>
>>>>>> On 15 May 2020, at 22:39, Tim FitzGeorge <
>>>>>> ipfr(a)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
>
>
>
next parent reply other threads:[~2020-06-10 0:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.125.1590157028.797.development@lists.ipfire.org>
2020-06-10 0:05 ` Jon Murphy [this message]
[not found] <851be8bf-9193-3c8a-1802-94a54b70909f@tfitzgeorge.me.uk>
2020-05-22 13:22 ` Michael Tremer
[not found] <04413F0C-96CD-4213-AC55-8012E649FB64@gmail.com>
2020-05-21 18:51 ` Jonatan Schlag
2020-05-22 13:19 ` Michael Tremer
[not found] <F683B9F1-464A-44C5-9E5B-13F91CAEE77F@gmail.com>
2020-05-19 20:45 ` Tim FitzGeorge
[not found] <mailman.1.1589630401.3663.development@lists.ipfire.org>
2020-05-16 16:10 ` Jon Murphy
2020-05-15 21:39 Tim FitzGeorge
2020-05-16 9:35 ` Michael Tremer
2020-05-18 20:18 ` Tim FitzGeorge
2020-05-22 13:07 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6050ABAD-F0DC-4D5C-81EA-5639333B596E@gmail.com \
--to=jcmurphy26@gmail.com \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox