Sometimes the best solutions are really the most simple.
A couple weeks ago, there was a great forum discussion on how to assign follow up tasks immediately after logging communications. This wasn’t just a back-and-forth, this was a full fledged discussion with forum users Bradley, Kenny, HansD, and Stewart taking part.
We have always had the ability to log a communication and to create a To-Do that was assigned to a user and linked back to a communication. But the forum users were looking for a way to “remind” the other users on their account to create a To-Do after logging a communication, if one was necessary. Many approaches were discussed, but the following messages made it clear what we needed to do:
From Bradley:
From a business-process stand point, logging a communication and generating the resulting task are a single action. Yes, you could log the communication, then open it, then start a to-do action. However, you’ve now undertaken three actions as opposed to one, any one of which a staff person could forget or be interrupted before completing.
And from Kenny:
For me, its the act of remotely communicating with another person that needs to be logged, and the next task programmed in simultaneously in such a way that it is not forgotten that is critical to a CRM.
So, in the confirmation box after saving the communication, we added a link to create a To-Do.
While he was in there, Sean made some great new additions as well. We used to store a link back to the communication in the details field of the To-Do. No more. Now it is directly linked to the communication, just as if you were linking it to a contact.
And Sean also added the ability for account admins to see the To-Do Lists of other users on the account.
What else was in last night’s update? Well, for one, I brought back microformats to BatchBook. Here, you can see the Firefox plug-in Operator detecting the hCard microformat on a Contact Detail.
If you’d like to read more about microformats (and see some incredibly old screen shots of BatchBook!), I wrote about them a while ago.
Oh, and there’s one more thing. We dressed up for Halloween!
We hope you like the latest updates. We’ve certainly got more coming at you!
Tweet This Post
Tags: communications management, Customer Service, forums, halloween, microformats, User Experience
As BatchBlue’s User Experience Designer, a big part of my job is to hide BatchBook’s technologies from users that don’t want to deal with them. My main goal is to make sure users can do what they need to do as efficiently and painlessly as possible.
For this reason, it takes a pretty compelling bit of technology for me to bring it into BatchBook and expose it to our users. Today, I wanted to share one of those technologies with you. Consider this a warning that this post can get a bit techy, but if you follow me you’ll see that it’s really not that bad and can actually be quite useful.
About Microformats
When I first heard of a technology called Microformats, my initial thought was “oh geez, now what?” This was at a time that I was already trying to learn about things like AJAX, Javascript libraries, and browser quirks in CSS development. Microformats sounded like just another thing to add to the list.
But microformats are different. They’re simple. And while the potential usefulness for them is just being uncovered, there is already an immediate benefit. One of the key microformats, hCard, is all about contact information. So, of course, that one is huge for BatchBook.
You may be familiar with vCard, the standard format that many address programs like Outlook and Address Book uses to import, store, and export contact information. hCard is an HTML version of vCard. Many sites offer links to vCards so users can download contact information and add it to Outlook or another address application. But offering a vCard in addition to your site’s content means you not only have to maintain your web site’s content but also the information stored in all those vCards. With hCard, you can have the same information available in both formats.
Microformats and BatchBook
It may be best to simply show you how this can directly help you when using BatchBook. One of the best tools for reaping the rewards of microformats is a Firefox extension called Operator, written by Michael Kaply of IBM.
Let’s pretend you’re scoping out a hot new small business. In their press section, you find contact information for their executives. Since you’d like to speak with this company, you start the tedious process of copying and pasting the information to your address book.
But there’s a better way.
This company marked up their contact information using the hCard format. If you’re using the Operator toolbar, this is what you’d see:
Operator is telling you that you can download the contact information for any or all of the executives with just one click. I think each one of them is super cool, so let’s grab all three.
Operator sent them right to my Address Book application. Of course, you can also add them to Outlook, Thunderbird, or any other application that supports the vCard format.
Let’s take the next step and import them into BatchBook:
Like magic, you just went from a plain old HTML page to BatchBook with a couple clicks. Here’s how the information looks in BatchBook.
And, of course, to keep the contact-sharing-goodness flowing full-circle, our Browse Contacts page is marked up in hCard. So, you can export yourself from BatchBook and send your sister your vCard so she never has to ask for your cell phone number or zip code again.
Though the example above shows only name, title, company, and email address, hCard can also be used for mailing and web addresses as well as phone, fax, and cell numbers.
Behind the Curtain
What kind of technology goes into making this possible? It is literally the difference between this:
<h2>Sean Ransom</h2>
and
<h2 class="fn">Sean Ransom</h2>
Simply adding class names around each type of data (zip-code, street-address, org, etc.) allows software (like Operator) to detect the information. The code is invisible to the user, but the benefits are not.
Our Own Use Case
Microformats came in ridiculously handy for BatchBlue recently. When we launched BatchBook at the DEMOfall07 conference, we provided a service for conference attendees that pre-populated their new BatchBook accounts with demonstrators from the past five DEMO conferences, their company’s executives, conference staff, and press. The DEMO site has a page for each presenter that contains all of this contact information.
It would have been a dream come true if these pages were marked up with hCard, but they weren’t. So, using another Firefox extension (called Greasemonkey) and Riley’s scripting skills, we were able to make our local versions of Firefox add microformats where needed on each page. We were then able to reap the rewards, exporting the information and uploading it into BatchBook. There’s nothing quite like NOT having to copy and paste hundreds of mailing addresses into the appropriate fields. We then offered the code changes to the DEMO team so everyone can benefit from this.
Beyond hCard
hCard isn’t the only microformat. There are others that are heavily used, such as hCalendar (the HTML version of the ICAL calendaring format). There are other “elemental” microformats that may not seem very powerful on their own, but when combined with other microformats and applications can do amazing things. Some of these, like XFN (eXtended Friend Network), play a big part in Brian Oberkirch’s writings about portable social networks.
But for small business owners, it is all about addressing pain points. Repetitive tasks such as copying and pasting contact information are obvious pain points that can be addressed with simple technologies such as microformats. Sometimes it seems as though you hear about new technology every day. Here’s one that can actually provide an immediate benefit.
Tweet This Post
Tags: batchbook, microformats, User Experience
With the launch of the Apple iPhone merely a few days away, Apple’s legion of loyal developers entered the week still anxiously awaiting word on how they are supposed to develop applications for the thing. The answer, most assumed, would come this week at the Worldwide Developer’s Conference (WWDC07) this week. The timing was frighteningly close to the iPhone’s launch, but better late than never.
Well, they got their answer. And many didn’t like it. As Michael Calore of Wired put it:
Suddenly, a sound that’s rarely ever heard in a Jobs keynote welled up in the giant conference hall. Crickets.
Apple’s self-proclaimed “sweet” solution is an interesting one. They essentially told the developers to “make web apps.” The iPhone runs a full version of Apple’s Safari web browser. (X)HTML, CSS, JavaScript, and Ajax are all fully supported, so essentially if a web app uses web standards, it will work on the iPhone.
For us, this is good news. BatchBook is a web app that is built with web standards. After a bit more massaging, it will run just fine in Safari. The fact that a user can run the very same version of our application whether on their desktop, notebook, or even their phone is just killer.
Developing for “the mobile web” up to this point has been an extremely frustrating exercise. Do you serve the same information to a mobile user? Do you use CSS to hide parts of the page the user doesn’t need? How do you balanace stripping out portions of the page against keeping one code base so that users don’t have to pay to download data they won’t even be viewing? How do you test for the hundreds of different mobile browsers? Do you just serve unstyled content for mobile users? What about these .mobi addresses? Is that forcing us to have a separate site for mobile users?
Sigh.
Then Apple comes along and (as usual) does something ridiculously simple that nobody had ever thought of doing. Just put the same browser on the phone. Then, users can just look at the same thing they look at on their computers. No different code bases. No features stripped out. No developers assuming they know what part of a web page mobile users want to see.
Nick Peters wrote a post a while back about how the iPhone can be a killer format for Microformats (standardized class names inserted into HTML to allow various functions to be performed on the data). It looks like instead the iPhone will have auto-detection of phone numbers (so you can call with one touch) and addresses (so you can map the location via Google Maps). Still, Microformats would add so much more since you would have more complex detection features such as events. With one touch, add it to your calendar, sync it back with your desktop. Perfect. For BatchBook, an application that relies heavily on contact information, the possibilities make me drool.
I see one disappointment in the “no SDK” annoucement, though. We’re investigating ways to deploy BatchBook as a desktop application as well, so users don’t need to be connected to the web to access their data. Having a native application on the iPhone would allow data to sync between the desktop app, the iPhone app, and the web app. So, when you need a customer’s number, you could just open your phone and get it.
The iPhone auto-detects a wifi signal, so if you are on your wireless network you can access your data right away. However, if you are not, you’ll need to go ahead and use your cellular data plan to get that number. This is more inconvenient than insurmountable, but it’s nice to have that freedom of building contact lists when you are on the subway, unable to get a signal.
I must say, I can’t wait to play with BatchBook on an iPhone. I’m also looking forward to seeing if Apple changes the third party development plans. While the announcement isn’t a big one from BatchBook’s perspective, a lot of other developers are bummed because they can’t do what they want via the web app route.
Tweet This Post
Tags: batchbook, iphone, microformats, mobile browser, mobile web, mobility
