Re: Adding Org Files to org-agenda-files

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2020-11-29 08:24]:
> * Research
> ** TODO Explore enhancement to HTTP/2 [0/4]
> *** TODO Research HTTP/2
> *** TODO Implement HTTP/2 in feature branch
> *** TODO Test and benchmark HTTP/2
> *** TODO Generate report for board
> ** TODO Migrate from REST to GraphQL API
> *** TODO Research graphql
> *** TODO Plan graphql implementation
> *** TODO Implement new API
> *** TODO Plan migration to production
> **** TODO Merge into master
> **** TODO Update API documentation
> **** TODO Coordinate release with PROD team

Unrelated to the message, the repetitive TODO above after some while
could lose the purpose of alerting the user. By habit user may
indurate to seeing TODO.

One among several definitions of "indurate"

4. inure, harden, indurate -- (cause to accept or become hardened to; 
habituate; "He was inured to the cold")

Then again there is problem that if TODO is forgotten the heading
loses its type of being actionable and more important, user may lose
track of forgotten TODOs.

Enhanced workflow would be that when actionable heading is added that
such cannot be changed easily to non-actionable. That would be something like:

- press key, maybe {C-c t} which would create

** TODO And user writes the heading

But TODO would not be possible to just remove, it would be the TODO
type. User could as usual switch to DONE or similar but the type of
heading would not be editable. One would better invoke some key to
remove the action type. That way Org editing and task creation would
be more rigid and help not in losing some of them.

> All of the tasks have been captured using the same TODO capture
> template. I can easily generate reports on total time spent in
> development, total time spent in development for each main 'feature' or
> time spent in each sub task or sub-sub task etc simply by selecting
> different 'scope' and 'level' settings for the clocktable report.
> 
> In my project org files, I have a heading called '* Clocks', where I
> have all my clock reports. I will have as many different clock reports
> as required. For example, I might have one which clocks the time for all
> tasks in the file with up to 3 levels, then I might have one which only
> clocks the time for tasks in a specific subtree or perhaps one which
> only clocks/summarises times for tasks with a specific tag. It is very
> flexible.

When I read your workflow it is interesting. It also reminds me how
much of those functions are built-in into PostgreSQL database and how
such backend could enhance and speed up things and minimize the
development of features that already exist.

Then heading become something like this:

** Heading
   DEADLINE: <2020-11-23 Mon> SCHEDULED: <2020-11-29 Sun>
   :LOGBOOK:
   CLOCK: [2020-11-30 Mon 10:15]--[2020-11-30 Mon 16:06] =>  5:51
   CLOCK: [2020-11-29 Sun 14:06]--[2020-11-29 Sun 20:06] =>  6:00
   CLOCK: [2020-11-29 Sun 12:06]--[2020-11-29 Sun 12:25] =>  0:19
   CLOCK: [2020-11-29 Sun 11:06]--[2020-11-29 Sun 11:35] =>  0:29
   CLOCK: [2020-11-29 Sun 10:15]--[2020-11-29 Sun 10:30] =>  0:15
   CLOCK: [2020-11-29 Sun 10:06]--[2020-11-29 Sun 10:10] =>  0:04
   :END:
   
And that is where Org defeats itself to be plain simple text. It wants
to be relational database. org-clock.el is great code of 114K and does
probably much more than the above ordering. Yet by using PostgreSQL
and maybe other SQL database in background, the clocking in and
clocking out becomes trivial and reliable:

- DEADLINEs may be entered in the database and their modifications can
  automatically be recorded for later review. Isn't that significant
  piece of information if person modified a deadline? That could be
  dodging of the work. Deadline could be displayed if necessary but it
  could also totally disappear. One only need unique way of
  identifying the heading.

- SCHEDULED the same, if it is changed it is piece of information
  indicating dodging. It should be recorded. Recording change into SQL
  database is trivial, it is normally just one function, 3-4 lines of
  Emacs Lisp.

- CLOCK-IN and CLOCK-OUT becomes also trivial. One database table may
  record all of them. Press key and CLOCK-IN is done. It could be
  displayed in various manners, under heading, or in message buffer or
  in separate info buffer, frame, etc. Total time spent can be easily
  calculated as that is the power of PostgreSQL and other SQL
  databases that may calculate periods of time and add them together.

Finally the above table of CLOCK data does not look human friendly to
me. It is good for advanced users. But even as advanced user I would
not like spending time in interpretation of data that is meant to be
interpreted by computer. I would rather like to be told like:

"Total time spent 12 hours and 58 minutes" and nothing much more.

Org provides this feature:

#+BEGIN: clocktable :scope subtree :maxlevel 2
#+CAPTION: Clock summary at [2020-11-29 Sun 10:17]
| Headline     | Time    |       |
|--------------+---------+-------|
| *Total time* | *12:58* |       |
|--------------+---------+-------|
| \_  Heading  |         | 12:58 |
#+END:

And this is all great, it just does not look to me human friendly. I
rather think of those workflows in simpler manner:

- Create clocked type of task
  
- When person starts working press key, it will be displayed in
  message buffer or by notification. It could be sent by email, SMS,
  chat to people of relevance. It should be without user putting any
  more attention to CLOCK IN than just a key.

  When employer arrives to company building such inserts its ID card
  into the machine for a second and may move on to the work.

  That is how CLOCK IN should be. No attention, no thinking, no funny
  and hackish displaying of dates. Just record.

- When person CLOCKS OUT, that should be just a key. Finished there

Tasks would then give human readable and this would mean readable by
any average English or other language speaker, and not only Org mode
user. Report has to be readable and understandable and users who
create such should not need to handle low level data.

While these does have meaning for Org users, it lacks various
relations to objects shown and for lack of relations and associations
it would give very little meaning to a reader who is not Org user.

** TODO Heading
   DEADLINE: <2020-11-23 Mon> SCHEDULED: <2020-11-29 Sun>
   :LOGBOOK:
   CLOCK: [2020-11-30 Mon 10:15]--[2020-11-30 Mon 16:06] =>  5:51
   CLOCK: [2020-11-29 Sun 14:06]--[2020-11-29 Sun 20:06] =>  6:00
   CLOCK: [2020-11-29 Sun 12:06]--[2020-11-29 Sun 12:25] =>  0:19
   CLOCK: [2020-11-29 Sun 11:06]--[2020-11-29 Sun 11:35] =>  0:29
   CLOCK: [2020-11-29 Sun 10:15]--[2020-11-29 Sun 10:30] =>  0:15
   CLOCK: [2020-11-29 Sun 10:06]--[2020-11-29 Sun 10:10] =>  0:04
   :END:

>From my viewpoint of sending and assigning tasks to other people the
fragile nature of such text files could easily be disturbed by slight
typo. And report like that may be modified at any time by anybody and
I would not even know it any more. Assigner would need to use diff
files to know if the assigned Org task is really trusted and genuine.

If by different method user designats on the mobile phone the CLOCK IN
then this piece of information may enter remote database and by
subsequent CLOCK OUT, that is about all what one does. There
disappears the need for error prone clock tables and pieces of
information that are important but could be tampered at any time.

> I can easily see breakdown of time spent on specific tasks, groups of
> tasks, project tasks, all tasks etc.

That is great. Just that so much time is spent on people editing it
themselves. I can clearly see that Org as how it developed moves
towards structured data. It could be improved in that sense. And one
would not need a separate software database in background, it can be
just Emacs structure or EIEIO object that gets stored somewhere in ~/.emacs.d

When I am using Emacs browser eww and press `w' to copy a bookmark
that is all what I do there. I can yank it. But as user I am not
exposed to underlying process as that I do not need. If I need I could
get report. Or I press `b' for bookmark and anser `y' for yes. That is
all I need to do to *record* some piece of information. Later I can get reports.

Org tries to record everything in properties and displayes information
that makes the Org node less readable for third parties. If I was
measuring clock table for myself, then again I want to know reliably
how much time was actually spent to maybe charge fortime. Not that I
want to know each start and end time. And what if thereare 10 or 30 of
them? One can see that CLOCK function in Org would have so much use of
having it external and that it does not scale really.

With thirty employed people each of them in the field and bushes need
to come to report for a work. Report would need to be quick.

Forget the editing. There shall be list of persons supposed to come to
work. Call the name and clock-in by one key, and person can sign in on
paper without caller attenting. Next.

I know what is necessary there from personal experience as I was using
Org in the field to record people coming to work.

Using Org is slow in that case and cost money. As if I lose 20 minutes
excess time on 30 people that is already good money lost as their time
is paid anyway even if they are waiting during the roll call.

It needs better structured, quicker accessible, highly reliable, and
less disturbing process:

- Click to get list of employees for a roll call
  
- Call person's name, clock in. Person signs on paper in background.

- Talk shortly with person. Click for a note, write and close. No
  moving with arrows up and down, no searching, thinking of
  attributes, dates, etc.

  If it is TODO, click for TODO instead of a note to be recorded. Tell
  person what is to be done. Close buffer.

- Next. New person is called. Repeat all process.

Above is editing of structured objects on a meta level. Those become
Org file. But Org file editing is error prone especially in such
situations where speed is required. Org could benefit of using
database in background for quicker capturing of pieces of information.

My Org file editing for staff member roll call:

- Duplicate previous day heading into new heading for a new date. [1]

  This is redundant with the database backend. I can just open same
  list of employees. There is no need to duplicate headings for a new
  date, as date is tracked by the database.

- Go over the headings, now I need to open each heading to maybe see
  some attributes or get reminded for previous date. I have to use key
  movements pretty much to get to the information. With better
  structured approach it would be one click to see anything.

  ** 2020-11-10 Work day
  *** Employee A
  **** Tasks
  *** Employee B

  ** 2020-11-11 Work day
  *** Employee A
  *** Employee B

- Now call person, clock in for the work.

- Take care to enter new task under new subheading for the the staff
  member.

  It means it creates tasks related to one person but under different
  date. Tasks related to one person get sparse this way. Previous
  heading was indicating the date as it was collecting information by
  date. New heading is for new date. But list of people is same under
  every heading.

  Other way to go would be to make one list of people and then to
  create under each person new date and new clock tables. This way I
  get list of people not to repeat itself every day, but I get dates
  to be repeated and much more headings to make for each date under
  each person's name.

  ** Employees

  *** Employee A
  **** 2020-11-10 Work day
  ***** Tasks
  **** 2020-11-11 Work day

  *** Employee B
  **** 2020-11-10 Work day
  **** 2020-11-11 Work day

  Third solution would be to simply not bother with multiple headings
  but just to clock their work and to get reports of days and
  hours. For 30 days it would look like below.

*** Employee B
    :LOGBOOK:
    CLOCK: [2020-12-09 Wed 08:00]--[2020-12-09 Wed 18:00] => 10:00
    CLOCK: [2020-12-08 Tue 08:00]--[2020-12-08 Tue 18:00] => 10:00
    CLOCK: [2020-12-07 Mon 08:00]--[2020-12-07 Mon 18:00] => 10:00
    CLOCK: [2020-12-06 Sun 08:00]--[2020-12-06 Sun 18:00] => 10:00
    CLOCK: [2020-12-05 Sat 08:00]--[2020-12-05 Sat 18:00] => 10:00
    CLOCK: [2020-12-04 Fri 08:00]--[2020-12-04 Fri 18:00] => 10:00
    CLOCK: [2020-12-03 Thu 08:00]--[2020-12-03 Thu 18:00] => 10:00
    CLOCK: [2020-12-02 Wed 08:00]--[2020-12-02 Wed 18:00] => 10:00
    CLOCK: [2020-12-01 Tue 08:00]--[2020-12-01 Tue 18:00] => 10:00
    CLOCK: [2020-11-30 Mon 08:00]--[2020-11-30 Mon 18:00] => 10:00
    CLOCK: [2020-11-29 Sun 08:00]--[2020-11-29 Sun 18:00] => 10:00
    :END:

Plus the addition of notes and tasks for the employee.

Thus there is no nice integrated solution to that problem of data
getting sparse by using Org file. That is where I have to jump to what
I name meta level. Solution is in following.

1. Employee A
2. Employee B <--------- selected line
3. Employee C

There is no editing of the structure of text any more. 

- If I have finished with employee A, I would call Employee B.

- if employee is not there, his friend may say he is after goats being
  stolen. Press `n' for note, write shortly in a new buffer, close. I
  am not thinking of headlines as headline can be date and time, but
  it need not be displayed for me. I am not thinking of date created
  for the note as it has been automatically recorded.

- if employee is there present, I can press clock in, like `c' and
  tell "go ahead". Employee may sign on paper to be there. Signing and
  talking are different actions so I cannot let people just sign on
  paper. Clock in does not require me to do nothing but `c' and I am
  not disturbed with any kind of hackish and for third parties
  nonsensical CLOCK tables.

- if I need to assign task, I could press `t' write the task, close
  buffer, task is printed automatically and somebody will give it to
  employee.

  But I do not need to think: where to place headline, that I do not
  make some mistake in typing, that I place "TODO". If I pressed `t'
  that is TODO, and type of the node is TODO, finished there.

No thinking of editing, arrows, directions, attributes, properties,
etc. Database does that and my decision is summarized by one key.

If I need to see tasks not done for employee I press other key and see
them together with notes. But no need to browse for it, scroll down,
up, etc until I can see it as nodes are anyway collapsed and pretty
large list is visible at once. There is no error prone editing.

When I am working on a person, I am also using speech output by using
`festival'. This makes it easier for people around me to jump in if
there is some correction necessary. In 30 days or 60 days of work I
can be good typer and editor, but the attention when doing such roll
call asks for many things, like looking outside of the office,
inviting employees to sit down, talking with them, inviting other
people. Cursor can move from one place or one employee's heading to
other and I may skip it. In other words it asks for too much of human
attention to get things done without errors. In 30 days there are few
errors that I discover later.

If the highlighted line is on this selected line and on any action
related to this person the action is actually spoken. If I choose
task, it is spoken as "Task for Joe Doe". Instead of moving cursors to
right place, then editing headline, assigning task to person, new
buffer is opened and task is assigned automatically to the relevant
person, headline is assigned from the date.

1. Employee A
2. Employee B <--------- selected line
3. Employee C
   
There is no duplicated headline in front of me and no duplicated
headline that means "DATE" in front of me, as such dates are in the
database. But I am not watching them neither need to put attention on
them. I like to put attention on the design of the process one time
and then use the process many times in future without thinking any
more of all the typing.

Calculating periods with PostgreSQL is trivial:

SELECT timestamp '2001-09-28 19:00' - timestamp '2001-09-28 08:00';
 ?column? 
----------
 11:00:00

Data like CLOCK table with timestamps can be all together in one table
with relation for each entry to specific task.

All the CLOCK IN and CLOCK OUT results related to specific task can be
selected and simple sum() function used:

SELECT sum((timestamp '2001-09-28 19:00' - timestamp '2001-09-28 08:00') + 
(timestamp '2001-09-29 19:00' - timestamp '2001-09-29 08:00'));

10000 rows or 20000 rows coul be as well selected without visible
delay. It means that for a single task accounted with CLOCK
information the selection is very fast.

By using ::interval on the end, one can get more meaningful information:

admin=# SELECT sum((timestamp '2001-10-21 19:00' - timestamp '2001-09-28 
08:00') + (timestamp '2001-09-29 19:00' - timestamp '2001-09-29 
08:00'))::interval;
       sum        
------------------
 23 days 22:00:00

By using Emacs skeleton as this one: http://ix.io/2FTd one may create
the SQL table quite quickly.

I would first define types:

CREATE TABLE timestamptypes (
timestamptypes_id SERIAL NOT NULL PRIMARY KEY,
timestamptypes_name TEXT NOT NULL,
timestamptypes_description TEXT
);

As types can tell for example if it is:

- SCHEDULED
- DEADLINE
- CLOCK-IN
- CLOCK-OUT

rcdbusiness=# INSERT INTO timestamptypes (timestamptypes_name) VALUES 
('SCHEDULED');
INSERT 0 1
rcdbusiness=# INSERT INTO timestamptypes (timestamptypes_name) VALUES 
('DEADLINE');
INSERT 0 1
rcdbusiness=# INSERT INTO timestamptypes (timestamptypes_name) VALUES 
('CLOCK-IN');
INSERT 0 1
rcdbusiness=# INSERT INTO timestamptypes (timestamptypes_name) VALUES 
('CLOCK-OUT');
INSERT 0 1

and what else one may need. New timestamp types can be added as one
wish and want. But there is no need to add them per Org file. Adding
one time in central database is fine. I may need to give types such as
NO-SCHEDULED or NO-DEADLINE to keep the previous SCHEDULED still
recorded in the database. If I do not want to calculate
CLOCK-IN/CLOCK-OUT, but I still wish to keep track of it, maybe I wish
to add "NO-CLOCK" type. 

One can make better comments on the table and columns:

COMMENT ON TABLE timestamptypes IS 'Time Stamp Types';
COMMENT ON COLUMN timestamptypes.timestamptypes_id IS 'ID';
COMMENT ON COLUMN timestamptypes.timestamptypes_name IS 'Name';
COMMENT ON COLUMN timestamptypes.timestamptypes_description IS 'Description';

Then in the next step I define the `timestamps' table:

CREATE TABLE timestamps (
timestamps_id SERIAL NOT NULL PRIMARY KEY,
timestamps_datecreated TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
timestamps_datemodified TIMESTAMP,
timestamps_usercreated TEXT NOT NULL DEFAULT current_user,
timestamps_usermodified TEXT NOT NULL DEFAULT current_user,
timestamps_timestamp TIMESTAMP WITH TIME ZONE NOT NULL,
timestamps_timestampstypes INT4 REFERENCES timestamptypes NOT NULL,
timestamps_tasks INT4 REFERENCES tasks,
timestamps_adminscaletasks INT4 REFERENCES adminscaletasks,
timestamps_hlinks INT4 REFERENCES hlinks,
timestamps_description TEXT
);
GRANT ALL ON timestamps TO PUBLIC;

Using skeleton that definition becomes trivial.

Some comments:

COMMENT ON TABLE timestamps IS 'Timestamps';
COMMENT ON COLUMN timestamps.timestamps_id IS 'ID';
COMMENT ON COLUMN timestamps.timestamps_datecreated IS 'Date created';
COMMENT ON COLUMN timestamps.timestamps_datemodified IS 'Date modified';
COMMENT ON COLUMN timestamps.timestamps_usercreated IS 'User created';
COMMENT ON COLUMN timestamps.timestamps_usermodified IS 'User modified';
COMMENT ON COLUMN timestamps.timestamps_timestamp IS 'Timestamp';
COMMENT ON COLUMN timestamps.timestamps_timestampstypes IS 'Type';
COMMENT ON COLUMN timestamps.timestamps_description IS 'Description';
COMMENT ON COLUMN timestamps.timestamps_tasks IS 'Task';
COMMENT ON COLUMN timestamps.timestamps_adminscaletasks IS 'Admin Scale Task';
COMMENT ON COLUMN timestamps.timestamps_hlinks IS 'Hyperdocument Task';

And some trigger to know which user edited the timestamp and when:

-- Triggers
-- For Date Modified
CREATE TRIGGER timestamps_moddatetime
BEFORE UPDATE ON timestamps
FOR EACH ROW
EXECUTE PROCEDURE moddatetime(timestamps_datemodified);

-- For User Modified
CREATE TRIGGER insert_username_timestamps
BEFORE INSERT OR UPDATE ON timestamps
FOR EACH ROW
EXECUTE PROCEDURE insert_username(timestamps_usermodified);

After that definition once and now for next decades, I have forgotten
about timestamps and need not necessarily know how they look like. I
can press "i" for CLOCK-IN and if I am located in the object "Task"
with the ID number 3 computer will assign it correctly and record my
CLOCK-IN with underlying SQL:

Example:

INSERT INTO timestamps (timestamps_timestamp, timestamps_timestampstypes, 
timestamps_tasks) VALUES (current_timestamp, 3, 5);
INSERT 0 1

It inserted the timestamp for the task with the ID number 5, with the
type being ID numbe 3 or 'CLOCK-IN'. It selected `current_timestamp'
automatically. If necessary user could edit it in the same way how it
is edited in Org mode.

Table may be seen as:

SELECT * FROM timestamps;
-[ RECORD 1 ]--------------+------------------------------
timestamps_id              | 2
timestamps_datecreated     | 2020-11-29 09:55:52.715337
timestamps_datemodified    | 
timestamps_usercreated     | username
timestamps_usermodified    | username
timestamps_timestamp       | 2020-11-29 09:55:52.715337+01
timestamps_timestampstypes | 3
timestamps_tasks           | 5
timestamps_adminscaletasks | 
timestamps_hlinks          | 
timestamps_description     | 

If the entry is modified, the version information goes to version
control table. One can even know when was some entry modified and by
which user at what time. If description is modified it looks as:

SELECT * FROM timestamps;
-[ RECORD 1 
]--------------+--------------------------------------------------------
timestamps_id              | 2
timestamps_datecreated     | 2020-11-29 09:55:52.715337
timestamps_datemodified    | 2020-11-29 09:59:13.294634
timestamps_usercreated     | maddox
timestamps_usermodified    | maddox
timestamps_timestamp       | 2020-11-29 09:55:52.715337+01
timestamps_timestampstypes | 3
timestamps_tasks           | 5
timestamps_adminscaletasks | 
timestamps_hlinks          | 
timestamps_description     | That was clock-in as he finally arrived from 
Melbourne.

On my side I have various types of tasks:

- tasks, can be anything and related to anything
  
- adminscaletasks, for project planning, belong to project headings only
  
- hyperdocument tasks, more powerful than the above, as these can be
  of any type. Need not be text, and it can be action required
  (TODO). It can point to any database table, Org, Org heading, media
  files, any files, paper references, any PDF, annotation, task, note,
  just anything and are related to each other and related to other objects.

When those are excluded the above concept of tracking timestamps can
be simplified.

I am well aware that database handling of timestamps is not Org method
of handling timestamps. But it may become in future. And when I refer
to "database" I do not necessarily mean PostgreSQL database. It could
be LISP data, EIEIO objects, or any type of centralized structure
record.

By using this approach as database like PostgreSQL has so many good
built-in functions for date and time, efforts become lesser and
various reports and features become possible with a function of 3-4
lines:

- How long time was spent on each task. No need for parsing the
  table. I do not know how org-clock.el does it but I have looked
  inside and it looks hackish to parse the clock table.

- Which person have worked more or less, as tasks are usually related to people

- reliable multi user environment is automatically
  accessible. Multiple users could work on same tasks and CLOCK-IN,
  CLOCK-OUT. It becomes possible to track work of multiple people on
  one task. As that is how reality is, not one person is working on
  the task and not all people CLOCK-IN and CLOCK-OUT in the same time.

  But there is nothing to think about this, it is
  automatic. Concurrency is supported.

- collaborative text editing such as
  https://code.librehq.com/qhong/crdt.el.git may help users of a
  groupware to edit simultaneously tasks or notes.

- inner or underlying calculations need no special hacks. Database has
  many built-in handy functions for dates and times.

- no need any more to think of scalability and injecting clock table
  in front of people's eyes. While they can be hidden, they can be
  also ruined. It is important, valuable, structured information that
  should not be freely editable.

- tracking of who and when changed the DEADLINE or SCHEDULED date to a
  later date is automatically included.

User of a system is then left to do only:

- press key to clock-in, nothing need be visible, but can be opened to
  be visible by other key.

  Sending heading with its body to other user need not reveal its meta
  data. Heading remains empty. It becomes quite trivial to implement
  it for the present Org files. The only identificator should be the
  ID number that could be a tag. Identificator could be also the
  Heading but that is ambiguous, nevertheless could be heading in
  specific file to make things more simpler.

- press key to clock-out

- assign SCHEDULED/DEADLINE or other timestamps as needed.

- by press of a key, it can be all visible or it can all disappear
  completely. Meta data remains this way very stable in the database.

- all the reports become more human friendly.

And people like me can skip all the typing and too many complicated
keybindings and just use `t' for task related to person selected on
screen, `n' for note related to person selected, `i' to clock in, `o'
to clock out or `u' to undo. 
 
> All my tasks have basically the same format and are captured using
> the same capture template. when a clocktable report includes
> multiple files, there is a column which tells you which file the
> task is in (if you want it). The clocktable can use a single file,
> all files in your agenda, a list of files you specify, a subtree
> within a file etc.

Great work has been done and efforts that moved Org mode from plain
text editing into management of structured pieces of information. 

> When I was forced to generate gant charts etc, I actually used task
> juggler. There is a contrib library for it to make it work with org
> files. It is a bit dated now and probably needs to be
> 'refreshed'. There were a couple of irritating limitations which
> needed some hand tweaking of the generated task juggler files, but
> it worked pretty well.

I guess not many people are using gaant chart then. It was not usable
for me. I am not counting time, I am counting values. Values are then
automatically displayed on SVG/PNG/JPG files as statistics.

How many bread was baken in a week?

What quantity of minerals excavated?

Wheel barrows transported in a day? Day by day it makes the weekly
statistic, which makes monthly statistics.

By comparison one may find who is doing better and who is dodging.

Time without relation to some value to human is not of any use.

Jean