I usually don't write much about what I do for a living. In previous years, I considered such public discussion taboo. My previous job didn't have an Internet media policy, and no recommended code of conduct. My current job, however, is more enlightened. 

Today was the first day at the Curriculum Lead summit at work. For obvious reasons, I can't discuss the specifics of what happened, but there was something that gave me a great deal to think about. When working as a IT Trainer and Consultant with my previous company, it often seemed I was the only one with a passion for what IT education can be. I formulated and tried out design choices, education styles, and writing styles. Eventually, I settled into my characteristic wordy, detailed, graphic-rich style.

I based much of my work on a few fundemental ideas:

• Some students are visual learners. They need screenshots.
• Some students are word learners. They need instructions.
• Some students are intimidated. They need encouragement.
• The instructor delivers value in the classroom.
• The course manual delivers a longer value outside the classroom.

Historically, I've tried to "write the instructor out of the equation" in my classes. The idea is that while the instructor can be very knowledgeable and very skilled, most people will not retain what you teach them once they leave the classroom. The course manual then, is the real source of continuing value in the class. I feel a certain kind of pride when I've found my course books on the desks of clients, dogeared and annotated. 

You can call it the "thick book" approach. Two of my classes nearly are 1000 pages each -- huge, thick tomes that would cause injury if hurled at a coworker. Maintaining material of this size, however, is no easy task. A major update to one of the these courses could take many, many weeks. I tend to work very, very fast, so the scale of the task didn't intimidate me as it did others.

Today, however, someone challenged those conceptions.

The fast-talking man from India presented his curriculum analysis with impressive energy. After the introductions and details were out of the way, he told us a story. Once upon a time his class was as long as my classes -- longer, in fact. I can certainly see why, as the product he's writing about is a complex piece of development and runtime software. I've read the manuals for it. With the length of the material, he was achieving a majority of passed certifications. 

Then the story took a turn. As an experiment, he put the huge, thick tome aside and gave the students a very carefully and engagingly written short manual only a tenth of the length. Amazingly, the precentage of students that passed the certification did not changeI was blown away. So short a manual, achieving such good results? Could that even work? Apparently, it did, resoundingly well too. The advantages of this approach are obvious. The shorter length means shorter development times and less turn over time when new versions are brought to market. Much discussion ensued about the "happy medium" in course material.

This has me reevaluating my fundamental theories. Many of them were formed in a very different environment that I am now. While the instructors at my previous job were highly skilled, we often had to wear a great many hats. This often resulted in quality problems when an instructor was assigned to a class where they are not a product expert. This colored my early perceptions of how course material should be written. The courseware was what I could control, what I could bake in quality from the beginning. Today, however, the instructors at my current job often specialize in the product in which they teach. Rarely are instructors switched out because a customer issue cropped up elsewhere. This is the difference between working in a small company, and now a large one.

At 6pm, my phone unexpectedly uttered a loud notification alarm, followed by the rattle of a small device vibrating on a tabletop. The little plastic trackball shines the occasional yellow before fading to darkness. 

When I unlock the device to see what it's on about, I'm presented with the picture of a little pink squid. Above the chibi mollusk, a yellow speech bubble reads off "Time to work! Draw something!!!" This isn't the first time it's done this; in fact, it's been doing this for over two days now. Each time reading messages like:

• Stop snoozing! Draw something!!!
• No more postponing! Draw something!!!
  
  ...and...
  
  
• You can do it! Draw something!!!

The reminders come from a small application called Asterid, that's synced to my RememberTheMilk account. It was easy enough to put it off the first time, but it's becoming more and more difficult to ignore my squidform task master. 

Oddly enough, I have been finding myself with the growing desire to draw. This has been a problem for me for over two years now. I simply haven't had it in me to keep it up. The reasons are only outnumbered by the excuses. I'm curious, however, if by going out of my way to add a task to my list, schedule a time or day to attend to my derelict creative pursuits, that I've subconsciously given myself a reason to draw something, rather than not.

One thing that occurred to me today is that we really don't have a good place to put projects on deninet. For a while, I had planned on implementing project management features on the site. I did manage to start some of that by adding events and tasks. The further I got, however, the more it became obvious that "wasn't us". Other sites do project management far better and if anything, we should leverage those.

Project management, however, isn't the same as project -- is it? The former implies task lists, schedules, events, Gantt Charts... These aren't the features I wish to develop or maintain on the site. Again, other sites dedicated to that purpose do it far, far better. What I'm thinking about is a place to showcase our projects. 

Let me give you a little history: Years and years ago I came to the realization late one night that what we seemed to have in abundance was ideas. What we needed was a mechanism by which to store and categorize them. This was the beginning of a project called Net*man*a*ger. It was a Java based client for entering and storing ideas to a remote website running a Perl backend. Hey, it was the early 2000s, thick clients were all the rage! I spent most of my holiday vacation that year happily steeped in Java code.

As I began to put together the interface, I created a data topology. Ideas were made of Versions, Versions had Thoughts contributed to them, Comments and Votes were applied to Thoughts. Soon, however, I began to realize that Ideas needed a top level container. Naturally, the first one I thought of was "Project". The more I thought about it, however, the term seemed limiting. Not all Ideas could be grouped into projects, some were just....ideas. So, I instead decided to use the word "Net".

Eventually as client matured, I began to realize that it would be far simpler to develop a website that was both the backend and the front end. This was a couple before "Web 2.0" became a popular buzzword. Add more than a dash of ambition, and the "Internet Idea Database" was born. The term "nets" were dropped and replaced with "Channels".

I worked for years on IIDB, but there were a lot of problems with how it was put together. The code was too constrained and not easily expandable. I no longer wanted to work on the project, and as the system powering our website, I was stuck. I chucked it all and switched to Drupal. My thought was I could eventually reimplement IIDB on Drupal, but that never quite materialized. 

This is why deninet has channels today. First there were projects, then nets, and now channels. I had assumed that any project we wish to implement today on deninet could have a channel associated with it. These project-central channels would be the hubs by which visitors could find and follow project developments. This is why we have a Springboard, and why you can subscribe to channels to follow posts.

The biggest problem with this system is just how monolithic it is. How can we tell a "project-centric" channel from one that just is for general blog posts? There are a few ways to go about this. A field could be added that would identify the type of channel it is. This seems inadaquate however, as projects would have special fields attached to them like what users are working in what roles on the project, or the current status, or expected release date. Doesn't that imply that these should not be a channel but something unique?

I'm still figuring that one out...

Trice: One can imagine Spock's surprise on getting their first glimpse of the video from the Romulan vessel. "Wow, Romulans look just like my father."
Tess: Hehehe
Tess: I always wondered that myself.
Trice: =^_^=
Trice: Been discussing with [name redacted] whether it should have been Romulans as the antagonists in The Search for Spock.
Tess: Well, neither Romulans or Kilngons are more than a cardboard cutout for "The Villian!" in this film.
Trice: The one in question?
Tess: *nods*
Tess: They serve no purpose in the story but to drive events forward. They don't have any real stake in Genesis other than "they want it". Honestly, the whole thing is so generic that it might as well be a creeping smog monster blowing up the Grishim and killing Kirk's kid.
Tess: At least then there would be the minor amusement of "WTF Smog Monster!?!?!!"
Trice: :D
Tess: And Kirk turns out to be Ultraman.....and they fight. >.>
Trice: o.o

It occurred to me a few days ago that there are a few navigation issues with the site. 

At present, there's no easy way to get an RSS feed of individual users posts. In fact, there's no easy way to get a feed of any user's posts without going through the channel mechanism. It's not an impossible thing to fix, thankfully. My thought is to create overrides for the default user profile pages just as we have for the channels. I've done a little tinkering this evening, but nothing significant.

Pazi brought up a good point earlier this evening. There's actually no way (for a non-admin user) to view a concise list of users and user activity on the site. Again, this isn't a hard thing for Drupal. I can build a page that will give us a few of all users on the site in a variety of forms. The problem is where. 

There are a number of problems like this on deninet. The front page isn't particularly useful as it could be. Channels can often be confusing. The way posts are kept private is entirely unintuitive. 

*sigh*

I could go on, but I'd rather spend my remaining energy this evening trying to think of a solution.