The Power of APIs

So we just wrote a program here that really shows off the bang for the buck you get when applications provide you with an API. Microsoft Outlook, like other Office apps, has a great deal of its functionality exposed using Microsoft's ActiveX technology. And our Members Only app has a SOAP interface. So how hard can it be to write a pipe that connects the two? Well, it turned out not to be hard at all for our colleague Minghua Feng, who used Microsoft's published interface to write an Outlook plug-in to turn Members Only into an address book available from within Outlook. Our SOAP interface already provided services for retrieving a person by name, retrieving all people at a company, retrieving all people in one of your Workgroups, or retrieving all people with a specific tag, (actually Minghua set up most of those services too, I think, but that's besides the point...) so the plug-in can let you create an Outlook email to everyone on your Board, or your Staff, or your Legislative Alert List, straight from your main database, without any importing or exporting. And with the right security, you can pull this data from your server to wherever on the internet you are. One thing that excited me about this little app is that it is Internet technology without a browser. The idea of the Internet and the browser have been welded together in our minds, but really the Browser is just one way to display the content we pull across the network. Developers are just starting to realize that what used to be thought of as desktop apps can access data and content from anywhere on the net just as a browser can. One major vendor looking at this type of application is Adobe. They are starting to envision a browserless internet in a big way with their Apollo project. As CNET reports, "Adobe Systems is working on software meant to blur the line between the Web and desktop PCs." Another aspect of our little plug-in project we've been thinking about is how our API allows it to access the Members Only database without it's having any direct access to the database or knowledge of its structure. If another CRM product provided the same interface, the plug-in could use it instead of Members Only without any changes, regardless of how the data was structured or what SQL engine it used. A while back, Alan Benamer wrote a post calling for all CRM providers to make an API available, and I chimed in suggesting we form a workgroup to design a standard "lowest common denominator" API for non-profit CRM systems. Our little Outlook adventure makes it clear what a good idea that would be! Tags: nptech, API, SOA, SOAP

Hub-bub

Those of you who follow the current explosion of new web applications are probably well aware of Emily Chang's eHub site, which profiles new applications as she becomes aware of them. She also features interviews with the developers of projects that catch her interest. While many of these new apps are the inevitable "me too" calendar and wiki pages, a few of them, like GroupSharp, which hit her list just the other day, are beginning to demonstrate usable and flexible business functionality, the kind of thing a small non-profit might really gain from. This app wouldn't be a bit exciting if it were sitting on your desktop. But for a small organization that is currently storing most of its data in excel sheets, and thinks that having 12,000 database records is a lot, Groupsharp could be as great leap forward into the world of collaborative, use-anywhere web apps, for a mere $220 bucks a year. You should regularly monitor eHub if you want to see what the developers are up to out there. But while I've known about eHub for a long time, somehow I was oblivious to Max Kiesler's mHub site. Max is Emily's partner in Ideacodes, their web consultancy and design firm. mHub is eHub for developers - instead of serving up applications, Max leads us to sites that offer usable scripts, snippets, widgets, or techniques for our development efforts. In other words, its a candy store for programmers. A recent offering, for example, describes a method for building a tabbed notebook with CSS, and then using a simple Ajax-y technique to load each page of the notebook as it is opened with content laid out in another html file. He also points us to books, languages, and application frameworks - like this survey of five new "rails"-like application frameworks for php. You need to subscribe to the hubs! Tags: nptech, web2.0, programming

The Death of Wikipedia?

Last week Nicolas Carr, who Dion Hinchcliffe refers to as "that Web 2.0 curmudgeon extraordinaire," posted a piece gloating over what he claimed was the demise of Wikipedia; or at least of its vaunted commitment to open editing. In the wake of contraversies over false information found in its pages, Wikipedia has a asserted a modest level of page protection. This is what led Nick to write Wikipedia is dead. It died the way the pure products of idealism always do, slowly and quietly and largely in secret, through the corrosive process of compromise. It's just not true, and Nick does a real disservice to a remarkable project's efforts to sustain itself. The controls are truly minimal: you need to have your account for 4 days to edit a protected page. And if you have "vandalized" a page, you can be banned from editing. In a comment to Nick's post, I said that the protections seemed pretty sensible to me, and quite in keeping with a philosophy of openness. The only thing that worried me about these rules were the lack of transparency about the group that did the banning. Who are they? How do I know that won't declare me a vandal because of some social or political position I hold? Immediately I had an email in my box from Wikipedia founder Jimmy Wales pointing me to the policy on "blocking" - banning certain people from editing. The page goes into detail on reasons for a blocking, and on the makeup of board that can make a decision to block a user. Far from being a death knell, these changes sound, to crib from the title of Dion's posting, like social media "emerging from its adolescence". Tags: nptech, social_media, web2.0

Victory for Bloggers in California Court

It's good news for bloggers: On Friday a California Court of Appeals ruled the bloggers are entitled to the same protections as journalists in traditional media when it comes to being required to reveal confidential sources. The New York Times story (free registration required to view) quotes the decision as saying: We decline the implicit invitation to embroil ourselves in questions of what constitutes "legitimate journalism". The shield law is intended to protect the gathering and dissemination of news, and that is what petitioners did here. The case, Apple vs Does, involved bloggers who published articles containing confidential information about an unreleased product being developed by Apple Computer Inc. Apple went to court demanding the bloggers reveal their sources within the firm. Apple won, but Friday the appeals court overturned that decision. The bloggers were represented in their appeal by the Electronic Frontier Foundation. The EFF referred to the ruling as "a free speech victory for every citizen reporter who uses the Internet to distribute news." In addition to ruling that California's shield law as well as constitutional protections applied to the bloggers, the court also found it impermissible for Apple to subpoena the plaintiff's email from their email provider, finding that this violated federal law. Something else that can make us all breath easier. Tags: blogging, legal

Links Roundup: May 23

It's been a while since I've done a links roundup - so here are some postings and resources I've found interesting in the last while: 1. Haven't read this yet, but the last time the other Michael Stein recommended a book, I was glad I picked it up. The book is The Mercifully Brief, Real World Guide to Raising Thousands (If Not Tens of Thousands) of Dollars With Email and it was written by Madeline Stanionis. Michael's posting has links to a few excerpts. 2. Are you starting to fret about when and how your organization will upgrade to Windows Vista? Microsoft has finally posted their official hardware requirements for the upcoming OS. Along the same lines, they've made a "Beta 2" version of Office 2007 available to all comers, if you've got a spare PC to install it on. 3. Selfish Giving is a blog you might want to keep up with. It's a blog on cause marketing. I was really struck by this entry, which suggests that non-profits would get more from their corporate donors if they approached the relationship as more of a strategic partnership, focusing on what they can be providing to the donor as well as trying to upgrade their contribution level. 4. USA Today ran a piece on May 16th about the growing influence of blogs. Thanks to Steve Rubel for pointing this out. The article concludes that while blogs are read by only a small number of people compared to the traditional media, they have a disproportionate influence on public opinion and policy debate. 5. Kerri Karvetski pointed out this piece in the NonProfit Times about the role of Blogs and CRM tools in communicating with donors. The article by Michael Baler starts out: The constituent relationship management (CRM) paradigm has shifted. The public doesn'’t want to be “managed.” They want control of the dialog, to dictate terms, and choose methods of communication. This reminded me of very similar language I used in an entry last year about membership management and the importance of communicating outcomes to your chief supporters: Your members do not want to be managed. They want to know that your work is furthering shared goals. Tags: nptech

RFP

In my last post I shared a few ideas about software development contracts. Today I'm thinking about RFPs - Requests for Proposal. In the last month or so, we've been responding to a lot of RFPs because we've been receiving a lot of inquiries about our work. I'm certainly not going to complain about that. But I do have a few observations that can help your organization with its due dilligence the next time you go looking for software. Organizations who want to learn more about our software and services are our lifeblood. But we sometimes find ourselves grumbling at the way some of these RFPs ask us to respond. An RFP can cause us hours of extra work and nontheless prevent us from really telling an organization why we would be a good choice for them. How do RFPs do this? 1. Some RPPs make it VERY CLEAR that responding in our own format, rather than simply filling in the form provided, will disqualify us. What we'd rather do is include our boiler-plate chapters whenever possible, and in your grid just point you to the page that explains our methodology, or our tools, or how much liability we carry. This saves us time. Why should you care? Because if we are not wasting hours cutting our standard material into little bits and pasting it into your framework, we have more time to respond to the important issues your RFP raises that truly are unique and demand some original thought on our part. Give your potential vendors time to think about you and your mission and you'll get proposals that seem much more on the mark. 2. A particularly annoying style of RFP asks us to respond yes or no to whether our software supports each of literally hundreds of specified features. The real hallmark of this is the RFP that includes a matrix with numbered items such as 5.3.2.c The system will allow the entry of either a 5 or 9 digit US zipcode. What's wrong with this? Obviously there's no CRM you'd consider looking at that didn't support US zipcodes. Many of the requirements these heavily feature-based RFPs ask about are going to be supported by every contender. So these answers really don't help you distinguish between your prospects. They don't do you any good at all. What would serve you better? A focus on requirements that you suspect might not be available from all the contestants. Use a shorter grid with items that will really help you distinguish among your suitors. 3. Of course your RFP is built to reflect your requirements analysis. But that doesn't imply you should only ask questions about your identified needs. If you do this you are making it hard for any of the vendors to tell you what is unique and innovative about their approach. You ask them about your ideas, but not about their's. While you absolutely need to assess whether they meet your essential requirements, you also want to learn what is special about each of these vendors. They've worked with lots of non-profits. They each have a different take on the challenges you are presenting. You deserve to hear it. Additional Resources: If you are new to the RFP process, you might want to take a look at these RFP resources on the Techsoup site. Technorati Tags: nptech, RFP

Are those my shoes burning?

The other day there was an interesting little discussion on Deborah Finn's Information Systems Forum list about software development contracts. (You should get to know Deborah's projects if you don't already - check out her blog). [hmm... seems she's temporarily unavailable.] It's a subject that I find very interesting because over the years I've watched the contract we use grow from a one-page letter of intent to an eight page novella - and this is without ever mentioning any of the specifics about a project, which are relegated to the attachments. What feeds this growth of contractual yada-yada? It seems each time we do a project, the new client mumbles something half-apologetically about "Our board wants me to pass your contract by our lawyer". Now, the lawyer usually does not feel she will look like she's on her toes if she doesn't find at least one little issue to be concerned about. So a new point is proposed. We let our legal advisor glance at their proposed langauge. He says, "Sounds fine to me as long as you also add "blah-blah-blah" to give you the same protection. And voila - a clause is born. We've gotten pretty sanguine about the contract negotiations. They're just part of the process of building trust. It's like when your girlfriend's father said, "I want my daughter home no later than midnight." Once you announce your engagement, none of these early negotiations matter. The only part of the contract that really matters is how you agree you will handle things in the case the relationship really goes south. For example, you might want to put in a clause saying disputes will be settled by arbitration to reduce the risk of lawsuit. Fortunately, we've never had a dispute with anyone reach this point. And disputes of lesser intensity are going to be resolved by discussion and compromise, no matter what the contract says. All that being said, there is one thing that came up in the discussion on the list that I responded quite vehemently to. Helen Seal from Compumentor suggested: Other things to consider include: Penalties for not meeting deadlines (make sure you're up to meeting your deadlines too!). You could also have bonuses for coming in ahead of schedule and within budget.... I've had such bad experience with incentives like this I just had to reply. I've quit signing contracts with penalties for late delivery or rewards for early installation, and I'm convinced it's a mistake to ask your developer to do so. Every time we've accepted such terms, it's had a harmful effect on the quality of the software. Not surprisingly - it flies in the face of all the latest wisdom on software project management. The last time we did it, the guy who asked for the clause said "I want some way to hold your feet to the fire." I should have realized right then it would be an error - ever try to concentrate while your shoes were burning? We caused the client a great deal of grief by skimping on the testing and installing an application that was not really ready for prime time. But we wanted the bonus. Software takes time. Don't encourage your developer to rush. You and your developer will need to learn to manage requirement and schedule changes - they are bound to happen -- and a contract clause won't prevent them. Tags: nptech, contracts, software_development

Covert Operations

As technology assistance providers, my company is often called upon to solve our users' problems. And I think many of you who are readers of this blog are in the same situation. Whether you are a consultant working with your clients, a non-profit techy working with your fellow staff members, or an ISV working with users, folks come to you all day long with their problems. How do we solve these problems? We saw in March how a lot of writers have focused on the need to calm down, to slow down and clarify the issue, as a first step towards a solution. But this can be hard to do. Why? Because problems often have an overt and a covert side. The overt problem is the simple technical statement of the problem as it is brought to you. "I'm running out of disk space on my server. What can I delete?" But your user will very often have a covert problem as well. Maybe its something like "Our network is acting up again, and I'm on the line. I get blamed for all these network problems, but I am not authorized to delete anyone's Office files. But I've got to fix this before my boss gets on my case! Maybe there are database files I can kill." Another user might have a different covert problem in the same situation: "If I can't store my Word documents, I'll be late getting this report done for tonight's board meeting. How will I explain that?" The covert problem is generally some form of "Oh-oh, I'm in big trouble now!" It's a feeling we've known since we were kids. But when it is not acknowledged as a problem to solve, we get confused and think the overt problem is urgent. If we can help our users and clients get rid of the sense that they are personally in deep doo-doo, suddenly we have enough time to approach the overt problem systematically. It involves addressing this doo-doo factor directly, by offering to make sure that our user's personal worries get resolved first. "Here's a laptop to use while I resolve the network problems" or "Let me write a memo to your director explaining how I think this should be solved". Sometimes even a simple "Do you mind if I copy your boss on this response so he understands why this will take some time" will go a long way. Calming down our users so they give us the space to solve their problems is a lot easier once we recognize the full scope of their problem and help them solve it as it applies to them most personally. Tags: nptech, troubleshooting, support

RearView Fundraising

Every now and then you read something that strikes a chord... but you can't figure out exactly how to apply it. A posting by John Sviokla in his blog last month was like that for me. John's premise seems unassailable, whether you are discussing selling widgets to consumers, marketing your consulting services to non-profits, or fundraising for your 501c3: you need to keep your focus on the customers or donors with the greatest future value to your organization. But then he drops this bomb: Put another way, using CRM systems to drive your service system is like navigating by looking at the rear view mirror, while ignoring the scene outside the windshield. What does this mean? Well, one example from John: Verizon tracks the services he purchases from them... but they do not know how much telephone service he has with other vendors -- at his office for example. So they do not know what percentage of his total phone business they have already won. Translated into fundraising terms: most organizations use their CRM or Fundraising software to track a donor's past performance with their organization. But do they record what other organizations this donor funds, and at what levels? Without this information, the system can't help you assess this prospect's full potential. And of course, having a CRM that lets you track other organizational involvement for each donor is just the tip of the iceberg. Obtaining this information and keeping it up to date is the real challenge. But this is just an example. How do you assess the future potential of each donor when prospecting for major gifts? And how might CRM software be put to better use in helping you make this forward-looking assessment? Tags: nptech, CRM, fundraising

Software Bricklaying?

Every now and then you see an article about how - real soon now - the art of crafting software will be radically de-skilled. They've been appearing for ten years or more -- in the early days, it was going to be because of components. Now that object-oriented environments were enabling people to write little self-contained blocks of code that encapsulated an entire business function, developers would be able to buy some libraries and snap the components together like legos. Now its because of webservices and SOA (service-oriented architectures). Relatively unskilled developers will just mashup a bunch of enterprise services and -voila! - mission critical software applications. Earlier this year, Charlie Bess in the EDS "Next Big Thing" Blog made this prediction yet again. I've never understood this way of thinking. First of all: someone needs to write all these components and services others will use. And my experience dictates that enterprises -- both corporate and non-profit -- will still decide it is cost-effective to build custom services to do things their way, and competitive forces will drive development groups to build new and better services. Service building will be a growth field, both inside and outside the enterprise. It is already. But suppose the overwhelming majority of the building blocks are just there and are just waiting to be put together. Darryl Taft, writing in eweek, suggests that the future software developer will be rather like a bricklayer, just putting software bricks in place, one on top of the other, whistling as he works. As they say in the infomercials, "it's just that easy!" But I'll bet the future of enterprise development will be less like building a wall from a pile of bricks than like assembling a car from a catalog of autoparts, while worrying about safety at high speeds. The idea that the business objects -- the bricks, if you will -- and the end-user application -- the wall -- can be completely separated conceptually is just not true. Read this little piece Shawn McGrath wrote a couple years ago about this. In fact, Jeff Palermo thinks writing software has already gotten too easy. Tools today make custom software too easy to develop. This statement may seem controversial, but I believe it. I’ve seen too many unskilled people take a programming tool and throw together something that seems to work initially. The business folks can’t tell a fraud from an expert or evaluate the work, so they use it and then feel the pain later when they actually have to maintain it... Software is serious, from bank transactions to supply lines to taking orders on the web. I think anyone who has watched their staff work around an ungainly application, or struggled to get a customization really working exactly as it must, knows just what I mean. Tags: nptech, programming

How to embed a You Tube player in your blog post

Wow. Ever since I wrote a post about the You Tube site, I've been getting hit after hit from searches looking for some variant of "How do put a your-tube player on your blog?" So I figured I oughta answer the question. But first let me remind those of you who are new to web stuff - you can often learn how something was done by viewing the source of any web page. On FireFox, in the main menu, select View, and then Page Source. In IE - oh, figure it out, I'm not gonna open IE just to look... and remember, on a blog page you need to wade through all the sidebars and headers to see how something was done in a post. So you might want to search for a phrase in the post to get there quickly. You could search for Wow to find the player on this page, for example. If you look at any video on You Tube - like this one - you will see on the right hand side of the page, next to the player, a box captioned "About this Video". It looks like this: The second line in that box is an Edit labeled Embed. In it will be a string of text that is the complete HTML code you need to embed this video on your log or website. If you click in here the entire string will be selected. Then use Ctrl-C to copy this text onto the clipboard. Now you just need to paste this text into your blog post. Careful: Do not copy it into your wysiwyg editor, but into the HTML view of the post. On Blogger, for example, click Edit HTML and paste it in there! Sizing the player: if you want to make the player smaller, change the height and width of the object and embed tags. Careful: change them both by the same proportion or your viewer will look warped! And change both places where the height and width occur. Prettying it up. If you want the text to wrap to the right of the player, like on this post, put div tags around the entire block of code and set the style to float:left. You will also want to set a margin, so the text is not sitting right on the player. So the whole thing, might look like this: <div style="margin: 4px; float: left;"><object height="235" width="285"><param name="movie" value="http://www.youtube.com/v/LVCb52iQrfo"><embed src="http://www.youtube.com/v/LVCb52iQrfo" type="application/x-shockwave-flash" height="235" width="285"></embed></object></div> This is the code I used to put the player on this post, where you can see some unusual percussion playing. Tags: nptech, youtube, video

A few updates.

Here are a few updates to topics I've written about in the last while... 1. Legal matters. Just a few days ago I pointed you to the EFF Legal Guide for Bloggers. A day or two later, Steve Rubel mentioned a similar reference for podcasters. It's called Podcasting Legal Guide: Rules for the Revolution and you can find it at the Creative Commons wiki. 2. Video. I've also been on about participatory video on the net lately, in particular the much-in-the-news You Tube, as well as CurrentTV. In a comment on one of those posts Anne Walk refers us to this surprisingly long list of free video hosting services on the web. 3. Collaborative Spreadsheets. Not long ago I wrote about Dan Bricklin's wikiCalc project. Several correspondents have since pointed me to Irows, a different approach to spreadsheet sharing. You can embed a spreadsheet in your site with this tool. 4. Project Management. In my first post of the year, I shared my thoughts about using Scrum, a project management method intended for software development projects, to manage other types of IT efforts. Yesterday, Susan Richardson at Joining Dots talked about both Scrum and the more esoteric "Theory of Constraints" in IT project management. Tags: nptech, resources

Current TV

Quite a different take on participatory video than You Tube, CurrentTV is a cable and satellite TV network whose content is made up entirely of short pieces they call pods; each is around 5 minutes in length. About a third of CurrentTV's programming is produced and uploaded by users of the CurrentTV website. Everyone in the CurrentTV online community votes for what uploads should be "greenlighted" to appear on TV; there are online discussions of each piece. Participants don't just produce the content on CurrentTV - they produce the ads as well. And here there is money to be made: if your ad airs, you get a flat $1,000.00 And if the sponsor likes the ad enough to air it on other media, you might take home up to $50,000. As you might expect, this approach enhances the quality of the uploaded material. Contributors are aiming for a loftier goal than getting their work embedded in some blogger's post. But as you see, a video player for displaying a CurrentTV video on your blog or website is provided. So here, in honor of Cinco de Mayo, is a recent upload to CurrentTV about two schoolgirls' participation in the May 1st Immigrant's Rights activities in San Francisco. Tags: video, tv

Blogging and the Law

The Electronic Frontier Foundation has recently updated their legal guide for bloggers: you can find it on their website here . The guide addresses a broad range of legal pitfalls that a blogger might encounter. The news has been full of bloggers who suffered retribution from their employers - but the EFF points out that this is just one possible area of legal conflict. In general, bloggers might run afoul of claims in any of these areas: Defamation Intellectual Property (Copyright/Trademark) Trade Secret Right of Publicity Publication of Private Facts Intrusion into Seclusion For example, if you blog about technology and provide product reviews, tips, under-the-hood insights, or opinions on various trends or major vendors, you could be accused of almost any of these sins. The difference between you and the reporter at your local newspaper is that in many cases, you may not have the benefit of training or resources to help you determine whether what you're doing is legal. And on top of that, sometimes knowing the law doesn't help - in many cases it was written for traditional journalists, and the courts haven't yet decided how it applies to bloggers. This a link every blogger needs to have on his or her desktop. Tags: nptech, blogging, legal