Instill like the idea of contexts and have gotten a lot of mileage out of a fairly vanilla GTD-canonical list of them over the years, but I can definitely see your point. Between having a smartphone that has ubiquitous Internet and Office capabilities and the fact that I've been working from home this year, I feel contexts are starting to lose their punch.
I do still think a few kinds of context lists still hold all of their power: Errands (which you mention), Agendas, and travel-specific (when-in-city-x or at-conference-y) lists are still gold to me. I've also started trying to sort Next Actions by type of task--@Email or @Coding or @Drafts, not @Computer--to keep the main list shorter and group like items for batch processing.
But I feel a GTD reboot coming on, and I may try a more classic list again. We'll see...
I do still think a few kinds of context lists still hold all of their power: Errands (which you mention), Agendas, and travel-specific (when-in-city-x or at-conference-y) lists are still gold to me. I've also started trying to sort Next Actions by type of task--@Email or @Coding or @Drafts, not @Computer--to keep the main list shorter and group like items for batch processing.
But I feel a GTD reboot coming on, and I may try a more classic list again. We'll see...
Rethink contexts
I had started to find my contexts useless for the same reasons listed in the OP. Every next action was being labeled @computer which was becoming meaningless. Then I changed my contexts to suit where I actually wanted to do things and realized that though I COULD perform some actions at a computer at home or at work, I really needed to leave some things at work and not bring so many tasks home with me.
Contexts helped me decide in advance to STOP working when I leave a context, rather than helping me to STARTworking when I enter a context. Workaholics like me may find contexts useful after all.
I had started to find my contexts useless for the same reasons listed in the OP. Every next action was being labeled @computer which was becoming meaningless. Then I changed my contexts to suit where I actually wanted to do things and realized that though I COULD perform some actions at a computer at home or at work, I really needed to leave some things at work and not bring so many tasks home with me.
Contexts helped me decide in advance to STOP working when I leave a context, rather than helping me to STARTworking when I enter a context. Workaholics like me may find contexts useful after all.
Still valuable
Coming to this conversation late, but still fwiw here's my view.
Think about why we have contexts. Its not for some arcane reason. It simply recognises that we may have upwards of 200 Next Actions in front of us at any given time. Contexts are just a way to break down that list a little so that we don't have to scan through all 200 every time. The easiest way to reduce that list is to ignore those we can't do, which is why context was always so helpful. Not at home? Ignore those. No Internet? Ignore those too, and so on.
if you have no contexts, you're just going to have to trawl through a long list of actions, and probably face either missing important ones, or just feeling overwhelmed about the whole thing.
Granted contexts will change over time (@Moon?). but the need to drill down your list doesn't change. Just the opposite, as we all take on more and more tasks (and know to define them as such) we need better ways to drill down than ever before.
Coming to this conversation late, but still fwiw here's my view.
Think about why we have contexts. Its not for some arcane reason. It simply recognises that we may have upwards of 200 Next Actions in front of us at any given time. Contexts are just a way to break down that list a little so that we don't have to scan through all 200 every time. The easiest way to reduce that list is to ignore those we can't do, which is why context was always so helpful. Not at home? Ignore those. No Internet? Ignore those too, and so on.
if you have no contexts, you're just going to have to trawl through a long list of actions, and probably face either missing important ones, or just feeling overwhelmed about the whole thing.
Granted contexts will change over time (@Moon?). but the need to drill down your list doesn't change. Just the opposite, as we all take on more and more tasks (and know to define them as such) we need better ways to drill down than ever before.
I've held off for a while with this topic...wow...page 7. I think context is important!
I love context. I tag every Next Action and Project with as many tags as appropriate. They help me a lot!
If a NA has a person associated with it I tag it to that person. Then when I am with that person I select their name and EVERYTHING I have with them comes up. This saves me all the time. I also tag with locations...I manage a facility with 25 buildings divided amongst two campuses. Tagging by location saves me all the time too.
I really feel Contexts is one of the best things about GTD.
I love context. I tag every Next Action and Project with as many tags as appropriate. They help me a lot!
If a NA has a person associated with it I tag it to that person. Then when I am with that person I select their name and EVERYTHING I have with them comes up. This saves me all the time. I also tag with locations...I manage a facility with 25 buildings divided amongst two campuses. Tagging by location saves me all the time too.
I really feel Contexts is one of the best things about GTD.
Similar response...
I echo what others have said. It's true that some of the original GTD contexts may become unuseful (is that a word?) with the advent of new technology, but the principle remains the same.
I heard this question in a webinar recently: when you are in a given situation (context), what choices do you WANT to see? If you want to see all ofyour NAs, fine, but if there are situations where you would like a filtered list, then that is a context.
I like digital list managers for this reason. Like MarkDillon, I assign multiple contexts to each NA so that I can custom-filter as needed. For instance, email tasks get a tag of @HomeInside, @Online and @Email. That way, if I'm at home and want to see the full list of choices, I view @HomeInside. If I'm sitting in front of my computer and feel like doing emails I'll just pull up @Email.
However, at work I have pretty much ditched the traditional contexts. I have a desk job and don't travel, so I always have computer, phone, and Internet available. I rarely have more than 12 or so NAs at one time (my work system is separate from my personal life system), so I don't find it overwhelming to see them all at once. I just use consistent verbs to label them, so, when listed alphabetically, similar tasks (e.g. email) appear together.
MJP
I echo what others have said. It's true that some of the original GTD contexts may become unuseful (is that a word?) with the advent of new technology, but the principle remains the same.
I heard this question in a webinar recently: when you are in a given situation (context), what choices do you WANT to see? If you want to see all ofyour NAs, fine, but if there are situations where you would like a filtered list, then that is a context.
I like digital list managers for this reason. Like MarkDillon, I assign multiple contexts to each NA so that I can custom-filter as needed. For instance, email tasks get a tag of @HomeInside, @Online and @Email. That way, if I'm at home and want to see the full list of choices, I view @HomeInside. If I'm sitting in front of my computer and feel like doing emails I'll just pull up @Email.
However, at work I have pretty much ditched the traditional contexts. I have a desk job and don't travel, so I always have computer, phone, and Internet available. I rarely have more than 12 or so NAs at one time (my work system is separate from my personal life system), so I don't find it overwhelming to see them all at once. I just use consistent verbs to label them, so, when listed alphabetically, similar tasks (e.g. email) appear together.
MJP
enyonam
0
Oogiem;106940 said:
Well said Oogie.
My contexts have definitely changed over the years. Heck, I probably change them every couple of weeks. But that's the elegance of the concept. Whatever your circumstance, they are still there to represent physical or working modes.
So for instance when about to travel to multiple cities, I have a context of "@before trip" and then I start creating contexts for each city e.g. "@accra". And yes, like everyone else many of my next actions end up in "@computer" these days so I break this down further to "@word", "@browser", "ipad" and so forth. My contexts indicate where I have to, or am likely to, do the next action. It allows me to get tasks done without context switching all day long.
The list may be small ... e.g. I may only have 3 things on my @home list but the nice thing is that if when I get home I know I have forecasted my day in such a way that I only need to see my @home context done before I relax for the evening ... voila! I get the three things done and shut off all electronics with a no guilt feeling.
Hope this thread has given you more ideas about how to tweak contexts for you.
scamden
Registered
I realize this thread is incredibly old but it finally clarified for me something that’s been bothering me about GTD over the last few years. I appreciate many of the thoughts the OP posted (despite devolving into sarcasm and attack later which I will certainly endeavor to avoid). I wonder too how much more true it is 7 years later that we nearly always have all these contexts available but that actually isn’t the main issue that’s bugged me with contexts.
it’s this quote that finally made me understand my problem with it
This is absolutely untrue for me. And it’s a perfect example of the problem I’ve had with contexts. It seems the traditional contexts are formed around tools, locations, people. These make a ton of sense if you are completing widgety tasks. The most important thing you need when making widgets is the widget maker and who cares if you have to make a bunch of red, blue, yellow widgets as long as you have the right tool it just doesn’t matter.
But for difficult knowledge work (or maybe you prefer deep work), the tool switching isn’t the primary cost: it’s the mental switching between ideas that really costs (ironically referred to as context switching by non GTD people).
because I’m also a programmer this android example really brought this home for me. When I start working on a feature of our app, the hardest part is getting into my mind all the state about how it needs to work, what modules in the code are affected, how those systems go together, etc. If I implement some part of this in the Android framework the absolute least efficient thing I could do would be to find some other unrelated Android feature and try to get all that state into my head and implement it. I will lose all that valuable context and thinking (and it’s basic neuroscience that this makes you very tired). For me the most efficient thing, is to keep all that mental state in mind and go implement another piece of it in the database, or maybe the web app. The particular expression of the idea costs almost nothing. Sure i have to open a different code editor but that takes all of 5 seconds. What really costs is switching the mental context not the physical context. So in the case of difficult mental projects the most important context is the project not the particular tool.
(To be clear Oogiem, I’m not implying that your Android work is widgety or not mentally difficult, but maybe it’s just focused enough that the mental state and the tool are essentially one. idk the particulars. Def not intending to insult
)
that’s what’s bothered me so much about contexts. When I read about people’s use of them it seems that they are like machines jumping from mental state to mental state with ease and as long as they don’t have to switch tools they are efficient. Now I realize that this is true for a specific type of task and works well for me as well. One off phone calls, errands etc are great to batch. But the most difficult and important projects in my life require total focus and are actually hindered by splintering into other projects that just happen to have NAs associated with the tool I’m using.
to be clear I am not throwing out contexts or gtd I’m just posting this realization cause I think like many people have said in this thread, it’s not about ditching contexts, it’s just about using the right ones! And sometimes the right “context” is no context (or really the project or idea itself).
I think maybe that’s why the op was getting so worked up because for some of us, these larger projects are the most important work in our lives. To imagine not having that total focus on them for the majority of our time seems “ridiculous.” Sure we have to get the milk, or pay the bills (and gtd is great for managing that stuff and keeping it away) but we have to remember to do the important stuff as much as we can and not just get caught up with context first action choices.
so practically im considering this change to my gtd system and would love feedback:
Keep one off tasks and small projects (2-3 steps) the same and use my current contexts. Have a new class of context called “big projects” (or maybe “hard projects”) so each hard project is itself a context (then the only things that wouldn’t go there would be actions that I truly can’t do in that focus state like errands as the op suggested originally, essentially things that “block” me as we say in software). Then maybe use time blocking as many people have suggested around the forum to schedule the all important time to work on these hard things. Idk the idea is still loosely formed but curious what people think. Sorry for resurrecting the thread but I hope this might be valuable to someone
it’s this quote that finally made me understand my problem with it
This is absolutely untrue for me. And it’s a perfect example of the problem I’ve had with contexts. It seems the traditional contexts are formed around tools, locations, people. These make a ton of sense if you are completing widgety tasks. The most important thing you need when making widgets is the widget maker and who cares if you have to make a bunch of red, blue, yellow widgets as long as you have the right tool it just doesn’t matter.
But for difficult knowledge work (or maybe you prefer deep work), the tool switching isn’t the primary cost: it’s the mental switching between ideas that really costs (ironically referred to as context switching by non GTD people).
because I’m also a programmer this android example really brought this home for me. When I start working on a feature of our app, the hardest part is getting into my mind all the state about how it needs to work, what modules in the code are affected, how those systems go together, etc. If I implement some part of this in the Android framework the absolute least efficient thing I could do would be to find some other unrelated Android feature and try to get all that state into my head and implement it. I will lose all that valuable context and thinking (and it’s basic neuroscience that this makes you very tired). For me the most efficient thing, is to keep all that mental state in mind and go implement another piece of it in the database, or maybe the web app. The particular expression of the idea costs almost nothing. Sure i have to open a different code editor but that takes all of 5 seconds. What really costs is switching the mental context not the physical context. So in the case of difficult mental projects the most important context is the project not the particular tool.
(To be clear Oogiem, I’m not implying that your Android work is widgety or not mentally difficult, but maybe it’s just focused enough that the mental state and the tool are essentially one. idk the particulars. Def not intending to insult
)that’s what’s bothered me so much about contexts. When I read about people’s use of them it seems that they are like machines jumping from mental state to mental state with ease and as long as they don’t have to switch tools they are efficient. Now I realize that this is true for a specific type of task and works well for me as well. One off phone calls, errands etc are great to batch. But the most difficult and important projects in my life require total focus and are actually hindered by splintering into other projects that just happen to have NAs associated with the tool I’m using.
to be clear I am not throwing out contexts or gtd I’m just posting this realization cause I think like many people have said in this thread, it’s not about ditching contexts, it’s just about using the right ones! And sometimes the right “context” is no context (or really the project or idea itself).
I think maybe that’s why the op was getting so worked up because for some of us, these larger projects are the most important work in our lives. To imagine not having that total focus on them for the majority of our time seems “ridiculous.” Sure we have to get the milk, or pay the bills (and gtd is great for managing that stuff and keeping it away) but we have to remember to do the important stuff as much as we can and not just get caught up with context first action choices.
so practically im considering this change to my gtd system and would love feedback:
Keep one off tasks and small projects (2-3 steps) the same and use my current contexts. Have a new class of context called “big projects” (or maybe “hard projects”) so each hard project is itself a context (then the only things that wouldn’t go there would be actions that I truly can’t do in that focus state like errands as the op suggested originally, essentially things that “block” me as we say in software). Then maybe use time blocking as many people have suggested around the forum to schedule the all important time to work on these hard things. Idk the idea is still loosely formed but curious what people think. Sorry for resurrecting the thread but I hope this might be valuable to someone
Personally, I set a goal in 2020 to spend less time online, on the computer, or on my phone. Because of this, I’ve returned to the basic contexts recommended in the book. They are just as valid today as they were in 2001. I still rely heavily on blocking out time for focused work and important projects.
Oogiem
0
Maybe a clarification is in order. For example right now I am working on a major expansion of LambTracker. Right now part of my struggle is adapting my mind to write in Python vs Java for the desktop app. But ignoring that I still work in chunks, or contexts and across GTD projects.
Here's what I was doing today: I am in the IDE for Python Development, working in a section of the code (currently trying to decide how to handle the user interfaces ). I have 6 major modules and I am unsure how to best organize the UI to make it easy to work in. I have multiple apps open at once on 2 different computers and 3 screens. On my main development machine I have my PyCharm IDE with 3 open projects (tese are not GTD projects they are IDE projects). One is the current prototype desktop app, one is a tutorial app on using tkinter in Python with examples and one is a tutorial app on sqlite in Python. One machine has an existing system that I use now so I can verify that I am covering all potential use cases. My documentation of the use cases is poor. That machine also has Safari up so I can quickly look up syntax if necessary and I also have my iPad with my Programming Python book up as well.
However my GTD Projects in this area are: Implement top level UI for LT-Desktop, Implement UI for Population Genetics Module, Implement UI for Sheep Module, Implement UI for Owner Module, Implement UI for Set-up Module and so on. It's far faster for me to update the various modules with the current button styles and other UI elements at once. It crosses GTD project lines but is similar in mental energy. So that is one chunk of stuff I'll work on at once. Another big section is debugging my SQLite queries with the new database structure. That is totally different and I'll again crosses GTD projects. I need to get the various queries translated from my entered in by hand in an SQLIte tool format to Python query formats. It's complex since a typical query is about 75 lines of code. That's what I mean by staying in context but crossing GTD projects.
Not necessarily. I create contexts as needed for almost anything. I use apps, locations, mental state and more when I create, use and then delete my contexts.
Ah but for me that is exactly why I prefer to stay in the application. Earlier today I was in the mode of deep focused work on UI in LambTracker. It's much harder to flip out to something else than it is to stay there and continue the deep work.
I tend to agree. But that is switching projects for me. Projects in the GTD sense not projects in the coding sense. LambTracker is a coding project. But it has hundreds of GTD projects and for me LambTracker is an Area of Focus not a project in GTD terms.
Again, I think you are confusing things a bit in terms of GTD practice and terminology. It's EXACTLY the cost of mental jumping that is why contexts are so useful for me. That and the physical movements for my location based contexts.
Of course larger outcomes are very important. But they are proably NOT single GTD projects. They are multiple projects in GTD terms. That's why you ahve to have space to do them and that means being efficient.
Give it a try. FWIW one of my contexts is LambTracker because even though I use several tools (PyCharm, terminal, various SQLite editors etc.) I have to be in the right frame of mind and with enough time to do some good and accomplish something to get anything done there. I am pretty sure that all significant LambTracker work will cease once lambing starts because I am too interrupted then to get anything complex done. I may work on updating the manual, or something else simple but it sure won't be implementing complex SQLite queries or handling UI tasks which is something I am terrible at.
BTW if you want to take a look at the handheld Android version of LambTracker it's out on GitLab under OogieM. The Python work is the desktop app that I'm doing onow. My Android piece is what I use out with the sheep in the field.
This sounds logical, but I strongly suspect that it would not work that way for me. I would be aware that I'm going to do these several very similar tasks, and I'd probably take notes or make a checklist to guide me through the second, third, fourth, etc., but I really don't think I could do them in parallel.
Oogiem, have I ever raised the scenario where you might be part of the 2.5 percent of the population who are "super multitaskers"?
Longstreet
Professor of microbiology and infectious diseases
Actually, context does matter. While not directly related to GTD, one can see from this very recent study that decisions made are based on the context of where we are. Intriguing.
How does the brain put decisions in context? Study finds unexpected brain region at work
When crossing the street, which way do you first turn your head to check for oncoming traffic? This decision depends on the context of where you are. A group of scientists has been studying how animals use context when making decisions. And now, their latest findings have tied this ability to an...
www.sciencedaily.com
TesTeq
0
So true and easy to confirm. You just have to go to the store twice with the same shopping list. First time go there when you are hungry, second time when you are full. At the checkout you will find more goods in your shopping cart when you're hungry.Actually, context does matter. While not directly related to GTD, one can see from this very recent study that decisions made are based on the context of where we are. Intriguing.
How does the brain put decisions in context? Study finds unexpected brain region at work
When crossing the street, which way do you first turn your head to check for oncoming traffic? This decision depends on the context of where you are. A group of scientists has been studying how animals use context when making decisions. And now, their latest findings have tied this ability to an...www.sciencedaily.com
Oogiem
0
Still Misunderstanding me. I don't do them in parallel, I would program the buttons in one module and then go do them in all the other modules. So each module update is sequential but the task is in the same context and mindset across multiple GTD projects.
I don't think so, But I'm also not convinced that there is anyone who can actually handle multitasking well.
Sorry, yes, I wasn't imagining that you did Button 1, Button 1, Button 1, across them all, I was figuring you did the tasks as a group. But...hm. Yeah, this is an interesting example. Are you changing projects, or IS the project "make batch changes across applications". Hm.
Apparently hardly anybody can, and the ones who rate their multitasking ability the highest are the ones who are least able to do it.
But that 2.5 percent, according to studies, can.
scamden
Registered
This is precisely the kind of widget-y task I was talking about (maybe we see this differently because I started out in UI but..) This is a perfect example of a good use of batching for a task that isn't mentally taxing. Once you've designed and decided on the button styles (which could be mentally taxing), updating them everywhere is just cranking widgets, and for me that would be a single project called "Update styles everywhere" or something, like Gardener suggested. (Also, on a side note, I will nearly always create a shared component and/or style library unless it's literally impossible, so that updating the styles is as simple as writing the code once and then installing it everywhere.)
Depending on what these entail, I believe the thinking and decisions involved with these projects could get deep enough that it would be very hard for me to work on more than one at the same time. In my mental model, there's a huge difference between "skin" (color, font, look and feel, vertical rhythm etc) and function. The function of a UI for me often takes much more thought, it can have implications on what the backend is doing (aka this piece of ui is a virtualized grid so the backend needs to be able to give me all 10000 ids, but then batch the actual rows as I request them on scroll, for example). And actually at my current company we use a schema driven UI model, so UI is literally generated based on the kind of data it's about (along with another handful of configuration options). If I want to make a change to UI it often means just changing the way that engine works. This has the upside of only having basically one actual <button> in all our code, but the downside of requiring me to consider thoughtfully any change we might make in terms of how it plays out more generally. I'm getting into the weeds and this is difficult to describe on a forum, but the point I'm driving at is that I intentionally code in such a way as to avoid the widget-y tasks (because D.R.Y. and in our case the need to be configurable), so most of what I'm doing isn't batching lots of small things, but thinking hard about one single thing if that makes sense.
Certain classes of bugs are another perfect kind of batch-able task. These sound like that kind of thing. Essentially you can get into "sql mode" and certain parts of translating the queries become rote. You find things you're doing repeatedly and start copy pasting, maybe you use multicursor etc. I call this "fast task" mode. But (and again I mean no offense here), I don't view this kind of task as complex in the sense I'm describing. Debugging and updating styles are all polish type things that happen after the deep work is done. The deep part is designing the ui and those queries and the functionality of the interface and how the whole system goes together (and whether you can or should reuse things you already have, or what changes these new functions will require to the current system etc) or writing a really difficult recursive algorithm (or god save you refactoring that algorithm), or changing the contract of a module that has rippling effects throughout the code. If you're lucky, once you've decided what it should do the how might be batchable, but I tend to find that the thinking kinda is the work. If I have sufficiently thought out what the query should do, I've essentially written it. And in fact, often times until I have written it I really haven't fully thought it out and will find things I hadn't considered, so in my experience it's often fruitless to sit and plan and then do all the things I planned. Instead I think better if I just start doing it. Thinking hard and coding together (the coding tends to inform my thinking since reality is so much more detailed and rigorous than I am). I have made some attempts to do a lot of upfront thinking (I think DA calls it informal project planning), and then just have a nice set of NA's I can churn through, but I just haven't found that it works. It's always too artificial, brittle, and often just incorrect. For me at least, most of thinking has to be done as coding for it to have any real meaning. Obviously this is even more true for song writing. The task is atomic: "Sit down and try to write song", until it's nearly complete, and then I might have batchable things like "find a different word for love" or "rerecord keys sections."
Right flipping out of LambTracker mode would be a mental context switch, but my point is: isn't there really an even more specific mental context within LambTracker that is expensive to switch? For me "Implement UI for Population Genetics Module" might require enough thought that flipping out of that mode to "Implement UI for Owner Module" would be an expensive switch beyond just the larger category of LambTracker (assuming we're not just talking "skin" for those things).
Sure I'm just suggesting that the mental jumping is sometimes exactly as granular as the actual projects themselves. So the traditional question of contexts eliminating what I can't do, isn't really good enough. Obviously I don't want to see tasks from tools and contexts I can't use (aka errands when i'm coding), but more than that I don't want to see tasks from any other project if the current project requires a certain level of focus.
I feel like we are kinda saying the same thing, and maybe the way we think differs just slightly or the nature of our work does.
I think some of this might just come down to differences in what feels mentally taxing to us. For me switching languages isn't nearly as mentally taxing as switching feature projects. But that's likely because I've been programming long enough with the tools I'm using. If I had to start using Ruby, I'd probably be constantly flipping out to google to figure out "how Ruby does that one regex feature". So maybe the real task is trying to figure out where the lines of difficult mental switches lie right now for me and making those into contexts.
I'll add a task to take a look
I find the above discussion interesting from several perspectives, UI design being amongst them. Productivity in software development is not my problem, but it is fascinating to see the thinking you guys put forth.
Regarding contexts, I feel you already left DA's definition of them. He didn't talk about "mental contexts" and other uses of the word context. Sure, mental contexts exist and I myself take them into account. But DA's idea was very simple: just fold away those tasks, that you CAN'T do NOW anyway, because you lack something physical: a tool, a location etc
In those olde days, when David wrote that book, a computer was not everywhere to be found. If the computer was there, you data maybe wasn't. Broadband and "always on" - did not happen back then. It was then, back in those days, that "@computer" was a big thing to say.
A laptop. I can sit on a coach in a different room of the house, even on another house, and have my laptop synched with my desktop computer, down to the state of every single window in every single program. From that alone the context should be renamed as @a_computer.
When the bottle is emptied, we have to come to a point. Do we open another one?
So, certainly lists like "@a_programming_mind" do make a lot of sense.
Contexts, however became more fluid in their relationship to work, where it's done and when and so on.
Where are the hard edges? That's IMHO the question to be pondered.
Regarding contexts, I feel you already left DA's definition of them. He didn't talk about "mental contexts" and other uses of the word context. Sure, mental contexts exist and I myself take them into account. But DA's idea was very simple: just fold away those tasks, that you CAN'T do NOW anyway, because you lack something physical: a tool, a location etc
In those olde days, when David wrote that book, a computer was not everywhere to be found. If the computer was there, you data maybe wasn't. Broadband and "always on" - did not happen back then. It was then, back in those days, that "@computer" was a big thing to say.
A laptop. I can sit on a coach in a different room of the house, even on another house, and have my laptop synched with my desktop computer, down to the state of every single window in every single program. From that alone the context should be renamed as @a_computer.
When the bottle is emptied, we have to come to a point. Do we open another one?
So, certainly lists like "@a_programming_mind" do make a lot of sense.
Contexts, however became more fluid in their relationship to work, where it's done and when and so on.
Where are the hard edges? That's IMHO the question to be pondered.
scamden
Registered
Agree.
also:
[/QUOTE]
Can you explain what hard edges mean a little more? I’ve seen people use that term so much in here and I think
I recall DA using it in the book but I’ve honestly never really understood it well. I’d be curious to know what that means to you.
also:
[/QUOTE]
Can you explain what hard edges mean a little more? I’ve seen people use that term so much in here and I think
I recall DA using it in the book but I’ve honestly never really understood it well. I’d be curious to know what that means to you.
Oogiem
0
I do not do UI at all well. For me ANYTHING related to how the user interacts is a struggle. My forte is the database design and then the actual user case since I am both a farmer (one of my users) and a registrar (another use case) the only use case I do not have much experience with is governmental agencies but I have some experience in pulling reports from them acting in one of my other roles. Also it is pretty much a given that all my users are probably NOT skilled at using computers as a rule.
Agreed. And the UI for a farm with 100000 sheep pulling a report has to be different from one with less than 100 sheep. I am the only programmer at this time on this project. When I am working in the UI section I model either in my mind or with some test data how to get the reports/interactions out, where the user will be (environmental conditions etc.) and then try to figure out a good way to get that data displayed. Then I mock them up and test them against a subset of the live data which has all the corner cases I know of at this time. Figuring out one section for one type of task needs to then get adapted for the other modules even though for me it crosses GTD project lines. I find that once I solve one segment I can apply that same basic concept and tools in other modules efficiently even though I still have to do more thinking on the how and details once there. It's the same type of task for me so I do it across modules.
D.R.Y is a goal but as a practical matter it's not as easy as I would like. For example the field chute and sheep side hardware is an Android tablet. One of the current rules in Android is that you can't pass a database cursor across activities, and each screen is a different activity. Due to screen real estate I have cases with multiple activities to accomplish a task. I have to redo the get a current cursor based on the data I want several times. That by necessity causes you to reuse stuff and not even in a library due to Android rules. it's a real PITA IMO. There are also the limits of data storage, RAM and screen size in the mobile app that are less relevant in the desktop versions. The desktop has to run on Linux, Mac and Windows computers so that limits how I can set up the UI as it has to look/feel native but be one set of code. I'm using 2 completely different languages for the mobile vs desktop in part so I can easily add in scientific analysis code that is already written and available only in Python.
For me it is the opposite.I can switch features and modules far easier than I can switch languages. I originally learned to code in FORTRAN IV. My Java coding is only in the last 6 years and Python is basically 3 months after testing and then rejecting several other possible language options for the desktop app. So I'm still in the major learning curve about the entire Python language and the almost religious argument between 2.7 and 3.7
However I've been working in the application area trying to do the tasks I want LambTracker to do and the reports I need for over 20 years. I know my working environment and many of the issues and problems with existing tools because I've tried nearly all of them.The failure of the existing software and hardware tools to solve my problems in a way I can use that is both elegant and inexpensive is why I started the whole LambTracker project. So I can quickly flip between what I need to work out in the field when processing a newborn lamb vs what I need at my desk during a blizzard in November when I am planning the matings for the next season vs what I need when deciding which sheep to send to butcher this time. I've done those tasks so many times that I can easily switch to that mode. I think we are saying about the same thing. For example: It's funny you mention a massive recursive task. In population genetic analysis one task that all the further code uses is to build a sequential file of animals where all parents are in the file before all children. Since parents and children can be added to the database in any order you can't just read the animal tables sequentially to build your input for the next procedure. As a practical matter you are recursively looking up the parents of a particular child and moving backwards. Or you can try to locate the oldest animal and run forwards. There are advantages and disadvantages to both options. Which one I choose often depends on the total population size. Doing a full analysis on a population of millions of animals is far different than doing one where the total population is under 500 animals. The UI has to adapt, at least in the reporting section. The start the task interface can be the same. So for me the UI of initiation is a separate project from reporting based on results.
Another thing that happens with me is as I figure out how to do and get certain types of reports and data out I then start thinking of many other things where I know the data are there but the code to make the correlations that turn that data into useful knowledge isn't. Those ideas may turn into entire whole projects or even an entirely new program that will become part of the LambTracker family of programs and hardware.
YES!!! And that is why contexts can have a starting point as outlined in the book but then must adapt and change to the person and their work. A big step forward in my GTD practice was when I finally grokked that contexts are personal and variable and fluid. That's why now I try to answer questions in the light of how GTD works for me. Offer some other options that people can try and either use, adapt or discard as they see fit. That goes for contexts, compartmentalization of work, inclusion of everything not just work into my GTD system, how I organize project support materials and reference etc. etc. etc.
By the way I am really enjoying this conversation. It may be off topic for GTD but I would love to continue the conversation about UIs and programming. One of my problems is I am somewhat isolated and don't have many folks I can bat ideas around with. My husband is a hardware designer and does the low level device driver and real time coding type stuff but nothing with databases. A lot of my fascination with LambTracker is with the general case of "If I collect this information in the field real time and have a history of it what other useful stuff can I extract out of that data in the future?"
Very good point. And I think those hard edges will change based on the person and the work. Or kind of like "There is no spoon." "There are no hard edges"
scamden
Registered
Ugh I long for this. My users have been sales people primarily through 3 companies. I would give an ear to work on something I was actually using myself.
Pretty much always
This is interesting. I'd be really surprised if Google hasn't got someway to decompose these problems. Unfortunately my last Android experience was a college project so I can't help with specifics, but in my general experience, there's almost always a way to share the bulk of the code for things like this. It seems like you have a little bit of a non-standard use case being out on a large farm. Normally you would host the db and hit it through an api, but are you keeping the sqllite on the phone to avoid the need for data connection?
Why not build a webapp? These days with modern browser apis you can even design the thing to operate offline. Plus then you can use Typescript which is the best language since ever
Ya all my science-y friends love python. This makes sense. I would just see if you can think more micro-service-y about the setup so the parts that require python are hit through some interface but you can choose whatever language you want for the normal app logic. Sounds like maybe you'd prefer Java with all your Android experience but I prefer Typescript / Node (did I mention? )
So interesting. Ya recursion is classically applicable to tree structures. So a family tree is... that. Again, I'm UI guy that has since become Full stack so I'm no db expert, but I wonder if there aren't DB's that natively store as a tree so you don't have to reinvent that in sql.
yay!
Super appreciate that way of thinking
Same! Definitely have gotten into the coding weeds but I love that haha. And yes, having inspiring, knowledgeable people around is so so helpful. There are so many intangible benefits. Even working remotely at home has been tougher for me in that sense despite still having a team to work with. I took a brief look at your gitlab (which why not github? just curious) and I'm no android expert but looks like you have some good stuff going. More than happy to take the discussion offline somehow (DM on here or something?). I love discussing this stuff! I might not be super helpful with Android specifics, but definitely app development / architecture / and general coding stuff I can
Thanks again for all the GTD thoughts as well!