Today we are launching a beautifully designed, dedicated marketing site for Onehub Transfers. The goal of the site is to better engage visitors with great copy, alluring design and a super simple sign up process.

The change won’t affect the way you use Transfers but having a dedicated site will make it easier to explain each product to new visitors. The Transfers product section on onehub.com will go away soon and will be replaced with new content for the upcoming launch of Workspaces 2.

Transfers Marketing Site

Our lead designer, Matthew Anderson, did an awesome job on the site so you should take a look and let us know what you think in the comments.

Share it:

Today we’ve added in the ability to delete individual versions of files. You can find this in the file details under the versions tab. Just click the red X icon next to the version you would like to remove to delete it. Please note that deleting a version will permanently remove it and it will not be added to the recycle bin.

Share it:

Sharing files online is great. As long as you don’t have to switch to your browser every 5 minutes to manually upload and download files when they change.

Onehub Sync is a new feature for Workspaces that keeps a local copy of all the files and folders stored in the online Workspace. The Onehub Sync client is a lightweight application than runs continually to watch for changes to online and local files. When changes are detected, the client automatically synchronizes the two.

Download Onehub Sync

Why should you try Onehub Sync?

It’s Easy. Onehub Sync only takes a few minutes to setup.
It’s Automatic. Once installed, you work on files in your special Onehub folder and everything is automatically synchronized in the background.
It’s Free. Onehub Sync is free with any paid plan. For free users, you can try Sync free for 30 days.

Benefits of Onehub Sync

Increase Productivity

By seamlessly connecting your computer to the robust collaboration tools offered in Onehub Workspaces you can more productively and efficiently work with people inside and outside your firewall.

Effortless Collaboration

When other members of your workspace use Onehub sync, you’ll automatically receive their changes as well. Everyone in the workspace always has the most up-to-date versions of files.

Work Offline

Access and work on your files even when you’re offline. Any changes you make will be tracked and synced with your workspaces the next time you are online.

Learn more about Onehub Sync.

Share it:

Birch Leaf Global Logo

Once again it is time to visit another conversation with a customer at Onehub. This week I spent some time speaking with Bruce Ricciuti, managing member of Birch Leaf Global. Bruce gave us some insight as to why the customization and flexibility of Onehub created the right file sharing solution for their company. By using Onehub Birch Leaf Global is able to better provide their investors with information in a quick, secure, and professional manner.

Stephanie Chinn (Onehub): Please start by sharing with us a little bit about your company and what exactly it is you do there.

Bruce Ricciuti

Bruce Ricciuti (Birch Leaf Global): Birch Leaf Global is a real estate investment company that funds commercial, university, hospital, and institutional projects across the US by finding foreign capital sources. Our company promotes projects with developers by marketing the projects to investors in China, Latin America, India, Brazil, and other foreign countries.  My position at Birch Leaf Global is managing member.

Stephanie Chinn (Onehub): How did your company hear about Onehub?

Bruce Ricciuti (Birch Leaf Global): Previous to Onehub we were using a competitive product, which we were constantly having problems with. Eventually we decided that we needed to look into another file sharing product. I spent some time researching other solutions and software platforms in the file sharing market and I quickly came to the conclusion that the customization offered by Onehub made it the best option for our company.

Stephanie Chinn (Onehub): What were some of the problems that you ran into when you were using the other product?

Bruce Ricciuti (Birch Leaf Global): Well with the other product we ran into quite a few problems that sadly, we felt the company was unwilling to address. Our biggest issue was with the product’s notification system. When sending messages to our investors we often send the same message, but we don’t necessarily want those investors to have access to one another. With this particular product we were having problems with sending messages that only allowed the recipient to reply directly to us, and not to everyone who was receiving the email. Having a “reply to all” function that was unable to be turned off caused a couple embarrassing incidents for our company. Ultimately we were looking for a way to create a virtual data room where we could customize whom we sent our information to, the amount of access those individuals had to one another, and also customize the manner in which we received information back from those individuals. Another issue that we were facing with the previous product was that our investors were having difficulties with the basic usability of the product. We were constantly receiving phone calls about log in issues and questions regarding account set up. However since switching to Onehub we have eliminated all of those types of issues.

Stephanie Chinn (Onehub): And how would you say that your company is using Onehub today?

Bruce Ricciuti (Birch Leaf Global): Well as with any real estate project there is an extreme amount of data and property information being exchanged and reviewed. This is especially so when you have investors that are looking to invest five hundred thousand to one million dollars into a project, which is true for most of the investors that we are working with. Overall we use Onehub to automate the flow of information we send to our investors. Once we qualify an investor, we will send them an invitation to the hub that we have set up for that specific project. Onehub makes it simple for us to give our investors quick and easy access to videos, pictures, site plans, building plans, and legal documents pertaining to the project they are reviewing and considering. In this way, Onehub allows for a type of due diligence that is secure, but that we can also customize to whom we send the information. The best part is the amount of time we save by just having to upload the information once. After the information has been uploaded all we have to do is simply click a button and we can send that information to any interested investor.

Stephanie Chinn (Onehub): What are some of the major benefits you have found since switching to Onehub?

Bruce Ricciuti (Birch Leaf Global): One of the main benefits has been how easily our investors have adapted to using the product. We are constantly working with individuals from all over the world. In working with different countries the language barrier is of course always going to be a concern, however with Onehub we have yet to run into any problems with clients successfully logging in and accessing the information they wish to review. The way Onehub is set up allows for individuals to catch on quickly and understand how to navigate without any type of tutorial or explanation. Even the novice computer user can just go log in and immediately feel like they know their way around the product. Another thing that we appreciated about Onehub is that you make it so easy-to-use, while maintaining a very professional look and feel to the site at the same time. The professionalism allows us to share the hub directly with our investors without having to do any type of design work on our part. Overall using Onehub was not only a cost effective choice, but it also instantly increased our productivity.

Stephanie Chinn (Onehub): What do your colleagues, and investors say about Onehub?

Bruce Ricciuti (Birch Leaf Global): We have received nothing but positive feedback. The best thing that we have found since switching to Onehub is that we have received absolutely no phone calls regarding questions about the service. Again we understand that when working with investors from all over the world language barriers can be a problem, but with Onehub our overseas investors have been able to easily and quickly access all information. As a company we have no complaints, it is probably one of the best external products that we work with here, the one we are most happy with.

Share it:

The Art of Drag & Drop Uploading – Part 1

Last week, we launched our new HTML5 drag & drop uploader. This week and next, Leigh and I are writing about how we did it. A few days ago, Leigh broke the ice with a post on building our drag and drop uploader. In this post, I’m going to discuss the creative process behind the user experience.

Approaching shiny, new features

When designing new features (especially those involving new technology), I design them for the person who has never used the service before. I do this for two reasons. First, it frees me from any expectations I might be aware of from existing customers. This allows me to focus on how the feature should be, rather than how it could be. Second, when I design for new users first, I’m less likely to forget about them during my creative process. Once I’ve isolated what I think is the best idea for new users, I go back and connect the dots for existing customers.

I imagined a new drag & drop files widget and tackled the most obvious and important question that came to mind.

Where do I drop my files?

The drop target not only dictates how someone initiates a drag & drop upload, it also influences the rest of the user experience. I sketched several ideas and ended up with four options for consideration.

  • Drop the files on to the menu bar
  • Drop the files on to a new, unique location
  • Drop files anywhere on the file list and/or in to a folder
  • Drop files anywhere on the file list

Option B. The first to go. The most intuitive place to create a unique target for adding files would be below the other files (in a footer); however, that would require a ton of scrolling if you had lots of files. Moving the target further up solved the scrolling issue, but was less intuitive and wasted screen real estate when not in use.

Option A. Next off the list. It made contextual sense because it was close to the current Upload button, but that was about it. I anticipated dragging files from the bottom and side of the browser window. Hitting the target on this option could require a lot of mouse movement. Additionally, the drop target felt fairly small.

Option C. The early favorite. A few team members really liked the idea that you could drop a file directly in to a subfolder. This approach was more complicated though because it actually consisted of multiple drop targets. After sitting with this option for a bit, dragging in to a subfolder didn’t seem to be very useful either. Anything more than a single nested folder still required traditional navigation. The real killer for me though was that the targets were even smaller than in Option A. It would be easy to accidentally drop files in to a subfolder and/or into the wrong folder. The cool factor wasn’t worth the increased risk of error.

Option D. The winner. It was intuitive and very accident-proof. It also had the largest drop target which I felt would be the most engaging and easiest to use. Other than not being able to drop files in to folders, we couldn’t find anything that we didn’t like about this approach at first glance. It was time to prototype.

Early prototype gets the bugs

At Onehub, we prototype as early as possible. Playing around with prototypes, no matter how basic, gets you thinking like an actual user. Also, this is typically where the largest number of changes occur in my designs. The earlier I reach the prototype phase, the quicker I become confident in the feature.

While using the prototype, I noticed that we weren’t conveying one very important detail about the uploader – you shouldn’t touch the files widget during an upload. With Option D, the menu bar and sort headers were still available during an upload. The widget did not appear to be fully ‘locked’. You could easily click any button in the menu, including the ‘Upload’ button. Ironic.

The solution was easy – expand the drop target to surround the entire files widget. The entire widget became one huge drop target and the experience of dropping files felt right.

Keeping feedback simple, Stupid

I felt strongly that the most important thing to get right was going to be feedback. One thing I learned from our original uploader was that the interface quickly became cluttered when displaying data & progress for individual files. So, I wanted to see if I could keep feedback comprehensive without displaying too much information.

It is easy to add things; harder to take them away. So, before showing the prototype to the rest of the team for the first time, I removed anything I didn’t absolutely need to know about a given upload. I made a list of all the data at my disposal and started pruning.

I ditched overall size for two reasons. One, your brain automatically figures out the ‘size’ of an upload by combining the number of files with how fast the progress bar is moving. Two, most users don’t know/care how much bigger 3.6 MB is than 3,600 KB.

Next, I axed all information pertaining to individual files for the reasons stated above, with the exception of filename. This was necessary for informative error handling. If there was an issue with one or more files, Leigh and I had decided to continue, successfully uploading everything else. Given that scenario, it would be nice to know which files didn’t get uploaded so you could try them again.

As it turns out, uploading files via drag & drop happens concurrently. At any given moment, three or more files are in transit. To provide accurate feedback on individual files we would either need to disable concurrent uploads (slow down the uploader) or show progress bars for all of the files in transit (clutter the interface). If my intuition was sound, we wouldn’t need to do either of these. Bonus.

In the end, I settled on state, number of files and overall progress. Minimal and meaningful. If anyone on the team felt something was missing, I was confident it would eventually work its way back in.

The rest was easy

Once satisfied with the drop target and the feedback requirements, the rest of the interface fell in to place. I opted for an overlay, which provided a consistent minimum width & height, and designed unique panes for each of the five interaction states – ready, drop, uploading, success & error.

A better experience is always the best new feature

I didn’t want there to be any question as to why you should use our new uploader over existing options and I think we succeeded. The drag & drop uploader is faster and more reliable, doesn’t require a single mouse click or browser plugin, looks beautiful and is fun to use.

If you’re using Chrome, Safari or Firefox please give the new uploader a try and let us know what you think. If not, it is definitely time for an upgrade. The future is coming!

In my next post, I’ll document how we built our progress bar without a single image using CSS3.

Share it:

Upon setting out to build a Drag & Drop uploader, I first trawled the web for prior art. Blog posts, examples, any information that would lead me down a well-trodden path. As it turns out, such a path doesn’t really exist yet.

FileReader: A Dead End

Any cursory research into HTML5 file handling will undoubtedly turn up mention of the FileReader class which has made an appearance in the most recent versions of Chrome and Firefox. FileReader is useful, in that it allows a browser to read data from files, either all at once, or in chunks, however it quickly becomes unworkable when you try to use it to read large files for uploading to a server. This is due to the fact that you need to read the entire file in one fell swoop to pass off to an XMLHttpRequest, and buffering this much data (this much being 50MB or more) will cause every browser I tested to become completely unresponsive.

XMLHttpRequest Level 2: The Missing Piece

Why haven’t more drag and drop multi-file uploaders shown up on the web before now? Certainly lack of support for gathering file information from drop events was one reason, but another was the fact that until recently, XMLHttpRequest didn’t provide any mechanism for sending file data to the server. Some clever hacks abound, such as using an IFrame or Flash, but none of these would really work for our purposes.

It just so happens that the XMLHttpRequest spec has recently been revised by the W3C: enter XMLHttpRequest Level 2. Here’s the description from the aforelinked working draft:

The XMLHttpRequest Level 2 specification enhances the XMLHttpRequest object with new features, such as cross-origin requests, progress events, and the handling of byte streams for both sending and receiving.

Wow, that sounds perfect! So in supported browsers, an XHR will have an upload attribute, which is an instance of XMLHttpRequestUpload. You can even get progress events from this object, allowing you to build progress tracking into your uploader. This appears to be supported in Firefox 3.5+, Safari 5+, and recent versions of Chrome stable (6.0.472.63 as of writing, but it’s probably supported in earlier versions).

There is one caveat to this approach: there’s currently no good way to perform your XHR file upload as a multipart form post. Experimental support for this has been added in recent builds of Firefox 4, using the FormData interface, however currently the only way to reliably submit a file in a multipart form using XHR in existing browsers is to use FileReader, read the entire thing into memory, then manually build a multipart post. So in other words, it’s a non-starter. Instead, a XMLHttpRequestUpload can be sent with a reference to a file, which the browser will stream from the filesystem as the body of the request. This may require some extra work on the server side, if you want to avoid buffering the entire file inside the process handling the request. For our part, we’ve made some modifications to the venerable nginx upload module, allowing it to also accept PUT requests with raw file contents in the body.

Drag & Drop: Just Enough to Get By

People with far more knowledge and tenacity than I have written eloquent sonnets declaring their undying love for the HTML5 drag & drop API. Unfortunately, it’s the only game in town if you want to do interesting things with files dropped on the browser window. For the remainder of this post, and in subsequent posts, I’ll be building an uploader from the ground up, adding features and complexity as I go. For now, the simplest thing that can possibly work: a drop target on the page, which listens for drop events and, if any files are dropped, creates XMLHttpRequests to send the files to a URL. Things get a lot more dicey when you want to make a complex element (like a table) into a drop target, highlight the drop area, or show information underneath the mouse, so we’ll go for progressive enhancement and add that stuff in later.

Where The Rubber Meets Brass Tacks

This example micro-app will use Sinatra, and have two endpoints, one that displays a page with a drop target, and one that accepts a file upload. Follow the code on github. We’re implementing the front-end code as a jQuery plugin, but most of the concepts can be adapted to Prototype or even plain Javascript.

First, we create a simple page with a drop target div on it. We also include a CSS file and links to both jQuery and our uploader Javascript file. Lastly, we attach an uploader to the drop target:

  <html>
    <head>
      <title>Drag &amp; Drop Tacos</title>
      <link rel="stylesheet" href="/css/master.css" type="text/css" media="screen" title="no title" charset="utf-8">
    </head>

    <body>
      <div id="drop_target">
      </div>
    </body>

    <script type="text/javascript" charset="utf-8" src="/javascripts/jquery-1.4.3.js"></script>
    <script type="text/javascript" charset="utf-8" src="/javascripts/jquery.dnduploader.js"></script>
    <script type="text/javascript" charset="utf-8">
      $("#drop_target").dndUploader({
        url : "/"
      });
    </script>
  </html>

The Ruby code to support this is super simple:

  require 'rubygems'
  require 'sinatra'
  require 'erb'

  get '/' do
    erb :"index.html"
  end

To run the app, make sure you have the Sinatra gem installed (gem install sinatra … depending on your system, you might have to sudo), drop into the example app directory, and type ruby app.rb. WEBrick should start up, and you should be able to access the application at localhost:4567.

Now, let’s take a look at the jQuery plugin. I’ll dispense with the boilerplate plugin code, but if you’d like a refresher, the jQuery documentation will get you up to speed. This is a first pass at the plugin– it won’t really do any uploading yet, but it’ll allow you to drag and drop files onto the drop target and prevent the browser from trying to open them:

(function( $ ){

  var methods = {
    init : function( options ) {

    return this.each(function(){

       var $this = $(this);

       $this.bind('dragenter.dndUploader', methods.dragEnter);
       $this.bind('dragover.dndUploader', methods.dragOver);
       $this.bind('drop.dndUploader', methods.drop);
     });
    },

    dragEnter : function ( event ) {
      event.stopPropagation();
      event.preventDefault();

      return false;
    },

    dragOver : function ( event ) {
      event.stopPropagation();
      event.preventDefault();

      return false;
    },

    drop : function( event ) {
      event.stopPropagation();
      event.preventDefault();

      return false;
    }
  };

  $.fn.dndUploader = function( method ) {
    if ( methods[method] ) {
      return methods[method].apply( this, Array.prototype.slice.call( arguments, 1 ));
    } else if ( typeof method === 'object' || ! method ) {
      return methods.init.apply( this, arguments );
    } else {
      $.error( 'Method ' +  method + ' does not exist on jQuery.dndUploader' );
    }
  };
})( jQuery );

The first order of business is to intercept three drag & drop events: dragenter, dragover, and drop. In order to define your own behavior for drag & drop, the default behavior and event bubbling must be cancelled in your event handler. This bears repeating- if you don’t cancel event propagation, the browser’s default drop handling behavior will take over, and your code won’t work at all. So, we write three identical functions to handle these events:

  dragEnter : function ( event ) {
    event.stopPropagation();
    event.preventDefault();

    return false;
  },

  dragOver : function ( event ) {
    event.stopPropagation();
    event.preventDefault();

    return false;
  },

  drop : function( event ) {
    event.stopPropagation();
    event.preventDefault();

    return false;
  },

Then, in our init function, we bind our event handlers to the appropriate events:

  init : function( options ) {

  return this.each(function() {

     var $this = $(this);

     $this.bind('dragenter', methods.dragEnter);
     $this.bind('dragover', methods.dragOver);
     $this.bind('drop', methods.drop);
   });
  }

So, with all of that, we should now have a drop target primed to accept items dragged onto it.

Getting information out of the MouseEvent

When files are dropped into our target, the event carries with it important information about what items were dropped. This information can be found in the dataTransfer property of the MouseEvent. The following modification will allow us to list the contents:

  drop : function( event ) {
    event.stopPropagation();
    event.preventDefault();

    console.log( event.originalEvent.dataTransfer.files );

    return false;
  }

If you’ve been following along, when you drop a couple of files onto the target, you should see something like this:

  FileList
    0: File
      fileName: "Scan 2.pdf"
      fileSize: 4999673
      name: "Scan 2.pdf"
      size: 4999673
      type: "application/pdf"
      webkitRelativePath: ""
      __proto__: File
    1: File
      fileName: "Scan.jpeg"
      fileSize: 943332
      name: "Scan.jpeg"
      size: 943332
      type: "image/jpeg"
      webkitRelativePath: ""
      __proto__: File
      length: 2
      __proto__: FileList

So, we can easily get the filename, size, and type from the objects in the dataTransfer. Next, we’ll loop through and upload each file. Since this only works with XMLHttpRequest Level 2, we won’t bother with interfaces that abstract away the XMLHttpRequest object- we’ll create one and manipulate it directly. First though, we should make sure to store the url, and any other options, on the uploader node:

  return this.each( function () {

    var $this = $(this);

    $.each(options, function( label, setting ) {
      $this.data(label, setting);
    });

    $this.bind('dragenter.dndUploader', methods.dragEnter);

So, now that a url and method can be passed in, we’ll handle the upload once the files have been dropped:

  drop : function( event ) {
    event.stopPropagation();
    event.preventDefault();

    var $this = $(this);
    var dataTransfer = event.originalEvent.dataTransfer;

    if (dataTransfer.files.length > 0) {
      $.each(dataTransfer.files, function ( i, file ) {
        var xhr    = new XMLHttpRequest();
        var upload = xhr.upload;

        xhr.open($this.data('method') || 'POST', $this.data('url'), true);
        xhr.setRequestHeader('X-Filename', file.fileName);

        xhr.send(file);
      });
    };

    return false;
  }

Next, make sure to edit index.html so that it specifies a PUT:

  $("#drop_target").dndUploader({
    url : "/",
    method : "PUT"
  });

Finally, we’ll add rudimentary handling of the file on the server. For now, this just prints the name of the file and its length. From here, reading the contents or writing to the filesystem isn’t much of a stretch, but for the time being, I’ll leave that as an exercise to the reader.

  get '/' do
    erb :"index.html"
  end

  put '/' do
    puts "uploaded #{env['HTTP_X_FILENAME']} - #{request.body.read.size} bytes"
  end

What’s Next?

There are some nice features we should probably add to this uploader, such as the ability to show/hide an overlay when the mouse hovers over the drop target, an upload progress bar, and feedback when the files have successfully (or unsuccessfully) uploaded. In the next post in this series, I’ll work on adding these features.

Share it:

Recently, there has been a lot of discussion surrounding the Firefox add-on Firesheep. Firesheep is a tool that makes it easy for its user to assume (hijack) the identity of other users on a number of popular websites. I want to take a moment to explain not only how Firesheep works, but how when you are using the Onehub site, we protect you from the vulnerabilities that Firesheep exposes.

The Internet, and the protocol it is primarily built on, HTTP, are inherently stateless, meaning that by default no information is kept on either the client or server between requests. In other words, if you request the homepage from a website, then the product page, the website has no way of knowing that these two requests came from the same person, thereby making things like user logins and shopping carts impossible to track. In order to work around this limitation, and provide the seamless experience we have all come to expect, websites place a small piece of data on each user’s computer: a cookie. These cookies (specific to each website) are sent back to the website with every browser request, and they can use the information contained therein to recognize that all of your requests are coming from you, and you alone. In essence, once you are signed-in, you are your cookie. Cookies have a bad reputation amongst some users, however they are an indespensible piece of technology, and without them the modern Internet would not function.

An Example

Let us use a simple story. Charles would like to visit onehub.com to check the latest activity in his Workspaces.

Charles opens his web browser, Mozilla Firefox, and types onehub.com into the location bar. On his behalf, Firefox sends a request to the onehub.com servers for the homepage. In a few milliseconds the server replies with the HTML, CSS, JavaScript and images that make-up the onehub.com homepage. Firefox takes this data and renders onehub.com in Charles’ browser. So far so good. In order to see the latest activity, Charles will need to sign-in, and then visit the activity tab. So he clicks the “Sign In” button on the top-right of page and again, Firefox sends a request for a webpage to the onehub.com servers, but this time for the sign-in screen. This is where it gets interesting.

The sign-in screen is secured via SSL/TLS (indicated by the S in the HTTPS in Charles’ browser). This ensures that the onehub.com server really is who it claims to be, and encrypts all the data exchanged between Charles’ computer and the server. Confident that his email and password will not be exposed to the world, Charles fills out the form and presses enter. With the email and password in hand, the server does a few checks. It first looks in the database to see if a user with Charles’ email exists, if this is the case, it checks the password for that account against the password Charles typed in earlier. Provided both of these pieces of data match, the server replies back with the requested data, Charles’ home screen. In addition, the server provides a small piece of data in a cookie, a session identifier. This is a randomly generated string of characters, something like “a74822fdbce86b1541fec9c1f92d366f”. In addition to sending this identifier to Charles’ browser in a cookie, it is also stored by the onehub.com servers. In fact, if you are signed in to onehub.com right now you may look in your cookies for _onehub_session_id which will have your unique session identifier.

The session identifier functions as a stand-in for the user’s credentials, it saves Charles from having to provide this information on every single request.

Now that Charles is on the homepage, he clicks on the activity tab. Firefox again requests a specific webpage from the onehub.com servers, but this time it also provides the data in the cookie, the session identifier.

The server accepts this request, and looks up the session identifier in the database. The database provides two pieces of information to the server about this particular identifier. First, if this identifier was created recently enough (you may extend the length a session identifier is valid by choosing ‘Keep Me Signed In’), and second, that it belongs to Charles. The server can now reply with the data for Firefox to render Charles’ activity page.

This type of data exchange happens millions of times per-second across the Internet and it is this same technique that lets you do everything from sharing a photo on Flickr to keeping a shopping cart on Amazon.com.

So how does Firesheep work?

It is actually relatively simple. Most websites (onehub.com included) secure their sign-in forms with SSL/TLS. This means your email or username and password are encrypted when sent to the server. However, once a user is signed-in these sites do not encrypt the data exchanged between the browser and the server (onehub.com does). Firesheep watches all the traffic flying around on the network it is running on, like the coffeeshop which Charles is working from this morning. It listens specifically for the session identifiers for many popular websites including Facebook and Twitter. Firesheep then provides an easy way to change Charles’ session identifier to another one that Firesheep has found on the network. Charles is transparently able to assume (hijack) someone else’s identity.

How is Onehub secure?

We do two things differently than the majority of sites. First, we encrypt all traffic, all the time. This makes the session identifiers opaque to tools like Firesheep, provided the user visits the SSL/TLS secured webpage. Second, when providing the cookie to the browser, onehub.com marks the cookie as ‘Secure’. The implications of this second measure are subtle. Suppose Charles visits http://onehub.com (without the S). Without the cookie marked as ‘Secure’, Firefox would transmit the cookie to the onehub.com servers unencrypted. While onehub.com could redirect his browser to visit https://onehub.com (with the S), the damage is already done: Charles has broadcast his session identifer in an insecure fasion. Firesheep and other tools would be able to intercept it before the server can instruct the browser to try again via the secure connection.

Internet Security is a tough problem, it requires education of both end-users (Charles) and system administrators (Onehub) to ensure data is not leaked. The team here at Onehub works very hard to ensure your data is safe. We will continue to monitor new threats as they arrive, and adjust our systems and policies where appropriate.

Share it:

As with many residents of our fine state, I’m sure a lot of people follow the Cliff Mass Weather Blog. We’ve been bracing for a storm for a few days now, and it seems that it’s here. The coast has been getting the brunt of it, and we’ve been eagerly watching the Forks, WA webcam. This afternoon we  noticed something a bit… irregular.

Share it:

Onehub Sync

As companies seek to break out of department silos and collaborate on projects that could drive more sales, the question becomes: Who’s going to make that happen? Without someone in charge of guiding the collaboration process, cross-department initiatives tend to waste employees’ time and sputter out.

The challenge can be even greater when workers based in multiple locations seek to collaborate on a project. Increasingly, virtual teams are being formed across company branches, between companies and freelancers, or between companies and strategic partners. In any of these scenarios, someone needs to make sure the collaboration runs smoothly and stays on track.

In the book Collaboration – How Leaders Avoid the Traps, Create Unity and Reap Big Results, University of California-Berkeley management professor Morten Hansen describes how badly managed collaboration can be worse than no collaboration at all.

That’s why Hansen and others advocate that companies appoint a chief collaboration officer. It doesn’t have to be a new position, or another role for the CEO. But possibly the CIO, CFO, COO, head of HR, or a strategy or business-development chief could add a focus on making sure collaborations work at the organization.

The type of collaboration taking place may be a guide for who would be the most likely candidate for the chief collaboration officer role. If part of the challenge is how to best use technology to collaborate across distance, this might be the CTO’s job, for instance, or the CMO might spearhead collaboration of a cross-divisional team that’s formed to handle the company’s social-media marketing.

Besides having a leader to oversee the collaboration, another key issue is making sure employees have a vested interest in the collaboration and a clear sense of what’s in it for them, says ZDNet columnist Oliver Marks. Collaboration technology can help, but it can’t take the place of clearly understood, shared goals and genuine enthusiasm from the team for what the project could accomplish.

Do you have a chief collaboration officer? Is your company collaborating across departments, or with outside contractors or partners? Leave a comment and let us know how you manage the collaboration process.

Photo licensed under Creative Commons 2.0 via Flickr user: woodleywonderworks

Share it:

Drag and drop files from your desktop to your workspace using Safari, Firefox, and Chrome.

HTML5, the next major revision of the HTML standard has given us the ability to support file uploads via the web interface using drag and drop. The new HTML standard incorporates features like video playback and drag-and-drop that have been previously dependent on third-party browser plug-ins such as Adobe Flash and Microsoft Silverlight. This is no longer the case.

You can now just drag the files from your desktop onto the files widget and drop them. The simplicity of this new feature makes file sharing and online collaboration a breeze.

Dragging Files

Right now, this feature is available when using Firefox, newer versions of Safari, and Chrome.  We have heard rumors that Internet Explorer 9 (which is currently in Beta) will support HTML5 including drag and drop.  However, if you want to try this out now, download one of the modern browsers I mentioned above.   We can’t wait to hear your thoughts on this cool feature.  We hope you are as excited as we are.  Tell us what you think by commenting on this post.

Happy Dragging and Dropping!

View more images of the new HTML5 Uploader:
Share it: