Category Archives: workflow

No Office Export in Keynote/Numbers for iPad?

To be honest, I’m getting even more excited about the iPad. Not that we get that much more info about it, but:

For one thing, the Pages for iPad webpage is explicitly stating Word support:

Attach them to an email as Pages files for Mac, Microsoft Word files, or PDF documents.

Maybe this is because Steve Jobs himself promised it to Walt Mossberg?
Thing is, the equivalent pages about Keynote for iPad and about Numbers for iPad aren’t so explicit:

The presentations you create in Keynote on your iPad can be exported as Keynote files for Mac or PDF documents

and…

To share your work, export your spreadsheet as a Numbers file for Mac or PDF document

Not a huge issue, but it seems strange that Apple would have such an “export to Microsoft Office” feature on only one of the three “iWork for iPad” apps. Now, the differences in the way exports are described may not mean that Keynote won’t be able to export to Microsoft PowerPoint or that Numbers won’t be able to export to Microsoft Excel. After all, these texts may have been written at different times. But it does sound like PowerPoint and Excel will be import-only, on the iPad.

Which, again, may not be that big an issue. Maybe iWork.com will work well enough for people’s needs. And some other cloud-based tools do support Keynote. (Though Google Docs and Zoho Show don’t.)

The reason I care is simple: I do share most of my presentation files. Either to students (as resources on Moodle) or to whole wide world (through Slideshare). My desktop outliner of choice, OmniOutliner, exports to Keynote and Microsoft Word. My ideal workflow would be to send, in parallel, presentation files to Keynote for display while on stage and to PowerPoint for sharing. The Word version could also be useful for sharing.

Speaking of presenting “slides” on stage, I’m also hoping that the “iPad Dock Connector to VGA Adapter” will support “presenter mode” at some point (though it doesn’t seem to be the case, right now). I also dream of a way to control an iPad presentation with some kind of remote. In fact, it’s not too hard to imagine it as an iPod touch app (maybe made by Appiction, down in ATX).

To be clear: my “presentation files” aren’t really about presenting so much as they are a way to package and organize items. Yes, I use bullet points. No, I don’t try to make the presentation sexy. My presentation files are acting like cue cards and like whiteboard snapshots. During a class, I use the “slides” as a way to keep track of where I planned the discussion to go. I can skip around, but it’s easier for me to get at least some students focused on what’s important (the actual depth of the discussion) because they know the structure (as “slides”) will be available online. Since I also podcast my lectures, it means that they can go back to all the material.

I also use “slides” to capture things we build in class, such as lists of themes from the readings or potential exam questions.  Again, the “whiteboard” idea. I don’t typically do the same thing during a one-time talk (say, at an unconference). But I still want to share my “slides,” at some point.

So, in all of these situations, I need a file format for “slides.” I really wish there were a format which could work directly out of the browser and could be converted back and forth with other formats (especially Keynote, OpenOffice, and PowerPoint). I don’t need anything fancy. I don’t even care about transitions, animations, or even inserting pictures. But, despite some friends’ attempts at making me use open solutions, I end up having to use presentation files.

Unfortunately, at this point, PowerPoint is the de facto standard for presentation files. So I need it, somehow. Not that I really need PowerPoint itself. But it’s still the only format I can use to share “slides.”

So, if Keynote for iPad doesn’t export directly to PowerPoint, it means that I’ll have to find another way to make my workflow fit.

Ah, well…

Advertisements

Why I Need an iPad

I’m one of those who feel the iPad is the right tool for the job.

This is mostly meant as a reply to this blogthread. But it’s also more generally about my personal reaction to Apple’s iPad announcement.

Some background.

I’m an ethnographer and a teacher. I read a fair deal, write a lot of notes, and work in a variety of contexts. These days, I tend to spend a good amount of time in cafés and other public places where I like to work without being too isolated. I also commute using public transit, listen to lots of podcast, and create my own. I’m also very aural.

I’ve used a number of PDAs, over the years, from a Newton MessagePad 130 (1997) to a variety of PalmOS devices (until 2008). In fact, some people readily associated me with PDA use.

As soon as I learnt about the iPod touch, I needed one. As soon as I’ve heard about the SafariPad, I wanted one. I’ve been an intense ‘touch user since the iPhone OS 2.0 release and I’m a happy camper.

(A major reason I never bought an iPhone, apart from price, is that it requires a contract.)

In my experience, the ‘touch is the most appropriate device for all sorts of activities which are either part of an other activity (reading during a commute) or are simply too short in duration to constitute an actual “computer session.” You don’t “sit down to work at your ‘touch” the way you might sit in front of a laptop or desktop screen. This works great for “looking up stufff” or “checking email.” It also makes a lot of sense during commutes in crowded buses or metros.

In those cases, the iPod touch is almost ideal. Ubiquitous access to Internet would be nice, but that’s not a deal-breaker. Alternative text-input methods would help in some cases, but I do end up being about as fast on my ‘touch as I was with Graffiti on PalmOS.

For other tasks, I have a Mac mini. Sure, it’s limited. But it does the job. In fact, I have no intention of switching for another desktop and I even have an eMachines collecting dust (it’s too noisy to make a good server).

What I miss, though, is a laptop. I used an iBook G3 for several years and loved it. For a little while later, I was able to share a MacBook with somebody else and it was a wonderful experience. I even got to play with the OLPC XO for a few weeks. That one was not so pleasant an experience but it did give me a taste for netbooks. And it made me think about other types of iPhone-like devices. Especially in educational contexts. (As I mentioned, I’m a teacher)

I’ve been laptop-less for a while, now. And though my ‘touch replaces it in many contexts, there are still times when I’d really need a laptop. And these have to do with what I might call “mobile sessions.”

For instance: liveblogging a conference or meeting. I’ve used my ‘touch for this very purpose on a good number of occasions. But it gets rather uncomfortable, after a while, and it’s not very fast. A laptop is better for this, with a keyboard and a larger form factor. But the iPad will be even better because of lower risks of RSI. A related example: just imagine TweetDeck on iPad.

Possibly my favourite example of a context in which the iPad will be ideal: presentations. Even before learning about the prospect of getting iWork on a tablet, presentations were a context in which I really missed a laptop.

Sure, in most cases, these days, there’s a computer (usually a desktop running XP) hooked to a projector. You just need to download your presentation file from Slideshare, show it from Prezi, or transfer it through USB. No biggie.

But it’s not the extra steps which change everything. It’s the uncertainty. Even if it’s often unfounded, I usually get worried that something might just not work, along the way. The slides might not show the same way as you see it because something is missing on that computer or that computer is simply using a different version of the presentation software. In fact, that software is typically Microsoft PowerPoint which, while convenient, fits much less in my workflow than does Apple Keynote.

The other big thing about presentations is the “presenter mode,” allowing you to get more content than (or different content from) what the audience sees. In most contexts where I’ve used someone else’s computer to do a presentation, the projector was mirroring the computer’s screen, not using it as a different space. PowerPoint has this convenient “presenter view” but very rarely did I see it as an available option on “the computer in the room.” I wish I could use my ‘touch to drive presentations, which I could do if I installed software on that “computer in the room.” But it’s not something that is likely to happen, in most cases.

A MacBook solves all of these problems. and it’s an obvious use for laptops. But how, then, is the iPad better? Basically because of interface. Switching slides on a laptop isn’t hard, but it’s more awkward than we realize. Even before watching the demo of Keynote on the iPad, I could simply imagine the actual pleasure of flipping through slides using a touch interface. The fit is “natural.”

I sincerely think that Keynote on the iPad will change a number of things, for me. Including the way I teach.

Then, there’s reading.

Now, I’m not one of those people who just can’t read on a computer screen. In fact, I even grade assignments directly from the screen. But I must admit that online reading hasn’t been ideal, for me. I’ve read full books as PDF files or dedicated formats on PalmOS, but it wasn’t so much fun, in terms of the reading process. And I’ve used my ‘touch to read things through Stanza or ReadItLater. But it doesn’t work so well for longer reading sessions. Even in terms of holding the ‘touch, it’s not so obvious. And, what’s funny, even a laptop isn’t that ideal, for me, as a reading device. In a sense, this is when the keyboard “gets in the way.”

Sure, I could get a Kindle. I’m not a big fan of dedicated devices and, at least on paper, I find the Kindle a bit limited for my needs. Especially in terms of sources. I’d like to be able to use documents in a variety of formats and put them in a reading list, for extended reading sessions. No, not “curled up in bed.” But maybe lying down in a sofa without external lighting. Given my experience with the ‘touch, the iPad is very likely the ideal device for this.

Then, there’s the overall “multi-touch device” thing. People have already been quite creative with the small touchscreen on iPhones and ‘touches, I can just imagine what may be done with a larger screen. Lots has been said about differences in “screen real estate” in laptop or desktop screens. We all know it can make a big difference in terms of what you can display at the same time. In some cases, two screens isn’t even a luxury, for instance when you code and display a page at the same time (LaTeX, CSS…). Certainly, the same qualitative difference applies to multitouch devices. Probably even more so, since the display is also used for input. What Han found missing in the iPhone’s multitouch was the ability to use both hands. With the iPad, Han’s vision is finding its space.

Oh, sure, the iPad is very restricted. For instance, it’s easy to imagine how much more useful it’d be if it did support multitasking with third-party apps. And a front-facing camera is something I was expecting in the first iPhone. It would just make so much sense that a friend seems very disappointed by this lack of videoconferencing potential. But we’re probably talking about predetermined expectations, here. We’re comparing the iPad with something we had in mind.

Then, there’s the issue of the competition. Tablets have been released and some multitouch tablets have recently been announced. What makes the iPad better than these? Well, we could all get in the same OS wars as have been happening with laptops and desktops. In my case, the investment in applications, files, and expertise that I have made in a Mac ecosystem rendered my XP years relatively uncomfortable and me appreciate returning to the Mac. My iPod touch fits right in that context. Oh, sure, I could use it with a Windows machine, which is in fact what I did for the first several months. But the relationship between the iPhone OS and Mac OS X is such that using devices in those two systems is much more efficient, in terms of my own workflow, than I could get while using XP and iPhone OS. There are some technical dimensions to this, such as the integration between iCal and the iPhone OS Calendar, or even the filesystem. But I’m actually thinking more about the cognitive dimensions of recognizing some of the same interface elements. “Look and feel” isn’t just about shiny and “purty.” It’s about interactions between a human brain, a complex sensorimotor apparatus, and a machine. Things go more quickly when you don’t have to think too much about where some tools are, as you’re working.

So my reasons for wanting an iPad aren’t about being dazzled by a revolutionary device. They are about the right tool for the job.


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


WordPress MU, BuddyPress, and bbPress on Local Machine

Was recently able to install and integrate three neat products based on Automattic code:

  1. WordPress µ 2.8.1 (a.k.a. WPµ, WordPress MU… Platform for multi-user blogs and Content Management System).
  2. BuddyPress 1.0.2 (A social network system based on WordPress µ).
  3. bbPress 1.0.1 (A forum system based on WordPress).

Did this after attending WordCamp Montreal. The fact that the large majority of WordPress and WordPress µ are merging motivated me, in part, to try it out. I currently serve as webguru for the Society for Linguistic Anthropology.

This is all on a local machine, a Mac mini running Mac OS X 10.5 Leopard.

It took me several attempts so it might not be as obvious as one would think.

I wrote as detailed a walkthrough as I could. Not exactly for the faint of heart. And, as IANAC, some things aren’t completely clear to me. I wish I could say I’m able to troubleshoot other people’s problems with these systems, but it’s really not the case. I ended up working out diverse issues, but it took me time and concentration.

A few resources I’ve used:

  1. Andy Peatling’s tutorial on BuddyPress (and WordPress µ) on a Mac.
  2. Sam Bauers’s screencast on integrating WordPress and bbPress. (Not µ or BuddyPress. Requires WordPress.org login.)
  3. Trent Adams’s tutorial on BuddyPress/bbPress integration.
  4. This file: <WPinstall>/wp-content/plugins/buddypress/bp-forums/installation-readme.txt (also available here).

I’ve used many other resources, but they turned out to be confusing, partly because of changes in versions. In fact, the last file was the most useful one. It’s a very different method from the other ones, but it worked. It’s actually much simpler than the other methods and it still gave me what I needed. I now have a working installation of a complete platform which integrates blogging, social networking, and forums. In a way, it’s like having simple versions of Drupal and Ning in the same install. Perfect for tests.

Some conventions.

<dbname> commondb
<name> common
<username> alexandre
<bbname> forums
<adminpass> (generated) 5e6aee85e6d4
<blogname> uethnographer
<blogpass> (generated) 601a6100
<confkey> (generated)
  1. [T] refers to things done in Terminal.app
  2. [B] refers to things done in the browser (Safari.app in my case)
  3. Brackets serve to refer to installation-specific items. I could have used variables.
    1. <dbname> is the database name in MySQL (can be anything)
    2. <name> is the name used for the WordPress install (domain/<name>; can be anything)
    3. <username> is the abbreviated username on the local machine. ~<username> would be the user’s home directory. Determined in Mac OS X.
    4. <bbname> is the name for the bbPress install  (domain/<name>/<bbname>; can be anything)
    5. <adminpass> is the password for the WordPress admin (generated)
    6. <blogname> is the main username for a blog administrator (can be anything)
    7. <blogpass> is the password for that blog administrator (generated)
    8. <confkey> is a confirmation key upon creating that blog administrator (generated)

So, here’s what I did.

  1. Switched to a user with administrative rights on my Mac. I usually work with a non-admin user and grant admin privileges when needed. Quite cumbersome in this case.
  2. Opened Terminal.app
  3. Installed and configured MAMP
    1. Downloaded http://downloads.sourceforge.net/mamp/MAMP_1.7.2.dmg.zip and copied the MAMP folder to /Applications
    2. Opened MAMP.app
    3. Changed MAMP preferences
      1. Preferences
      2. Ports: “Default Apache and MySQL ports”
      3. Apache: Choose: /Users/<username>/Sites
      4. Clicked Ok
  4. Clicked “Open home page” in MAMP
  5. Went to phpMyAdmin
  6. Created a database in phpMyAdmin with <dbname> as the name
  7. Edited /etc/hosts to add: 127.0.0.1 localhost.localdomain
  8. Downloaded WordPress µ through Subversion: [T] svn co http://svn.automattic.com/wordpress-mu/branches/2.8 /Users/<username>/Sites/<name>
  9. Went to my local WordPress µ home: [B] http://localhost.localdomain/<name&gt;
  10. Filled in the necessary information
    1. “Use subdirectories” (subdomains would be a huge hassle)
    2. Database name: <dbname>
    3. User Name: root
    4. Password: root (changing it is a huge hassle)
    5. Title (title for the main WPµ install, can be anything)
    6. Email (valid email for the WPµ admin)
    7. Saved changes
  11. Noted <adminpass> for later use (generated and displayed)
  12. Changed file ownership: [T] chmod 755  /Users/<username>/Sites/<name> /Users/<username>/Sites/<name>/wp-content/
  13. Logged into WPµ admin: [B] http://localhost.localdomain/<name>/wp-admin/
    1. User: admin
    2. Password: <adminpass>
  14. Changed plugin options: [B] http://localhost.localdomain/<name>/wp-admin/wpmu-options.php#menu
    1. Plugins: check
    2. “Allow new registrations”: “Enabled. Blogs and user accounts can be created.”
    3. “Add New Users”: Yes
    4. “Upload media button”: Checked Images/Videos/Music
    5. “Blog upload space”: 100MB
    6. Clicked “Update Options”
  15. Installed BuddyPress directly
    1. [B] http://localhost.localdomain/<name>/wp-admin/plugin-install.php?tab=plugin-information&plugin=buddypress&TB_iframe=true&width=640&height=542
    2. Clicked “Install”
    3. Clicked “Activate”
    4. Moved BP themes to the right location: [T] mv /Users/<username>/Sites/<name>/wp-content/plugins/buddypress/bp-themes /Users/<username>/Sites/<name>/wp-content/
    5. Moved the BP Default Home theme to the right location: [T] mv /Users/<username>/Sites/<name>/wp-content/bp-themes/bphome/ /Users/<username>/Sites/<name>/wp-content/themes/
    6. Activated the BP Default Home theme: [B] http://localhost.localdomain/<name>/wp-admin/wpmu-themes.php
      1. Clicked yes on “BuddyPress Default Home Theme”
      2. Clicked Update Themes
    7. Activated the BP theme
      1. [B] http://localhost.localdomain/<name>/wp-admin/themes.php
      2. Clicked “Activate” on “BuddyPress Default Home”
    8. Added widgets to the BP theme
      1. [B] http://localhost.localdomain/<name>/wp-admin/widgets.php
      2. Placed widgets through drag-and-drop
    9. Checked the BuddyPress install: [B] http://localhost.localdomain/<name>
  16. Installed and integrated bbPress
    1. Downloaded bbPress using Subversion: [T] svn co http://svn.automattic.com/bbpress/trunk/ /Users/<username>/Sites/<name>/<bbname>/
    2. Went through the install process: [B] http://localhost.localdomain/<name>/<bbname>/bb-admin/install.php
    3. Go to step 1
    4. Added the following details
      1. Database Name <dbname> (same as WPMU)
      2. Database user root
      3. Database password root
      4. Clicked Save database configuration file
    5. Check for configuration file
    6. Go to Step 2
    7. Added the following details
      1. Add integration settings
      2. Add user database integration settings (without the cookie integration)
      3. User database table prefix wp_
      4. WordPress MU primary blog ID 1
      5. Clicked “Save WordPress integration settings”
    8. Clicked “Go to step 3”
      1. Added the following details
        1. Site Name (Name of the bbPress site, can be anything)
        2. Key Master username admin
        3. First Forum Name (Name of the first forum, can be anything)
        4. Clicked “Save site settings”
    9. Complete the installation
    10. Ignored the warnings
    11. Went through the writing options: [B] http://localhost.localdomain/<name>/<bbname>/bb-admin/options-writing.php
      1. Username: admin
      2. Password: <adminpass>
      3. Clicked on XML-RPC Enable the bbPress XML-RPC publishing protocol.
      4. Clicked “Save changes”
    12. Went to the discussion options: [B] http://localhost.localdomain/<name>/<bbname>/bb-admin/options-discussion.php
      1. “Enable Pingbacks”: “Allow link notifications from other sites.”
      2. Clicked “Save Changes”
    13. Moved the BuddyPress/bbPress integration plugin to the right location: [T] mv /Users/<username>/Sites/<name>/wp-content/plugins/buddypress/bp-forums/bbpress-plugins/buddypress-enable.php /Users/<username>/Sites/<name>/<bbname>/my-plugins/
    14. Went to the bbPress plugin options: [B] http://localhost.localdomain/<name>/<bbname>/bb-admin/plugins.php
      1. Clicked “Activate” on “BuddyPress Support Plugin”
    15. Went to the WPµ site: [B] http://localhost.localdomain/<name>
    16. Clicked “Log Out”
    17. Registered a new user: [B] http://localhost.localdomain/<name>/register
      1. Username <blogname>
      2. Email address (blog administrator’s valid email)
      3. Name (full name of blog administrator, can be anything)
      4. Clicked “Next”
      5. “Blog Title” (name of the blog administrator’s main blog, can be anything)
      6. Clicked “Signup”
      7. Checked for email at blog administrator’s email address
      8. Clicked confirmation link: [B] http://localhost.localdomain/<name>/activate?key=<confkey>
      9. Noted <blogpass> (generated)
      10. Gave administrative rights to the newly created blog administrator: [B] http://localhost.localdomain/<name>/<bbname>/bb-admin/users.php
        1. Logged in with admin/<adminpass>
        2. Clicked on <blogname>: Edit
        3. Clicked on “User Type: Administrator”
        4. Clicked on “Update Profile”
      11. Edited the bbPress configuration file:
        1. [T] open -e /Users/<username>/Sites/<name>/<bbname>/bb-config.php
        2. Added the following:
          1. $bb->bb_xmlrpc_allow_user_switching = true;
          1. (say, after /**#@-*/)
        3. Saved
      12. Went to BuddyPress options: [B] http://localhost.localdomain/<name>/wp-admin/admin.php?page=buddypress/bp-forums/bp-forums-admin.php
        1. Logged in with admin/<adminpass>
        2. Added the following details
          1. bbPress URL: http://localhost.localdomain/<name>/<bbname>/
          1. bbPress username <blogname>
          1. bbPress password <blogpass>
        3. Clicked “Save Settings”
  17. That was it. Phew!

I ended up with a nice testing platform. All plugins I’ve tried so far work quite well, are extremely easy to install, and give me ideas about the SLA’s site.

It was an involved process and I wouldn’t recommend it to anyone who’s afraid of fiddling with a bit of code. But I did try it out and it seems fairly robust as a method. I could almost create a script for this but that’d mean I might receive support requests that I just can’t handle. I could also make a screencast but that’d require software I don’t have (like Snapz Pro). Besides, I think copy paste is easier, if you remember to change the appropriate items. Obviously, anyone who wants to use this procedure as-is should replace all the bracketed items with the appropriate ones for your install. Some are generated during the process, others you can choose (such as the name of the database).

I’m not extremely clear on how secure this install is. But I’m only running it when I need to.

You can ask me questions in the comments but I really can’t guarantee that I’ll have an answer.


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


Buzz Factor

I have an ambivalent relationship with buzzwords and buzzphrases. I find them dangerous, especially when they contribute to groupthink, but I also like to play with them. Whether I try (perhaps clumsily) to create some or I find one to be useful in encapsulating insight.

The reason I’m thinking about this is that I participated in the PodCamp Montreal UnConference, giving a buzzphrase-laden presentation on social media and academia (or “social acamedia,” as I later called it).

I’ll surely revisit a number of notes I’ve taken (mostly through Twitter) during the unconference. But I thought I’d post something as a placeholder.

Some buzzphrases/-words I’ve been known to use should serve as the bases for explanations about a few things I’ve been rambling about the past few years.

Here are a few (some of which I’ve tried to coin):

Not that all of these paint a clear picture of what I’ve been thinking about. But they’re all part of a bigger framework through which I observe and participate in Geek Culture. One day, I might do a formal/academic ethnography of the Geek Crowd.


Crazy App Idea: Happy Meter

I keep getting ideas for apps I’d like to see on Apple’s App Store for iPod touch and iPhone. This one may sound a bit weird but I think it could be fun. An app where you can record your mood and optionally broadcast it to friends. It could become rather sophisticated, actually. And I think it can have interesting consequences.

The idea mostly comes from Philippe Lemay, a psychologist friend of mine and fellow PDA fan. Haven’t talked to him in a while but I was just thinking about something he did, a number of years ago (in the mid-1990s). As part of an academic project, Philippe helped develop a PDA-based research program whereby subjects would record different things about their state of mind at intervals during the day. Apart from the neatness of the data gathering technique, this whole concept stayed with me. As a non-psychologist, I personally get the strong impression that recording your moods frequently during the day can actually be a very useful thing to do in terms of mental health.

And I really like the PDA angle. Since I think of the App Store as transforming Apple’s touch devices into full-fledged PDAs, the connection is rather strong between Philippe’s work at that time and the current state of App Store development.

Since that project of Philippe’s, a number of things have been going on which might help refine the “happy meter” concept.

One is that “lifecasting” became rather big, especially among certain groups of Netizens (typically younger people, but also many members of geek culture). Though the lifecasting concept applies mostly to video streams, there are connections with many other trends in online culture. The connection with vidcasting specifically (and podcasting generally) is rather obvious. But there are other connections. For instance, with mo-, photo-, or microblogging. Or even with all the “mood” apps on Facebook.

Speaking of Facebook as a platform, I think it meshes especially well with touch devices.

So, “happy meter” could be part of a broader app which does other things: updating Facebook status, posting tweets, broadcasting location, sending personal blogposts, listing scores in a Brain Age type game, etc.

Yet I think the “happy meter” could be useful on its own, as a way to track your own mood. “Turns out, my mood was improving pretty quickly on that day.” “Sounds like I didn’t let things affect me too much despite all sorts of things I was going through.”

As a mood-tracker, the “happy meter” should be extremely efficient. Because it’s easy, I’m thinking of sliders. One main slider for general mood and different sliders for different moods and emotions. It would also be possible to extend the “entry form” on occasion, when the user wants to record more data about their mental state.

Of course, everything would be save automatically and “sent to the cloud” on occasion. There could be a way to selectively broadcast some slider values. The app could conceivably send reminders to the user to update their mood at regular intervals. It could even serve as a “break reminder” feature. Though there are limitations on OSX iPhone in terms of interapplication communication, it’d be even neater if the app were able to record other things happening on the touch device at the same time, such as music which is playing or some apps which have been used.

Now, very obviously, there are lots of privacy issues involved. But what social networking services have taught us is that users can have pretty sophisticated notions of privacy management, if they’re given the chance. For instance, adept Facebook users may seem to indiscrimately post just about everything about themselves but are often very clear about what they want to “let out,” in context. So, clearly, every type of broadcasting should be controlled by the user. No opt-out here.

I know this all sounds crazy. And it all might be a very bad idea. But the thing about letting my mind wander is that it helps me remain happy.