Monthly Archives: January 2006

FeedLounge.com Notes

Posted by —

0

On Steve’s recommendation, and his comments about it over the past few months, I got myself a FeedLounge.com account.

My quick-advice is: if you spend a lot of time in aggregators and don’t mind some 1.0-style problems, check it out.

I’m a Feed Readin’ Nutbird

People often joke that the only way to get my attention or tell me about something is to put an item in an RSS feed (the for:bushwald tag in del.icio.us is a good way ;>). I won’t dispute that. So, you can imagine that I spend a shit load of time in my aggregator. As such, decided on an aggregator to use isn’t something I take lightly: it’s more important than my email client, and only slightly less (or equally?) important than my IM client.

The point of all that background is this: I’ve tried switching from the venerable bloglines before, but it’s never stuck. This time I think it will, even despite a few missing features and the current (I hope just current) overall slowness of the system.

Pros and Cons

  • Pro – I was able to quickly import my bloglines subscriptions. Feedlounge, of course, didn’t know what I’d read or not read, so it set everything to read (so to speak). I actually like this because it gives me a fresh start on keeping up with things. Now I’m “only” at 473 unread items instead of however many 1,000 I was at.
  • Con – FeedLounge uses the concept of tags (most analogous in use to GMail) instead of folders. Unfortunately, you can’t order the tags at the moment. I sorted my folders in bloglines in order of “most important to read,” so I’ve been missing this feature. Whereas in bloglines I had the subscriptions I read hourly at the top, in FeedLounge they’re alpha sorted so I have to scroll around a lot to get to my “top tags.”
  • Pro – On the other hand, being tags, you can apply more than one tag to each feed. Thus, it can show up in more than one “folder.” I haven’t fully appreciated this yet, but it was something I wanted in bloglines. I’ll see how it works out, or if it’s just a sugar-feature.
  • Pro – You can also tag posts. I’m not really too interested in this as I’m a del.icio.us nut. Now, what’d be killer is if the “tag a post” feature was a way to add a del.icio.us bookmark. That’d flip my shit.
  • Con – FeedLounge mixes together your read with unread items instead of just unread. In bloglines, when you click on a feed you only see items you haven’t read yet (or ones you’ve made sticky). At the very least, I’d like to toggle this in the Settings.
  • Con – As you would expect from a just released web app, it’s painfully slow. That’s just growing pains; as a programmer, I appreciate any bear that can dance ;>
  • Pro – It has 3 different types of layouts: Outlook style 3 pane layout, 3 vertical pane layout, and what I call “normal” (’cause it’s how bloglines did it…and I refuse to use that other term.) If you want to skim headlines, the 3 vertical pane one is good. If you’re looking at, say, a an picture feed, the “normal” layout is best. I haven’t come up with a use for the 3 pane one: I hate that email reader metaphor/layout. You can also switch between each layout by typing either 1, 2, or 3. Quick-keys in web apps are great! Being able to switch between these layouts (at least two of them in my case) is one of my favorite features.
  • Pro – There’s great potential in the history feature. FeedLounge.com keeps track of all the posts you read (something is only marked as read if you click on it or “page” to it). On it’s own, this is good for trying to remember something you read and liked but were foolish enough not to bookmark. But what this part of the system really needs to become — and I’m dead serious about how much it needs to — is first an RSS feed and then a way to generate attention.xml. That alone would greatly differentiate FeedLounge from the competition.
  • Con – The up and down arrow keys can’t be depended on to scroll the content. FeedLounge has a lot of key bindings, and the arrow keys are (sadly for me) used to navigate the tags and feeds your reading. I use the arrow keys extensively to scroll. I have a 12″ PowerBook, often with no external mouse (read: scroll-wheel), so I like using the arrow keys to move web pages and up and down. Granted, the space bar can be used to “page down” a post, but my reading style (much to Kim’s chagrin when she read with me) has been to frequently scroll through a web page, even as little as a line at a time. Perhaps I’ll get used to the new way of using arrow keys and the spacebar. But, in the mean time, I’ll be using the track-pad and mouse a lot.
  • Con – As Steve pointed out, there isn’t an out-of-the-box way to expose a “blogroll” yet; I don’t think there’s even a public OPML URL. This was always a nice feature of bloglines: it was fun to both display the blogroll (or a link to it) on your blog, but even more fun to go browse other people’s setup in bloglines. I used this a lot to figure out how to arrange my feeds.
  • Con – At times, on my 12″ screen, all the meta information that decorates each post can be too much. For the high-frequency feeds in bloglines (news and searches), I’d configured bloglines to display just the titles and nothing else. This allowed me to skim those high traffic feeds quickly. While you can certainly use the 3 vertical pane layout to achieve this, I’d still like to turn it on in the “normal” view. Again, this might just be a case of me needing to get used to the new way of doing things.
  • Pro – The AJAX interface is nicely done. I’m quite enamored of all the “Loading” messages and screens. Well, it’d be nice if saw less of them, but at least they look good ;>

In summary: there’s a whole lot to like about FeedLounge.com if you live part of your life in an aggregator like I do. At the same time there’s some key, missing features, and some annoying 1.0 problems (slow speed, minimal configurability, no public facing/blog/JavaScript widgets). But, I’ll be happy to keep paying for it, ’cause my instinct tells me it’s gonna be good. I’ll be looking for a free t-shirt once it get acquired or wildly successful. Those bloglines bastards never sent me one ;>

Technical vs. Non-technical, or, Re: The Process Variant of Conway’s Law

Posted by —

1

Scott Sehlhorst has a thorough reply to the Document Mobile example in one of last week’s posts.

I like his re-thinking of the cynical idea that layers of docs are a way for non-technical people to hide-out. Indeed, the docs do provide a sort of “common language” for the technical and non-technical people to talk in.

In fact, Sehlhorst’s post serves well as a “what you should be doing” reply to the problem of Document Mobiles.

Non-Technical People

As I’ve discussed these ideas with people over the last few days, I’ve realized that my definition of “non-technical” is broader than most folks think. For example, I don’t expect a “technical” person to know how to program, or even debug a hairy system problem. Those types of things are what “programmers,” or, at least, “system administrators” do.

What Do Technical People Know?

I do expect “technical” people, for example, to know things like:

  • Right clicking on a web page is an extreamly weird and uncommon thing: like a 3 wheeled car.
  • Changing the wording on a screen isn’t a big deal.
  • When to use a GUI vs. a web app.
  • Most aspects of web app usability and design, e.g.: methods of text overflow controlling and scrolling issues, or what “AJAX” means for making web apps more dynamic and realtime.

Of course, there are exceptions, variations, and thin lines to walk for those, and other, things depending on the system and requirements. But, being able to sort out those issues is the core of what makes someone “technical.”

Editors and Writers

To make an analogy: an editor isn’t a “writer” but they’re certainly in the business of helping put together articles, books, and stories. There’s a shit-load of shared knowledge between editors and writers. If you took some dude off the street and had them be an editor, chances are the best you’d get when they read the book would be “this books is long,” or, “I like this book.”

Non-technical people often give similar responses when confronted with demos of software: “could we move that header over a little to the left?”

An Example

I’ve had the pleasure to meet several “technical” people who aren’t programmers. For the issue at hand, Brandon stands out as a good example. He’s a product manager, though he did used to write code…in C++ I think of, all horrors. No wonder he stopped programming ;>.

Despite being a “mouse person” (as opposed to the “keyboard people” who type code), he knows his shit when it comes to software. For example, if you tell him you’re starting an application, he’ll throw a barrage of technical questions at you like:

  • Are you bundling a database? Oracle? MySQL? Hypersonic? Can I switch out the database? Can I move the database?
  • Is it a web application? Java? Ruby? Does it use JBoss? Just Tomcat? Rails?
  • OK, do you have group permissions? Fine grained permissions? Permissions at all? LDAP? Active Directory?
  • How about an XML over HTTP based API? On that note, do you implement the <insert your domain here> blah-blah data/process standard(s)?
  • You doing water-fall or Agile? How long’s the iteration?
  • Of course you’ll want to upgrade to the new Java. But do we really need to? Does it at least run faster?
  • Users don’t want 3,000 nodes, events, or 3,000 of anything. Let’s give them 5.
  • There is no right click on a web page. Shove that JavaScript up your ass.

(OK, maybe that last, ass part is what I’d say. Brandon has — what do they call it? — couth?)

The above is a good mix of “speeds and feeds and feature tick-lists” and to understanding how technologies are used and can be used, in both old and new ways.

Point being: he can actually add a shit-load of value to the process of writing kick-ass software. And that, of course, is the idea of a “technical” person. They don’t need to write code, but their work should directly inform and feed into the development and (if you’re into making money) monetization of code. Otherwise, there’s probably a degree of waste going on that could be cut out.

[DrunkAndRetired.com Podcast] Episode 36 – Fans and Focus!

Posted by —

0

In this episode, we talk about some recent positive comments — and cash-money from Jomdom! — and the tediousness of dealing with focus in web browsers. We also catch up on Charle’s indie-programmer life-style.

And, don’t forget to add yourself to our frappr map: you can check out where other listeners are!

As always, leave a comment on the blog entry, email comments (text or MP3s) to comments@drunkandretired.com, or call out Skype number and leave voice-mail: drunkandretired or +1-512-879-6339.

(This episode edited by Coté)

Tags: , .

The Process Variant of Conway's Law

Posted by —

0

Recently I’ve found myself explaining what I call “The process Variant of Conway’s Law” to several people. Most of you, dear readers, have probably figured out that Conway’s Law is one of my top 5 favorite “laws” about software development (probably right behind “9 women can’t make a baby in one month”). I’ve mentioned it in several posts in the past, for example this one on sizing iterations to your desired goal, where I said:

You end up with a sort of process/methodology version of Conway’s Law: the software development process an organization uses will directly reflect the managerial and communication structure of that organization.

And there’s another mention in this post.

The Document Mobile as a Test

My neighbor’s have a mobile hanging in their tree made out of, well, what seems like junk: CD’s, card-board but-outs, old styrofoam cups, and Mentos tins. When I look at it I think of an org-chart with it’s single point at the top and branching out sub-trees with all sorts of stuff hanging from it. Branches and leaves to use nerd-talk.

Cauvin, as he often does in the space of project management, did a good job outlining an all too common “document mobile” in the software world: you start with an MRD, which branches out to a PRD, and then an FRS, then an SRS, and finally, when the coder is coding away, tasks and other “get the shit done” items. (Don’t worry if you don’t know all those TLA’s. The actual meaning — the answer to the question “what the fuck do I write in this?” — varies from group to group across companies).

Ostensibly, the two goals of this document mobile are:

  1. To start out very broad — “we need software that allows The Kids to live a mobile life-style!” — and slowly whittle down to the extremely specific — we need to use the Motorola Fizy5 TuneDaddy with the latest Upchuck IM’ing client, but disable the Bluetooth photo sharing” … “to accomplish that we’ll use our own OS with the following screens, functionality, wizards, etc.”
  2. Allow those at the top to keep track of how much those at the bottom are getting done. That is, workflow and dashboards!

In practice, this document mobile is the prime example of The Process Variant of Conway’s Law. That is, each of those document maps almost 1-1 to a level in your org-chart:

process-conway-tree.jpg

I obviously have a strong stance on the need for software companies to simplify their over-all approach and reduce waste, so you can imagine that document mobiles like the above drive me nuts.

The point is, when it comes to process and documents, whip out your org-chart, and I guarantee there’ll be endless “synergy” between that chart and all the artifacts and practices in your process/methodology.

What You Want

Put simply, when it comes to innovating software, we’d like something like this:


process-conway-flat.jpg

Tags: , , , .

Calandaring Search

Posted by —

0

Like most info workers, I’m chained to Outlook for my calendaring and meeting scheduling. Yesterday I encountered a use case that be nice to have implemented: I was looking for an available conference room with a projector in my building.

While it’s easy to figure out if a conference room is available, I’m not sure how to query if the room has a projector or not. Even better than dicking around in Outlook would a nice Google-like web page I can go to and simply type in “austin available conference room projector” and see a nice, clean list of conference rooms that have projectors.

Tags: , , , , .

Two Takes on Prototypes

Posted by —

0

As so often happens, two different people in the old blogroll talked about the same general topic the other day. This time, prototypes:

  • Steve O’Grady:

    The net net is that most of the pitches I receive with respect to software are about telling me something, rather than showing me something. It’s one of the reasons that I love firms that ship me the bits; I don’t get to install everything I’d like to, but I play with as much of it as I can. Unsurprisingly, those experiences tend to be infinitely more compelling than anything that can described to me in a Powerpoint deck. And if that’s true of an analyst, how do you think a developer might feel? You think they’d prefer to see how they can use your product to mashup Google Maps and NIPP RSS concerts feed, or look at a couple of slides describing generic web services?

    …

    What do I mean? Let’s take databases, as an example. If I said that Derby can be used as a backend for offline, persistent browser based applications – how interesting is that really? No matter how I dress that up in PowerPoint or wordsmith it, it sounds dry and rather boring. But what if you showed that capability, live? You just might impress some very sharp people.

    So the lesson in all of this is probably rather obvious: if you want to interest new audiences to your product – think about showing it to them. Or better yet, letting them show it to themselves. Because PowerPoint and press releases should be the fallback position, not the default option.

  • Godin, via Cauvin:

    “Too many times, I’ve gotten excited about an idea and created a conceptual prototype. And almost every time, people, smart people, didn’t get it.

    Here’s my new prototype rule of thumb: your prototype has to be better (better build quality, faster interface, better lighting, whatever) than the finished product is going to be. That’s what people expect anyway–they see your prototype and take off 20% for reality.”

Tags: , , , , , .

[DrunkAndRetired.com Podcast] Episode 35 – Zombies, More Goddamn Ruby on Rails

Posted by —

0

In this episode, Coté lays out his master’s thesis* on the current story trend in the Zombie genre: zombie evolution.

As if that weren’t enough, we try to finally close out the Ruby on Rails conversation — spanning 4-5 episodes — by responding to this comment.

* It’s not really Coté’s master thesis. C’mon. That’s
about as believable as Coté and Charles being retired!
Yeah. …it’s his doctoral one.

(This episode edited by Charles.)

Tags: , , .