Recently met someone who started describing their restaurant after calling it a “café”. The “pitch” revolved around ethical practices, using local products, etc. As both a coffee geek and ethnographer, my simple question was: “Which coffee do you use?” Turns out, they’re importing coffee from a multinational corporation. “Oh, but, they’re lending us an expensive espresso machine for free! And they have fair-trade coffee!”

Luckily, we didn’t start talking about “fair trade”. And this person was willing to reflect upon the practices involved, including about the analogy with Anheuser-Busch or Coca-Cola. We didn’t get further into the deeper consequences of the resto’s actions, but the “seed” has been planted.

Sure, it’s important to focus on your financials and there’s nothing preventing a business from being both socially responsible and profitable. It just requires a shift in mindset. Small, lean, nimble businesses are more likely to do it than big, multinational corporate empires…

…which leads me to Google.

Over the years since its IPO, Google has attracted its share of praise and criticism. Like any big, multinational corporate empire. In any sector.

Within the tech sector, the Goog‘ is often compared with Microsoft, Facebook, Twitter, and Apple. All of these corporate entities have been associated in some people’s minds with some specific issue, from child labour and failure to protect users’ privacy to anticompetitive practices (the tech equivalent of free fridges and espresso machines). The issues are distinct and tech enthusiast spend a large amount of time discussing which one is worse. Meanwhile, we’re forgetting a number of larger issues.

Twitter is an interesting example, here. The service took its value from being at the centre of an ecosystem. As with any ecosystem, numerous interactions among many different members produce unexpected and often remarkable results. As the story goes, elements like hashtags and “@-replies” were invented by users and became an important part of the system. Third-party developers were instrumental in Twitter’s reach outside of its original confines. Though most of the original actors have since left the company, the ecosystem has maintained itself over the years.

When Twitter started changing the rules concerning its API, it shook the ecosystem. Sure, the ecosystem will maintain itself, in the end. But it’s nearly impossible to predict how it will change. For people at Twitter, it must have been obvious that the first changes was a warning shot to scare away those they didn’t want in their ecosystem. But, to this day, there are people who depend on Twitter, one way or another.

Google Reader offers an interesting case. The decision to kill it might have been myopic and its death might have a domino effect.

The warning shot was ambiguous, but the “writing was on the wall”. Among potential consequences of the move, the death of RSS readers was to be expected. One might also expect users of feedreaders to be displeased. In the end, the ecosystem will maintain itself.

Chances are, feedreading will be even more marginalized than it’s been and something else might replace it. Already, many people have been switching from feedreading to using Twitter as a way to gather news items.

What’s not so well-understood is the set of indirect consequences, further down the line. Again, domino effect. Some dominoes are falling in the direction of news outlets which have been slow to adapt to the ways people create and “consume” news items. Though their ad-driven models may sound similar to Google’s, and though feedreading might not be a significant source of direct revenue, the death of feedreaders may give way to the birth of new models for news production and “consumption” which might destabilize them even further. Among the things I tag as #FoJ (“Future of Journalism”) are several pieces of a big puzzle which seems misunderstood by news organizations.

There are other big dominoes which might fall from the death of Google Reader. Partly because RSS itself is part of a whole ecosystem. Dave Winer and Aaron Swartz have been major actors in the technical specifications of RSS. But Chris Lydon and people building on calendar syndication are also part of the ecosystem. In business-speak, you might call them “stakeholders”. But thinking about the ecosystem itself leads to a deeper set of thoughts, beyond the individuals involved. In the aftermath of Aaron Swartz’s premature death, it may be appropriate to point out that the ecosystem is more than the sum of its parts.

As I said on a service owned by another widely-criticized corporate empire:

Many of us keep saying that Google needs to listen to its social scientists. It also needs to understand ecology.

I got a lot of indirect help and I wouldn’t have been able to go very far in my project without that help. But, basically, it’s been a learning experience for me as an individual. I’m sure more skilled people would have been able to whip this up in no time.

Thing is, it’s been fun. Close to Csíkszentmihályi’s notion of “flow”. (Philippe’s a friend of mine who did research on flow and videogames. He’s the one who first introduced me to “flow”, in this sense.)

So, how did I achieve this? Well, through both plugins and theme files.

In fact, I ended up coding my custom taxonomies “from scratch”, after running into apparent problems with the More Taxonomies plugin. Eventually did the same thing with my “Syllabus” post type, replacing More Types. Wasn’t very difficult and it solved some rather tricky bugs.

Naïvely, I thought that the plugins’ export function would actually create that code, so I’d be able to put it in my own files and get rid of that plugin. But it’s not the case. Doh! Unfortunately, the support forums don’t seem so helpful either, with many questions left unanswered. So I wouldn’t really recommend these plugins apart from their pedagogical value.

The plugins were useful in helping me get around some “conceptual” issues, but it seems safer and more practical to code things from scratch, at least with taxonomies and custom post types. For “custom metaboxes”, I’m not sure I’ll have as easy a time replacing More Fields as I did replacing More Taxonomies and More Types. (More Fields helps create custom fields in the post editing interface.)

Attachments provides an easy way to attach files to a post and, importantly, its plugin page provides usable notes about implementation which greatly helped me in my learning process. I think I could code in some of that plugin’s functionality, now that I get a better idea of how WordPress attachments work. But it seems not to be too buggy so I’ll probably keep it.

As its name does not imply, gde can embed any file from a rather large array of file types: Adobe Reader (PDF), Microsoft Office (doc/docx, ppt/pptx/pps, xsl/xslx), and iWork Pages, along with multipage image files (tiff, Adobe Illustrator, Photoshop, SVG, EPS/PS…). The file format support comes from Google Docs Viewer (hence the plugin name).

Allowing the display of archives might be very useful, in this case. It’s fairly easily to get people to put files in a zip archive and upload it. In fact, several mail clients do all of this automatically, so there’s probably a way to get documents through emailed zip files and display the content along with the syllabus.

As it so happens, gde is already installed on the academic site for which I’m building this very same syllabus database. In that case, I’ve been using gde to embed PDF files (for instance, in this page providing web enhancements page for an article in the association’s journal). So I knew it could be useful in terms of displaying course outlines and such, within individual pages of the syllabus database.

What I wasn’t sure I could do is programmatically embed files added to a syllabus page. In other words, I knew I could display these files using some shortcode on appropriate files’ URLs (including those of attached files). What I wasn’t sure how to do (and had a hard time figuring out) is how to send these URLs from a field in the database: I knew how to manually enter the code, but I didn’t know how to automatically display the results of the code when a link is entered in the right place.

The reason this matters is that I would like “normal human beings” (i.e., noncoders and, mostly, nongeeks) to enter the relevant information for their syllabi. One of WordPress’s advantages is the fact that, despite its power, it’s very easy to get nongeeks to do neat things with it. I’d like the syllabus database to be this type of neat thing.

The Attachmentsplugin helps, but still isn’t completely ideal. It does allow for drag-and-drop upload and it does provide a minimalist interface for attaching uploaded files to blogposts.

Screenshot of First “Attach” Button

In the first case, it’s just a matter of clicking the Attach button and dropping a file in the appropriate field. In the second case, it’s a matter of clicking another Attachbutton.

Screenshot of the Second “Attach” Button

The problem is between these two Attach buttons.

Screenshot of the Uploaded File

The part of the process between uploading the file and finding the Attach button takes several nonobvious steps. After the file has been uploaded, the most obvious buttons are Insert into Post and Save all changes, neither of which sounds particularly useful in this context. But Save all changes is the one which should be clicked.

To get to the second Attach button, I first need to go to the Media Library a second time. Recently uploaded images are showing.

Screenshot of the Media Library Only Showing Images

For other types of files, I then click All Types, which shows a reverse chronological list of all recently uploaded files (older files can be found through the Search Media field). I then click on the Show link associated with a given file (most likely, the most recent upload, which is the first in the list).

Screenshot of the second “Attach” Button

Then, finally, the final Attach button shows up.

Clicking it, the file is attached to the current post, which was the reason behind the whole process. Thanks to both gde and Attachments, that file is then displayed along with the rest of the syllabus entry.

It only takes a matter of seconds to minutes, to attach a file (depending on filesize, connection speed, etc.). Not that long. And the media library can be very useful in many ways. But I just imagine myself explaining the process to instructors and other people submitting syllabi for inclusion the the database.

Far from ideal.

A much easier process is the one of adding files by pasting a file URL in a field. Which is exactly what I’ve added as a possibility for a syllabus’s main document (say, the PDF version of the syllabus).

Screenshot of the Course Data Box

Passing that URL to gde, I can automatically display the document in the document page, as I’m doing with attachments from the media library. The problem with this, obviously, is that it requires a public URL for the document. The very same “media library” can be used to upload documents. In fact, copying the URL from an uploaded file is easier than finding the “Attach” button as explained previously. But it makes the upload a separate process on the main site. A process which can be taught fairly easily, but a process which isn’t immediately obvious.

I might make use of a DropBox account for just this kind of situation. It’s also a separate process, but it’s one which may be easier for some people.

In the end, I’ll have to see with users what makes the most sense for them.

In the past, I’ve used plugins like Contact Form 7 (CF7), by Takayuki Miyoshi, and Fast Secure Contact Form (FSCF) by Mike Challis to try and implement something similar. A major advantage is that they allow for submissions by users who aren’t logged in. This might be a dealmaking feature for either FSCF or CF7, as I don’t necessarily want to create accounts for everyone who might submit a syllabus. Had issues with user registration, in the past. Like attachments, onboarding remains an issue for a lot of people. Also, thanks to yet other plugins like Michael Simpson’s Contact Form to Database (CFDB), it should be possible to make form submissions into pending items in the syllabus database. I’ll be looking into this.

Another solution might be Gravity Forms. Unlike the plugins I’ve mentioned so far, it’s a commercial product. But it sounds like it might offer some rather neat features which may make syllabus submission a much more interesting process. However, it’s meant for a very different use case, which has more to do with “lead data management” and other business-focused usage. I could innovate through its use. But there might be more appropriate solutions.

As is often the case with WordPress, the “There’s a plugin for that” motto can lead to innovation. Even documenting the process (by blogging it) can be a source of neat ideas.

Overall, Pods CMS sounds like a neat approach. Its pros and cons make it sound like an interesting alternative to WordPress’s custom post types for certain projects, as well as a significant shift from the main ways WordPress is used. During WordCamp Montreal, people I asked about it were wary of Pods. I eventually thought I would wait for version 2.0 to come out before investing significant effort in it.

In the meantime, what I’ve built is a useful base knowledge of how to use WordPress as a content database.

Can’t wait to finish adding features and fixing bugs, so I can release it to the academic organization. I’m sure they’ll enjoy it.

Even if they don’t ever use it, I’ve gained a lot of practical insight into how to do such things. It may be obvious to others but it does wonders to my satisfaction levels.

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.

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.)

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:

Click “BuddyPress”

Click “Forum Setup”

Click “Set up a new bbPress installation”

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:

Click “Visit Site”

Click “Groups”

Click “Create a Group”

Fill in the group name and description.

Click “Create Group and Continue”

Select whether or not you want to enable the discussion forum, choose the privacy options, and click “Next Step”

Choose an avatar (or leave the default one) and click “Next Step”

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.”

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.

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).

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.

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… 😉

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.

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.

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?