On Jan 23, 2009, at 3:16 PM, zvi wrote: (I saw Mark answering this as I was writing mine -- I'll try not to repeat what he's said *too* much...)
> So I was reading the list of changes from LJ again, and I saw: An > improved to-do list, allowing for better task management. > > And I have to ask myself: why? The LJ to-do list was only ever > about quarter-assed. The limits on it are ridiculous (25 items for > basic? 25? That doesn't cover my shopping list. The details limit > appears to be about 100 characters. You have to have a paid account > to have any privacy.) It's currently not even listed in the site map. > > I have ... great difficulty believing that anyone who actually > wishes to have an on-line to do list is using LJ's crippled > feature (as a to-do list, anyway. It might have some salutary re- > purposing use that I haven't imagined, but it's completely > inadequate as a to-do list.) Oddly enough, I have seen some glorious repurposing of the to-do list -- nothing *really* awesome comes to mind at the moment (it's been a while since I was doing a lot of watching things that way), but I remember having seen writers using it to update people on their works in progress, community maintainers using it to track people they've banned from the comm/issued maintainer warnings to, etc. The existing implementation of it fails, and fails hard -- that's why we have a ticket in Bugzilla (for anyone who wants to pick up the project) to rip it out by the roots and then stomp around on the roots for a while. But I do still think there's room for our own implementation of something like that, because ... > The thing about it is, the on-line to-do list problem has been, if > not licked, meticulously studied and tackled, in a variety of ways > that work for a wide variety of people out there. My favorite is > rememberthemilk.com, but there's also tadalist, todoist, google > offers something through both igoogle and g-mail, voo2do, etc., > etc., etc. > > And considering that there's an awful lot that dreamwidth is going > to do that is integral to making the site work better as journal/ > blog/cms/personal publishing platform/bulletin board and > considering that other people do this particular task ten million > times better than the existing code, I have to ask myself ... why > not just integrate the existing better solutions and not spend > developer hours on something that's been awful in LJ since it was > first rolled out? I would propose a two step solution, of, first, > allowing people to enter two URLs that show up on their profile > (journal?) page (and for which, of course, they control their level > of privacy): one to their personal online to-do list and one to the > URL to enter a new task, if it is a separate URL from viewing the > list. And then, somewhere further down the line, as it becomes > clearer which online task managers are favored by DW users, work on > integrating the more popular ones more fully into people's > journals, so they can display the tasks on their journal (or > profile? pages) instead of navigating away from the site to view > them. (I have a vision of something integrated into the sidebar, in > a vaguely gmail gadget-y away, but it's an extremely mist-y > vision.) And maybe also having a journal entry appear as a task, if > someone is feeling extraordinarily clever and accomplishy. Yes, and this absolutely falls into the "make Dreamwidth more interoperable with the rest of the internet" long-term goal. Eventually, if it has an RSS feed, an API, or any sort of attempt to interact with the rest of the internet world, we want to be able to support you using it through DW *somehow*, whether that's linking in a sidebar or on your profile or having it autopost an entry to your journal. But -- and this is absolutely not to discount your "why reinvent the wheel" point, because that point is a very good one, and one I'm absolutely asking myself with every task we put on that list -- there are a few major advantages to a homegrown system rather than integrating a third-party, and those advantages apply to everything, not just the todo list: -- Built-in means privacy-level-aware and easily aggregated: you can trust that it's going to have security levels built in *and* you can do interesting things with the intersection of all your friends' use of that feature. (With the todo, for instance, maybe you and your friends want to create a joint todo list spread out among three journals, or whatever.) -- No need to create an account on a third-party site; not all of them support OpenID gracefully, or really, at all. -- You might trust us with your information more than you trust J. Random Site. -- Integration with communities -- as it stands, communities don't have anywhere near the full range of what I consider vital community- management features, so any step that will allow for a group of people to aggregate data or functions or what-have-you is a positive step. (Community to-do lists, for instance, would let a community organize a group project or what-have-you.) Now, for all of these "plugin tasks" -- todo, bookmarks, etc -- there are sites and projects out there that do it right, and we'll absolutely learn from them if we decide to implement a native version of their features. But the advantages to having an on-site plugin that replicates the functionality is that it allows us to do interesting things around built-in privacy, security, and aggregation features that we couldn't do if we just interfaced with someone else's implementation of a particular feature. If we build it DW- native, we can take advantage of our particular social climate (whatever that happens to become) and design to support the things we're awesome at, like privacy & security and aggregation of data among your social networks and extended networks. As Mark says, for plugins like this, it isn't to say that we'll be reinventing the wheel every time -- maybe there's a service out there that Does It Right and whose APIs are awesome enough that we can just extend upon their implementation; maybe there's an Open Source package that does 90% of what we want to do that we can integrate into our code as a plugin in exchange for contributing patches back up the tree; maybe the answer *is* to rewrite our own from scratch. But all of these functionalities are things that we think would enhance the process of spending your time on Dreamwidth, so we want to have the functionality available *somehow*. Eventually. None of this is a "do it tomorrow". :) --D -- Denise Paolucci [email protected] Dreamwidth Studios: Open Source, open expression, open operations. Coming soon! _______________________________________________ dw-discuss mailing list [email protected] http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss
