I have been busy working on my own business in a desperate effort to keep working for myself and to do this I need to make my home based business sustainable and profitable.  To do this Ineed to put in many hours and that means not as much minti time as I used to.

The great news is that so far I am growing my business enough to stay at home for now and make a dollar as well.

I have started a web hosting service that builds and sustains small websites for home based or micro business and this provides income to offset the subsidised computer training service I provide to the elderly and dissabled in my local community. The computer training is done more for personal reward and fuzzy feelings so it will never really work as a business in the long term so the website hosting service is working out to be a godsend for now and should see me through until I start my next big project which will be internet based and may see me through into my eighties and create a few jobs and much positive family values along the way.

So this is what I have been doing and I look forward to sharing my progress and experience along the way.

Have a great day form the Big Red F.   

I have started working on a community toolbar to initially share with my customers and eventually to whoever wants it. I am so proud of it I want to show it off to you but I would like suggestions, ideas and feedback.

It is perfectly safe and containd no bad things but it has a lot of good things such as

• search,
• links to banking and shopping (Aust links only at the moment but will update on request)
• an online radio
• email checker and notifier
• gadgets (to do, notes, games ect)
• weather
• news
• a message service where I deliver urgent security updates or news
• chat rooms

and many other features that you can add yourself.

If you are interested please download it here and let me know what you think.

Thanks in advance.

• children
• ball
• park

Just grab your children and drag them to the park and kick the footy, throw a ball, play soccer or keepings off. Play tagg for a while and then head home and you will probably find you are turning the heater down for while.

Save money, keep fit and bond with your family. .

Tomorrow night is just as much about me as like many dads you set these goals and have these dreams that one day you will go to a game of football or other activity with your son and to have it happen is like a little milestone for me.

It makes you think you are doing a good job with your life and the plans you set are falling into place.

Well done to all involved including those who are using the features.

The Cook boys are making Cookies

Frontiers Foto Friday is back

If you plug the quoted phrase “the data finds the data” into any of the search engines, the first hit will be one of several essays on Jeff Jonas’ blog. Other evocative phrases that lead to Jeff’s blog include “perpetual analytics”, “sequence neutrality,” and “persistent context,” but while those will soon resonate once you scratch the surface of Jeff’s work, none is as broadly compelling as “the data finds the data.” As sound bites go, that one’s a keeper.

Jeff Jonas is chief scientist for IBM’s Entity Analytic Solutions. His long career in data surveillance, and recent interest in privacy-respecting data surveillance, has drawn a lot of media attention lately. In the mainstream he’s appeared in Newsweek and on NPR. In the techsphere, Tim O’Reilly blogged about Jeff’s visit to PC Forum, Dan Farber interviewed him at the Web 2.0 conference and Phil Windley wrote a detailed review of his keynote at ETech 2007.

Given our shared interests — including surveillance, analytics, security, privacy, and manufactured serendipity — it’s surprising that I only recently became aware of Jeff’s work. Of course, we’ve been working different ends of the same street. He’s focused on finding bad guys: casino fraudsters, terrorists, and others who collaborate secretly. I’ve focused on helping people who collaborate openly do so more effectively. And yet…these really are two sides of the same coin.

Here’s an example of “the data finds the data” in Jeff’s world, from his article in IEEE Security and Privacy entitled Threat and Fraud Intelligence, Las Vegas Style. You have two records that refer to the same person, but you don’t know that they do. Then a third record appears which relates to each of the first two, and which establishes that all three refer to the same person. The first two pieces of data find one another, through the agency of a third piece of data.

Here’s an example of “the data finds the data” in my world. On June 17 I bookmarked this item from Mike Caulfield, who is a local friend, the webmaster at Keene State College, and a forward thinker about Net-enabled education. On June 19 I noticed that Jim Groom — who is a distant acquantance at the University of Mary Washington and another forward thinker on the same topic — had responded to Mike’s post. Ten days later I noticed that Mike had become Jim’s new favorite blogger.

I don’t know whether Jim subscribes to my bookmark feed or not, but if he does, that would be the likely vector for this nice bit of manufactured serendipity. I’d been wanting to introduce Mike at KSC to Jim (and his innovative team) at UMW. It would be delightful to have accomplished that introduction by simply publishing a bookmark.

But even if that weren’t the vector, the point is that given the overlap between Jim’s published work and Mike’s published work, it’s likely that they would sooner or later have discovered one another. In the realm of personal publishing, thanks to syndication and search, data tends to finds data. And when it does, people find each other.

This process of discovery works best, of course, when there’s common data available to the syndication and search engines. When the same things have different URLs or different names, the connections are non-obvious.

For non-obvious connections that don’t want to be found, you need a technology like the one Jeff Jonas sold to IBM. It goes by the name NORA: non-obvious relationship awareness.

For non-obvious connections that do want to be found, though, we can help the process along in a variety of ways. Publishing hyperlinks is one way to expose non-obvious relationships. Publishing key words and phrases is another. So, for example, in reading up on Jeff Jonas’ work, I realized that the privacy-assuring version of NORA, called ANNA, which uses one-way hashes to obscure private information while still enabling matching and discovery, is related to Peter Wayner’s notion of translucent databases (1, 2).

I’m not the first one to make that connection — Noah Campbell noted it last fall — but this item will strengthen it, in a way that may help some data find some other data, and some people find some other people.

Dryden, New York is a small town near Ithaca. Four years ago, local resident Simon St. Laurent began chronicling the civic life of the town on a blog called Living in Dryden. In a 2004 profile the Ithaca Journal wrote:

St. Laurent can be seen, notebook and digital camera in tow, at Planning Board and Conservation Advisory Council gatherings, as well as at special meetings on fire departments, speeding and comprehensive plans.

And it asked:

What could motivate this seemingly normal man to submit himself to hours of political talk and legalese?

The answer is that Simon St. Laurent is leading the way to an understanding of how local blogging can reflect and enrich the life of a community. Day by day, and year by year, he’s showing his fellow citizens that political blogging doesn’t have to be bombastic and divisive. It can be a civil dialogue that informs and unites.

I first wrote about Simon’s project more than three years ago. I’ve mentioned it in several talks since then, and this week I interviewed him for my weekly ITConversations show. The show’s not posted yet, and I’ll probably be away from my computer when it is, but check here later today if you’re interested. Personally I think Simon’s project is one of the more important things you’ll never read about on TechMeme. Here are some quotes from the interview that highlight two of Simon’s Laws:

Responsiblity is inversely proportional to community size

When you’re doing local stuff, you can’t stay anonymous for long. I think that has a major impact on the tone of things. The content has to be a lot more accurate because people will call you on it. Somehow the level of responsibility increases as the size of community decreases. It really changes the dynamics thoroughly.

Don’t make people spit out their coffee

Dealing with the threshold where people don’t really trust what they read is something I worry about pretty consistently. My usual rule is that nobody should have to spit out their coffee when they’re reading it. I have a neighbor up the hill who’s a conservative Republican, and I count on him to tell me when I’ve gone too far. Having that kind of tight feedback loop makes it possible for me to write things that I know will appeal to a lot of people.

From time to time I like to dabble in social network analysis. Now that Facebook has opened itself up to programmatic access, I thought I’d do some spelunking to see what I could learn. Here are a couple of questions I’d like to answer about the “clubbiness” of tech-company Facebookers:

1. Looking at the tech-company population as a whole, do people socialize within and across corporate networks more than elsewhere?

2. Looking at individual tech companies, which are more or less likely to mingle with other tech companies?

The questions are certainly answerable. Surfing around in Facebook, for example, I can view the profiles of my friends at Microsoft and elsewhere, and find out to what extent they, and their friends, socialize with people in their home corporate networks, with people in other corporate networks, and with people elsewhere. Since Facebook is a web application, the same information is — by definition — available by means of screenscraping, if you want to go to the trouble, which I don’t.

So far as I can see, though, you can’t automate this process using the Facebook API. A Facebook application can enumerate the friends of the logged-in user, but not those friends’ friends. It’s hardly surprising. There’s plenty of risk in allowing that kind of transitive data-mining, and no obvious benefit to Facebook.

I guess the Facebook way of doing this kind of analysis would be to create an application that goes viral, and pools information from the perspective of many different Facebookers. I’m unlikely to do that, but if it’s something you’re considering, here are a few points to consider.

First, in order to avoid the server meltdown problem that Marc Andreessen discusses in his analysis of the Facebook platform, it might be interesting to do a desktop application. I hadn’t known such a thing existed, but I wrote a little one today, using the Python bindings to the Facebook API. In this scenario, client-side code invokes the browser to do an interactive login, and then makes API calls into Facebook. The advantage is that if your application gets more popular than you could support with a service in the cloud, it’s no problem, because users download it and run it locally. The disadvantage, of course, is that they have to download it and run it locally. And especially for an application like this one, which intentionally crosses cultural boundaries, you’d have to be prepared to run on any client OS.

Second, it looks as though, in one respect, the Facebook API doesn’t quite work as advertised. My desktop application should at least be able to report how many of my own friends are in the Microsoft network. But while the documentation says I can query for all of my friends’ affiliations, I’m only seeing one affiliation per friend. So if a Microsoft friend’s primary affiliation is the Seattle network, my application doesn’t know that he’s a Microsoft friend. Am I right in regarding that as either a software or documentation bug?

Today Lauren Weinstein draws attention to “a fascinating and apparently singular page on Google that you’ve probably never seen.” He’s right, I hadn’t, and apparently not many others have either. The page, http://www.google.com/explanation.html, appears as a sponsored link when you search for the word Jew, and apologizes for the fact that a hate site appears as a highly-ranked result. Although the apology dates back to April 2004, more than three years ago, it has so far attracted fewer citations (currently 50) and bookmarks (currently 26) than some of the blog posts I’ve written since April 2004.

Lauren writes:

The Web, after all, isn’t really computers and routers, fiber and spinning disk arrays, databases and blogs. The Web is people. Our job now is to find the path toward helping make sure that the power of Web search enhances people’s lives while not incidentally creating asymmetric opportunities for seriously damaging innocent lives in the process.

Lauren’s item today points back to a pair of earlier items in which he proposed a dispute resolution mechanism that’s reminiscent of Wikipedia’s:

Question: Would it make sense for search engines, only in carefully limited, delineated, and serious situations, to provide on some search results a “Disputed Page” link to information explaining the dispute in detail, as an available middle ground between complete non-action and total page take downs?

As we see today, that’s already happening in at least this one case. I’m sure it won’t be the only one, and that the kind of mechanism Lauren envisions will emerge.

In parallel, I believe we’ll increasingly need and want more and better explanations of all search results. Today, for example, I am the second and tenth results for the word Jon. As recently as last week I edged out Jon Stewart for the top spot. Why? I have a large Web surface area, it has grown steadily over many years, it’s mostly contained within the link-happy blogosphere.

Five years ago I called this a temporary anomaly, and predicted that a democratization of web presence will adjust the imbalance. It hasn’t happened yet, though. Meanwhile, it’s reasonable to expect that search engines might begin to provide the kinds of explanations that I’ve given here. Yes, ranking algorithms are proprietary, but some evidence — about the number of supporting pages, the structure of collections, the nature of supporting link networks — could go a long way toward helping people contextualize search results.

Web search can create an asymmetric advantage for all kinds of agendas. In exceptional circumstances where such advantage is exploited to do damage to people, I think Lauren’s right, we’ll need a mechanism to handle those exceptions. But in all cases, whether the agenda is positive or negative, better accounting for the nature of the advantage would be helpful.

It was a great pleasure to speak with John Willinsky for this week’s ITConversations show. We refer to another podcast I mentioned here. As much as I hope people will listen to this week’s show, I think it’s even more important to hear that other one, which is a talk that Dr. Willinsky gave at the UBC Okanagan Learning Conference last year.

If you’re an educator planning an offsite meeting or workshop, I would strongly recommend that you use that time to do two things:

1. Listen, together, to John Willinsky’s UBC Okanagan talk.
2. Discuss it.

Although my own weekly podcast appears on the ITConversations channel of the Gigavox network, lately I find myself listening more often to our sister channel, Social Innovation Conversations. And I’ve started to wonder: Why are these two different channels, for two different audiences? Increasingly I wish I could mash them together. Dean Kamen’s recent appearance on Tim Zak’s Globeshakers series on SIConversations gives me a sense of what that would be like. Here his pitch:

Given the enormous rate at which technology is moving forward, almost all the ‘Can this be done?’ questions have essentially been answered by ‘Yes.’ The much tougher question right now isn’t ‘What can we do with technology?’ — it’s ‘What should we do with technology?’ That’s a much harder question involving practical issues, moral issues…the haves and the have-nots, in technology, education, and health care, are diverging.

People who can develop new technologies ought to start thinking, more than they have in the last few decades, about where it’s appropriate to deploy the energy and passion to develop the next level of technology. There are just so many video games that we need, and just so many luxury leisure-time products that we need.

If societies start to recognize that we really do get what we celebrate, and we start celebrating the right things, we’ll see a much more effective use of our available technologies and a much more appropriate and focused set of developments of our future technologies. Instead of focusing on what we can do with technology, we should focus on how to be responsible to each other, to the environment, to the future of this delicate little planet.

I’ve transcribed that quote here for two reasons. First, because I know that relatively few people have the time or inclination to listen to as many podcasts as I lately find myself wanting to do. Second, because I know that people who self-identify as technogeeks are more likely to subscribe to ITConversations than to SIConversations.

As I write this entry I’m enroute from one technogeek paradise, the Microsoft campus, to another, the O’Reilly campus. In doing so I’m crossing a bridge between two cultures that are, in some ways, very different. On the Microsoft campus, for example, Windows laptops are ubiquitous and Macintosh laptops are scarce. On the O’Reilly campus it’s the reverse.

In other ways these cultures are very alike. In both places, you’ll routinely see people whizzing around on the invention for which Dean Kamen is best known: the Segway. Geeks of all persuasions are early adopters and everyday users of this machine which, for most people, remains an exotic curiosity.

And yet, there wasn’t a single mention of the Segway in Tim Zak’s 45-minute interview with Dean Kamen. What’s top of mind, for Kamen, is US FIRST — the acronym expands to For Inspiration and Recognition of Science and Technology. The goal is to reframe the idea of success which, he says, too many teenagers define unrealistically in terms of sports and entertainment. He wants them to know that success in science and engineering is, for the vast majority, both more achievable and more socially productive. A Wired article in 2000 called the idea far-fetched, but FIRST’s robotics competitions have grown steadily since 1992, and in 2007, Kamen says, the final event packed 70,000 people into Atlanta’s Georgia Dome.

A key ingredient of the program is the mentoring that’s provided by scientists and engineers on loan from corporate sponsors:

These kids really weren’t building robots. They were building relationships with serious adults, they were building an understanding of what’s possible if you put your energy and passion to things that matter.

I’d love to see a mashup of ITConversations and SIConversations that would produce more shows like that.

It’s been an interesting couple of weeks for folks who care about RESTful web services. Dare Obasanjo kicked things off with a couple of items about the Atom Publishing Protocol (APP) and Google’s use of it for its GData project. Tim Bray bristled at Dare’s characterization of APP, and it looked like we were headed for another summer syndication flamefest. (Why do those always happen in June?) When the Web3S protocol — not the Atom Publishing Protocol — was revealed as the proposed mechanism for granting read/write access to the half-billion Hotmail contacts, Messenger buddies, and Spaces friends that comprise the Live Contacts database, I was sure it’d turn into a flamefest.

But it didn’t. And now that things have settled down a bit, I’d like to note two points that may interest the majority of folks who don’t follow the saga of RESTful web services.

First, there’s the role of the blogosphere. I’ve often talked about how the interplay of voices in the technical blogosophere models a style of professional collaboration that I expect will someday prevail more broadly. We see that happening here. Sam Ruby usefully asks whether another protocol proposed by Microsoft, SSE, might play a role in contact synchronization. Tim Bray usefully analyzes the Web3S spec and offers some excellent advice, in particular:

Get yourself a test suite! APP has already been helped by the existence of code from Joe Gregorio, me, and others. Test suites matter way more than specs, in the big picture.

Along with the technical back-and-forth you can see a social process at work as the always-tricky interplay between competition and cooperation gets sorted out. APP folks: “If you had concerns about APP’s capabilities, why didn’t you voice them sooner?” Microsoft folks: “Well, we were worried about seeming to interfere, but yeah, in retrospect, we should have.” Although some of us have started to take this interplay for granted, it’s still quite novel for most people, and it’s a remarkable thing.

The second point is that, technical back-and-forth notwithstanding, the purpose of Web3S is to open up walled-garden social networks. That’s been another — and more broadly inclusive — conversation in the blogosphere recently. Facebook’s ignorance of web reputation is part of the story. Here’s another, the Facebook friend finder:

In order to find people you may know on one or another of the popular webmail systems, you’re invited to lend Facebook your credentials so it can probe your address book on one of those systems. I understand why this happens, but it’s totally the wrong message about security and digital identity to be sending to a large community of young people.

From that perspective, Web3S is just a small part of a big story: opening up Live Contacts so there’s no need for this kind of impersonation. In his talk at MIX¹ (MP3 here²), Yaron Goland lays out two scenarios. For one-off exchanges, there’s the contacts control which a third-party site can embed in one of its pages so people can selectively relay Live Contacts data into the page. For longer-term relationships with trusted services, people can grant the permission to read and update their Live Contacts directly, so that social activities elsewhere will be reflected in their own address books.

In both scenarios, you retain control. You never allow a service to use your name and password to impersonate you to another service. That’s a good thing for Facebook, which would rather not have to impersonate people. It’s a good thing for people who (whether they realize it or not) don’t want to be impersonated. It’s a good thing for Microsoft because the enabling platform services will become a business. It’s a good thing for RESTful web services³ because the API is RESTful. And it’s a good thing for everyone who believes that ultimately the Internet is our social network.

² I had to extract the soundtrack from the video and then republish it. Note to team: Let’s please make it easier for people to hear these things.

³ I’m wondering, though, like Tim Bray, about the introduction of a new HTTP verb. The session blurb was: “Data wants to be free! So come to this technical deep dive to learn how you can POST/GET/PUT/DELETE your way into Windows Live.” There was no mention of UPDATE. Of course the spec was published in order to solicit feedback, so I’ll be interested to see what comes of that.

The audio accompaniment for yesterday’s exercise hour was Tom Raftery’s interview with Brad Abrams, group program manager for Silverlight. I mention it for three reasons.

First, it’s a nice comprehensive overview of the history and mission of the Silverlight project. Now that the flurry of MIX announcements is over, this is a good time to step back and reflect on the big picture. As someone who’s been working on the .NET Common Language Runtime since its inception, Brad’s in a good position to paint that picture.

Second, it reminds me of an obvious strategy for podcasts that I’ve somehow managed to ignore: solicit questions ahead of time! Tom Raftery does that routinely. In this case people asked a bunch of great questions, Brad Abrams engaged straightforwardly with them, and the resulting show was much richer and deeper than it otherwise would have been. Given that I was an avid practitioner of this method in my journalism days, it’s crazy that I haven’t carried it forward into my podcasting. Gotta fix that.

Third, one particular segment of the interview really grabbed me. Referring to his talk at MIX (WMV, MP4), Brad discusses a strategy for exposing videos to search engines. The ingredients of the strategy are:

1. A feature of the ASP.NET “Futures” release — DynamicDataSearchSiteMapProvider — that helps developers dynamically generate sitemaps that provide the breadcrumb trails otherwise unavailable to search engines when they visit dynamically-generated sites.
2. An data source from which the sitemap provider can extract titles and timecodes for chapters within a video.
3. A SMIL wrapper that provides closed captioning both to the video and, indirectly, to the web pages that the sitemap points crawlers to.
4. A streaming server.

As an industry we’ve gone back and forth on that last point. In the beginning there was Real which primarily relied on streaming servers rather than standard web servers. The downside was that these were specialized and non-ubiquitous. One of the upsides was that they enabled random access. But then, hardly anybody took advantage of that opportunity. As you can see here, although it’s quite feasible to form URLs that point into Real streams, the details are just geeky enough to deter almost everyone.

Then things shifted. Increasingly the media encoders and players conspired to support progressive downloading. In this mode, you only need a standard webserver, serving up static files. The encoders tuck enough extra information into the files so that players can begin playing right away, after only a short buffering delay. It looks like streaming to most people, and a lot of applications and services even call it streaming rather than progressive downloading.

The upside here was that no specialized servers were needed. Any regular webserver would work, so this approach is very blog-friendly. Got an audio or video file? Just upload it to your blog, and bingo, you’re podcasting or videoblogging.

This radically democratized media publishing, and continues to do so. But, although few recognized the tradeoff, there was one. You couldn’t randomly access a static media file.

Or so most of us thought.

As it turned out, that’s not strictly true, at least not for MP3 files. I realized that some players were able to randomly access parts of statically-served MP3 files, found out how, and prototyped a gateway that would enable anyone to form a URL to a timecoded segment from an MP3 file hosted on a remote webserver.

This was an interesting result, but it was even clunkier than the methods already supported by the Real servers and players — and as we’ve seen, hardly anybody ever discovered or used their random-access features. What’s more, my method only worked for MP3 files by virtue of a special property of that format: frames are (usually) independent of one another, so you can reach blindly into the middle of a file, shove bytes at a player, and expect it to find the next frame boundary and start playing. I’m mostly ignorant of the details of video formats but, so far as I can tell, they don’t tend to work that way.

Now I wonder if we’re heading back to the future. Flash (with FLV) and Silverlight (with WMV) don’t require streaming servers on the back end, they can do progressive downloading as well. But in the services era, you’re less likely to worry about deploying your own streaming server and more likely to use an instance of one that runs in the cloud. That instance can react to requests for timecoded segments in a more intelligent way than by seeking to byte offsets.

It’s true that we failed, the first time around, to make the formation of those requests easy and obvious to people using media players. But a new generation of players — again, both Flash-based and now Silverlight-based — can be friendlier to that kind of innovation.

An example of what we should expect appears at 59:50 in Brad Abrams’ MIX talk (WMV, MP4). You search, find some title or caption text (thanks to a sitemap), click the link, and begin playing a segment at a timecode.

The hardest part, of course, is the data preparation. On my trip to the UK in January I mentioned the Open University’s FlashMeeting system which does a great job of segmenting captured video on the fly, then making it randomly accessible.

There are already too many triple-S acronyms so I probably shouldn’t do this, but the formula I’m looking for is: Sitemaps + Segmentation + Streaming.

While I’m back on the topic of screencasting, I’ve been meaning to mention another important use of the medium. Recently a colleague reported severe trouble trying to present demos that rely on a live connection to the Internet. My solution is a variation of the old joke:

Patient: It hurts when I do that.

Doctor: Don’t do that!

To avoid the pain I use screencasts instead of live demos. There are a variety of reasons for doing so. An obvious one is that it makes you immune to network glitches.

A subtler reason is that it’s hard to show software in use without wasting effort and motion. You reach for the wrong menu item, you fumble while typing. These are perfectly normal and natural behaviors, but they only add dead time to your presentation and therefore, by definition, they detract from it. When you edit out the wasted motion and false starts you create an effect that isn’t quite real — it’s hyperreal — but that’s exactly the effect that you want (or anyway, I want) a presentation to achieve.

Another subtler reason is that video playback gives you more control over timing. It can be hard or even impossible to replay a piece of a demo in response to an audience question. Likewise, it can be hard or impossible to fast-forward a demo if you’re running short on time, or if you’re losing the audience. When you’ve canned your demos as screencasts, you have a lot more flexibility.

Finally, there’s just the peace of mind that comes with only having to keep track of one single media file, as opposed to lots of moving parts. When you are speaking and showing demos, the fewer moving parts, the better.

I’ll be in Redmond for part of next week and, although my first effort to have a Crossroads Mall meetup got sidetracked, I’d like to try again. To keep things simple: I’ll just be there this Thursday night, the 21st, at around 6:30, near the bookstore. (I look kind of like this but grayer.) At some point I’ll gravitate toward the noodle soup.

As part of my re-exploration of the walled-garden social networks, I’ve accepted the entire batch of LinkedIn invitations that had queued up in my dormant account. One of them was a request from Beth Kanter for advice on screencasting. From my point of view, LinkedIn was superfluous in this case because the same request had already been made (implicitly) in this blog post in which Beth summarizes what she had figured out for herself, and then invites feedback.

Although we should probably not yet simply assume that linking to a blog post will draw the attention of the author of that post, the blogosphere does in fact propagate awareness in that way, and does so with remarkable speed and reliability. So in this case I’d seen Beth’s item before I began receiving requests from her via LinkedIn intermediaries. Because I was boycotting walled-garden social networks at the time, I thought this was a good opportunity to show how, in a case like this, the open Net can obviate the need for a closed network. So I replied to Beth’s blog item in a comment. Or rather, I thought I did. But although I wrote the reply it seems I never managed to post it. Oops. I’m sorry about that, Beth, and I’ll try to make up for it here.

But first, I want to note that your item is a textbook example of how to construct an online query for information. By summarizing what you’ve already learned, you’re helping bring other folks up to speed. At the same time, you’re helping me understand where and how I can add value. This custom is just good common sense, of course, but one that’s honored more often in breach than in the observance. If I were teaching this kind of thing in grade school, I’d use del.icio.us to keep lists of good examples of netiquette, and I’d put this example on one of those lists.

Now, in the context of the genre that I’ve called the conversational demo, here are your questions and my answers.

Q: How much scripting does he do prior to the interview?

A: None.

Q: Does he “rehearse” with his guest?

A: No. I do, of course, choose topics in which I’m interested, and to which I bring plenty of domain knowledge.

Q: Or does he capture everything and edit?

A: Yes. As with my podcasts, I lean heavily on editing when making these conversational screencasts. The editing happens on two levels: macro and micro. On the macro level, because we (interviewer and interviewee) know that whole scenes can be cut, we don’t need to worry about the performance. If something doesn’t work we can just call it a bad take and try again. We can also plan, on the fly, where to go next, again knowing that such discussion is effectively out of band and will be deleted.

On the micro level, there’s internal editing. The term comes from the audio domain and it applies in the same way here. If I can eliminate ums and you knows and false starts without compromising the video, I do.

Q: What tools does he use to capture these interviews?

A: For video I mostly use Camtasia in conjunction with one or another of the many screen-sharing tools. Since most software demos don’t require a high frame rate and don’t push lots of screen bits, that’s usually OK. However in this screencast about tagging in Photo Gallery — which, by the way, was edited down from 35 minutes to 14 minutes — the screen-sharing setup couldn’t keep pace with all the images. So I had Scott Dart record locally using Windows Media Encoder, and then ship me the resulting WMV file. I was able to follow along in screen-sharing well enough to carry on the conversation, even though what was displayed on my screen would have been useless for production. This is a variation of a technique that’s really useful for podcasters who are struggling with expensive and/or poor-quality phone lines. If you can get both parties to record high-quality audio locally, you can use a marginal VoIP setup to converse and then join up the high-quality audio later. I did that here and I’d love to do more shows that way.

For audio I also mostly use Camtasia. Originally I didn’t, I used Audacity, because I hadn’t figured out how to get Camtasia to record the two channels (caller, callee) from my Telos as a stereo track. Eventually I found that setting. It’s in Tools Options -> Streams -> Audio Setup.

Because the conversational screencast is a superset of a podcast, you’re dealing with all of the same audio production issues as in podcasting. For me, working remotely, that’s been an ongoing challenge. Telephone recording is just plain hard. Although I’ve been using a Telos for a while, for example, I only recently discovered that I’d been using it incorrectly. On the other hand, VoIP recording is hard too.

Granted, I wasn’t born with an audio chromosome, but then neither were most folks. So, remote audio is going to be a problem for most of us — a problem that, I reckon, somebody is going to make money by solving. At this point I can muddle through fairly well. But if I hadn’t already invested in the Telos I’d be looking really hard at the technique of recording locally on both ends and then joining the results in post-production. It’s not particularly hard to do that, and it’s really nice to simply abolish all the problems associated with the voice channel — whether it’s the public telephone system or the Internet.

Because it rarely applies to me, I haven’t mentioned the scenario in which both parties are together in the same place looking at the same computer. In that case I’d use whatever capture software was convenient. If the software were on the interviewee’s computer, I’d ask the interviewee to install the free Windows Media Encoder and capture video that way. And I’d probably use a standalone digital audio recorder with a handheld microphone to separately capture audio.

One final point from my recent conversation with Doug Kaye: a lot of people who think they don’t have digital audio recorders overlook the fact that they have camcorders which can perform that function. A related point: if you use a camcorder, it’s tempting to let it do the whole job — that is, screen capture as well as audio capture. Although my Channel 9 colleagues do that all the time, I don’t recommend it. You’d much rather use perfect screen capture than fuzzy camcorder capture. And ideally you’d like to be able to do that without installing any software on the target computer, using a direct-capture device. I’ve never seen one of those, but next week in Redmond I’ll be visiting our new production studio where I’m told we have such a beast. I’m curious to see it in action.

Q: Does he edit in Camtasia?

A: Yes, I do. I’d honestly rather edit in iMovie instead, because I find it to be more elegant and more capable, but it’s a huge hassle to get stuff in and out of iMovie so I usually take the path of least resistance and edit in Camtasia. If you want to do micro-edits in Camtasia, one important tip is to record at a higher frame rate than you will ultimately produce. A screencast is legible at 5 or even fewer frames per second. But if you only capture at that rate, you’ll find that you can’t make intra-frame audio micro-edits. So record at 15 or more frames per second, then produce at a lower rate.

Q: What are some best practices in terms of production and editing?

A: It’s tempting to jump in and start editing right away, and to be honest I often do. But I think it’s better to just watch the raw recording all the way through, setting markers along the way to annotate the segments that you want to include, discard, or perhaps rearrange. Ultimately you’re trying to tell a story, and those markers will help you visualize the outline of the story.

Sorry this took so long, Beth. I hope it helps.

This week’s show on ITConversations explores what Jeannette Wing means by computational thinking. As I noted here, she has coined that evocative phrase to suggest how the intellectual tools of computer science — including abstraction, naming, composition, state machines, refactoring, and separation of concerns — can add up to “a universally applicable attitude and skill set that everyone, not just computer scientists, would be eager to learn and use.”

At Carnegie Mellon, where Dr. Wing is head of the computer science department, this way of thinking pervades many other academic disciplines. But in her view, it’s really as fundamental as reading, writing, and arithmetic, and like those skills it should be taught in grade school. Since that’s not likely to happen anytime soon, I wonder if computer games — which already teach kids certain aspects of computational thinking — could help advance this agenda in a more deliberate way.