I know that it is a significant extension of what DTPO supports but I’d LOVE a checkbox/list file type that is available in both DTTG and DTPO versions. I’ve looked at many other task, grocery and list managers and all depend on some cloud service I do not control (iCloud or DropBox or similar) or do not have a desktop version or do not have the simple solution of a template I can duplicate and use once as I do a tasks.
I do use Omnifocus and while I can create templates for tasks in it it does become cumbersome for these sort of very large checklists. (700-800 item).
Keeping as much of that in the few apps I want to use that work across all my devices, desktop, laptop, tablet and phone is critical.
With tasks lists I go the Numbers route and have it indexed in DEVONthink. This works well for me.
As far as the subscription argument goes I am generally against them and if a software goes to subscription I will look for an alternative that is not subscription. When Adobe made the move I did this, found and tested some alternatives and settled on the DxO suite of software together with an old (free) version of Lightroom; I mention this not to advertise DxO, (I could easily have chosen something else but DxO just suited me more) but to make the point that if you look around there generally is software that will do the job as well and sometimes much better than the subscription one. Interestingly I found that in making the move from Adobe I have hit upon a suite of applications that sits me better and which I find simpler to use with better results.
Lesson of the story? Perhaps it is good to occasionally have a look to see if alternatives are better.
When you only go shopping once a month or even less frequently because the nearest major place to shop is a 150 mile round trip and you use a large four door pickup truck with a shell on the back so lots of cargo space it’s easy to have a shopping list that contains several hundred items to get. The total list though is much larger. I hate having to redo things so I use the giant shopping list as a reminder of the things and brands of stuff we buy.
I would (politely) challenge some of this, on three grounds (all of which are highly debatable):
Productivity works differently for different people, and I am suspicious of wide generalisations like the two here. So much depends on how you measure productivity and over what period, as well as personal idiosyncrasies. I’d argue that productivity measured by number of activities completed in an hour or a day is a very different thing from that measured by goals achieved in a day/week/month etc. There isn’t a simple relationship between rate of activity completion and rate of goal achievement and I don’t think this kind of assertion recognises that.
Even within the same app, switching tasks is a switch. Yes, a substantial thunk in UI makes the switch bumpier, but there’s a cognitive difference between (say) reviewing research material, setting a task and writing a memo. For some (maybe many) people, a consistent UI eases the transition, but there’s still a switch into a different kind of thinking.
Different UIs will for some (maybe many) people be a positive aid to the different kinds of thinking involved in different types of task.
I don’t know whether developers are having a hard time or not (some certainly are). Apps have got cheaper, in some cases by orders of magnitude. The overall market has grown by several orders fo magnitude, which increases potential revenues, but also increases the potential support load. Once upon a time, price was a barrier to entry for users, so they had a real need or a real belief before they paid your high price; your customer base was a cohesive group of like-minded people. Now, you’re trying to support everyone from the dedicated pros to the (forgive my rudeness) half-educated dilettantes who want the app to “just work”. Not to mention annual radical OS updates and short hardware cycles.
I can see that it’s a problem and I can see why you might make a rational commercial judgement that subscription is the best way to go. I think the apps that survive as sub-only will be those that reward subscribers by (a) being good and (b) supplying frequent, substantial updates. But, in truth, most of them won’t survive. As you say, after a year or two, people will start looking at their subscription outgoings and decide to trim them. To that end, extending your software to cover a range of uses might be a benefit (if you do it well).
Just to note - I do not subscribe to software. The overall cost can turn out to be massive (it wouldn’t take much for me to be paying hundreds or even thousands per year) and, frankly, a sa self-employed freelance project manager, I have to know that I can keep my tools during the inevitable lean periods.
I am happy to agree that some of us spend (waste?) far too much time trying to identify the perfect app for the job, and should maybe just get on with our work
If you like OF you will probably like omnioutliner which supports status checkboxes and also column checkboxes.
If you put your omnioutliner files in iCloud folder or other cloud folder then you index that folder so you can see all your outlines in DT but can also open them easily from the app on iOS.
It’s a reasonably elegant solution. I agree with your sentiment about not putting all lists in OF and cluttering it up. Also if you wanted you could save your files with checklists as a template in omnioutliner and reuse those as you see fit.
There is also a button in the toolbar to open a file in an external application so when you’re in Devonthink you just click that button and it will open your files in omnioutliner by default.
Just thought I’d mention my solution to this here, in case useful for someone. Nothing new conceptually – I’ve seen a number of mentions of using some form of text expansion to achieve checkbox lists. But perhaps a small new element in the implementation, which might be of some interest.
By way of background: In my workflow, I make a lot of notes on a project as I go, to document what I am doing and why, and how I am solving a problem – and I often make a checkbox list at the end of one segment of the project, to take stock of where I am, and as a guide to what I need to work on next. I’ve been making the checkbox lists right at the end of my notes on the particular segment of the project, all in OneNote. For me, it has felt really valuable to have the checkboxlists integrated with my documentation notes.
Now that I’m attempting to switch to DT, and having settled on RTF as the format I’m going to use for notes, I found that clickable chekbox lists are not possible within an RTF. I therefore experimented, as people have suggested here, with using checkbox lists in a different document that is still accessibel from DT (OmniOutliner; iAWriter; Notes; a Task list template) – but (for me) this felt disruptive as compared with having the checkbox list embedded in my notes.
So, my current low-tech solution (which hopefully will work well enough for me) is as shown below. Not real clickable cheboxes, but visually distinguishable nevertheless (both as to-dos, and as completed to-dos), and right where I want them in my RTF notes:
