the dojo psi

Tasks as an Art Form

Out of the new-idea of setting everything up in a personal ‘task library’ came some other fabulous ideas from the beta testers.

If you’ve ever used Firefox browser add-ons, or open source software that has plug-ins, add-ons, mods, hacks, or other names for “special stuff that other people build and make available for you to use too”, you’ll understand this concept.

The original idea was actually, “Can I share my library?” which was a great idea, but I wasn’t fond of it in full for several reasons, like:

1. It would complicate things in my coding, making some private and not others, and I’m not willing to share my whole library.
2. It would mean the total quantity of available tasks would end up being so huge that it would be useless, like doing a search and getting 10 milion results, and people wouldn’t know where to start, plus they’d end up with a lot of duplicates shared across libraries. It would just take so long to find good stuff, wading through so much, with lots of peoples’ entire library shared.
3. It would instantly lose track of where/who anything came from.
4. It would end up with tons of available tasks that were kind of crappy tasks, just casual stuff people do on the fly, and I’d kind of like shared things to be deliberately done and focused on quality, so the feedback is diverse, is included locally, etc.

But I loved the base idea of that which was really, “Can I share certain of my tasks with other taskers?”

What if a person really put some major effort into making an exceptional task? Or let’s say, a small group of tasks with something in common?

It occurred to me — a sort of epiphany really — that TASKS are just as much an art form as sessions, if not moreso. Good tasks usually take longer to setup than it takes to do a session. From quality feedback, to trying to find non-copyrighted feedback (such as creative commons / copyleft, something you can credit but are allowed to use publicly), to a variety of feedback (custom paraphrased key info from an encyclopedia or website, a quality photo(s), etc.), putting together a good task can be a bit of work. They deserve recognition and appreciation totally on their own, totally apart from the viewing.

Could a tasker do something to ‘package’ those tasks up, so other taskers could use them too? So people looking for something to task might have some ready-made options by other taskers? Whether they assign these to themselves, friends, offsite groups/people, a local team, etc. doesn’t matter, it’s up to them.

I think that’s a fabulous idea. Better yet, I think it should be set up a little like firefox add-ons, where you have the option not only to download something (or in this case, you click a button to have those tasks [and any associated media files] copied to your own library), but also to leave a comment about it or rate it.

That way people making and sharing tasks can get some feedback from others, and that way if there are eventually tons of options for sharing, one can at least ’sort by rating’ and get the packages that other taskers have thought the most of over time.

This would also keep track of who did what; it might allow some taskers to ‘further build on’ a collection or approach one tasker had already begun; it would allow a tasker to ‘update’ a set later; it would prevent those borrowing from getting duplicates; it would emphasize the ‘quality’ of tasks that are shared; it would reduce the massive overabundance of shared tasks that entire shared libraries would bring; for folks who like exploring different kinds of creativity, it might give them a new area to create in and share with others; and it would provide a better focus on tasks as an art form in the project that most ought to be recognizing that.

So it’s a “win” on more than half a dozen fronts.

The nice part about the redesign of the TASKER module in tBot is that this makes a separate subproject like this pretty easy. It’s not a big deal to just let someone click a few tasks from a list or category, give it a name and make a comment and press a button, and have all that copied to new holding table and holding folder. (That way if the original provider deletes a file/task from their library, it will not affect the shared collection.) And it’s pretty easy to just have someone click a button and have it all copied right into their own library. Simple and fast and versatile; ideal.

I think quality tasking is underrated in the RV field. I think a lot of people put emphasis on things which may not matter quite so much (like wording–which probably does matter, but probably not as hugely as assumed in the case of free-response (vs. binary dowsing) RV), and don’t put enough emphasis on things which are ideal–such as having some quality, succinct, informative text along with a quality photo or video (and even better yet, all this able to be posted publicly without the viewer getting sued for copyright violation, which takes custom paraphrasing and special searching for media that fits that criteria).

I also think people tend to err on one side or the other in tasking, either providing too little information, or providing too much. It’s laziness really. A website about Easter Island is too much information, especially a few websites. A hand-crafted, very succinct yet informative and FOCUSED text summary, along with a couple good photos of the same thing from different perspectives (which should be whatever the text is talking about), that makes a good task feedback. And it should be able to be posted publicly without copyright infringement. Getting all those elements together takes time and effort.

When the tasking is ‘framed and focused’ based on the feedback, then the quality of that feedback becomes even more important.

So I best like that it provides a whole area for a special focus on tasks as an art form. That it also provides a bunch of other neat feature is just a handy side-effect.

I don’t know what I’d do without the beta testers because most of these great ideas and totally new ways of looking at all this are thanks to them. I’m the originally programmer so my model is both old and ’set’ and they don’t have those limitations so they are really expanding the horizons — and drastically improving the final product we’ll end up with.

They’ll get it free as a result of their help. I might charge for at least some of the features when it finally opens (2010).

PJ

Posted in Project: Taskerbot | No Comments »

TASKER: reworking from ground up

Inside Taskerbot the most primary module is the one called TASKER. This is where you create and assign tasks to yourself, to the outside world, and to friends in-system. It’s also where you see the listings of all the tasks created by anything anywhere in Taskerbot. There are other modules that do tasking of various kinds but this is the main ‘base’ of the project.

Originally:

TASKER had been set up so that you could task to yourself. Then it was expanded, so you could connect with friends in-system, and task directly to their pools (or vice-versa). Then it was expanded, so you could create a task for anybody even outside the program. You’d set the date/time for feedback and the system would handle it automatically. This approach neatly solved several major problems I saw happening in view groups. It would give you a link (no login required) that you could email a friend or post to a group for the feedback. It had other limits but as a simple way to task it was good.

But Taskerbot, aka “tBot” was originally based on the simple idea of creating your own target pool. The problem with doing this is that you need to be doubleblind. You can have humans do the task creating, but what you need is a ‘bot’ — an automated randomized system — that can “distribute” the tasks so they truly are doubleblind.

(So tBot is not a tasker software for viewers, but rather, it is a task-distribution software for taskers. Viewers and project managers just happen to also be ideally served by many of its functions.)

So because of its beginning idea, it had built-in limitations, like:

• If you tasked to offsite it was ‘over there’ and you could clone (replicate) it to save time, but only to another offsite task.
• If it was to yourself, you could clone (replicate) it but only to a ‘local’ (task to self/friend) type task.
• If you tasked a friend, you could ‘retract’ it before assigned, but the record belonged to them, so if they deleted it, you didn’t see it anymore either. So you couldn’t later go back and task it again to someone without making a whole new task.
• You only had one pool so you had to make multiple logins if you wanted separate pools.
• The TEAM module in development had yet a whole ‘nuther separate tasking form etc. only further adding to the complication.

Thanks to the ideas of the beta testers, who have been totally invaluable so far, this is being rebuilt from the ground up. It’s one of those, “If we only knew then what we know now…” things. Now we have a greater oversight on both its usage and its potential.

New version planned:

In the new idea, everybody has a ‘task library’. These don’t have task numbers, these are basically just a task set-up. Not for anybody in particular, just “a task”. All tasks go into your own “task library” first.

The library has categories, allowing multiple default target pools that MIXER module can choose from (so no more multiple logins needed for separate pools). Actually there are three levels of categorization but they are ‘floating’ heirarchical not fixed.

Also that means you keep any task you create forever, unless you delete them, so you always have them for tracking/reassigning.

From your library, THEN you choose something and “assign” it in any way you want — such as to a friend or offsite or to a TEAM. This means a lot more flexibility in the use of the tasks between types.

Every task record also has ‘tags’ allowed, so you can tag a given task with a variety of terms/phrases and quick-find anything by clicking on the tag-cloud term or using search.

Once you “assign” a task–clone it from the library into a specific tasking with a task number and so on–then it goes into a separate table for assigned tasks, and you can tag that one as well, assumedly with some different things that might include something about the reason you’re tasking it (eg ‘practice’) or the person/group/project for which you’re tasking.

This vastly simplifies the primary ‘create a task’ option because now instead of a different form for every type of tasking (to self or friends, to offsite, or to a team), there is just one form for task creation.

And since all the task part is already taken care of, there are only a few key fields of info to address (which vary depending on task type) in order to “assign” something, so that part should be quick and easy.

It also means when you first come into tasker it should be a little easier to figure out, as there will be only four options:

1. Create a new task for your library
2. Assign an existing task from your library
3. View the tasks in your library
4. View the tasks you have assigned

I was just beginning this process when my computer died — the power input jack literally broke into pieces when I was plugging it in one day. Alas as it had been on battery too long and closed down, it means I couldn’t even get stuff I was working on right then off it. (Although I need the software for database and middleware that is on it for ‘real’ work.) So we had to take a break from the beta testing for awhile. This is probably good because it had been pretty intense for awhile until we finally arrived at the “wait, let’s rewind and start from scratch” idea. I figure it will resume sometime next week.

PJ

Posted in Project: Taskerbot | No Comments »

Taskerbot BETA Testing

Taskerbot over time has developed into an extended “tools and utilities” multi-module program for taskers/viewers/managers. At the beginning of this year I pulled it out away from TKR so it is stand-alone as its own project, and then closed it to all but people who volunteered as beta-testing. I expect this to take all of 2009 since there is a lot (a lot!) involved.

In the process of going through the first and most major module, TASKER, the awesome beta testers had a variety of questions and requests. After thinking about it a bit, it became clear that the fundamental nature of the thing needed to change. It had been originally designed with one general usage idea, but over time had come to be used for a broader scope. It needs to be redesigned to fit that broader scope from the ground up.

I’m going to put some notes here about each module’s changes as a kind of summary, to make it easier at the end of the year to go back and see what all happened. There is too much correspondence during the beta, on the private tbot beta board at the dojo forum, to easily keep track of the ‘end result’ of a lot of discussion and testing.

PJ

Posted in Project: Taskerbot | No Comments »