Category Archives: blogging systems

What Not to Tweet

Here’s a list I tweeted earlier.

Twenty Things You Should Never, Ever Tweet for Fear of Retaliation from the Tweet Police

  1. Lists. Too difficult to follow.
  2. Do’s and don’ts. Who died and made you bandleader?
  3. Personal thoughts. Nobody cares what anyone else thinks, anyway.
  4. Anything in a foreign language. It confuses everyone.
  5. Personal opinions. You may offend someone.
  6. Jokes. Same reason as #5.
  7. Links. Too dangerous, since some could be malicious.
  8. Anything in “the second degree.” The bareness of context prevents careful reading.
  9. Anything insightful. Who do you think you are?
  10. Personal replies. Can’t you get a room?
  11. -20: What @oatmeal said you shouldn’t tweet. If it’s funny, it must be true.

In case it wasn’t clear… Yes, I mean this as sarcasm. One of my pet peeves is to hear people tell others what to do or not to do, without appropriate context. It’s often perceived to be funny or useful but, to be honest, it just rubs me the wrong way. Sure, they’re allowed to do it. I won’t prevent them. I don’t even think they should stop, that’s really not for me to decide. It’s just that, being honest with myself, I realize how negative of an effect it has on me. It actually reaches waaaaay down into something I don’t care to visit very often.

The Oatmeal can be quite funny. Reading a few of these comics, recently, I literally LOLed. And this one probably pleased a lot of people, because it described some of their own pet peeves. Besides, it’s an old comic, probably coming from a time when tweets were really considered to be answers to the original Twitter prompt: “What are you doing?” (i.e., before the change to the somewhat more open “What’s happening?”). But I’ve heard enough expressions of what people should or shouldn’t do with a specific social media system that I felt the need to vent. So, that was the equivalent of a rant (and this post is closer to an actual rant).

I mean, there’s a huge difference between saying “these are the kinds of uses for which I think Twitter is the appropriate tool” and the flat-out dismissal of what others have done. While Twitter is old news, as social media go, it’s still unfolding and much of its strength comes from the fact that we don’t actually have a rigid notion of what it should be.

Not that there aren’t uses of Twitter I dislike. In fact, for much of 2009, I felt it was becoming too commercial for my taste. I felt there was too much promotion of commercial entities and products, and that it was relatively difficult to avoid such promotional tweets if one were to follow the reciprocation principle (“I really should make sure I follow those who follow me, even if a large proportion of them are just trying to increase their follower counts”). But none of this means that “Twitter isn’t for commercial promotion.” Structurally, Twitter almost seems to be made for such uses. Conceptually, it comes from the same “broadcast” view of communication, shared by many marketers, advertisers, PR experts, and movie producers. As social media tools go, Twitter is among the most appropriate ones to use to broadly distribute focused messages without having to build social relationships. So, no matter how annoyed I may get at these tweets and at commercial Twitterers, it’d be inaccurate to say that “Twitter isn’t for that.” Besides, “Twitter, Inc.” has adopted commercial promotion as a major part of its “business model.” No matter what one feels about this (say, that it’s not very creative or that it will help distinguish between commercial tweets and the rest of Twitter traffic), it seems to imply that Twitter is indeed about commercial promotion as much as it is about “shar[ing] and discover[ing] what’s happening now.”

The same couldn’t be said about other forms of tweeting that others may dislike. It’d be much harder to make a case for, say, conference liveblogging as being an essential part of what Twitter is about. In fact, some well-known and quite vocal people have made pronouncements about how inappropriate, in their minds, such a practice was. To me, much of it sounds like attempts at rationalizing a matter of individual preference. Some may dislike it but Twitter does make a very interesting platform for liveblogging conferences. Sure, we’ve heard about the negative consequences of the Twitter backchannel at some high-profile events. And there are some technical dimensions of Twitter which make liveblogging potentially more annoying, to some users, than if it were on another platform. But claiming that Twitter isn’t for liveblogging  reveals a rather rigid perspective of what social media can be. Again, one of the major strengths in Twitter is its flexibility. From “mentions” and “hashtags” to “retweets” and metadata, the platform has been developing over time based on usage patterns.

For one thing, it’s now much more conversational than it was in 2007, and some Twitter advocates are quite proud of that. So one might think that Twitter is for conversation. But, at least in my experience, Twitter isn’t that effective a tool for two-way communication let alone for conversations involving more than two people. So, if we’re to use conversation to evaluate Twitter (as its development may suggest we should do), it seems not to be that successful.

In this blog version of my list, I added a header with a mention of the “Tweet Police.” I mean it in the way that people talk about the “Fashion Police,” wish immediately makes me think about “fashion victims,” the beauty myth, the objectification of the human body, the social pressure to conform to some almost-arbitrary canons, the power struggles between those who decide what’s fashionable and those who need to dress fashionably to be accepted in some social contexts, etc. Basically, it leads to rather unpleasant thoughts. In a way, my mention of the “Tweet Police” is a strategy to “fight this demon” by showing how absurd it may become. Sure, it’d be a very tricky strategy if it were about getting everyone to just “get the message.” But, in this case, it’s about doing something which feels good. It’s my birthday, so I allow myself to do this.


Installing BuddyPress 1.2 on FatCow: Quick Edition

I recently posted a rambling version of instructions about how to install BuddyPress 1.1.3 on FatCow:

Installing BuddyPress on a Webhost « Disparate.

BuddyPress 1.2 was just released, with some neat new features including the ability to run on a standard (non-WPµ) version of WordPress and a new way to handle templates. They now have three-step instructions on how to install BuddyPress. Here’s my somewhat more verbose take (but still reasonably straightforward and concise). A few things are FatCow-specific but everything should be easy to adapt for any decent webhost. (In fact, it’d likely be easier elsewhere.)

  1. Create database in FatCow’s Manage MySQL
  2. Download WP 2.9.2 from the download page.
  3. Uncompress WP  using FatCow’s Archive Gateway
  4. Rename “wordpress” to <name> (not necessary, but useful, I find; “community” or “commons” would make sense for <name>)
  5. Go to <full domain>/<name> (say, “example.com/commons” if you used “commons” for <name> and your domain were “example.com”)
  6. Click “Create a Configuration file”
  7. Click “Let’s Go”
  8. Enter database information from database created in MySQL
  9. Change “localhost” to “<username>.fatcowmysql.com” (where <username> is your FatCow username)
  10. Click “Submit”
  11. Click “Run the Install”
  12. Fill in blog title and email, decide on crawling
  13. Click on “Install WordPress”
  14. Copy generated password
  15. Enter login details
  16. Click “Log In”
  17. Click “Yes, Take me to my profile page”
  18. Add “New password” (twice)
  19. Click “Update Profile”
  20. Click “Plugins”
  21. Click “Add New”
  22. In the searchbox, type “BuddyPress”
  23. Find BuddyPress 1.2 (created by “The BuddyPress Community”)
  24. Click “Install”
  25. Click “Install Now”
  26. Click “Activate Plugin”
  27. Click “update your permalink structure”
  28. Choose an option (say, “Day and Name”)
  29. Click “Save Changes”
  30. Click “Appearance”
  31. Click “Activate” under BuddyPress default

You now have a full BuddyPress installation. “Social Networking in a Box”

You can do a number of things, now. Including visiting your BuddyPress installation by clicking on the “Visit Site” link at the top of the page.

But there are several options in BuddyPress which should probably be set if you want to do anything with the site. For instance, you can setup forums through the bbPress installation which is included in BuddyPress. So, if you’re still in the WordPress dashboard, you can do the following:

  1. Click “BuddyPress”
  2. Click “Forum Setup”
  3. Click “Set up a new bbPress installation”
  4. Click “Complete Installation”

This way, any time you create a new group, you’ll be able to add a forum to it. To do so:

  1. Click “Visit Site”
  2. Click “Groups”
  3. Click “Create a Group”
  4. Fill in the group name and description.
  5. Click “Create Group and Continue”
  6. Select whether or not you want to enable the discussion forum, choose the privacy options, and click “Next Step”
  7. Choose an avatar (or leave the default one) and click “Next Step”
  8. Click “Finish”

You now have a fully functioning group, with discussion forum.

There’s a lot of things you can now do, including all sorts of neat plugins, change the theme, etc. But this installation is fully functional and fun. So I’d encourage you to play with it, especially if you already have a group of users. The way BuddyPress is set up, you can do all sorts of things on the site itself. So you can click “Visit Site” and start creating profiles, groups, etc.

One thing with the BuddyPress Default Theme, though, is that it doesn’t make it obvious how you can come back to the Dashboard. You can do so by going to “<full domain>/<name>/wp-admin/” (adding “/wp-admin/” to your BuddyPress address). Another way, which is less obvious, but also works is to go to a blog comment (there’s one added by defaul) and click on “Edit.”


Installing BuddyPress on a Webhost

[Jump here for more technical details.]

A few months ago, I installed BuddyPress on my Mac to try it out. It was a bit of an involved process, so I documented it:

WordPress MU, BuddyPress, and bbPress on Local Machine « Disparate.

More recently, I decided to get a webhost. Both to run some tests and, eventually, to build something useful. BuddyPress seems like a good way to go at it, especially since it’s improved a lot, in the past several months.

In fact, the installation process is much simpler, now, and I ran into some difficulties because I was following my own instructions (though adapting the process to my webhost). So a new blogpost may be in order. My previous one was very (possibly too) detailed. This one is much simpler, technically.

One thing to make clear is that BuddyPress is a set of plugins meant for WordPress µ (“WordPress MU,” “WPMU,” “WPµ”), the multi-user version of the WordPress blogging platform. BP is meant as a way to make WPµ more “social,” with such useful features as flexible profiles, user-to-user relationships, and forums (through bbPress, yet another one of those independent projects based on WordPress).

While BuddyPress depends on WPµ and does follow a blogging logic, I’m thinking about it as a social platform. Once I build it into something practical, I’ll probably use the blogging features but, in a way, it’s more of a tool to engage people in online social activities. BuddyPress probably doesn’t work as a way to “build a community” from scratch. But I think it can be quite useful as a way to engage members of an existing community, even if this engagement follows a blogger’s version of a Pareto distribution (which, hopefully, is dissociated from elitist principles).

But I digress, of course. This blogpost is more about the practical issue of adding a BuddyPress installation to a webhost.

Webhosts have come a long way, recently. Especially in terms of shared webhosting focused on LAMP (or PHP/MySQL, more specifically) for blogs and content-management. I don’t have any data on this, but it seems to me that a lot of people these days are relying on third-party webhosts instead of relying on their own servers when they want to build on their own blogging and content-management platforms. Of course, there’s a lot more people who prefer to use preexisting blog and content-management systems. For instance, it seems that there are more bloggers on WordPress.com than on other WordPress installations. And WP.com blogs probably represent a small number of people in comparison to the number of people who visit these blogs. So, in a way, those who run their own WordPress installations are a minority in the group of active WordPress bloggers which, itself, is a minority of blog visitors. Again, let’s hope this “power distribution” not a basis for elite theory!

Yes, another digression. I did tell you to skip, if you wanted the technical details!

I became part of the “self-hosted WordPress” community through a project on which I started work during the summer. It’s a website for an academic organization and I’m acting as the organization’s “Web Guru” (no, I didn’t choose the title). The site was already based on WordPress but I was rebuilding much of it in collaboration with the then-current “Digital Content Editor.” Through this project, I got to learn a lot about WordPress, themes, PHP, CSS, etc. And it was my first experience using a cPanel- (and Fantastico-)enabled webhost (BlueHost, at the time). It’s also how I decided to install WordPress on my local machine and did some amount of work from that machine.

But the local installation wasn’t an ideal solution for two reasons: a) I had to be in front of that local machine to work on this project; and b) it was much harder to show the results to the person with whom I was collaborating.

So, in the Fall, I decided to get my own staging server. After a few quick searches, I decided HostGator, partly because it was available on a monthly basis. Since this staging server was meant as a temporary solution, HG was close to ideal. It was easy to set up as a PayPal “subscription,” wasn’t that expensive (9$/month), had adequate support, and included everything that I needed at that point to install a current version of WordPress and play with theme files (after importing content from the original site). I’m really glad I made that decision because it made a number of things easier, including working from different computers, and sending links to get feedback.

While monthly HostGator fees were reasonable, it was still a more expensive proposition than what I had in mind for a longer-term solution. So, recently, a few weeks after releasing the new version of the organization’s website, I decided to cancel my HostGator subscription. A decision I made without any regret or bad feeling. HostGator was good to me. It’s just that I didn’t have any reason to keep that account or to do anything major with the domain name I was using on HG.

Though only a few weeks elapsed since I canceled that account, I didn’t immediately set out to transition to a new webhost. I didn’t go from HostGator to another webhost.

But having my own webhost still remained at the back of my mind as something which might be useful. For instance, while not really making a staging server necessary, a new phase in the academic website project brought up a sandboxing idea. Also, I went to a “WordPress Montreal” meeting and got to think about further WordPress development/deployment, including using BuddyPress for my own needs (both as my own project and as a way to build my own knowledge of the platform) instead of it being part of an organization’s project. I was also thinking about other interesting platforms which necessitate a webhost.

(More on these other platforms at a later point in time. Bottom line is, I’m happy with the prospects.)

So I wanted a new webhost. I set out to do some comparison shopping, as I’m wont to do. In my (allegedly limited) experience, finding the ideal webhost is particularly difficult. For one thing, search results are cluttered with a variety of “unuseful” things such as rants, advertising, and limited comparisons. And it’s actually not that easy to give a new webhost a try. For one thing, these hosting companies don’t necessarily have the most liberal refund policies you could imagine. And, switching a domain name between different hosts and registrars is a complicated process through which a name may remain “hostage.” Had I realized what was involved, I might have used a domain name to which I have no attachment or actually eschewed the whole domain transition and just try the webhost without a dedicated domain name.

Doh!
Live and learn. I sure do. Loving almost every minute of it.

At any rate, I had a relatively hard time finding my webhost.

I really didn’t need “bells and whistles.” For instance, all the AdSense, shopping cart, and other business-oriented features which seem to be publicized by most webhosting companies have no interest, to me.

I didn’t even care so much about absolute degree of reliability or speed. What I’m to do with this host is fairly basic stuff. The core idea is to use my own host to bypass some limitations. For instance, WordPress.com doesn’t allow for plugins yet most of the WordPress fun has to do with plugins.

I did want an “unlimited” host, as much as possible. Not because expect to have huge resource needs but I just didn’t want to have to monitor bandwidth.

I thought that my needs would be basic enough that any cPanel-enabled webhost would fit. As much as I could see, I needed FTP access to something which had PHP 5 and MySQL 5. I expected to install things myself, without use of the webhost’s scripts but I also thought the host would have some useful scripts. Although I had already registered the domain I wanted to use (through Name.com), I thought it might be useful to have a free domain in the webhosting package. Not that domain names are expensive, it’s more of a matter of convenience in terms of payment or setup.

I ended up with FatCow. But, honestly, I’d probably go with a different host if I were to start over (which I may do with another project).

I paid 88$ for two years of “unlimited” hosting, which is quite reasonable. And, on paper, FatCow has everything I need (and I bunch of things I don’t need). The missing parts aren’t anything major but have to do with minor annoyances. In other words, no real deal-breaker, here. But there’s a few things I wish I had realized before I committed on FatCow with a domain name I actually want to use.

Something which was almost a deal-breaker for me is the fact that FatCow requires payment for any additional subdomain. And these aren’t cheap: the minimum is 5$/month for five subdomains, up to 25$/month for unlimited subdomains! Even at a “regular” price of 88$/year for the basic webhosting plan, the “unlimited subdomains” feature (included in some webhosting plans elsewhere) is more than three times more expensive than the core plan.

As I don’t absolutely need extra subdomains, this is mostly a minor irritant. But it’s one reason I’ll probably be using another webhost for other projects.

Other issues with FatCow are probably not enough to motivate a switch.

For instance, the PHP version installed on FatCow (5.2.1) is a few minor releases behind the one needed by some interesting web applications. No biggie, especially if PHP is updated in a relatively reasonable timeframe. But still makes for a slight frustration.

The MySQL version seems recent enough, but it uses non-standard tools to manage it, which makes for some confusion. Attempting to create some MySQL databases with obvious names (say “wordpress”) fails because the database allegedly exists (even though it doesn’t show up in the MySQL administration). In the same vein, the URL of the MySQL is <username>.fatcowmysql.com instead of localhost as most installers seem to expect. Easy to handle once you realize it, but it makes for some confusion.

In terms of Fantastico-like simplified installation of webapps, FatCow uses InstallCentral, which looks like it might be its own Fantastico replacement. InstallCentral is decent enough as an installation tool and FatCow does provide for some of the most popular blog and CMS platforms. But, in some cases, the application version installed by FatCow is old enough (2005!)  that it requires multiple upgrades to get to a current version. Compared to other installation tools, FatCow’s InstallCentral doesn’t seem really efficient at keeping track of installed and released versions.

Something which is partly a neat feature and partly a potential issue is the way FatCow handles Apache-related security. This isn’t something which is so clear to me, so I might be wrong.

Accounts on both BlueHost and HostGator include a public_html directory where all sorts of things go, especially if they’re related to publicly-accessible content. This directory serves as the website’s root, so one expects content to be available there. The “index.html” or “index.php” file in this directory serves as the website’s frontpage. It’s fairly obvious, but it does require that one would understand a few things about webservers. FatCow doesn’t seem to create a public_html directory in a user’s server space. Or, more accurately, it seems that the root directory (aka ‘/’) is in fact public_html. In this sense, a user doesn’t have to think about which directory to use to share things on the Web. But it also means that some higher-level directories aren’t available. I’ve already run into some issues with this and I’ll probably be looking for a workaround. I’m assuming there’s one. But it’s sometimes easier to use generally-applicable advice than to find a custom solution.

Further, in terms of access control… It seems that webapps typically make use of diverse directories and .htaccess files to manage some forms of access controls. Unix-style file permissions are also involved but the kind of access needed for a web app is somewhat different from the “User/Group/All” of Unix filesystems. AFAICT, FatCow does support those .htaccess files. But it has its own tools for building them. That can be a neat feature, as it makes it easier, for instance, to password-protect some directories. But it could also be the source of some confusion.

There are other issues I have with FatCow, but it’s probably enough for now.

So… On to the installation process… 😉

It only takes a few minutes and is rather straightforward. This is the most verbose version of that process you could imagine…

Surprised? 😎

Disclaimer: I’m mostly documenting how I did it and there are some things about which I’m unclear. So it may not work for you. If it doesn’t, I may be able to help but I provide no guarantee that I will. I’m an anthropologist, not a Web development expert.

As always, YMMV.

A few instructions here are specific to FatCow, but the general process is probably valid on other hosts.

I’m presenting things in a sequence which should make sense. I used a slightly different order myself, but I think this one should still work. (If it doesn’t, drop me a comment!)

In these instructions, straight quotes (“”) are used to isolate elements from the rest of the text. They shouldn’t be typed or pasted.

I use “example.com” to refer to the domain on which the installation is done. In my case, it’s the domain name I transfered to FatCow from another registrar but it could probably be done without a dedicated domain (in which case it would be “<username>.fatcow.com” where “<username>” is your FatCow username).

I started with creating a MySQL database for WordPress MU. FatCow does have phpMyAdmin but the default tool in the cPanel is labeled “Manage MySQL.” It’s slightly easier to use for creating new databases than phpMyAdmin because it creates the database and initial user (with confirmed password) in a single, easy-to-understand dialog box.

So I created that new database, user, and password, noting down this information. Since that password appears in clear text at some point and can easily be changed through the same interface, I used one which was easy to remember but wasn’t one I use elsewhere.
Then, I dowloaded the following files to my local machine in order to upload them to my FatCow server space. The upload can be done through either FTP or FatCow’s FileManager. I tend to prefer FTP (via CyberDuck on the Mac or FileZilla on PC). But the FileManager does allow for easy uploads.
(Wish it could be more direct, using the HTTP links directly instead of downloading to upload. But I haven’t found a way to do it through either FTP or the FileManager.)
At any rate, here are the four files I transfered to my FatCow space, using .zip when there’s a choice (the .tar.gz “tarball” versions also work but require a couple of extra steps).
  1. WordPress MU (wordpress-mu-2.9.1.1.zip, in my case)
  2. Buddymatic (buddymatic.0.9.6.3.1.zip, in my case)
  3. EarlyMorning (only one version, it seems)
  4. EarlyMorning-BP (only one version, it seems)

Only the WordPress MU archive is needed to install BuddyPress. The last three files are needed for EarlyMorning, a BuddyPress theme that I found particularly neat. It’s perfectly possible to install BuddyPress without this specific theme. (Although, doing so, you need to install a BuddyPress-compatible theme, if only by moving some folders to make the default theme available, as I explained in point 15 in that previous tutorial.) Buddymatic itself is a theme framework which includes some child themes, so you don’t need to install EarlyMorning. But installing it is easy enough that I’m adding instructions related to that theme.

These files can be uploaded anywhere in my FatCow space. I uploaded them to a kind of test/upload directory, just to make it clear, for me.

A major FatCow idiosyncrasy is its FileManager (actually called “FileManager Beta” in the documentation but showing up as “FileManager” in the cPanel). From my experience with both BlueHost and HostGator (two well-known webhosting companies), I can say that FC’s FileManager is quite limited. One thing it doesn’t do is uncompress archives. So I have to resort to the “Archive Gateway,” which is surprisingly slow and cumbersome.

At any rate, I used that Archive Gateway to uncompress the four files. WordPress µ first (in the root directory or “/”), then both Buddymatic and EarlyMorning in “/wordpress-mu/wp-content/themes” (you can chose the output directory for zip and tar files), and finally EarlyMorning-BP (anywhere, individual files are moved later). To uncompress each file, select it in the dropdown menu (it can be located in any subdirectory, Archive Gateway looks everywhere), add the output directory in the appropriate field in the case of Buddymatic or EarlyMorning, and press “Extract/Uncompress”. Wait to see a message (in green) at the top of the window saying that the file has been uncompressed successfully.

Then, in the FileManager, the contents of the EarlyMorning-BP directory have to be moved to “/wordpress-mu/wp-content/themes/earlymorning”. (Thought they could be uncompressed there directly, but it created an extra folder.) To move those files in the FileManager, I browse to that earlymorning-bp directory, click on the checkbox to select all, click on the “Move” button (fourth from right, marked with a blue folder), and add the output path: /wordpress-mu/wp-content/themes/earlymorning

These files are tweaks to make the EarlyMorning theme work with BuddyPress.

Then, I had to change two files, through the FileManager (it could also be done with an FTP client).

One change is to EarlyMorning’s style.css:

/wordpress-mu/wp-content/themes/earlymorning/style.css

There, “Template: thematic” has to be changed to “Template: buddymatic” (so, “the” should be changed to “buddy”).

That change is needed because the EarlyMorning theme is a child theme of the “Thematic” WordPress parent theme. Buddymatic is a BuddyPress-savvy version of Thematic and this changes the child-parent relation from Thematic to Buddymatic.

The other change is in the Buddymatic “extensions”:

/wordpress-mu/wp-content/themes/buddymatic/library/extensions/buddypress_extensions.php

There, on line 39, “$bp->root_domain” should be changed to “bp_root_domain()”.

This change is needed because of something I’d consider a bug but that a commenter on another blog was kind enough to troubleshoot. Without this modification, the login button in BuddyPress wasn’t working because it was going to the website’s root (example.com/wp-login.php) instead of the WPµ installation (example.com/wordpress-mu/wp-login.php). I was quite happy to find this workaround but I’m not completely clear on the reason it works.

Then, something I did which might not be needed is to rename the “wordpress-mu” directory. Without that change, the BuddyPress installation would sit at “example.com/wordpress-mu,” which seems a bit cryptic for users. In my mind, “example.com/<name>,” where “<name>” is something meaningful like “social” or “community” works well enough for my needs. Because FatCow charges for subdomains, the “<name>.example.com” option would be costly.

(Of course, WPµ and BuddyPress could be installed in the site’s root and the frontpage for “example.com” could be the BuddyPress frontpage. But since I think of BuddyPress as an add-on to a more complete site, it seems better to have it as a level lower in the site’s hierarchy.)

With all of this done, the actual WPµ installation process can begin.

The first thing is to browse to that directory in which WPµ resides, either “example.com/wordpress-mu” or “example.com/<name>” with the “<name>” you chose. You’re then presented with the WordPress µ Installation screen.

Since FatCow charges for subdomains, it’s important to choose the following option: “Sub-directories (like example.com/blog1).” It’s actually by selecting the other option that I realized that FatCow restricted subdomains.

The Database Name, username and password are the ones you created initially with Manage MySQL. If you forgot that password, you can actually change it with that same tool.

An important FatCow-specific point, here, is that “Database Host” should be “<username>.fatcowmysql.com” (where “<username>” is your FatCow username). In my experience, other webhosts use “localhost” and WPµ defaults to that.

You’re asked to give a name to your blog. In a way, though, if you think of BuddyPress as more of a platform than a blogging system, that name should be rather general. As you’re installing “WordPress Multi-User,” you’ll be able to create many blogs with more specific names, if you want. But the name you’re entering here is for BuddyPress as a whole. As with <name> in “example.com/<name>” (instead of “example.com/wordpress-mu”), it’s a matter of personal opinion.

Something I noticed with the EarlyMorning theme is that it’s a good idea to keep the main blog’s name relatively short. I used thirteen characters and it seemed to fit quite well.

Once you’re done filling in this page, WPµ is installed in a flash. You’re then presented with some information about your installation. It’s probably a good idea to note down some of that information, including the full paths to your installation and the administrator’s password.

But the first thing you should do, as soon as you log in with “admin” as username and the password provided, is probably to the change that administrator password. (In fact, it seems that a frequent advice in the WordPress community is to create a new administrator user account, with a different username than “admin,” and delete the “admin” account. Given some security issues with WordPress in the past, it seems like a good piece of advice. But I won’t describe it here. I did do it in my installation and it’s quite easy to do in WPµ.

Then, you should probably enable plugins here:

example.com/<name>/wp-admin/wpmu-options.php#menu

(From what I understand, it might be possible to install BuddyPress without enabling plugins, since you’re logged in as the administrator, but it still makes sense to enable them and it happens to be what I did.)

You can also change a few other options, but these can be set at another point.

One option which is probably useful, is this one:

Allow new registrations Disabled
Enabled. Blogs and user accounts can be created.
Only user account can be created.

Obviously, it’s not necessary. But in the interest of opening up the BuddyPress to the wider world without worrying too much about a proliferation of blogs, it might make sense. You may end up with some fake user accounts, but that shouldn’t be a difficult problem to solve.

Now comes the installation of the BuddyPress plugin itself. You can do so by going here:

example.com/<name>/wp-admin/plugin-install.php

And do a search for “BuddyPress” as a term. The plugin you want was authored by “The BuddyPress Community.” (In my case, version 1.1.3.) Click the “Install” link to bring up the installation dialog, then click “Install Now” to actually install the plugin.

Once the install is done, click the “Activate” link to complete the basic BuddyPress installation.

You now have a working installation of BuddyPress but the BuddyPress-savvy EarlyMorning isn’t enabled. So you need to go to “example.com/<name>/wp-admin/wpmu-themes.php” to enable both Buddymatic and EarlyMorning. You should then go to “example.com/<name>/wp-admin/themes.php” to activate the EarlyMorning theme.

Something which tripped me up because it’s now much easier than before is that forums (provided through bbPress) are now, literally, a one-click install. If you go here:

example.com/<name>/wp-admin/admin.php?page=bb-forums-setup

You can set up a new bbPress install (“Set up a new bbPress installation”) and everything will work wonderfully in terms of having forums fully integrated in BuddyPress. It’s so seamless that I wasn’t completely sure it had worked.

Besides this, I’d advise that you set up a few widgets for the BuddyPress frontpage. You do so through an easy-to-use drag-and-drop interface here:

example.com/<name>/wp-admin/widgets.php

I especially advise you to add the Twitter RSS widget because it seems to me to fit right in. If I’m not mistaken, the EarlyMorning theme contains specific elements to make this widget look good.

After that, you can just have fun with your new BuddyPress installation. The first thing I did was to register a new user. To do so, I logged out of my admin account,  and clicked on the Sign Up button. Since I “allow new registrations,” it’s a very simple process. In fact, this is one place where I think that BuddyPress shines. Something I didn’t explain is that you can add a series of fields for that registration and the user profile which goes with it.

The whole process really shouldn’t take very long. In fact, the longest parts have probably to do with waiting for Archive Gateway.

The rest is “merely” to get people involved in your BuddyPress installation. It can happen relatively easily, if you already have a group of people trying to do things together online. But it can be much more complicated than any software installation process… 😉


Sharing Tool Wishlist

The following is an edited version of a wishlist I had been keeping on the side. The main idea is to define what would be, in my mind, the “ultimate social bookmarking system.” Which, obviously, goes way beyond social bookmarking. In a way, I even conceive of it as the ultimate tool for sharing online content. Yes, it’s that ambitious. Will it ever exist? Probably not. Should it exist? I personally think so. But I may be alone in this. Surely, you’ll tell me that I am indeed alone, which is fine. As long as you share your own wishlist items.

The trigger for my posting this is that someone contacted me, asking for what I’d like in a social bookmarking system. I find this person’s move quite remarkable, as a thoughtful strategy. Not only because this person contacted me directly (almost flattering), but because such a request reveals an approach to listening and responding to people’s needs that I find lacking in some software development circles.

This person’s message served as a prompt for my blogging this, but I’ve been meaning to blog this for a while. In fact, my guess is that I created a first version of this wishlist in 2007 after having it on my mind for a while before that. As such, it represents a type of “diachronic” or “longitudinal” view of social bookmarking and the way it works in the broader scheme of social media.

Which also means that I wrote this before I heard about Google Wave. In fact, I’m still unclear about Google Wave and I’ll need to blog about that. Not that I expect Wave to fulfill all the needs I set up for a sharing tool, but I get the impression that Google is finally putting some cards on the table.

The main part of this post is in outline form. I often think through outlines, especially with such a type of notes. I fully realize that it may not be that clear, as a structure, for other people to understand. Some of these bullet points cover a much broader issue than what they look like. But the overall idea might be fairly obvious to grasp, even if it may sound crazy to other people.

I’m posting this to the benefit of anyone who may wish to build the killer app for social media. Of course, it’s just one man’s opinion. But it’s my entitled opinion.

Concepts

What do we share online?

  • “Link”
  • “Page”
  • Identified content
  • Text
    • Narrative
    • Contact information
    • Event description
  • Contact information
  • Event invitation
  • Image
  • Recording
  • Structured content
  • Snippet
  • Access to semi-private content
  • Site’s entry point

Selective sharing

Private
  • Archiving
  • Cloud access
Individually shared
  • “Check this out”
  • Access to address book
  • Password protection
  • Specialization/expertise
  • Friendship
Group shared
  • Shared interests (SIG)
  • Collaboration (task-based)
Shared through network
  • Define identity in network
  • Semi-public
Public
  • Publishing
  • Processed
  • Reading lists

Notetaking

  • Active reading
  • Anchoring text
  • Ad hoc list of bookmarks
  • “Empty URL”
    • Create container/page
    • Personal notes

Todos

  • To read
  • To blog
  • To share
  • To update
  • Projects
    • GTD
    • Contexts
  • Add to calendar (recognized as event)

Outlining/Mindmapping

  • Manage lists of links
  • Prioritize
  • Easily group

Social aspects of sharing

  • Gift economy
  • Personal interaction
  • Trust
  • Hype
  • Value
  • Customized

Cloud computing

  • Webware
  • “Online disk”
  • Without download
  • Touch devices
  • Edit online

Personal streaming

  • Activities through pages
  • Logging
  • Flesh out personal profile

Tagging

  • “Folksonomy”
  • Enables non-hierarchical structure
  • Semantic fields
  • Related tags
  • Can include hierarchy
  • Tagclouds define concept map

Required Features

Crossplatform, crossbrowser

  • Browser-specific tools
  • Bookmarklets
  • Complete access through cloud
Keyboard shortcuts
  • Quick add (to account)
  • Vote
  • Bookmark all tabs (à la Flock)
  • Quick tags

Related pages

Recommended
  • Based on social graph
  • Based on tags
  • Based on content
  • Based on popularity
  • Pointing to this page

Quickly enter links

  • Add in place (while editing)
  • Similar to “spell as you type”
  • Incremental search
  • Add full link (title, URL, text, metadata)

Archiving

  • Prevent linkrot
  • Prepare for post-processing (offline reading, blogging…)
  • Enable bulk processing
  • Maintain version history
  • Internet Archive

Automatic processing

  • Tags
  • Summary
  • Wordcount
  • Reading time
  • Language(s)
  • Page structure analysis
  • Geotagging
  • Vote

Thread following

  • Blog comments
  • Forum comments
  • Trackbacks
  • Pings

Exporting

All
  • Archiving
  • Prepare for import
  • Maintain hierarchy
Selected
  • Tag
  • Category
  • Recently used
  • Shared
  • Site homepage
  • Blogroll
  • Blogs
Formats
  • Other services
  • HTML
  • RSS
  • OPML
  • Widget
Features
  • Comments
  • Tags
  • Statistics
  • Content

Offline processing

  • Browser-based
  • Device based
  • Offline archiving
  • Include content
  • Synchronization

Microblogging support

  • Laconi.ca/Identi.ca
  • Twitter
  • Ping.fm
  • Jaiku

Fixed/Static URL

  • Prevent linkrot
  • Maintain list for same page
  • Short URLs
  • Automatically generated
  • Expansion on mouseover
  • Statistics

Authentication

  • Use of resources
  • Identify
  • Privacy
  • Unnecessary for basic processing
  • Sticks (no need to login frequently)
  • Access to contacts and social graph
  • Multiple accounts
    • Personal/professional
    • Contexts
    • Group accounts
  • Premium accounts
    • Server space
    • Usage statistics
    • Promotion
  • Support
    • OpenID
      • As group login
    • Google Accounts
    • Facebook Connect
    • OAuth

Integration

  • Web history
  • Notebook
  • Blogging platform
  • Blog editor
  • Microblogging platform
  • Logbook
  • General purpose content editor
  • Toolbar
  • URL shortening
  • Address book
  • Social graph
  • Personal profile
  • Browser
    • Bookmarks
    • History
    • Autocomplete
  • Analytics
  • Email
  • Search
    • Online
    • Offline

Related Tools

  • Diigo
  • WebCitation
  • Ping.fm
  • BackType
  • Facebook share
  • Blog This
  • Link This
  • Share this
  • Digg
  • Plum
  • Spurl
  • CoComments
  • MyBlogLog
  • TwtVite
  • Twistory
  • Windows Live Writer
  • Magnolia
  • Stumble Upon
  • Delicious
  • Google Reader
  • Yahoo Pipes
  • Google Notebook
  • Zoho Notebook
  • Google Browser Sync
  • YouTube
  • Flock
  • Zotero

Relevant Blogposts


Social Networks and Microblogging

Microblogging (Laconica, Twitter, etc.) is still a hot topic. For instance, during the past few episodes of This Week in Tech, comments were made about the preponderance of Twitter as a discussion theme: microblogging is so prominent on that show that some people complain that there’s too much talk about Twitter. Given the centrality of Leo Laporte’s podcast in geek culture (among Anglos, at least), such comments are significant.

The context for the latest comments about TWiT coverage of Twitter had to do with Twitter’s financials: during this financial crisis, Twitter is given funding without even asking for it. While it may seem surprising at first, given the fact that Twitter hasn’t publicized a business plan and doesn’t appear to be profitable at this time, 

Along with social networking, microblogging is even discussed in mainstream media. For instance, Médialogues (a media critique on Swiss national radio) recently had a segment about both Facebook and Twitter. Just yesterday, Comedy Central’s The Daily Show with Jon Stewart made fun of compulsive twittering and mainstream media coverage of Twitter (original, Canadian access).

Clearly, microblogging is getting some mindshare.

What the future holds for microblogging is clearly uncertain. Anything can happen. My guess is that microblogging will remain important for a while (at least a few years) but that it will transform itself rather radically. Chances are that other platforms will have microblogging features (something Facebook can do with status updates and something Automattic has been trying to do with some WordPress themes). In these troubled times, Montreal startup Identi.ca received some funding to continue developing its open microblogging platform.  Jaiku, bought by Google last year, is going open source, which may be good news for microblogging in general. Twitter itself might maintain its “marketshare” or other players may take over. There’s already a large number of third-party tools and services making use of Twitter, from Mahalo Answers to Remember the Milk, Twistory to TweetDeck.

Together, these all point to the current importance of microblogging and the potential for further development in that sphere. None of this means that microblogging is “The Next Big Thing.” But it’s reasonable to expect that microblogging will continue to grow in use.

(Those who are trying to grok microblogging, Common Craft’s Twitter in Plain English video is among the best-known descriptions of Twitter and it seems like an efficient way to “get the idea.”)

One thing which is rarely mentioned about microblogging is the prominent social structure supporting it. Like “Social Networking Systems” (LinkedIn, Facebook, Ning, MySpace…), microblogging makes it possible for people to “connect” to one another (as contacts/acquaintances/friends). Like blogs, microblogging platforms make it possible to link to somebody else’s material and get notifications for some of these links (a bit like pings and trackbacks). Like blogrolls, microblogging systems allow for lists of “favourite authors.” Unlike Social Networking Systems but similar to blogrolls, microblogging allow for asymmetrical relations, unreciprocated links: if I like somebody’s microblogging updates, I can subscribe to those (by “following” that person) and publicly show my appreciation of that person’s work, regardless of whether or not this microblogger likes my own updates.

There’s something strangely powerful there because it taps the power of social networks while avoiding tricky issues of reciprocity, “confidentiality,” and “intimacy.”

From the end user’s perspective, microblogging contacts may be easier to establish than contacts through Facebook or Orkut. From a social science perspective, microblogging links seem to approximate some of the fluidity found in social networks, without adding much complexity in the description of the relationships. Subscribing to someone’s updates gives me the role of “follower” with regards to that person. Conversely, those I follow receive the role of “following” (“followee” would seem logical, given the common “-er”/”-ee” pattern). The following and follower roles are complementary but each is sufficient by itself as a useful social link.

Typically, a microblogging system like Twitter or Identi.ca qualifies two-way connections as “friendship” while one-way connections could be labelled as “fandom” (if Andrew follows Betty’s updates but Betty doesn’t follow Andrew’s, Andrew is perceived as one of Betty’s “fans”). Profiles on microblogging systems are relatively simple and public, allowing for low-involvement online “presence.” As long as updates are kept public, anybody can connect to anybody else without even needing an introduction. In fact, because microblogging systems send notifications to users when they get new followers (through email and/or SMS), subscribing to someone’s update is often akin to introducing yourself to that person. 

Reciprocating is the object of relatively intense social pressure. A microblogger whose follower:following ratio is far from 1:1 may be regarded as either a snob (follower:following much higher than 1:1) or as something of a microblogging failure (follower:following much lower than 1:1). As in any social context, perceived snobbery may be associated with sophistication but it also carries opprobrium. Perry Belcher  made a video about what he calls “Twitter Snobs” and some French bloggers have elaborated on that concept. (Some are now claiming their right to be Twitter Snobs.) Low follower:following ratios can result from breach of etiquette (for instance, ostentatious self-promotion carried beyond the accepted limit) or even non-human status (many microblogging accounts are associated to “bots” producing automated content).

The result of the pressure for reciprocation is that contacts are reciprocated regardless of personal relations.  Some users even set up ways to automatically follow everyone who follows them. Despite being tricky, these methods escape the personal connection issue. Contrary to Social Networking Systems (and despite the term “friend” used for reciprocated contacts), following someone on a microblogging service implies little in terms of friendship.

One reason I personally find this fascinating is that specifying personal connections has been an important part of the development of social networks online. For instance, long-defunct SixDegrees.com (one of the earliest Social Networking Systems to appear online) required of users that they specified the precise nature of their relationship to users with whom they were connected. Details escape me but I distinctly remember that acquaintances, colleagues, and friends were distinguished. If I remember correctly, only one such personal connection was allowed for any pair of users and this connection had to be confirmed before the two users were linked through the system. Facebook’s method to account for personal connections is somewhat more sophisticated despite the fact that all contacts are labelled as “friends” regardless of the nature of the connection. The uniform use of the term “friend” has been decried by many public commentators of Facebook (including in the United States where “friend” is often applied to any person with whom one is simply on friendly terms).

In this context, the flexibility with which microblogging contacts are made merits consideration: by allowing unidirectional contacts, microblogging platforms may have solved a tricky social network problem. And while the strength of the connection between two microbloggers is left unacknowledged, there are several methods to assess it (for instance through replies and republished updates).

Social contacts are the very basis of social media. In this case, microblogging represents a step towards both simplified and complexified social contacts.

Which leads me to the theme which prompted me to start this blogpost: event-based microblogging.

I posted the following blog entry (in French) about event-based microblogging, back in November.

Microblogue d’événement

I haven’t received any direct feedback on it and the topic seems to have little echoes in the social media sphere.

During the last PodMtl meeting on February 18, I tried to throw my event-based microblogging idea in the ring. This generated a rather lengthy between a friend and myself. (Because I don’t want to put words in this friend’s mouth, who happens to be relatively high-profile, I won’t mention this friend’s name.) This friend voiced several objections to my main idea and I got to think about this basic notion a bit further. At the risk of sounding exceedingly opinionated, I must say that my friend’s objections actually comforted me in the notion that my “event microblog” idea makes a lot of sense.

The basic idea is quite simple: microblogging instances tied to specific events. There are technical issues in terms of hosting and such but I’m mostly thinking about associating microblogs and events.

What I had in mind during the PodMtl discussion has to do with grouping features, which are often requested by Twitter users (including by Perry Belcher who called out Twitter Snobs). And while I do insist on events as a basis for those instances (like groups), some of the same logic applies to specific interests. However, given the time-sensitivity of microblogging, I still think that events are more significant in this context than interests, however defined.

In the PodMtl discussion, I frequently referred to BarCamp-like events (in part because my friend and interlocutor had participated in a number of such events). The same concept applies to any event, including one which is just unfolding (say, assassination of Guinea-Bissau’s president or bombings in Mumbai).

Microblogging users are expected to think about “hashtags,” those textual labels preceded with the ‘#’ symbol which are meant to categorize microblogging updates. But hashtags are problematic on several levels.

  • They require preliminary agreement among multiple microbloggers, a tricky proposition in any social media. “Let’s use #Bissau09. Everybody agrees with that?” It can get ugly and, even if it doesn’t, the process is awkward (especially for new users).
  • Even if agreement has been reached, there might be discrepancies in the way hashtags are typed. “Was it #TwestivalMtl or #TwestivalMontreal, I forgot.”
  • In terms of language economy, it’s unsurprising that the same hashtag would be used for different things. Is “#pcmtl” about Podcamp Montreal, about personal computers in Montreal, about PCM Transcoding Library…?
  • Hashtags are frequently misunderstood by many microbloggers. Just this week, a tweep of mine (a “peep” on Twitter) asked about them after having been on Twitter for months.
  • While there are multiple ways to track hashtags (including through SMS, in some regions), there is no way to further specify the tracked updates (for instance, by user).
  • The distinction between a hashtag and a keyword is too subtle to be really useful. Twitter Search, for instance, lumps the two together.
  • Hashtags take time to type. Even if microbloggers aren’t necessarily typing frantically, the time taken to type all those hashtags seems counterproductive and may even distract microbloggers.
  • Repetitively typing the same string is a very specific kind of task which seems to go against the microblogging ethos, if not the cognitive processes associated with microblogging.
  • The number of character in a hashtag decreases the amount of text in every update. When all you have is 140 characters at a time, the thirteen characters in “#TwestivalMtl” constitute almost 10% of your update.
  • If the same hashtag is used by a large number of people, the visual effect can be that this hashtag is actually dominating the microblogging stream. Since there currently isn’t a way to ignore updates containing a certain hashtag, this effect may even discourage people from using a microblogging service.

There are multiple solutions to these issues, of course. Some of them are surely discussed among developers of microblogging systems. And my notion of event-specific microblogs isn’t geared toward solving these issues. But I do think separate instances make more sense than hashtags, especially in terms of specific events.

My friend’s objections to my event microblogging idea had something to do with visibility. It seems that this friend wants all updates to be visible, regardless of the context. While I don’t disagree with this, I would claim that it would still be useful to “opt out” of certain discussions when people we follow are involved. If I know that Sean is participating in a PHP conference and that most of his updates will be about PHP for a period of time, I would enjoy the possibility to hide PHP-related updates for a specific period of time. The reason I talk about this specific case is simple: a friend of mine has manifested some frustration about the large number of updates made by participants in Podcamp Montreal (myself included). Partly in reaction to this, he stopped following me on Twitter and only resumed following me after Podcamp Montreal had ended. In this case, my friend could have hidden Podcamp Montreal updates and still have received other updates from the same microbloggers.

To a certain extent, event-specific instances are a bit similar to “rooms” in MMORPG and other forms of real-time many-to-many text-based communication such as the nostalgia-inducing Internet Relay Chat. Despite Dave Winer’s strong claim to the contrary (and attempt at defining microblogging away from IRC), a microblogging instance could, in fact, act as a de facto chatroom. When such a structure is needed. Taking advantage of the work done in microblogging over the past year (which seems to have advanced more rapidly than work on chatrooms has, during the past fifteen years). Instead of setting up an IRC channel, a Web-based chatroom, or even a session on MSN Messenger, users could use their microblogging platform of choice and either decide to follow all updates related to a given event or simply not “opt-out” of following those updates (depending on their preferences). Updates related to multiple events are visible simultaneously (which isn’t really the case with IRC or chatrooms) and there could be ways to make event-specific updates more prominent. In fact, there would be easy ways to keep real-time statistics of those updates and get a bird’s eye view of those conversations.

And there’s a point about event-specific microblogging which is likely to both displease “alpha geeks” and convince corporate users: updates about some events could be “protected” in the sense that they would not appear in the public stream in realtime. The simplest case for this could be a company-wide meeting during which backchannel is allowed and even expected “within the walls” of the event. The “nothing should leave this room” attitude seems contradictory to social media in general, but many cases can be made for “confidential microblogging.” Microblogged conversations can easily be archived and these archives could be made public at a later date. Event-specific microblogging allows for some control of the “permeability” of the boundaries surrounding the event. “But why would people use microblogging instead of simply talking to another?,” you ask. Several quick answers: participants aren’t in the same room, vocal communication is mostly single-channel, large groups of people are unlikely to communicate efficiently through oral means only, several things are more efficiently done through writing, written updates are easier to track and archive…

There are many other things I’d like to say about event-based microblogging but this post is already long. There’s one thing I want to explain, which connects back to the social network dimension of microblogging.

Events can be simplistically conceived as social contexts which bring people together. (Yes, duh!) Participants in a given event constitute a “community of experience” regardless of the personal connections between them. They may be strangers, ennemies, relatives, acquaintances, friends, etc. But they all share something. “Participation,” in this case, can be relatively passive and the difference between key participants (say, volunteers and lecturers in a conference) and attendees is relatively moot, at a certain level of analysis. The key, here, is the set of connections between people at the event.

These connections are a very powerful component of social networks. We typically meet people through “events,” albeit informal ones. Some events are explicitly meant to connect people who have something in common. In some circles, “networking” refers to something like this. The temporal dimension of social connections is an important one. By analogy to philosophy of language, the “first meeting” (and the set of “first impressions”) constitute the “baptism” of the personal (or social) connection. In social media especially, the nature of social connections tends to be monovalent enough that this “baptism event” gains special significance.

The online construction of social networks relies on a finite number of dimensions, including personal characteristics described in a profile, indirect connections (FOAF), shared interests, textual content, geographical location, and participation in certain activities. Depending on a variety of personal factors, people may be quite inclusive or rather exclusive, based on those dimensions. “I follow back everyone who lives in Austin” or “Only people I have met in person can belong to my inner circle.” The sophistication with which online personal connections are negotiated, along such dimensions, is a thing of beauty. In view of this sophistication, tools used in social media seem relatively crude and underdeveloped.

Going back to the (un)conference concept, the usefulness of having access to a list of all participants in a given event seems quite obvious. In an open event like BarCamp, it could greatly facilitate the event’s logistics. In a closed event with paid access, it could be linked to registration (despite geek resistance, closed events serve a purpose; one could even imagine events where attendance is free but the microblogging backchannel incurs a cost). In some events, everybody would be visible to everybody else. In others, there could be a sort of ACL for diverse types of participants. In some cases, people could be allowed to “lurk” without being seen while in others radically transparency could be enforced. For public events with all participants visible, lists of participants could be archived and used for several purposes (such as assessing which sessions in a conference are more popular or “tracking” event regulars).

One reason I keep thinking about event-specific microblogging is that I occasionally use microblogging like others use business cards. In a geek crowd, I may ask for someone’s Twitter username in order to establish a connection with that person. Typically, I will start following that person on Twitter and find opportunities to communicate with that person later on. Given the possibility for one-way relationships, it establishes a social connection without requiring personal involvement. In fact, that person may easily ignore me without the danger of a face threat.

If there were event-specific instances from microblogging platforms, we could manage connections and profiles in a more sophisticated way. For instance, someone could use a barebones profile for contacts made during an impersonal event and a full-fledged profile for contacts made during a more “intimate” event. After noticing a friend using an event-specific business card with an event-specific email address, I got to think that this event microblogging idea might serve as a way to fill a social need.

 

More than most of my other blogposts, I expect comments on this one. Objections are obviously welcomed, especially if they’re made thoughtfully (like my PodMtl friend made them). Suggestions would be especially useful. Or even questions about diverse points that I haven’t addressed (several of which I can already think about).

So…

 

What do you think of this idea of event-based microblogging? Would you use a microblogging instance linked to an event, say at an unconference? Can you think of fun features an event-based microblogging instance could have? If you think about similar ideas you’ve seen proposed online, care to share some links?

 

Thanks in advance!


My Blogging Life

Phew!

I just finished what might be one of my longest blogposts, ever:

PHP #1: Austin, TX (USA) « The Compulsive Pedestrian

I guess I had a lot to say… 😎

It’s on a new topical blog I created. That blog deals with what I now like to call “carfree living.” I was originally calling this “carless living” but “carfree” sounds better, for obvious reasons. 😉

I’ve been using that blog to talk about places that I know and that I perceive to be pedestrian-friendly or pedestrian-hostile. Hopefully, some people will connect to some of what I say about those places and eventually leave me comments. (Hint, hint! 😀 )

Actually, I’ve been receiving a decent number of comments through my blogs, recently. In fact, one blogpost became something of a forum thread, thanks in part to Carl Dyke who recently became a blogger. I “met” Carl on the anthro group blog Savage Minds, where Kerim Friedman and others have expressed their desire for more connections between anthro-friendly blogs.

For reasons which might not be entirely surprising, my blogpost comparing Texan and Albertan cities is getting a decent level of attention, especially from Edmontonians. In fact, it should be featured as a guest column on a community site. I even started looking at Edmonton as a place where I could live in the not-too-distant future!

Some of my other blogging activities are helping me get or keep in touch with diverse people. A coffee roaster, a former student, some local friends in both Montreal and Austin…

Though I tend not to care so much, I notice that visits to my main blog have been on the rise, in the past few months. If this tendency is maintained, I might get beyond my previous record of 5,867 visits in a month (in February, 2007). Through the rest of 2007, monthly visits to this blog ranged between 3,500 and 4,500, with a dip to 2,800 in June. (Yeah, I know. Fas-ci-na-ting.)

What’s more, I think that a larger proportion of visits to my blog are to posts I personally find interesting (as opposed to some silly posts which get lots of hits because their titles).

I’m now a bit more familiar with the new interface for WordPress.com blogs. Though the change was probably not visible to readers, the changes are rather extreme. What I find sad is that several features went away with the update: realtime wordcount, list nesting, automatic answerlinks, drag-and-drop widget management, and comma-separated categories. None of these features was really essential and the last one had good reasons to go, but it still implies a major adaptation. In fact, as much as I enjoy blogging on WordPress (and as grateful as I am to have access to a feature-full free blog host), I take issue with some of the ways Matt Mullenweg and his Automattic crew have treated WordPress.com users, on occasion. In this case, it would have been much easier if they had described the changes in advance, providing some documentation to enable a smooth transition. I know the update’s focus was on WordPress installed on people’s servers (i.e., not on blogs hosted on WordPress.com). But it does make me feel like a second-class citizen, which may not be what Automattic wants.

Thanks in part to changes in the way WordPress.com handles tags and categories, I’ve been able to clean up some of my categories for this blog. It’s still pretty much a mess, I know. But it’s much closer to being manageable than it was. And I notice the difference quite easily.

I also shuffled some widgets around my blog design, which was surprisingly difficult because of the changes in the WordPress.com interface. I think my blog is just a bit cleaner than it was.

The fact that my daily average blogpost count has increased in the past several days is partly due to a decision of mine to do more things through my blogs. I eventually realized what part blogging had to play in my life and these past several days were an occasion for me to use blogging as a kind of release. There really is something quite therapeutic about blogging.

One thing it might mean, though, is that this blogging spree will taper off relatively soon. As I’m preparing to move for the 22nd time since December, 2000, it’ll probably be best if I focus on other things besides blogging.

The cool thing is, blogging allows for this kind of behavior. The only thing a decrease in my blogging activities might mean is a drop in readership. But I care very little about hits and there are other ways for me to get in touch with people.


Obligatory New Feature Test

Yeah, I know, everyone is probably tired of WordPress.com blogs having test posts. Here’s mine.

Basically, I want to make sure editing in Safari 3.1 works as advertised, without garbling linebreaks and such.

So… Erm… About that WordPress.com update…

I’d say the update on WordPress.com is less significant than the 2.5 update for the WordPress package itself. But it’s interesting to have the whole blog updated without our intervention. The interface is different enough that I kind of wish they could have allowed us to keep the old version.

Ah, well…

Still, there’s a few neat new features.

I like the fact that tags can be edited. So they end up being fairly close to categories while remaining distinctive enough. I might convert more categories to tags, to finally clean up my blog (I really have hundreds of categories). Still, tags aren’t added in the del.icio.us or Blogger way.

The new category support makes sense, in context. It actually clarifies the difference between tags and categories.

I also like the new design of the main dashboard page. Quite efficient to see, at a glance, what’s been going on. I tend to not obsess on my stats that much, but I do enjoy looking at them. And I do care about pings and trackbacks.

The new media library features are quite cool too. Let’s try an MP3. Nah. The upload happens but it ends up saying the file type doesn’t meet their security requirements (meaning that the paid upgrade is needed).

Ah, well… It could have been fun. I eventually would like to be able to podcast using WordPress.com.

Overall, the update is mostly striking because of the interface. The new features are fairly light, when you get down to it. Isn’t there a saying about the Emperor’s new clothes? 😉