|
If
you want to know when new interviews go online,
subscribe to the WebWord.com
Usability Newsletter!
AmphetaDesk
and the Adventures of Morbus Iff
An interview with
Kevin Hemenway, a.k.a. Morbus Iff, creator
of AmphetaDesk
Conducted via email by John S. Rhodes
(10-June-2002)
Inside AmphetaDesk
What is
AmphetaDesk?
AmphetaDesk
is a syndicated news reader - it can display the news and content from
thousands of websites in a single, customizable page, saving the end-user
the hassle of visiting each site manually and slogging through
advertisements and confusing navigation. It's a massive time-saver for the
information junkie.
How have you made AmphetaDesk easy to understand by non-technical users? Why
is usability important to you?
I've really tried
to make AmphetaDesk easy all-around. There's no install program... when you
extract it from the download, it's installed and raring to go. I try not to
mention RSS anywhere, or force the user to understand what XML is. I try to
include documentation right on-screen, so that users don't have to run
scurrying for a manual. I try not to use terms I can't easily define, again,
on-screen. I've also tried to make it easy to get in touch with me - there's
an "Email Support" link on every page you'll see.
It's imperative to
me that users aren't confused or feel like they have to learn something new.
There are other programs that are specifically tailored to the web-browsing
elite, those who live and breathe this stuff, and they have immense learning
curves for people who haven't been around the block. I hate knowing that all
this wonderful technology is being lost to the normal crowd.
All of my work in
any project is catered to "everything for everyone". If I'm
worried that one person is going to miss out on something, it has to change
- it's rather hard for me to justify losing someone because I don't want to
take the effort to make things easier. The "Email Support" is
there as a lifeline, I want you to "phone a friend" and get the
answers you need when you're stuck.
What makes AmphetaDesk different than other RSS readers? Is your
interface better? Is your software easier to use? Does your software cost
less?
AmphetaDesk is
opensourced, free, and available on all platforms - there are very few
others that can say the same (about the nearest is HotSheet
from johnmunsch.com, and that
requires an install of some Java libraries that may or may not exist on your
box).
AmphetaDesk also
uses a web browser for its main interface (see Figure 1), which means
a number of good side effects. For one, the user is already familiar with a
browser - they know how to use one and may have customized it just the way
they like, meaning they'll be more at ease when they interact with
AmphetaDesk. They may have happy bookmarklets, customized Links or a
favorite theme, sidebars they interact with, etc. In this case, AmphetaDesk
works with the user's environment, instead of forcing a new interface. The
only other reader I know of that does this is Radio
Userland.

Figure 1
This is the AmphetaDesk browser interface.
Other benefits include easier visual customization for the user. If the end
user hates my color scheme, they can change it. If they find my ordering of
links annoying, they can change it. The templates behind AmphetaDesk are
rather powerful - the user can do anything they wish (and much more if they
know Perl, more on this below).
The downside of a
browsing interface is that there's only so much you can do that will be
usable in every browser available. The current templates have been tested in
about fifteen browsers on multiple OS's. As such, they don't take advantage
of new technology as much as they can - we're working to rectify that,
making it a user choice based on their current browsing environment.
l.m.orchard from decafbad.com has made some wonderful progress in the realm
of outlines, and there's a good chance his work will be shipped with the
next version. See: http://www.decafbad.com/news_archives/000187.phtml#000187
Is my interface
better? Is my software easier to use? I don't really know - the only reason
AmphetaDesk exists is because there were annoying little negatives in Radio
Userland's aggregator. I've corrected all those negatives in my software,
added a few positives of my own, and hopefully done a decent enough job. I'm
always looking for ways to improve things, and there are still a few things
stuck in my head to fix. It's a continual process.
AmphetaDesk is perhaps the only application that I have seen that runs on
my desktop but is written in Perl. What is the story? Why did you use Perl
to write AmphetaDesk?
Perl has always
been a favorite language of mine - it was easy to pick up, and it took over
my mind rather quickly. It was also one of the only languages I was
proficient in that was available on every OS I used (without heavy script
modification) and also had hinted (but rarely used) support for binary
runtimes (i.e. installations that didn't require Perl) either internally or
with third party utilities.
So, before I coded
anything, I did a couple of test runtimes with simple scripts, and had
decent success - I was flying blind since there wasn't a lot of information
available on doing so (there are rather close-knit communities for
OS-specific Perl coding, but most of it revolved around glue scripts, not
full fledged shippable applications).
From then on, it
became a question of "because I could" and "no one had done
it before". I know of only a few programs that are compiled into
binaries for Windows, and only one program that does the same for Macintosh
(I believe it's txt2pdf,
but I may be wrong).
With the release
of AmphetaDesk v0.93, the design of the code is even more powerful than
before, so much so that I'm shopping around to do an article concerning the
implementation. With v0.93, instead of all the source code being bundled
into the .exe, the .exe has been redesigned to run pure text source code in
a lib/ directory, also shipped with AmphetaDesk. This allows source code
modifications to AmphetaDesk without actually needed a full development
environment, since the .exe will just run the new changes on the next run.
For end-users of AmphetaDesk, this is a good thing - instead of waiting for
me to release a brand new version for your minor feature request, I can
instruct them how to change the code themselves.
What is a skin? Why can people skin AmphetaDesk? What value does it
offer?
A skin is a
generic name for "the visual look of AmphetaDesk". In previous
versions of AmphetaDesk, there wasn't a massive amount of value in the
skinning system, besides the ability to stick your logo on a page, tweak
your colors, or what have you. There weren't a lot of people customizing the
skins, and thus, I had no qualms with implementing a much stronger
templating system in v0.93 (if you *have* created a template in v0.92, send
it to me, and I'll convert it to v0.93 for you).
The templating
system is now entirely in Perl, which allows much stronger customization.
User's could display weather in their AmphetaDesk (I'll be releasing
documentation on how, shortly) as well as tweak what sort of data is
presented (customization of the templates allow people to sort their feeds
different, show only ten items from a feed, show only the first 100 words,
or what have you). Basically, anything possible in Perl can also be possible
in the template - I know a number of people who are implementing Google
boxes, translation services and more.
The nice thing is
that all these customizations can be released to the community easily enough
- it's just a simple matter of writing up a quick HOWTO and mentioning it on
your site, with perhaps a screenshot or two. I've plans on releasing a
number of HOWTO's to do little tweaks that will eventually be incorporated
into the next version, and the amphetadesk-discuss
mailing list is the best way to keep up to date on those (and/or discuss
your own tweaks).
What is the future of AmphetaDesk? What do you have planned? What motivates
you to improve your software?
There are so many
things that AmphetaDesk can improve upon that the future is a massive TODO
of hems and haws. AmphetaDesk needs to remember what items it has seen,
allowing the user to hide old data they no longer care about. AmphetaDesk
needs to have stronger support for some of the oft-unused features of RSS
(like <enclosures> from RSS v0.9x and third party modules from RSS
v1.0). AmphetaDesk should have a stronger plugin system, as well as how it
interacts with the templates - it's kinda a hodgepodge right now. I'd love
to see AmphetaDesk support stuff like webcams and comic strips, but that's
very far away - there's much more to do to make RSS viewing better.
The amount of work
still left to do doesn't surprise me in the least - relatively, RSS is an
emerging technology that's just beginning to catch on. It's been around for
a decent amount of time, but using RSS and manipulating the data in various
ways is still in its infancy. RSS needs to become a lot more personal - the
user needs to say "hey, I like cats" and the reader needs to say
"well, hey, I know you're not reading this feed right now, but they've
been talking about cats lately".
Motivation comes
from within - I'm a news junkie and I love knowing everything I can about
anything. Jack of all trades, master of none, and all that hoohaw. I created
AmphetaDesk to save time from visiting hundreds of sites a day. Instead, I
find that the time I saved is now filled reading even more sites than I had
before. There needs to be another evolution - AmphetaDesk needs to start
showing me news I'm more interested in, while pushing the garbage toward the
bottom. It really needs to become my Personal Shopper and Librarian.
XML and RSS
What is RSS? How is XML related to RSS?
RSS, which has no
true abbreviated meaning, is an XML format that anyone can use to syndicate
their news or content. As opposed to HTML, where site owners
have to worry about visual appeal and browser inconsistencies, RSS files
contain only the "good stuff" - the headlines, blurbs, and links
that mean the most to the reader. This allows the end-user to determine how
they want to view the content.
What are the main differences between the variants of RSS files (e.g.,
0.91 versus 1.0)? Does this matter to programmers? Does it matter to users?
A veritable jar of
worms, this question is, and you'll get different answers from different
people. There's a great deal of confusion concerning the v0.9x versions, and
the 1.0 version. In a nutshell, the 0.9x branch is still being actively
developed (with inherent backwards compatibility), whereas RSS 1.0 is being
expanded through the use of third party modules.
The main goal of
RSS 1.0 was to solve a "problem" with the simplicity of RSS 0.9x -
whenever someone wanted a new feature, they had to request it, fight for
it's inclusion, and then wait for a new 0.9x version to be released. To
alleviate the process, XML namespaces were added to RSS 1.0, which solved
the problem quite nicely - any user could create a new namespace and extend
RSS 1.0 the way they needed. RSS 1.0 was all about extending without
restriction, and there are nearly 20 modules now available (which few
readers support).
The downside of
namespaces is they add complexity to RSS 1.0, making the barrier of learning
a bit more difficult. This is the prime reason why RSS v0.9x still exists -
it's a much simpler format that is easy to get started with.
For developers,
this creates a wonderful perplexity. Developers can support RSS 1.0 and know
that the format won't change - the primary means of development are in
extended modules (which typically fill a small niche and are not widely
used). Supporting 1.0, however, may be more difficult than supporting the
easier v0.9x versions. The downside of supporting v0.9x is that you can't be
sure a new version won't come out while you sleep the weekend away.
From a user
standpoint, it doesn't much matter - most popular readers (AmphetaDesk
included) support both RSS 1.0 and RSS v0.9x. If the user is new to XML and
the whole idea of RSS and syndication, then they may want to put the effort
toward a v0.9x feed, as there'll be less frustration. If the user ever has
plans of expanding their RSS feed (be it to include more information not
defined within RSS v0.9x, or just to value-add), then they're going to want
to start with 1.0, as easy expandability was it's intent.
What are the best ways to find new RSS files? What makes one newsfeed better
than another?
At this point,
there's a clearing house of news feeds over at Syndic8.com,
and it's this same list (actually, a subset of feeds that have been
updated in the last 30 days) that's used within the "Add A
Channel" pages of AmphetaDesk. The best way, however, is to go to sites
you know you like, and find out what they're reading - many sites are
showing their reading list in sidebars, and there's a good chance that
you'll be able to score some decent related RSS feeds that way. This all
should be automatic, however, and that's why there's a definite need for an
RSS "Personal Shopper", one that suggests feeds that match your
interests.
I've tried, in a
minimal form, to allow reading lists to be easily imported into a user's
AmphetaDesk. The new AmphetaDesk allows mass imports based on single URLs or
a user's OPML file (which contains a list of their subscribed RSS feeds in
either AmphetaDesk or Radio Userland). This allows people to say "hey,
click here to import my reading list into your AmphetaDesk", creating a
sort of recommendation system based on trusted individuals. There's been a
decent amount of work done on this at Syndic8.com as well.
How can a person with a web site create an RSS feed? How can people validate
their XML files? How can their RSS files get picked up?
Most of the time,
to generate an RSS feed, you need to install some software on your server,
be it a CGI script or PHP, ASP, Visual Basic, etc. Whatever your backend,
there's a good chance that there's an RSS creator for you somewhere, and
most of the time, content management systems (like Blogger, Movable Type,
postNuke, etc.) have RSS support built in. Installing software, however, may
be too much for the new user, so there are also ways to customize your HTML
for easier rendering as an RSS feed. See:
http://www.voidstar.com/rssify.php
http://logicerror.com/blogifyYourPage
As for validators,
look toward Userland for v0.9x and ldodds.com for 1.0:
http://aggregator.userland.com/validator
http://www.ldodds.com/rss_validator/1.0/validator.html
When promoting
your RSS file, you almost always want to do two things: one, suggest it to
Syndic8.com, which is a clearing house of feeds. Two, throw an orange XML
icon on your site point to your spankin' new RSS feed. For instructions, see
http://www.disobey.com/amphetadesk/website_integration.htm
(optionally, this page also instructs you how to add one-click subscription
buttons for users of AmphetaDesk).
--
Morbus Iff ( united we're bland )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Tech: http://www.oreillynet.com/pub/au/779
- articles and weblog
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Editor's
Comments
Thanks for the
excellent information about XML and RSS, and thanks for telling us about
AmphetaDesk. You give developers a good name because you write good code and
you obviously care about your users.
-- John S.
Rhodes
What next?
|