• Create “paper trail” of changes made to user
• Role, grade, position, etc.
• Date-based
• Track any type of change for any type of user
• Students, teachers, administration, etc.
• Allow retrieval of full user history
• Allow retrieval of history of based on relationships/connections between content types
• Example: Retrieve history of a class by finding all teachers associated with class in their histories
• Allow queries for users based on properties in history
• Example: Find all students who have had a class with a specific teacher

Data Storage (Options)

1. User metadata (separate records)
• Store history in built-in wp_usermeta database table
• Methodology: Changing a property for a user
1. Save old property value in special meta key: hist_{property-name}
• {property-name} is property being changed
2. Set new property value in default meta key: {property-name}
• - Changes not dated
• Option: Could store date with old value as serialized data
• - Would need to parse/sort full query before results based on specific properties/values could be returned
• + Simple to query based on meta key
• Find all users with specified property/value combination
• ? Can user metadata store multiple items with same key for user? (ala post meta)
• A: Yes
2. User metadata (serialized data)
• Entire user history stored in single row for user in built-in wp_usermeta database table
• Data stored as serialized array
• Key: Timestamp of user property change
• Value: Object/array of properties/values
• - Must query all users’ histories before any connections can be made
• + Keeps wp_usermeta table cleaner
3. Separate database table
• User history stored in bespoke database table(s): user_history
• Structure (schema)
• id: Unique row ID
• user_id: User ID
• date: Timestamp of property/value change
• property: Property being set/changed
• value: New value of property
• Example: Student grade-level change
• id: Automatically set
• user_id: {user-id} (ID from wp_users table)
• date: Current date time
• property: “grade-level”
• value: 2
• ? Current user properties: How to manage/query? (Options)
1. Mirror current properties/values in user metadata
• History table used primarily for past history
• All current user data should be accessed from user metadata
• History updated when property changed/set
• + Can perform queries for current data using metadata (all students in class “x”, etc.)
• - Duplication of data: wp_usermeta/user_history
• Not too much of an issue because history only used for archival purposes (e.g. not validating current user properties)
2. Add current column to user history table
• Flag indicates row contains latest data for user property
• - Must unset previous row flagged as current when setting new data
• +Simple to query current data using where clause

  ...WHERE current = true

3. Use date column
• Query only latest matching rows
• Unique rows sorted by date column
• Will return most recent row of each property for user
• ? How to retrieve multiple properties with same key for user?
• Example: Student may currently be in multiple classes (and assigned to each class at different times)
• - Only most recently-set class would be returned for student

Properties with multiple values (Options)

Examples

• Student in multiple classes in current semester
• Teacher teaching multiple classes in current semester

1. Serialized property value
• Store data as array
• - Does not track granular changes
• Example: Single class changed while others remain
2. Multiple rows with same property
• Example: Separate row for each class that student is enrolled in
• + Current classes managed as user metadata
• History just for chronological record
• Dates of property changes “tells the story” of user’s changes

EDU: Notes – Core: User: History was originally published on Archetyped on March 21, 2012 06:09pm

• Teacher’s classes
• Student’s classes
• Class students

Implementation (Options)

1. Metadata
• Store history in usermeta/postmeta (depending on object storing history for)
• Example: Teacher’s class history
• usermeta properties (Array of arrays or objects)
• id: class ID
• date_start: [start date] (when user added to class)
• date_end: [end date] (when user removed from class)
• Example: Teacher(s) of old class (class no longer active)
• postmeta properties
• key: teachers – Array of user IDs
• Contains most current list of teachers for class

EDU: Notes – Data: Managing History was originally published on Archetyped on December 14, 2011 11:53am

• Link to/from anything
• Content to Content
• Same content type
• Different content types
• Content to User
• User to Content
• User to User
• Define relationship abilities on content type/user role basis
• Relationship type (see below)
• What content types/roles items of this type can be associated with
• Define relationship type
• One to Many
• Many to Many
• Many to One
• Track relationship changes (date/time of change, etc.)

Examples

User to Content

• Teacher to Class (many/many)
• Student to Class (many/many)

Content to Content

• Class to Grade level (parent/child?) (many/one)

Implementation (Options)

1. Custom DB Tables
• Store relationships in custom tables in database
• Tables
• Relationship Types
• Defines possible relationship types for current item
• Relationships
• Manages relationships between items
• Item ID, Type (content, user, etc.), Relationship  ID, Relationship Type
• - Custom tables require more management
• + Control over data/handling
• - Must build from ground up
• + Better query precision for finding appropriate data
• ? WP Taxonomy already has such functionality?
2. Meta/Options
• Store relationships for an item in WP meta table
• postmeta, usermeta, etc.
• Possible relationship types stored as option
• Methodology
• Store
• Example: Teacher to Class (User to Content)
• Relationship: many/many
• Relationships (array)
• Type: Content/User
• ID: Class ID
• Active: true
• Date created: now()
• Date modified: now()
• Updated when changes
• Track all relationships (do not delete) in array
• Add array to usermeta
• Retrieve
• Example: Teacher’s classes
• Retrieve user’s relationships (array) from user metadata
• Search array for active relationships to content
• Filter results to IDs that match “class” content type
• ? Class teachers
• - Need to store relationship with both parties
• - Duplication of data – Relationship must be stored in meta for both items
• - Management
• Must update metadata for each item when updating
• Potential for stale/incorrect data if both items are not updated
• - Relationships array will grow bigger and bigger over time
• Since old relationships are retained for history
3. WP Taxonomy
• Manage relationships using build in taxonomy functionality
• Need to look into WP taxonomy capabilities
• + Use prebuilt API
• - May not be tailor-made to fit needs
• Methodology
• Setup
• Register custom taxonomy for each relationship type (class, grade level, etc.)
• Set possible object types for taxonomy (user_student, user_teacher, etc.)
• Store
  • Example: Teacher’s classes
  • Create term for each class
  • Term references item ID (from posts table)
  • To retrieve details from later
  • List classes on teacher edit form (like categories– grouped by grade level)
  • Term relationships saved automatically
• Retrieve
• Example: Teacher’s classes
• get_object_terms($user_id, "user_$role")
• Retrieves all user classes (active & inactive)
• Filter out inactive classes
• History stored as user metadata (e.g. class_history)
• Class ID, Start date, End date
• Example: Class Users (teacher(s)/students)
• Get term associated with class (stored as metadata)
• Get all objects associated with term (e.g. teacher_class, class_student, etc.) [in term_taxonomy table]
• Retrieve objects (teachers, students, etc.) using IDs
• Creating term for custom post type
• Example: Class – Math
• Properties
• post_type: class
• ID: 3
• Term
• terms
• name: math
• slug: math
• Cannot depend on slug for matching with content
• Useful so we don’t have to retrieve full object just to list term
• term_taxonomy
1. Link term to post type
• term_id: [value from terms table]
• taxonomy: obj-reference
2. Link users to class (User to Content)
• term_id: [value from terms table]
• taxonomy: class (post type)
• term_relationships
• object_id: 3 (math post ID)
• term_taxonomy_id: [ID from term_taxonomy]
• Linking users to term
• ? Use same/different taxonomy when adding term to user? (options)
1. Same: One taxonomy for all associations (e.g. class <> user)
• Students/Teachers will be grouped together
• - Additional filtering necessary to retrieve only teachers or students associated with class
• Use get_users()
• Arguments
• include: [CSV of users associated with class],
• role: teacher
• - Query will take longer since all users fetched even if only one role is needed
• + Simpler management – Users may have multiple roles so selecting specific role may be difficult
• - Relationship type not clear
• Is user teach or student of class (e.g. if they have both roles)
• User can be a teacher of one class and a student of another at a university/college
• Would need to define relationship somewhere (terms, usermeta, etc.)
• + Easy to fetch all terms associated with user at once (since single taxonomy)
2. Different taxonomy depending on role
• Example: Class’ teacher is lined using class_teacher taxonomy
• + Easy to retrieve all users acting as teachers
• - Multiple queries required to get all users associated with class (teachers and students)
• + Efficient – Only retrieve users with desired role
• + Relationship defined
• class_teacher, class_student, etc.
• Usable roles are defined in code when defining relationships
• + Simple to iterate over roles to get all users linked to class

EDU: Notes – Management: Data Relationships was originally published on Archetyped on December 14, 2011 08:26am

When there’s no one else breathing down your neck to get stuff done, you have to be even more attentive to how effective you are with your time.

I work on projects that I am passionate about and have a deep interest in.  Nonetheless, momentum is incredibly important as any project worth doing will have it’s share of hard work.  Therefore, when I am working on a project and making good progress, I will generally continue to work on that project until I reach a milestone of some sort.  Stopping short of that feels like a waste of all of the momentum I’ve built up when the end could be just around the corner.

The Problem

It may be obvious what kind of problem this way of working may present– by focusing all of my attention on a single project, all other projects fall by the wayside.  If I was only interested and passionate about one thing at a time, this would not be a problem, but alas, I am usually working on several projects concurrently.

This leads to the dreaded “should be’s”, where I think about how I should be working on one project while I am working on another.  The longer that I don’t get back to working on a project, the stronger the feeling that I should be working on it gets.

The end result is a feeling of dissatisfaction with what I’ve accomplished and a sense that there’s always more to be done.

A Solution?

Though I plan out what I will be working on next, I have always been of the belief that there wasn’t much point in creating a rigid schedule because I wanted the freedom to continue working on a project into the next day (or week), should the current task require it.  Creating a fixed schedule would either stop all momentum cold, or cause me to feel guilty because I wasn’t sticking to it.

But was it true?

I decided to put my assumptions to the test, and so for the next 30 days, I will be working on a fixed schedule where my projects change on a daily basis.

The Details

• I will be working on 1-2 projects (maximum) per day.
• I will work on different projects each day of the week.
• The schedule repeats on a weekly basis.

Here is my weekly schedule for the next 30 days:

Monday

1. Simple Lightbox
2. Business development

Tuesday

1. Cornerstone
2. Site maintenance

Wednesday

1. Art (design, photography, etc.)
2. Wordpress in the Classroom

Thursday

1. Video (Shoot)

Friday

1. Video (Edit)

I’ve grouped projects together that are either related somehow (e.g. Cornerstone is used heavily on this site, so it will play a role in the site’s maintenance), or where one project will present a refreshing change from the other (so that I don’t get burnt out during the day).

The Rules

As always, I like to keep things simple, so the rules are deliberately brief:

• I can only work on the projects scheduled for the current day.  If I finish the tasks I scheduled for the current day’s projects, I can work on other tasks for those projects, but it would probably be better if I called it a day.
• Exception: User support for my software/plugins is exempt from this as waiting a week for an answer to a question or bug report is unreasonable.
• No adjustments. At least for the initial 30 days. I want to see this schedule through to the end to see how bad (or good) things get if I rigidly hold myself to the original schedule.

Closing Thoughts

I don’t begrudge structure, in fact I love it.  I’ve just never felt that a rigid and predefined schedule lends itself to creativity.  However, one of the questions I’d like explore over the next 30 days is if adding more structure to my schedule will free me to be more creative in other areas (e.g. in my projects).

30 Days of Schedules was originally published on Archetyped on October 16, 2011 08:00pm