https://futureofcoding.org/ logo
Join Slack
Powered by
<https://www.theverge.com/23521586/productivity-ap...
# linking-together
t
https://www.theverge.com/23521586/productivity-apps-to-do-lists How many different productivity apps do you use for your daily work? Would it be possible to build one to rule them all? Personally, I keep a weekly diary in OneNote to track most of my ongoing work. Somehow, knowledge work seems to resist being formalized into a single structured framework. (Or maybe that's just my own semi-scattered process.)
a
Who doesn't have a semi-scattered process, though? Among other concerns, the schema of tasks in our life doesn't usually stay the same long enough to really optimize toward it. Ed: I might have been too snarky, so I want to be explicit: any tool like this must plan for scattered processes.
👍 2
👍🏼 1
k
Reaction #1: I want a pony 🙂 Reaction #2: It's not clear if the author is aware of the Unix philosophy, which seems relevant here. Conflating messaging, project planning and personal tools seems counter-productive. They're only superficially similar. You can call everything in a computer a productivity task, but then you can also think of your computer as a whole as the "single productivity app to rule them all". Meanwhile your work isn't getting done. Reaction #3: Lean into the reality that computers are best as glue, and build your own tools to integrate between all the apps you have to juggle 😂 Hell isn't the computer, it's other people. All the way up to compliance regimes.
👍 2
a
Re #2: they're not conflating messaging, project planning, etc, or at least that's not their whole problem: those tasks genuinely need to share data. A large part of their complaint was duplicating info across apps. The Unix philosophy doesn't really work in the current ecosystem, and no one is incentivized to make it work. Interop requires a common language, and a common language is a lot of work to make it easier for your customers to stop paying you. You end up wanting "apps" to all be frontends to a common (user-owned) datastore that none of them control and is in constant schema flux. Who builds this nightmare? (yes, it's us lunatics, I know)
💯 3
❤️ 1
k
I agree that the real issue is data, not tools. Not just because of today’s corporate silos, but also as a result of everyone focusing on apps/tools over the last decades, leaving data models, data formats, and data storage as “technical details “. Everyone except for the database people of course, but their focus has always been on entreprise needs rather than personal data.
👍 1
BTW, my main “productivity app” is still Emacs. Not because it does everything I need, but because it can integrate with everything I use, due to its focus on plain-text data.
➕ 2
💯 2
n
One thing that caught my eye:
I spent four hours building multiple databases just to keep track of my bylines, sources, product inventory, running logs, test logs, and meal planning
Maybe I’ve got Computer Person Brain Worms, but for an initial investment of time that feels reasonable (only if it includes ingesting the actual data though).
This is also another instance of a different theme, which I’ve seen come up time and time again: Wouldn’t it be nice if there were fewer barriers between programs? This comes up in many places, whether it’s this article, the retro/minimalist computing community (100rabbits‘ uxn fantasy processor comes to mind), the desire for Steam to circumvent windows account separation so it can share game downloads across multiple accounts, and I’m sure many others. The problem, imo, is that any system that connects to the internet at all treats all applications as potential adversaries to one another and the user (and rightfully so). So programs are sandboxed as much as possible. This separation means that at the operating system level (and before that, in the designers‘ minds), there would need to be well-designed APIs to share data between programs (and a permission model to go along with them). Web 2.0, with its mostly open REST APIs, got the sharing part right, but not the permissions. Or maybe it did, but the consequence was that you (the proprietor of a web 2.0 service) would pay to host part of a competitor’s functionality, which isn’t a thing investors like, I guess.
k
I'm exploring an alternative approach: shared access to data is the most important thing so I'm starting with it and giving up everything else. Servers (local first!), databases (use the file system), users (everybody host your own damn data)
k
Data-first + local-first is indeed an approach worth exploring. Who else is working in this space? All I am aware of is @Kartik Agaram’s work and Alexander Obernauer's item-based OS (https://alexanderobenauer.com/). Beaker was another candidate (https://github.com/beakerbrowser/beaker/blob/master/archive-notice.md), but the project has ended. Something else worth exploring IMO is IPFS-based immutable data as the foundation. This would drastically reduce the number of mutable storage locations that require access control, and thus enable protection around the mutability points, rather than sandboxing the tools.
d
@Kartik Agaram you have "State last" in the spreadsheet, which seems contradictory to this claim! Meanwhile, I'm just reading all your links to see what it is you're working on ...
Right, I followed all the links ... and now I'm totally confused! Where is the project supporting "shared access to data is the most important thing so I'm starting with it and giving up everything else. Servers (local first!), databases (use the file system), users (everybody host your own damn data)" ??
k
This is not Mu 🙂
"Shared access to data is the most important thing" is not the same thing as "state first" in https://docs.google.com/spreadsheets/d/12sTu7RT-s_QlAupY1v-3DfI1Mm9NEX5YMWWTDAKHLfc/edit#gid=0. I'm still hiding the state like any conventional text programming language. The claim is just that there's an easy way for any of my apps to get to the data: the file system. This doesn't work in general, but if we're talking about note-taking apps there's no reason for the schema to be extremely trivial. Privilege easy interop above all else. Does that help?
a
The link isn't just talking about note taking, they're mostly talking about project management and email and calendars across lots of people.
k
For sure. Sorry, by "the claim" I meant my claim.
👍 1
d
Reading the article (! iknowright !), I have to say this person has a uniquely complex life to organise! Not sure anything from her life situation can be generalised... And, much as we all would like to be the person or organisation meeting her needs 99%, the fact is, nothing we conjure here will likely ever do better than 85%. And that applies even to people with a more normal life and work to manage.
"Still, there has to be some sort of middle ground between an unachievable fantasy and the current landscape."
We can probably help with that though.
And I think this thread is going in the right direction, but I would say that, because that is the direction that my own work is going! 😊 Anyway - my approach is to solve the problem in a simple and obvious way: get rid of apps all together! You're then left with the data all out in the open as the first thing you see. Instead of data being captive to each isolated app, it's now free to be linked together and mashed up in new ways. Functionality or behaviour, instead of wrapping data, is now inside it, as internal animation. Data interacts with data.
😄 2
t
What you're proposing sounds similar to a data lake. I believe the major cloud vendors are converging toward a model that uses a single common location for data, all of which is stored in open data formats and can be queried from anywhere. That's generally what enterprise customers want. But I don't see how the model would work for consumer software. The two main challenges I see are: 1. Schema changes are difficult to implement without explicit coordination from all of the applications that use a particular data set. 2. A single buggy application could ruin all your data. Presumably the model would allow different permission levels for different applications, but the average user isn't going to put any effort into managing permissions (or even understand what they mean). Perhaps the default would be that applications only have permission to read data that they've written, with the option to explicitly share data. That would work great for me, but for people who don't want to become data engineers in their free time, it seems like they'll just stick to the defaults. And then they won't get many benefits over the current walled garden model.
Open in Slack
PreviousNext
Powered by