TASKER: reworking from ground up
15 March 2009 – 3:49 pm | by PJInside 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:
- Create a new task for your library
- Assign an existing task from your library
- View the tasks in your library
- 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
You must be logged in to post a comment.