Re: Org Capture Menu cannot be fully viewed

[TRS-80]

On 2020-12-12 23:57, pietru@caramail.com wrote:
> TRS-80 wrote:
> > If you care to share a slightly bigger picture view, particularly
> > about the structure of the data you are trying to capture (and/or,
> > your workflow) we could likely come up with something that would work
> > much better for you than a capture template, at least in this
> > particular case.
>
> In many instances, previous work would have been done, so people would
> want to quickly skip entries.

I think perhaps plain old Org headline folding might be great for
quickly navigating to the incomplete portion of the document?
Especially if the sections each might contain a lot of prose and/or
notes, and/or the sections are logically organized in any sort of tree
structure.

If it's more about key: value type data, I would (again) recommend Org
Properties.  I'm sure there might be a way (or we could whip one up) to
help automate searching through the document looking for empty
Properties if that's the sort of workflow you would like.

> The plan for Org-Mode Capture is primarily for such Exclusive and
> Unsystematic Surveys where we do not necessarily use standard forms.
> I'm not sure if you capture the drift concerning unsystematic surveys.
> Most times I cannot tell you exactly what people in the field came up
> with.  The pace can be rapid and some could be working in challenging
> conditions.  The plan is for the Crew Chief to make a quick template,
> and which could change each day.  maintain and review notebooks and
> records and overseeing quality control is done daily.  It is customary
> to split the day.  One of the best ways we improve survey efficiency
> is to anticipate bottlenecks and invent creative logistical solutions
> right in the field.
>
> The long template situation then occurs.  You can access better than
> myself as you know what org and org-capture can do and what not.

Overall, what I am imagining is some set of Orgmode files as templates.
Each template containing all requirements of data collection for that
type.  So you would simply make new copy of empty template file for each
new instance of that particular case / template.  Inside would be
headings organizing the different parts of the survey or whatever the
work is.  And then Org Properties as needed for key: value data, located
within the tree structure on headings as appropriate (remembering that
Property inheritance is possible).

You could even use the TODO functionality to mark sections as being
complete.  It then becomes easy to find sections which have not been
finished yet.  With org-log-done and org-log-into-drawer (and other
related) settings you could even have different teams make (timestamped)
metadata notes about what they accomplished, making it easier to hand
off partially completed work between teams and allow them to communicate
between each other in a sort of side channel without that info being
directly in the report.

As you can see, there are often many options, so it's mostly about "what
workflow do you want?"  ;)

> I briefly reported on what we found problematic in practice.  But
> we're at the beginning of this, and would likely report on other
> things as we progress.

Yes, please let us know how you are getting on!

> Nevertheless, we see some aspects where your scheme can be improved to
> cater for more serious work.  Emacs is quite good software.

This is probably the strongest point.  Emacs can be almost whatever you
want it to be.  Even non-programmers (with a little effort) can stitch
together their own custom interfaces using some combination of
package(s), built-in functionality, and perhaps a bit of Elisp.  Which
makes it a bit of a universal User Interface framework, in a way.

> Hope my comments helped somewhat.

Yes, I think so.  Hopefully my replies will therefore heve been equally
helpful to you.

Cheers,
TRS-80