Recently in Collaboration Category

For many years, Adobe Contribute has been able to connect to commercially available popular blogging platforms such as Blogger or TypePad. I use Movable Type on my own server, and have wanted to get this going for some time.

There are a couple of configuration settings that make this all pretty easy, although the answers as to how to set them is not in one place. This entry serves as the one place.

First of all, you need to have Contribute CS4 installed, and your Movable Type blog needs to be up and running. You will need administrative access to the blog and to the paths where the cgi lives. With these in hand, we need to gather some information before making the connection.

Open your Movable Type administration panel and click on your name in the upper right hand corner. This will open your profile.

Having opened your profile, scroll down to the Preferences and click the reveal button to the right of the web services password. Write this down or copy it to your clipboard, as you will need it to connect to your blog.

Now, it's time to fire up Contribute. From Contribute, choose Contribute>My Connections... and select Create. Next, choose Blogs as the type of connection, and enter the URL for your blog.

You can also browse to your blog, which will open a little web browser for you. Browse to the top level of your site, and then click OK.

Click Continue to enter the connection settings, and this is where that password will come in handy. On this screen, you need to enter your userid, the web services password (not your regular login password), and the access point path.

The access point path is the path to where the Movable Type cgi files live. In my installation, I simply installed the entire MT folder in a folder on my web site, and created a second folder for the posted blog entries. This is pretty common, as most of us don't have access to the system-wide cgi folder. The item that's important is the file called mt-xmlrpc.cgi, which is the bit of glue that binds Movable Type and Contribute together. Having entered these three items, you are done. Click Finish to create the connection.

Having made the connection, you are ready to add or edit entries. There are some preferences you might want to set before you do, however.

Choose Contribute>Preferences and then select the Blog Defaults panel. You can choose to automatically allow comments and trackbacks here, and to create a new entry when you click the "New" button.

Under the Tagging panel, you may want to put the tags at the bottom of your entries so as not to clutter up the top. Contribute will automatically push your tags to the repositories you specify in the panel. Having made these changes, click OK.

Now, you're ready to blog with Contribute!

To create a new entry, click New Entry, or choose an existing entry from the menu at the right of the screen. This isn't about how to use Contribute to edit blog entries, so I'll leave that to you and your favorite training source.

I will say, though, that I enjoy seeing the blog entry rendered with the CSS and template of the blog. I also like the asset manager in Contribute, which consists of adding a picture to your blog entry, and Contribute will manage the rest. You can also use that built-in browser to browse to pages when adding links to your blog. That's handy when you can't remember the precise url, but you know the site that you want to reference.

If you need to set the entry aside, click Save for Later and then it will be available for you later to pick up where you left off. When you're ready to publish the entry, click Publish, and Contribute does all of the publishing for you.

Enjoy!

,,

I spent some time with DimDim the other day. It's a low cost online collaboration platform based on Flash. It hopes to compete with Adobe Acrobat Connect Pro or Webex, but in my opinion, it's not ready for prime time. They have a good start, though, and I can see lots of possibilities for the platform. Education users have glommed on to it for its price point, which is low. As to whether it will ever be taken seriously by enterprise users remains to be seen.
Last week while working with a customer while riding the Amtrak Downeaster between Boston and Portland, Maine, I created a Version Cue CS4-based PDF review. This process has always worked great in CS3 and Acrobat 8, and this was my first attempt with Acrobat 9 and Version Cue CS4. Platform disclaimer: ALL MAC Leopard, CS4 & Acrobat 9. All up to date as is the OS. Network is DHCP on the train.

The review creation process went without a hitch, and I was able to log into the VersionCue server, open the PDF in the browser, add comments to the PDF, and exit the browser. I then opened the PDF again in the browser, logged in as another user, applied some more comments, and exited the browser. When I tried to open the PDF from the VersionCue management console (open PDF in Acrobat is the button), however, the PDF opened in the browser and I saw no comments. 

Intrigued, I tried to see whether the review had been added to my Tracker, and when I opened the Tracker, I was presented with a dialog asking if it was OK for Acrobat to use the keychain item related to the VC server. I agreed, and that's the last I saw of the Tracker. 

Now, the Tracker won't start up. Occasionally I got these keychain messages from Acrobat, so I assume that the Tracker was still trying to connect to the VC server, but I can't see the Tracker. Well, having uninstalled and reinstalled Acrobat in hopes that the Tracker might reset itself, and after discovering that Acrobat conveniently remembers all of the reviews with which it is associated even after a reinstall, I dug around and found the following file on my Mac:

 ~user/Library/ApplicationSupport/Adobe/Acrobat/9.0_x86/Collab/Workflows 

I found the browser-based review that was causing the problems and changed the server ip address to localhost, where the VersionCue server resides regardless of its DHCP situation. Restarting Acrobat, though, and Tracker would still not appear.

I had resolved to confuse the hell out of Adobe tech support, when another idea occurred: join another shared review (not browser-based review like VersionCue). So, I joined another shared review, and Acrobat opened and voila! the Tracker reappeared, but then died after I tried to delete the dead review from the list. Thinking more about this, I restarted Acrobat and disabled "Show Notification inside Acrobat" in Preferences>Tracker, and opened the Tracker. Now, the Tracker did not try to connect to the bad server, and I was able to try deleting the bad browser-based reviews. Selecting one of the bad browser-based reviews, I clicked the trash can and got this handy message:
DeleteAcrobatSharedReviewBadServer.png
Without any guidance from the interface, I decided to go for broke and chose "OK." It was the right choice. The bad Browser-based review is gone, and my Tracker is back. 

Lessons learned: don't try to start a browser-based review on a train.
I went to Cloud Camp Boston recently and led a session on Collaboration, after I sat in on a session about security. Both of these are closely related, as any collaborative effort must also have an assurance that the participants in the collaboration are the only ones able to access the files or data that are part of the project. In a cloud situation, the files and data are often distributed over many different servers within the cloud. Concern was raised about shared resource situations, where multiple customers share resources on a single server in the cloud. The question: How do we prevent a malicious user from modifying or deleting content OUTSIDE of his realm? That is to say, a sideways attack. 

We all agreed that normal security best practices combined with a well-structured database with proper protections in place would be acceptable in most situations, since it is going to result in same or better protections that what we enjoy in client-server situations today. We can add pre-and post-transaction encryption to the mix to protect the data in transit, which is also pretty much standard these days with SSL as a minimum level. We could add to that hardware level encryption with dedicated appliances at each end of the line that encode, split, reassemble and decode the traffic, transparently to the user, but the cloud once again becomes the issue. 

In a client-server situation, there is one end-point (your data center) and multiple inputs (your clients). In a cloud situation, we add multiple end-points (the cloud). So long as the hardware encryption technology is present on all of the systems in the cloud (t which your project is assigned, of course), then there should be no problem.

On to the collaboration question. Collaboration has two meanings in the cloud; traditional person-to-person collaboration on projects,and also collaboration between apps/services in the cloud. Take Facebook as an example. Facebook opens its API to allow developers access your private data in order to enhance your Facebook experience. Facebook trades data with other applications by means of pre-arranged and well known data structures. Each application uses these data to produce is own content that gets displayed by Facebook. At the same time, the results are often shared with the user and the user's friends. Here, we have both schemes in place.

Our comfort level with our data must be driven by our trust that the applications in the cloud have been well designed and that vulnerabilities, when exposed, are addressed immediately. Unfortunately, since many cloud applications tend toward aggregation of services rather than having their own services, that trust must extend beyond to include secondary and tertiary applications, over which you have no control and with which you have no service agreement or contract. You may use an application with an email and calendaring function, for instance, but that functionality may be repackaged gmail and google calendars.

The watchwords, therefore, are "Constant Vigilance." Must like Mad-Eye Moody, we need to be aware of all of the players in our cloud applications, whether obvious to us or not. Talking to your service provider and setting clear expectations with respect to data interchange and secure transactions is also important, as your traditional agreements may not cover secondary and tertiary applications. Be sure to do your due diligence on those secondary and tertiary players as well. Despite Facebook's best efforts, an app may not have their same standards of data and privacy protection.

About this Archive

This page is a archive of recent entries in the Collaboration category.

Cloud Computing is the previous category.

Eureka! is the next category.

Find recent content on the main index or look in the archives to find all content.