Monday, April 15, 2002

What is an API? You wouldn't expect an email address like webmaster@company.com to be an API, would you?  Actually I do.  Just as sales@company.com and info@company.com and support@company.com are APIs.  Sure, just as with any API, you can choose to ignore them.  And, when you ignore standards, this is what you get. Here's what happened.  I was on the evolt mailing list and someone suggested this hosting company.  I was in the market for one so I went to the site.  First link on the products page -- broken link.  Sigh.  Email webmaster@company.com.  Guess what?  They don't even have an alias for this!  Guess what?  As a potential customer I just went _POOF!_  I'll never look at them again.  That's what happens when you ignore APIs and standards -- when they are important to potential customers, they may just leave and may not ever tell you about it. -----Original Message----- From: MAILER-DAEMON@mail.pwebtech.com [mailto:MAILER-DAEMON@mail.pwebtech.com] Sent: Monday, April 15, 2002 9:05 AM To: scott@fuzzygroup.com Subject: failure notice   Hi. This is the qmail-send program at mail.pwebtech.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <webmaster@pwebtech.com>;: Sorry, no mailbox here by that name. vpopmail (#5.1.1) --- Below this line is a copy of the message. Return-Path: <scott@fuzzygroup.com>; Received: (qmail 30722 invoked from network); 15 Apr 2002 16:05:28 -0000 Received: from unknown (HELO mx-out.daemonmail.net) (216.104.160.37) by rt1.pwebtech.com with SMTP; 15 Apr 2002 16:05:28 -0000 Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3/8.9.3) with SMTP id JAA00664 for <webmaster@pwebtech.com>;; Mon, 15 Apr 2002 09:05:02 -0700 (PDT) (envelope-from scott@fuzzygroup.com) Received: from sjohnsondev (sjohnsondev [24.128.62.203]) by mail.fuzzygroup.com with SMTP id dA00HT10 Mon, 15 Apr 2002 09:05:02 -0700 (PDT) Reply-To: <scott@fuzzygroup.com>; From: "J. Scott Johnson" <scott@fuzzygroup.com>; To: <webmaster@pwebtech.com>; Subject: Broken Link on Your Site Date: Mon, 15 Apr 2002 12:04:28 -0400 Message-ID: <00f501c1e497$39293100$6401a8c0@internal.fuzzygroup.com>; MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F6_01C1E475.B2179100" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_00F6_01C1E475.B2179100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, You were just recommended to me. When I went to check out you out, on page: http://www.pwebtech.com/dedicatedservers.html The More Info link is broken. Scott J. Scott Johnson Physical * * * * * * * * * * * * * * * * * * * * * * * * * * 80 Spring Road Nahant, MA 01908 Phone: * * * * * * * * * * * * * * * * * * * * * * * * * * 781 592 0262 - home 617 970 4719 - cell Virtual: * * * * * * * * * * * * * * * * * * * * * * * * * * sjohnson@fuzzygroup.com http://www.fuzzygroup.com/ Yahoo IM: fuzzygroup       comment [] 7:35:57 PM     Too Funny! I mistyped www.radishack.com this morning (I wanted www.radioshack.com).  Worth checking out. comment [] 1:49:40 PM     Radio Exposed It still isn't finished but yesterday's Radio hiccup or "Radio ate my weblog.  Tasty.  Burp" has resulted in a decent technical guide to hacking radio, "Radio Exposed". It is draft status with 2 incomplete sections but I think it is still useful (I'd do it now except I have to write a proposal for a new potential client in Luxembourg).  Isn't the Internet astonishing? comment [] 10:10:42 AM     Thinking About Knowledge Capture in Knowledge Management See KM credentials below under "Note".  Knowledge Management is, at its heart, about capturing knowledge.  Just like back into bad old days of AI where the issue was capturing expertise, its now all about capturing knowledge.  It seems to me that there are different "kinds" of knowledge to capture. Procedural Knowledge -- i.e. Documents Ad Hoc Descriptive Knowledge -- i.e. this is what my team did today Knowledge Bits -- "I'd buy your product if you add Better Reporting" That last one, Knowledge Bits or "KBits", is a real challenge.  As I write a new software product for "making email suck less", I'm increasingly concerned about these little random bits of knowledge that arrive via conversation, IM, email.  Anyone else out there ever solved this?  It seems to me that if you can't capture this as part of your existing daily workflow (or with some teeny, tiny bit of additional effort), it just fails.  When I built KM software a few years ago, our software was way too top heavy and that was a big issue. Despite the power of weblogs, I don't think that they solve the KBits problem since the big issue is incorporating KBits into planning efforts, scheduling and so on.  Also, KBits need multiple views, prioritization, grouping and, perhaps, ranking and voting. NOTE: I spent 3 1/2 years building enterprise KM software, http://www.fuzzygroup.com/dataware/, including designing the first dynamic expertise calculation engine based on contributions to a knowledge base (i.e. Give me an expert in LDAP from our 20,000 employees). comment [] 10:06:23 AM

© Copyright 2002 The FuzzyStuff. Last update: 4/15/2002; 10:06:24 AM.