I wonder exactly how SC links appear. There are so many buddhist forums on facebook, and such a wide variety of people interested in ‘buddhism’.
My initial thoughts were that the large number of visits from FB were just the result of vaguely interested people clicking on links - and that they were not really interested in the objectives of SC. As such one would expect a much smaller percentage of retention among this group. More or less ‘random’ clickers or tourists just having a look
So if you really want to ‘capture’ their interest and involve them in sutta study it would require some serious efforts to be expended. Personally, I’m more interested in existing Buddhist communities, that already expend a lot of effort following the teachings of the Buddha, getting access to accurate teachings via the EBT’s
So I’d say the goal with the FB cohort is to introduce them to Buddhism at a more serious level, as compared with providing accurate information to Buddhist practitioners.
Of course both are laudable, but may require different approaches - just some thoughts…
Added:
It would be interesting to have a look at what page they landed on, as you suggest. One of the issues that keeps coming up is the difficult of navigation and search in SC. This is certainly an obstacle of increasing difficulty, the less familiar one is with the material. So this may well have a significant impact on usage and retention of inexperienced users.
I’ve often joked that the best way to hide something is to put it on the internet. But seriously, Google does a fantastic job of search. And if we examine how Google search is implemented, we see vast amounts of special code for special cases. There is no “magic algorithm”.
What special case should we code for SC search?
Well. If we only search the segmented documents, an amazingly coherent picture emerges. Example: “desire is the root of suffering”
1. SuttaCentral search:
8489 results for desire is the root of suffering
2. Segmented search returns exactly the following:
sn42.11:2.11: For desire is the root of suffering.
sn42.11:2.13: For desire is the root of suffering.’”
sn42.11:2.17: For desire is the root of suffering.’
sn42.11:3.6: For desire is the root of suffering.’
sn42.11:5.6: For desire is the root of suffering.’”
To improve SC search, we’d need to understand what users expect, and what special cases need special code. Segmented search is a possibility but only the solution for one small special case. I wonder what the other cases are and what all those viewers are expecting…
At the moment my impression is that the more familiar someone is with the suttas, the easier it is to search. They can search by exact phrase, by nikaya, by reference number etc. All this involves knowing 1)how the tripitika and vinaya are organised 2) familiarity with the content 3) access to references for the suttas one wants in the correct format.
Now say that one doesn’t know any of these things - the way forward is to start at the beginning and read.
It would be good to pin the reading guides right to the centre front of the home page… or other central page - perhaps even to the drop down main menu of suttas, vinaya, abhidhama.
Then anyone without any expertise can use those to guide their way through… even have little linked collections.
But if we’re talking about increasing retention of those who are casual visitors, then ‘interesting’ and accessible things need to be served up on a plate, for initial engagement to take place.
When we were discussing the adoption of a plug-in for a different function it was pointed out that D&D needs an update (actually I think it is now 3 updates behind) and that we need to get on with the update before adding new plug-ins.
Unfortunately it is much more than 3 updates behind, it is almost a year
D&D is currently running on 2.3.0.beta5, which was released in March this year, and the latest version 2.4.0.beta9 was just released today.
Being so far behind represents a higher security risk (Discourse team is super quick in fixing bugs and possible security exploits), not to mention we’re missing on all the cool new features which were developed in the meantime.
Recommended regimen for updating Discourse is roughly:
twice a month (from the web admin, no downtime)
every two months (from console, full rebuild, requires downtime unless Discourse is configured with multiple containers)
twice a year (update/upgrade underlying OS, with automatic security updates enabled)
adding or removing plugins requires rebuild from the console, which automatically updates to latest release
test/staging site is recommended for sites with non-official plugins and/or specific customizations or when upgrading from very old versions, and having daily backups goes without saying
Detailed explanation is available here:
One thing I have learnt in my past existence as a systems engineer is that having clear and well documented procedures is of enormous benefit in the long run.
Only then can one even start thinking to share some of the administrative burden and delegate tasks to less experienced users when need arises (which inevitably happens over time to all sysadmins, because there is never less things to do, only more, even if one is incredibly skilled at keeping it all together).
I have been running a small private Discourse site for well over a year now and have hands-on experience with the day to day administration, so if I can be of any assistance please don’t hesitate to ask.
very nice 
- so it’s all on the back-burner for me till next year 
But I look forward to it then 
