Post-Mortem

Initial Project Goals

Initially we set out to provide new WordPress users with a roadmap for what they needed to do to setup a basic blog.  The plugin initially intended to use LinkedIn’s setup completion bar as a model.  A few weeks into development, however, issues arose given that many of the values users would potentially change during the course of setup were provided with defaults.  That is, sometimes a user may not feel particularly interested in changing something that has already been provided by default.  An example of this is the tagline.  An example of a setup task that is not completed by default would be creating a post.  As a result, it no longer made sense to have a progress bar as intended, and instead allow users to opt out of certain tasks.  This changed the face of the project, though the goal of orienting new users to WordPress was maintained.

Project Results

The project at a point shifted further to focusing on context-based tasks rather than ones merely intended for informational purposes.  This resulted from introducing “moderate a comment” as a potential task, whereby once a comment had been posted, the user would be notified and could complete the task.  This new way of looking at tasks opened a whole “can of worms”, and we subsequently had to revert as those changes deviated too far from the initial goals.  The “moderate a comment” now uses its own temporary comment that is deleted after the user approves the comment.

The project resulted with most of its initially intended features functioning.  We concluded the project term with 13 tasks.  We shot for 12-15 tasks, so I feel considering I had ample time to refine the existing tasks that this was a good result.

What was done well

An example I felt particularly satisfied with was the highlighting/scrolling features.  Tasks highlight pertinent information and scroll users to where instructions display.  Both were done via JavaScript, but it was definitely one portion of the code I never had any trouble with.

As for particular tasks, there were definitely a few that proved tricky.  The “customize a sidebar” task was especially difficult, due to the page’s use of JavaScript and the lack of appropriate WP Hooks.  In response, I was forced to continually refine the API sections of the project.  The diversity of the tasks also posed challenges, as some approaches conflicted with some tasks and vice versa.  I resulted with a series of functions that I felt aided task creation well.

What I didn’t get to, What I’d still like to do

-Frontend based tasks

-Showing changes as a result of a task in different sections (e.g. you create a category, now see on the “New Post” page the newly created category)

-More detail to tasks (e.g. walking users through much more specific steps as well as more steps)

-More commonality drawn amongst tasks to create more solid API/core

What I could have done better

Did code drastically change between iterations or was it a smooth progression?

Were unforeseen changes adapted to?

Was there ever a point that bugs became unmanageable and progress had to be reverted?

Design-wise, does WP Tasks orient new users  well?  How much more or less hand-holding should take place?

Did I accomplish my initial goals for this program (GSoC)?

-start blog

-gain insight into the structure/organization of large-scale web project & open-source development

-learn about large-scale systems and more regimented programming/development than I am accustomed to

-begin developing for WordPress

What I learned

-lots of insight into the numerous parties and contributors in open source

-insight into organization of large-scale projects, how updates are committed

-making small chunk of code (WP tasks) inter-operate efficiently with larger system (WordPress)

Background

Many times, we work with complex systems and either cannot absorb the possibilities or lose track of them as we keep pace with everything else.  The purpose of a tasks API is for both internal and 3rd party development to interface with different aspects of WordPress in order to provide contextually relevant tips for what a user could do next.  For instance, if you have your default post category as uncategorized and you create a category, this system reminds you reconsidering your default category to something different.

If you have 10 unmoderated comments and a week has passed since you last approved or even visited the comments page, now might be a good time to reevaluate how you filter/manage user comments.

To be a help more than a nuisance, this system allows users to “Skip for now” and attempts to process some interest level of the user of particular tasks.  For instance, if you twice tell the tasks API to bugger off about changing your tagline from “Just Another WordPress Blog!”, the tasks API will forget about asking you next time.

Implementation

These types of decisions can seem complex for obvious reasons.  In fact, they are implemented a surprisingly simple, yet (hopefully) powerful way.  That is, given a few different methods of controlling task priority, tasks end up being ranked numerically.  The controls are similar to for instance, an Adobe Flash Stage.  You can move forward, backward, to front and to back.  So editing your about page would be looked at as a beginning task, so a task like editing your tagline might move 3 paces forward on saying “Hey i’m here too!”.  However, if you go and edit your widget page, a task that is barely ever needed might say loud in clear, “HEY ALSO REMEMBER THERE ARE A MILLION WIDGETS ON WP.ORG!!!”.  Everything operates on a simple priority number, but the different influences on increasing/decreasing that number vary quite a bit.

State

The state of the task is very basic.  There are 3, to be exact:

  1. Active – this means that a task is listening intently for hooks relating to completion
  2. Hibernation – this means a task is listening to events that would bring the task back to an active state
  3. Complete – this means the task is said and done for and will never be “opened” to an active state again

There is a lot of grey area for these states.  An “edit tagline” task will likely be complete upon a single edit.  A “respond to comment” task, however, will never be complete since a visiting user can always leave a comment.  That is, in Hibernation, a “respond to comment task” may simply be looking for a next comment to go back to the Active state.  In addition to listening more directly for task completion, and Active state can be used as a conditional to direct task behavior/collection of feedback differently.

Tasks API

Changelog

Version…
0.3


added active detection of task completion on plugin activation
restructured task files
added feedback upon activation of plugin

0.2
further enhanced task files
fixed display issues with percentages
added feedback to passive task completion
added feature to see completed tasks
added switch_theme, change_permalinks, post_something tasks

0.1
added widget
added passive task completion
added percentages/points per task
added change_password task, change_tagline task