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: [email protected]
web: https://equinoxInitiative.org
direct: +1 770-709-5581
cell: +1 404-984-4366
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
