Ship69, I think that since reading speed is an issue, your system should be designed around minimizing reading. The system that you link to doesn't seem to be designed with that goal in mind. It does mention minimizing workflow and mention a Kanban-related source, but the numbers that it mentions are really big for Kanban.
I know GTD wants you to do a lot of reading--lots of current options, reading everything every week, and so on. But you're not doing that, right? My understanding is that you don't have time, so you don't do it.
If you accept that there WILL be a compromise and you won't read everything as often as you'd like, then adjust your system to control the compromise.
So I would suggest:
- Very short "active" lists. I'd get scientific about this. Figure out how much you can scan in X minutes--one minute? Five? And then limit your active lists to that number. This will force you to prioritize during the weekly review, and let you minimize reading during the week.
- Minimal actions per project, with the rest in project support material. In the active lists, just have one or two actions per project. If you want to have a list of lots of action for a project, move those to the project support material. You don't need to even look at the action list in the project support material until you've finished the current actions for a project, so you don't waste time reading it over and over.
- At least two levels of Someday/Maybe. Those very short "active" lists of course mean that you have long Someday/Maybe lists. But I would group these by priority, too.
I'd suggest an "on deck" list for stuff that you plan to move on to as soon as the current projects are done, and I'd make that list, again, short. And, again, I wouldn't have long lists of actions for each project--I'd either just have the bare project name with NO actions, or I'd write the actions in project support material.
Then a "backlog" list for other stuff--again, with no actions or only actions in support material. You look at the backlog once a month, not once a week. (Or you could do the weekly/monthly/quarterly thing, but I don't think you liked that.)
Edited to add: And where possible, even move things out of backlog. If you have two dozen books you want to read, don't make them two dozen lines in backlog--make a "Books to read" list that you ONLY look at when you finish the current book.
- Tickler list and date-sensitive mini-projects. Keeping so many projects out of sight means that you won't see date-sensitive things related to those projects very often. So you'll want to make sure that you don't miss those dates. I think that the best way is to extract the dates from the projects and put them in a separate list that you'll scan every week. But you only need to scan the actual dates.
For example, your "2016 taxes" project may be in your Backlog so that you don't keep on scanning it. But "check on W-2s" and "start taxes" may be in a dated list. In theory, you should be able to scan the dated list quickly, because all you need to look at is the dates themselves--you don't even need to read the text for items that have a future date. (You'll set your dates accordingly--so if Jane's birthday is 9/15, you add a dated item for 9/1 to remind you of it in plenty of time.)When something comes up, you can make it a mini-project--"Check on W-2s", will be over and done with quickly, while "do taxes" might sit on your lists, occupying reading time, from late January through mid-April.
(Edited to add: The tickler list is a refinement of my previous thought in a recent thread, where Jane's birthday would have had her actual birthday of 9/15, so that every time you scanned the list you'd have to consider when to start worrying about the item, which would require reading the item. Why do that evaluation every time you scan, instead of doing it just once when you add the item to the list? Then you can just read the date.)
That's my suggestion.