Collecting News for All: How I use Google Reader and Pageflakes

news magazines

Build your own mashup news feeds.

Because of my work, and my belief that information and knowledge should be shared as widely as possible, I collect web news and blog posts into RSS streams that anyone can follow.  Maybe you’d like to do this too; maybe you just want to “follow” my feeds.  In any case, here’s what I do and how I do it.

While I listen to CBC in the car and thereby get pretty much all the typical news I need, I do like to keep up on developments in various fields too.  That’s where the web comes in.

I use Google Reader.  There may be glitzier readers out there, but none can do the very simple thing of composing RSS feeds of articles I’ve tagged and shared.  Google does an excellent job of explaining how sharing works in Reader; I won’t duplicate that here.  Basically, this lets me build my own “custom” feeds out of other, existent feeds.  I guess that makes it a kind of mashup.

Continue reading

Advertisements

My web presence, IV: Diigo wins by an annotation

I’ve decided to use Diigo as my key bookmarking app.  Here’s why.

There’s a lot of useful stuff on the web, but it’s usually hidden in an awful lot of crap.  As a professor and design researcher, it’s important for me to have access to a wide assortment of good information.  The web can deliver that information only as fast as I can identify it.  So when I do find something particularly useful, I want to make sure I can remember (a) that it exists and (b) where it is.

Enter bookmarking apps.  These are web-based applications that let you bookmark other sites, and then search your bookmarks quickly.  Because the bookmarks are stored on servers elsewhere on the web, there are two immediate and important benefits.  First, you can get at your bookmarks from anywhere (i.e. you don’t have to carry your laptop around with you just for the sake of accessing your bookmarks).  Second, you can share bookmarks with others (this is an interesting and under-utilized method of collaboration these days).

Years ago, I’d pondered the few existent bookmarking services and found them all lacking on one particular front: you can tag a website, but the service won’t index the site too.  I think indexing would be good because the only “best” set of tags is an exhaustive set of descriptors and keywords that describe the item, which no one really wants to type in.  Most keywords are already in the item’s content, so why should one have to type them in again?  By indexing items, one can use fewer tags, which also makes tagging easier and more consistent.

So, since I couldn’t find what I needed, I decided to roll my own.  It’s quite buggy still, but SERF does work, sort of.  I call it “anti-social bookmarking” because I’m the only user who can add/edit items.  That’s mostly because (a) the software is still, as they say, pre-alpha, and (b) it’s only for storing the links that I care about for my teaching and research.  I’d love to develop it further, but I can’t get the funding I need to develop it as a research project, and I can’t find programmers I trust to work on it for me a-la FOSS.  (Though I’m always open to opportunities.)

But the web waits for no man, and while SERF is good for some things, there are more items that I want to track than I can possibly add to SERF – partly because many of them don’t have that much to do with my work.

So I needed something else, something I could use to pitch items into as temporary storage, but still functional enough that I can use it to quickly look things up when I need them – and make them available to my students and colleagues.

I’d had a Delicious account for ages, but never really used it.  By the time I realized that I really needed a bookmarking app, there were competitors.  So for the past couple of months, I’ve been playing with Delicious, StumbleUpon, Diigo, and Twine.  And I’ve recently come to the conclusion that Diigo is what I need.  I decided this based on five criteria: bookmarking functionality, look and feel, extra functionality, shareability, and performance.

Bookmarking

Delicious, Diigo, and Twine all have comparable basic bookmarking functionality, including appropriate bookmarklets and toolbars.  Basically, you navigate to the page you want to bookmark, click the right icon and you get some sort of popup that lets you tag the item, add a description, and, depending on the service, do various other things.  Twine has the most web-2.0-ish facility, but that doesn’t necessary impress me.  All but StumbleUpon recommend tags based on others who tagged the same resource.  But since I have my own tagging scheme that I find is significantly different from those of most other users, this doesn’t really matter to me.

As far as basic bookmarking goes, all four systems are pretty evenly matched.

Look and feel

Look and feel is, for me, extremely important, partly because I do appreciate an aesthetically pleasing web site, but also because I’ve found that look and feel ties very closely to usability.

Here, Delicious really shines.  It has an absolutely brilliant look and feel.  The screen is laid out in very carefully chunked areas that have consistent structure and content no matter what part of the site you access.  Every little design feature of the page serves a very clear purpose, and everything is there only once – there’s no redundancy.  Everything is visible: no strange icons or bits of text magically appear when you mouse over something.  (That really annoys me.)  I’m sure people who specialize more in web usability could go into much more detail, but suffice it to say that the Delicious look and feel is, for me, like a breath of fresh air.

Diigo comes in second.  It has a good layout with just a little redundancy.  Everything is visible.  I don’t like Diigo’s rendering of the tag cloud; it’s not as elegant as that in Delicious.  Indeed, the entire site is just not as elegant as Delicious – it looks slightly rough and seems to not use screen space quite as well as does Delicious.  (This might be because Delicious has been around for so much longer that its developers have had the time to carefully tweak the look and feel much more.)

StumbleUpon is next.  It’s interface is interesting, but not flexible enough for me.  I wish there were other ways of arranging things; I don’t mean just skins or themes here, I mean the arrangement of the actual items.  It has an ugly tag cloud.  I wish there was an easy way to get rid of the screenshot thumbnails for each entry; I can understand that some people might like them, but I find them useless.  And I was never able to get rid of them.  I don’t like how they string tags and the URL on one line, because if you have more than a few tags, the URL is truncated.  Indeed, showing the URL is of limited use anyways.  The other systems expect you to mouse over the item’s title and look at the address bar of your browser.  Put all these things together, and you get an app that I just don’t feel comfortable using, compared to the others.

Twine, unfortunately, comes up last here.  I tried real hard to understand the Twinerly way of doing things, but I just couldn’t get it.  I keep loosing track of which part of the screen I should be looking at, and what all the boxes were for.  The problem isn’t exactly the layout, but it’s the content.  For instance, under My Items, you can filter the list of your bookmarked items in lots of different ways – too many ways, if you ask me – including by “related people,” the meaning of which I’ve not yet deciphered.  Lists of items also seem to include all manner of items including individual bookmarks, twines (socially-constructed feeds of items on particular topics), comments you may have posted on individual items, and other things too.  I find this confusing, and I wish they were somehow compartmentalized.

Long story short, every time I use Twine is like the first time.  Which is not good.

Extra functionality

Each of these services provides extra functionality of one type or another.  Caveat lector: this category is very subjective, because the functionality I value is the functionality I need – which might not be what you need.

All four services offer alternative ways to establish groups around specific topics or subjects.  Each site has it’s own particular way of doing it, but they all really amount to the same thing.  They also all offer RSS feeds for virtually any list of items you can generate.

StumbleUpon has a very interesting service: you specify what kinds of websites you like (about, say, science fiction, or AJAX programming, or Labrador Retrievers) , and then when you hit the Stumble button, you are taken to a random site of that kind.  You then rate it with a simple thumbs up or down.  StumbleUpon’s recommendation engine uses your ratings continually fine tunes it’s recommendations.  I really like this approach – it’s clean and simple – but it works for people who aren’t looking for anything in particular, which is a category that doesn’t include me most of the time.

Twine’s unique contribution is it’s AI-ish tagging engine that is supposed to help you tag things and organize them into feeds (twines).  The problem for me is that my personal tagging style is informed by years of study on classification systems and taxonomies, which means I’m not your average tagger.  So Twine’s recommended tags rarely line up with what works for me.

Delicious offers little in the way of extra functionality except for being able to search the entire tag cloud of all entries, which can be amusing, but no where near as much fun as StumbleUpon.  But Delicious is the purist’s bookmarking site and extra functionality is just not what it’s about.  Which is fine by me.

Then there’s Diigo.  Diigo allows you to highlight and annotate sections of a web page, and share those annotations with other users.  Installing the Diigo toolbar gets you a collapsible sidebar in which all these annotations can be read side-by-side with the corresponding source material.  This means that groups of people can collaboratively analyze documents online and asynchronously.  It also means I can note specific passages that are important to me, so that when I come back to them later, when I’ve forgotten why I bothered to bookmark the site, I can just read my own annotations and remember what all the fuss was about.  Absolutely brilliant, especially for scatter-brained eggheads like me.

In terms of extra functionality, Diigo runs away with the prize.

Shareability

By shareability, I mean the ease with which bookmarks can be shared with others.  Here, again, Diigo pulls out in front – just by a tad – by providing synchronization of Diigo bookmarks with some other services, including Delicious.  I haven’t seen comparable services from the others.

All four systems support RSS feeds, and sharing via other mechanisms like email, or the formation of groups or other structures like them.

Performance

In terms of access speed, page load speed, and general zippiness, the only site that I found quite slow indeed was Twine.  Not only did the pages take long to load, but there are often quite dramatic pauses between clicking on a link and getting any response.  I know it’s not my ISP, because everything is behaving properly.  Perhaps Twine’s AI features combined with its recent and sudden increase in popularity is putting a bit of pressure on their servers.  I hope that’s all it is.

Still, speed is everything these days.  Web 2.0 apps were originally conceived especially to improve (perceived) performance on the client side.  So a slow Web 2.0 app, such as Twine, is really a contradiction in terms.

Summary

StumbleUpon has the fun factor, and Delicious has the brilliant look and feel.  These are important.  But to me, nothing can beat the raw functionality of Diigo’s annotation system.  Twine, unfortunately, just didn’t make the grade.

So, while your mileage may vary, I’m convinced Diigo is the cream of the crop for me.  And since I sync my Diigo bookmarks to Delicious, I also have an excellent “Plan B.”

I also continue to check updates on both Twine and StumbleUpon, because they’re different from what Diigo offers, and I occasionally find some really cool sites that way.

Other things

Sometimes, strange things happen on the Internet.  One of these things is Compete.com’s graph of unique visitors to Delicious, Twine, and Diigo.  The sudden spike in activity for Delicious relates, I think, to their offering connectivity with Twitter.  Twine’s increased activity, however, is different; it’s more gradual and shows all the marks of classic exponential growth (i.e. “going viral”) that mark word-of-mouth transmission.  The dip in the past month could be an anomaly – after all, some people just get caught up in things when they go viral, and eventually come the other side saying: What was I thinking? – or it could be something else; we’ll just have to wait and see.

It’s the exponential growth that gets me.  What in the world got into people?  I’ve been experimenting with Twine since long before October 2008 when the growth started, and I noticed nothing.  Sure, there were some changes to Twine’s user interface a few months ago, but they seemed pretty minor to me.

And then there’s the Alexa rank data for all four bookmarking sites, which you can see at the top left of my Computers tab on Pageflakes.  Since it’s rank that’s displayed, the low number is best.  Notice that Twine is the lowest rank, and StumbleUpon is first.  Also notice that something happened just before April.  This tells a different story than does Compete.com.  And I can’t find any explanations anywhere.

So much data; so little information.

Wrap-up

Lesson: I didn’t know what I really needed till I played with these systems.  You can rarely solve a real problem just by thinking about it – no matter what they taught you in high school.  To solve real-world problems, you have to act, to do things that poke at the problem.  This sets up a feedback loop between the problem and your brain that let’s your brain work both consciously and unconsciously on the problem.  This means you’ll solve the problem faster.

So when you’re looking for any kind of system, take the time to play with the alternatives and take the time to reflect on the good and bad points of each.  Make notes.  Then weigh the pros and cons of each and make an informed decision.  It’s harder and takes longer than just choosing something, but the upfront cost will more than pay off in increased productivity (and fun too!) later on.


Also see my last post about my web presence: A First Attempt.

 

My web presence, III: a first attempt

The road to bad software is paved with good intentions.

In “what’s my problem,” I described why I wanted a web presence. Now it’s time to explain my first attempt, why it failed, and why it still remains my ideal.

I was always interested in using computers to keep information organized. Back before the Web, I played with lisp code for Emacs, creating little hypercard-like modules that would let me link words in one file to other files. And once I’d discovered CGI scripting for the web, I often tried to figure out how to interact with web pages through a browser, but never had that breakthrough moment. I had to wait for Ward Cunningham to have it for me. A programmer with an engineering background, Cunningham invented the first wiki (which continues to thrive at c2). The instant I saw his solution, everything fell into place. It was without a doubt one of Those Moments in my intellectual life.

I began to experiment with all kinds of wikis: oddmuse, mediawiki, twiki, kwiki, moinmoin…. I was, one could say, rather promiscuous in those days. I was convinced that there was a way to make a wiki solve all my problems.

But no matter what wiki I tried, there was always something that chintzed me off – the look and feel was wrong, the editing shorthand was arcane, the API was obtuse, there weren’t enough functions, there were too many functions, performance was sluggish…. It was incredibly frustrating because the more I worked with wikis, the more I became convinced they were The Right Answer, but I could never find The Right Answer For Me.

So I decided to write my own wiki engine. And thus was born xiki. I’ve been putzing around with xiki for years now. I even have a tiny bit of research funding to develop it as a tool for engineering designers. Xiki is written in perl, and is quite fast, faster than most other wikis I’ve tried. It has a syntax that is quite concise, compared to many other wikis. Of course, it’s nowhere near as robust as most popular wikis, and I’m sure the code would make good perl programmers break into hysterical laughter. But it works well for me and my grad students.

Or so I thought.

Once I had the basics running, I started having big dreams about building into xiki all kinds of functions to help me handle my web presence. But as I started figuring out how to implement those big dreams, I started to discover problems in xiki.

For instance, it has a module to handle bibliographies in a reasonable and handy way. But it’s really slow when you want to search a bibliography. Also, a xiki page is processed and then spat out right at the end. So xiki cannot build output a bit at a time. This is something most other wikis do, and for good reason. Even though it makes the software trickier to write and slower, it appears to run faster, because it starts producing some output much faster. That’s one of those little tricks computers can play on the poor human mind. More practically, producing output a bit at a time does let one build pages in increments. These are things xiki just can’t handle.

Adding event handling (like an appointment calendar), aggregating RSS feeds, and tagging interesting web sites are all things I want to add to xiki. But I can’t – not at least with xiki as it is right now.

I ended up writing code that suffered exactly the same problem as every other wiki I’d tried – frustratingly close to what I needed, but not quite enough.

In the meantime, I still needed functionality and I couldn’t wait for myself to get xiki right. So I started using other things. I use a web-based calendar system called Calcium to keep my work-day appointments. Calcium hits as close to the sweet-spot as it gets: it’s dead simple to install and use, it’s robust, it’s flexible, and it lets others book appointments without needing accounts. This means my students can just book an appointment to see me whenever I’m free. As far as it goes, it’s been a life-saver.

Another thing I’d been doing for years was accumulating links to interesting web sites. I had no idea what to do with these. I tried all kinds of social bookmarking software (like delicious, diigo, and twine), but they all suffered from the same problem: I could only browse by the labels with which I’d tagged web sites. This is a problem because sometimes (often, actually, I want to look things up by keywords that I hadn’t thought of adding as tags. So I’d end up spending a lot of time browsing through many links without finding what I wanted – which rather defeats the whole point.

Also, as anyone knows who has been tagging things for any length of time, your tagging habits change with time. It happened to me. After months of tagging things, I found that the tags I’d used on my earliest links were somehow wrong. I tried to develop a taxonomy – a classification of tags – so that I’d have a usable set of rules to assign tags. But there was no way to develop a taxonomy that would cover all the tags I hadn’t yet thought of. So the taxonomy kept changing… which rather defeats the purpose.

Then one day I realized that the reason I kept using so many tags is that I was trying to capture every keyword that appeared in the web site I was tagging. What I needed, I realized, was a way to tag web sites, and also index them (like Google or Yahoo do).

Of course, there was no software that did that. To this day, I still can’t find anything that both tags and indexes web sites. So I wrote my own. The current incarnation of that software is called serf – and yes, it does look a bit like delicious. It uses a cool search engine library for Perl called KinoSearch. The neat part of serf is that it can search on either tags or keywords or both. Since most web pages have lots of good keywords in them, I need fewer tags. And also, those tags can be more consistent because they’re more general – specific tags are just keywords, already in the index for that web page.

I still use, and develop, serf. But I wish xiki could have done it.

Serf may be working out well, but it’s the only part of this sorry state of things. Xiki works fine as a plain wiki, but it needs serious help before it can replace any of the other tools I’ve become accustomed to.

Things finally came to a head a few months ago, when I realized I was spending more time pissing around with different bits of code and web apps than actually gathering information and using it for something. I realized I had to do something, because my productivity was shot. (Don’t tell my boss.)

And being a designer, I decided I had to start designing a better answer. I’ll write about that, next time.

My web presence II: what’s my problem?

I realized my web presence was all wrong. This was the first step: recognizing imbalance.

I’ve already explained what I mean by web presence.

One day, I realized that my web presence was slowing me down. And then I thought I must be an idiot for not having noticed before, because I also realized that my general frustration with syncing my web presence with my self had been going on for some time.

Why hadn’t I noticed sooner?

I think there’s two reasons. First, though my conscious mind hadn’t noticed any deep problems, my subconscious ming had. This is just how the brain works. A huge amount of cognitive computation is done unconsciously. Indeed, it seems that parts of the nervous system like the retina, the optic nerve, and the spinal cord are not just cabling trunks that transmit stuff to and from the brain, but are in fact essential processing units. Consciousness only lives in the cortex; we’re just not aware of all the “thinking” that the rest of the nervous system does.

So, part of my brain recognized the problem, but had nothing to “report to management” as it were – nothing to pass up to my conscious mind. In the meantime, my conscious mind, living in blissful ignorance of what the rest of my brain was thinking, kept on doing business as usual, convinced that it was doing the right thing.

But the brain is not a serious of compartments; it’s just one big thing, and there’s bleed-over (like dreams) between it’s elements. So my subconscious mind kept niggling my conscious mind that something was wrong, and my conscious mind kept telling it to shut up.

And that’s what my frustration was: the mismatch between what the conscious and the subconscious parts of my mind wanted me to do.

The second reason that it took me so long to recognize that I was doing something wrong was that I was unaware of all the possible tools I could use to create and manage my web presence.

I’m an old-school UNIX geek: in my day, if you needed some software to do something, you wrote it yourself. I know that must sound terribly parochial today, but that’s how I was growed up. So it never even occurred to me to look for software that did what I needed. And even if it had, I wouldn’t have known what keywords to give Google to look for it. It was only dumb luck that I came across some of the software, and, over time, studied more of it. Eventually, the amount of stuff I learnt reached a critical mass. And then it all made sense.

I’d found all kinds of services on the web, each providing a certain kind of functionality. What I needed to do was match up my needs with specific tools. DUH! (Yes, it’s embarrassing to admit I fouled up like such a newbie.) Once I did that, everything started falling into place.

So what are my needs?

Create a Body of Knowledge about Designing. This is my windmill against which I tilt, and probably will for the rest of my life. There is a huge amount of information about designing, but it’s not yet been integrated into a sensible body of knowledge. So I need a way to create suitable content for this.

Collect Bits of Information. Some things interest me. Bits of information about those things are scattered around, in assorted web pages and especially blogs, all over the world. This isn’t just trivia. It’s useful information that I find forms the subtext of things I think about, write about, and do in my research. When I find these bits, it’s important to save them because I can’t be sure I’ll ever remember where they were. So I need a way to capture and organize those bits of information.

Keep Current on Certain Topics. Besides the bits of knowledge floating out there in the ether, there’s also a good amount of information on current events. As a designer, it’s important to understand the context of design problems and solutions. I get the context by keeping up with current events. This comes through blogs (at least, the good stuff does). So I need a way to organize how I read blogs.

Share What I Find. Besides the pragmatic concern of making good information available to my students, I tend to want to share what I know and learn. This means that whatever bits of information I do gather, I want to make public. This also affects the way I present it – I would want such information to be arranged in a way that (as far as I can tell) will be usable to others.

Share What I Think. The information I gather informs my thinking. Sometimes this results in “research,” other times in opinion. Pure research I save for official publications in journals and at conferences. The opinions, however, can also be quite useful. Having to explain one’s thoughts to others is an excellent way of clarifying those thoughts to oneself; as they say, the best way to learn something is to have to teach it. So I need a way to communicate that’s more than just passing along bits of information.

What’s important to note here is that even my identification of these needs emerged only as I struggled to create a solution. Looking for the solution helped me understand the problem. Some designerly folks call this co-evolution (the problem and solution evolve together).

So how did I get to the point of understanding what the problem really was? That’s what my next post will be about.

My web presence, I: What’s a web presence?

As promised in a previous post, here’s the beginning of the explanation of how I am designing my web presence.

Web presence is the term I use to describe the abstraction that is the sum total of everything I put on the web. My web presence not me, like some avatar or simulation of me. It’s what I leave behind; it’s the things I build and give some purposeful shape to on the web, the things that are still there after I log off that others will use or abuse for their own purposes.

My web presence not an artifact, like a product I might design, because once the artifact is done and out the door, I’m through with it. My web presence is different because I’m always revisiting it, tweaking it, disassembling and reconstructing it to better reflect me, help me, stimulate me. It grows and evolves with me. I do log off, but I always log back on, loaded with new ideas and bits of information that I want to add to my digital universe-self.

Everyone’s web presence is different. Discovering what exactly your web presence is can be alot like a vision quest; you have to start seeing yourself from the outside and relate your self to the rest of the (digital) world. Your web presence will also evolve over time – partly because the web itself continues to change and evolve. The services that you can use today to express your web presence are far more sophisticated than what was available just a few years ago.

And if you want to have a true web presence – a presence that is true to you – then you need to learn about the alternatives. Don’t just use facebook because everyone you know uses facebook. Use it because it best suits your web presence.

My web presence is that of a geek with a slight case of OCD. I like to order and organize the things I know. And I like to keep up with certain kinds of information, even though that information isn’t directly useful to me in my career. I also like to express myself – not in social settings, but in more one-way settings. Hence this blog, and my wiki.