opened, other, tools, what's up

One More on Generalists

A few days ago, I wrote about the problems with breaking coherent web platforms down to delivering only a specialized kind of content. The kind of attitude that knowledge shall be brought to you by Blackboard, while your marketing website is okay to run on Drupal or WordPress. When technologies are siloed, we not only isolate the teams who end up only managing a specific platform for its specific function (teaching and learning, marketing or research…), but we also exclude many potential audiences from finding out or learning more about the topic.

How little do we know! Here is a question for you: is (TCMP) a research, marketing, teaching and learning website or professional development tool? I would argue it is all of the above! It is written by medical practitioners, discusses various health issues in an open environment, and contributes to the general public’s knowledge and understanding of those issues. Four out of six UBC values are covered here: Advancing and Sharing Knowledge, Public Interest (open blog, written in popular format); Excellence, Integrity, (done by medical experts): check, check, check, check!

It all looks good, but there is a catch: it is very uncertain whether there would be such a buy-in from busy doctors if there were nothing in return. No free lunch, as usual: upon publishing in TCMP, contributors to the site get study credits from the College of Family Physicians of Canada – the body that regulates licenses of medical doctors in Canada.
In my mind, this creates a great symbiosis of sustainable approach to promoting and sharing knowledge with the doctors’ need to keep their professional license! This model (along with many possible variations) is something that should come naturally to the university; the multipurpose, integrated approach should be the standard and not the notable exception to common practices of creating sites that are designed to deliver to one audience only.

It is a great marketing website as well – it has thousands of subscribers, it created quite a buzz in the medical community, it shows up high in Google searches. By driving a lot of traffic to UBC, it promotes the University’s work, excellence, impact and value to the community… and attracts potential students!

The best possible marketing for the university is the work of its people – so let’s make more of that visible. By doing so, we are also helping faculty, staff, and students promote their work and build portfolios and future careers. We are contributing to the public domain and sharing knowledge that would otherwise stay locked behind the secure doors of a closed LMS and then erased at the term’s end.

So, the university’s key engagements – teaching, learning, research, creation, and also, its practical need for marketing and promotion – should all happily cohabitate to deliver on the university’s key values – to connect to the community, make an impact on the local and global scale, etc.

And this is where we go back to our generalist story – generalists are not paralysed by too narrow of job description; with their many different skills are able to draw subtle connections between marketing and research, learning and networking. They can design balanced interfaces, and continually deepen and enrich the interactions around knowledge that is created, nurtured and shared in open, and provide a fantastic opportunity for the university to (besides saving tons of money on waste) promote itself in a more meaningful and community-oriented way, reinvent itself and at least try to find its niche in the new rich online landscape that seems to be reshaping fast and getting ahead of us at an accelerated rate.

blogs, opened, other, tools

Generalists vs. the Army of Waste

In many larger organizations, there is often a push to put things in a certain “order” that administration (non-educators and non-developers) is comfortable with. In the case of higher-ed, especially with its large, cubicle-seated, vertically organized groups, there is a strong trend to divide technology into The student learning management system (LMS) that covers “all” students’ teaching and learning needs, and into The content management system (CMS) that, managed by marketing people, is meant for “administrative” websites. And, of course, research is under a separate VP and thus needs to have its own systems and staff. And so on, for all the lovely silos. The more broken down, the merrier; this system creates more bureaucracy, more reporting and analysis. It is disconnected both from within itself and from its users, so it requires more staff to keep it going, more managers and more analysts.

This approach is a very typical and also very wrong one, as the expertise and resources needed to run and support, let’s say CMS (seen as “administrative” or “marketing” tool, though some of the best research or teaching and learning websites are built using UBC  CMS), are identical to those of an open publishing framework for teaching and learning (such as blog or wiki platforms) and shouldn’t be separated – one general, flexible and robust platform is capable of responding to most web needs. To further complicate things, in the administration’s desire to do things “properly” (like mid-’70s-IT properly) we are introducing too many flavours of unnecessary overhead or waste (Lean terminology), known as learning or web strategists (my title actually, though I wear few other hats), project managers, business analysts, faculty liaisons and many other fancy names.

We work (teach, design, code…) in the environment of rapid and constant change (perpetual beta) and by building so many layers between the faculty member who wants to experiment and embrace change, and the developer who wants to give, hack and create change, we are actually killing the experiment and killing the change itself.  We kill creativity and innovation, while we are supposed to support it. By stripping down web developers to the role of only coding whatever project manager or business analyst requires (and because managers and analysts are not creators and producers, they are not in business of inventing, hacking, dreaming and designing), we kill the much needed seeds of agility and entrepreneurship and we leave very little room for linchpins in us, with hard and practical skills.

That’s the shame, because the best of Web2.0 is telling us that we need to simplify things, not over-plan or over-analyse. Hear the idea, build, measure, learn. That’s why instead of many unnecessary roles, we need developers to be more of the generalists (Scott, thanks for this find) – for typical web company that’s the person that does information architecture, UX, coding front-end, back-end, db, scaling, bit of design; at the university, it is all of that plus bit of pedagogy and learning design. Not a biggy, few months of the right exposure for a reasonably intelligent individual.

blogs, tools, what's up

A Year Later

Actually, over a year since I last posted here. I guess I am not much of a blogger.
Anyways, just checking in, I am not sure why, perhaps to lubricate those few rows in one of the thousands of mySql tables that store much of UBC’s publishing content.

Aside from my dormant blog, things look great, we’ve never been busier and I mean healthy busy: working with great people, getting smart requests and supporting development of many new and existing websites.
I’ve never been happier with how our little team is performing and how much we deliver.

blogs, tools, what's up

about running large WP install

Just during last week, two well-known edublog spaces, Jim Groom’s UMW blogs and Alan Levine’s CodDogBlog (both WP-based) experienced serious hiccups and in case of UMW blogs serious downtime. There are many to blame, from mindless spammers to the mighty Google, but in the nutshell, problem seems to be the nature of how we use WP in general: our small pieces became one giant does-it-all piece with many loose holes that all the bad guys (viagra/casino/porn) and good guys (google and similar bots) so vigorously exploit.

this is why it is leaning
Can we hold it together?

In the next couple of posts, I will try to go through our experiences with running WordPress in larger institution; here is the preview:

  • scope (what we offer):
    Delete and forget about WP themes and base your offer on templates: blog, course, website, community portal, project management space, resource repository, rss aggregate, event calendar, research space, photo gallery…
  • signups and user management:
    Implement campus’ single-sign-on authentication, and write plugins to connect to campus student information system to download students to course blogs. One of the biggest time-consuming tasks with large user base systems is the user management and account creation and you want to automate this as much as possible.
  • development  framework and system maintenance:
    VMs, SVNs and Backups – your university IT department is your friend. Hang out with these guys and revisit your statements on cheap and dirty if you want to last. Development, Verification and Production server – you gotta have all three. In sync. Often looks like mission impossible but it is actually doable.
  • typical development tasks
    Based on our experience, these are the typical tasks in WP development that require framework mentioned in the previous bullet – you don’t want to try any of these on your production server:

    • Major Content/Architectural changes – your client will ask you to shift few hundred pages around. This is the case primarily with WP-based websites mostly
    • Look and Feel work – you have to change all your typography, headers and footers and rewrite all your CSS files because campus decided to update their look and feel.
    • Plug-ins development  – Make sure that your development environment is exactly the same as your production one or you are up for nasty surprises.
    • Back-end upgrades – Your LAMP, your WP core needs to stay upto date.
    • Migrations – We did migrate few hundred MovableType blogs to WP and survived.
  • buy-in, support and training
    Don’t count on your edupunk coolness. You are here to provide good service and support.
  • searching and reporting
    It is often pain in the butt and slows down the servers but it also gives a lot in return. Any WP coding that stores content in custom fields will not be indexed by WP itself so just use Google search instead. And after using Google analytics you can’t use any other tool. Also make sure to be able to report on number of blogs (and their types) and users at any time.
  • new requests
    Say no. They are typically unreasonable, otherwise plugins would be already written. If you hear it 1000 times than you might want to consider it. Clients are usually wrong.
blogs, tools, wikis

gimmie wiki!

Enej Bajgorić created the plugin for republishing MediaWiki (or any HTML) pages within WP.

For those who liked the idea, here are some good news: we are continuing development of this plugin for our culturepedia project.

Here is the functionality in the nutshell;

  • seamlessly integrate wiki pages, categories or searches into WP blogs.
  • works as both shortcode (more here and here) and widget.
  • content can be constantly refreshed (as wiki pages changes) or one-time brought in.
  • the wiki content will be searchable by google (not the case with WikiInc).
  • the wiki pages could be further shared by using embed functionality.

For example, if I want to publish all the pages from ubc wiki that are stored in both culturepedia AND idioms category, I should shortcode something like this:

[gimmiewiki -category URL: category:culturepedia,idioms refresh:yes popups:yes|embed|link]

Or if we end up developing a visual component, it could look like this:

Will get back with more!

blogs, tools

migrating a kiloblog: ubc goes from movabletype to wordpress

We have been running Movable Type for over three years and for number of reasons (far better platform, CWL integration, the support overhead and availability of plugins, to name a few) decided to move to WordPress.

Since last summer we have pretty smooth, CWL-enabled, pilot WPMU installation available to selected UBC faculty, staff and students; so far, things look pretty good!

Now that we are at ease with our ability to run the new system, we are planning to migrate more than a thousand MT users  and blogs to WP.  We are expecting that only the small number of people will actually want to move their blog – for the rest… well, we are thinking about it as the great autumn-cleaning opportunity. Anyways, EVERY blog will be backed up and saved in case users come in the future to restate their blogs.
Here is the process with its requirements and challenges along with the ideas on how to go around them:

Setup: There are three environments in which the migration takes place:

  • Original MT (Source)
  • Verification WP (Check-point)
  • Production WP (Target)

The process:

1.       Notifying the Users and Project Tracking.
We will send the email to users describing the migration process and inviting them to create an account and a blog on the Production WP, which is the new location for their blog. We have classified all the users on the scale of 1 to 5, based on the importance of the blog (we have tons of abandoned blogs) and we also have special VIP list – those blogs get extra attention!
Here are the fields of our migration tracking database:
blog_id, blog_name, entries_count, blog_site_url, author_id, author_name, author_email, other_blog_owners, blog_description(tags), priority_rating, migration_notes,  vip, new_author_name, other_authors_translation, new_url.
You can sense the complexity of this operation by just looking at these fields!

2.       User reports back
Upon creating the account, blog user gets back to us with the account and blog info (details instructions on how to do this were sent in an email). We then proceed with the next step of migration:

3.       The Import to Verification WP
MT blogs and users’ info are exported from MT to Verification WP by using WeblogsMigrator plugin that Michael Ha and Seth Tee have specifically developed for this purpose. This WP plugin actually queries the MT database and retrieves all the information on the given blog and user and then stores them in the Verification WP. So, we end up with blogs, authors and comments, all properly imported within WP Verification. Users from MT keep the same username in WP Verification. It is worth mentioning that in this process, all the links that point to the other posts within same blog are being re-written to point to the new URLs. It is even cooler that we are grabbing all the media files (images, movies) and storing them automatically in WP Verification.

4.       Finalizing the Look and Feel and dealing with blogs’ extras.
Here, we apply theme that look close to one in MT, for look and feel consistency. For VIPs, this may involve additional tweaking or creation of the new theme. If needed, we consult with users on how to proceed with extra content (if there is any) of their MT blogs. Usually, this means dealing with side bar content and advising on how to recreate these in WP (through using widgets).

5.       From WP Verification to Production
After examining the blog and round of QA, we do another round of export/import; this time using slightly changed WeblogMigrator. Things get hairy with blogs that have multiple authors; for this reason, we made sure that this plugin, which looks very much like standard WP to WP import, also provides username matching. With this, we make sure that the original users keep ownership of their posts after the blog is migrated. It is expected that many users will have different usernames from those on MT, that’s why we cannot automate this process. This is only important for multi user blogs.

6.       Redirecting old URLs
One of the major requirements of this process is to make sure that every post will automatically redirect to the new post’s URL.  In the process of importing (step 3), we record the old and the new URL for each post and store it in the database. This table is now queried to produce the  .htaccess file that will, for every post, redirect to the new post URL.

7.       User takes control
At this point user has the complete control over their blog. We are expecting that owners of more complex blogs will require additional support that we can provide through pointing to various WP support websites and examples online, or via direct support.

blogs, tools

resolving “comment-goes-to-admin-not-author” wp issue

We are planning the migration of our Movable-Type based websites to WordPress. While offering way nicer management interface and wealth of advanced controls, default WP installation still misses a few things that we took for granted in MT.

Here is the one: On our big websites that run on MT, such as Leap or OLT, we have multiple authors maintain number of posts and pages. Whenever there is a comment on any of these posts or pages, it should be directed to the author of the post for approval.

MT does this well, all the comments indeed go to the authors of the posts. WP however, redirects all the comments to the site admin (?!) with authors left in the dark about the new comments. Admin is usually the technical person who created the blog, without the clue what comments to approve. This makes management of the site very difficult as authors need to be able to respond to the comments in timely fashion.

Luckily we‘ve found Mark Ghosh’s extension that does exactly what we need: emails the comment to authors for approval. The extension is installed and working great at