![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
A typical assignment in my new setup (which I previously neglected to mention is not monochrome, but color-coded) looks like this on my screen:
Back when I started translating full-time, almost 20 years ago, I created a state-of-the-art assignment checklist that attempted to address all of the variables associated with a job. Some of those variables—who sent it, how much they were going to pay—were important; others—the method by which a job arrived (e.g., mail, courier, electronic file)—were not. After carefully crafting my list, and after using it for a couple of weeks, I found I was routinely ignoring about half the entries.
Lesson: Focus on essentials.
Corollary: Start with a minimum number of essentials. Add incrementally, as required. Pretend you're editing source code.
So aside from who sent me the job and what was sent for me to work on, what's essential?
Other stuff that needs to be kept track of with regard to a given document is stored in notes for the document. If a note requires some action on my part, I can create a check box for it.
What do properties do for me? Well, a triplet of key chords (C-c C-x C-c, in emacs-speak) transforms my screen into a table, like this:
Cheers...
* TODO 121226 ABC 12321 (XYZ Attachment)...The three dots at the end of the line tell me there is more to be seen for this TODO. If I fully expand it, I may see something like this:
* TODO 121226 ABC 12321 (XYZ Attachment)Some observations:
DEADLINE: <2012-12-28 17:00>
:PROPERTIES:
:KEYWORDS: shareholder meeting
:END-CLIENT: Acme, Inc.
:END:
* DONE cover email
:PROPERTIES:
:JOB: TR
:QTY: 233
:END:
- [X] requires OCR
* IN WORK XYZ Attachment
:PROPERTIES:
:JOB: TR
:QTY:
:END:
- [X] tell ABC right edge of p. 3 is cut off
- est. SWC is 2000
* TODO Attachment annex
<SCHEDULED 2012-12-28 09:00>
:PROPERTIES:
:JOB: ED
:QTY:
:END:
- do last, ABC is confirming latest version
- link to previous version
Back when I started translating full-time, almost 20 years ago, I created a state-of-the-art assignment checklist that attempted to address all of the variables associated with a job. Some of those variables—who sent it, how much they were going to pay—were important; others—the method by which a job arrived (e.g., mail, courier, electronic file)—were not. After carefully crafting my list, and after using it for a couple of weeks, I found I was routinely ignoring about half the entries.
Lesson: Focus on essentials.
Corollary: Start with a minimum number of essentials. Add incrementally, as required. Pretend you're editing source code.
So aside from who sent me the job and what was sent for me to work on, what's essential?
(a) what do they want done?There may some other items that are important, but these two are essential to a document. And so, my choice of properties for each document must reflect this, with a JOB property and a QTY property. I can add others later, or individually (using an org-mode key binding).
(b) what quantity shall I bill?
Other stuff that needs to be kept track of with regard to a given document is stored in notes for the document. If a note requires some action on my part, I can create a check box for it.
What do properties do for me? Well, a triplet of key chords (C-c C-x C-c, in emacs-speak) transforms my screen into a table, like this:
ITEM |JOB| QTYThe first time I tried this after reading about it in the org-mode manual, my eyes almost popped out of my head! It's not quite everything I need, but the tabular format goes a long way to making the job of invoicing that much easier!
121201 DEF rg-236 (phone logs)| |
October 2012 log | TR| 1023
November 2012 log | TR| 556
December 2012 log | TR| 976
Cheers...
I had been moving along with org-mode pretty much on autopilot, especially since things have been working well ever since I started using emacs and org-mode to keep track of jobs and invoice related data.
With my move away from the proprietary Invoice Manager software to the open source BambooImage code, I began to seriously think about what kind of effort would be required to create an org-mode environment in which I could execute some function that would automagically extract billing data from my org-mode files and stuff it into a MySQL database, so that I could use BambooInvoice to tweak the result and publish/print/send the final invoice. Or at least make the process simpler.
But before dealing with that, I had to deal with my use of a "note" for each document that was part of a job instead of a "todo," as it was becoming altogether too cumbersome to keep track of data this way.
Some background:
I first began using the "note" format in org-mode because a note can contain a check box, which enables tracking of progress in an assignment (i.e., in a todo). For example:
The deadline is self-explanatory. It will show up in my "agenda" for the upcoming week, which I routinely generate every morning.
The "properties" are key–value pairs. I use these for each assignment to identify keywords, end clients, and anything else that comes to mind.
While all of this may look complex, the only part that requires keyboard input in org-mode is shown in bold, above. Everything else is generated using keyboard macros bound to keystrokes, one of which actually cycles through just how much of all this information is actually displayed, keeping the rest out of sight. Typically, my screen will show only one assignment expanded; the rest reduced down to a single line.
What I had noticed, over this past year, is I never looked the progress string at all (except, perhaps, to verify that the "numerator" incremented when the status of a document was checked off), and so, I was not getting any benefit from using check boxes. Indeed, by not making each document a "sub" TODO item, I was depriving myself of the ability to use org-mode properties for each document.
And once I started creating a TODO for each document and storing billing data in properties, I stumbled across a series of three keychords that just blew my mind!
More in part 2, soon...
With my move away from the proprietary Invoice Manager software to the open source BambooImage code, I began to seriously think about what kind of effort would be required to create an org-mode environment in which I could execute some function that would automagically extract billing data from my org-mode files and stuff it into a MySQL database, so that I could use BambooInvoice to tweak the result and publish/print/send the final invoice. Or at least make the process simpler.
But before dealing with that, I had to deal with my use of a "note" for each document that was part of a job instead of a "todo," as it was becoming altogether too cumbersome to keep track of data this way.
Some background:
I first began using the "note" format in org-mode because a note can contain a check box, which enables tracking of progress in an assignment (i.e., in a todo). For example:
* TODO 121226 ABC 12321 (XYZ Attachment) [1/3]The string on the TODO line shows the date received (today), from what customer (ABC), the customer's assignment designation (12321), and a brief description (XYZ Attachment), which also happens to be a link that, when clicked, opens the folder containing these files). This particular job consists of three documents, one of which is complete (reflected by the "X" in the box formed by the square brackets, causing [1/3] to be displayed in the TODO line.
DEADLINE: <2012-12-28>
:PROPERTIES:
:KEYWORDS: shareholder meeting
:END-CLIENT: Acme, Inc.
:END:
- [X] cover email (220 twc)
- [ ] XYZ Attachment
- [ ] Attachment annex (edit)
The deadline is self-explanatory. It will show up in my "agenda" for the upcoming week, which I routinely generate every morning.
The "properties" are key–value pairs. I use these for each assignment to identify keywords, end clients, and anything else that comes to mind.
While all of this may look complex, the only part that requires keyboard input in org-mode is shown in bold, above. Everything else is generated using keyboard macros bound to keystrokes, one of which actually cycles through just how much of all this information is actually displayed, keeping the rest out of sight. Typically, my screen will show only one assignment expanded; the rest reduced down to a single line.
What I had noticed, over this past year, is I never looked the progress string at all (except, perhaps, to verify that the "numerator" incremented when the status of a document was checked off), and so, I was not getting any benefit from using check boxes. Indeed, by not making each document a "sub" TODO item, I was depriving myself of the ability to use org-mode properties for each document.
And once I started creating a TODO for each document and storing billing data in properties, I stumbled across a series of three keychords that just blew my mind!
More in part 2, soon...
