[Evergreen-dev] Ship Evergreen with a prebuilt manual?

[Blake Henderson]

Galen,

I was thinking along those same lines: give our users (library staff) 
documentation references for each staff UI - making it eas(ier) for 
folks to resolve questions they may have about the Evergreen staff 
client. I think this would be a boon to the Evergreen project as a whole 
and might* make users morph into DIG members!

This statement couldn't be more true: "Any project is only as good as 
it's documentation."

I believe you mentioned that Koha does this? Where there is a 
"consortium" level document for any given interface, and it can be 
overridden all the way down the org tree?

So - I am for* the general idea. Exactly how* might require everyone's 
input.

-Blake-
Conducting Magic
Can consume data in any format
MOBIUS

On 9/8/2020 11:27 AM, Galen Charlton wrote:
> Hi,
>
> To propose an idea for discussion, the Antora work gives us an 
> opportunity for us to (re)consider shipping a pre-built Antora site 
> with each release of Evergreen. Pre-built documentation could be made 
> available via (say) https://the.evergreen.server/docs/.
>
> Some pros I see are:
>
> * This would make it possible for the manual to be completely 
> self-contained.
> * Being able to count on /docs/ being available could inspire the 
> creation of more context-sensitive help.
> * /docs/ could more easily remain in sync with the version of 
> Evergreen that's currently installed.
> * Sites that wish to customize their documentation but are not writing 
> it from scratch (or rewriting it wholesale) would be able to do so. 
> Admittedly, that was already possible, but having more of the 
> documentation site-building scripts in Evergreen itself makes a 
> difference.
>
> Some cons include:
>
> * This would add about 45M to the uncompressed size of the Evergreen 
> tarball. Not huge, but not nothing.
> * Managing customized documentation that's built into an Antora site 
> would have a learning curve.
> * Built-in documentation could make certain features that consortium 
> administrators have intentionally turned off a bit more visible than 
> may be desired.
>
> If we do this, I imagine we'd need at least library settings to 
> control whether built-in documentation or externally-managed 
> documentation is linked to from the staff interface. I could also 
> imagine wanting to make access to /docs/ controlled by a staff permission.
>
> Thoughts? I should note that I'm _not_ proposing that we try to do 
> this for 3.6.0.
>
> Regards,
>
> Galen
> -- 
> Galen Charlton
> Implementation and Services Manager
> Equinox Open Library Initiative
> phone:  1-877-OPEN-ILS (673-6457)
> email:  gmc at equinoxInitiative.org
> web: https://equinoxInitiative.org
> direct: +1 770-709-5581
> cell:   +1 404-984-4366
>
> _______________________________________________
> Evergreen-dev mailing list
> Evergreen-dev at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20200908/36327477/attachment.html>