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 (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.

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.

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.

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.

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.

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. You can now simply drag and drop files from your desktop to your Workspaces. The simplicity of this new feature makes file sharing and online collaboration a breeze.

Right now, this feature is available in Chrome, Firefox, and newer versions of Safari. 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!

EBSCO Media chooses Onehub to create a better customer portal experience and enable sales team

EBSCO Media, Alabama’s largest commercial printer chooses Onehub to make it easy for their customers to share important business information with them.

EBSCO Media is Alabama’s largest commercial printer offering a full-service printing experience for customers across the United States. EBSCO provides offset and digital printing excellence as well as the ability to design, bind, fulfill, and mail custom-printed pieces. In business more than 60 years, EBSCO Media operates its 130,000 square-foot production facility and 50,000 square-foot warehouse in Birmingham, Alabama 24 hours a day, 7 days a week.

Situation
EBSCO receives hundreds of files a month from customers who need printing services. These files are typically InDesign, PDFs, and Quark files or any other file type used in desktop publishing. They also need to share different types of graphical and audio-video media files, spreadsheets, and presentation documents with partners.

Prior to finding Onehub, EBSCO hosted its own solution using a legacy file sharing product. EBSCO understood their current file sharing system had limitations and proactively looked for a better solution.

Solution
EBSCO Media found that Onehub was what they were looking for — and more.

“I wanted a third party solution that we could brand to look like our own. A solution that would work well for everyone, and is easy to use regardless of their computer knowledge. It needed to be web-based and have a way to segregate notifications so that the proper people are notified when files are uploaded,” says Randy Jamerson, Prepress Systems Administrator. “We also needed the ability to control access to specific files and folders so that customers could view only the files that belonged to them, not everything on the system. Onehub’s page and folder level permissions provided EBSCO Media with this functionality.”

EBSCO uses Onehub to make it easier for customers to upload files and for the customer service representatives and sales representatives to more easily access these files and related information. It’s a win–win for all parties involved.

“Our customers are overwhelmingly positive about the change from using traditional FTP to Onehub. Our salespeople now have more access to files without having to wade through information that doesn’t pertain to them. We are also using Onehub internally as an intranet for sales resources and training information.” says Randy Jamerson.

Research suggests that 50% of valuable business information and files are stored on individual employee computers. That is a huge amount of important business insights and possible ideas that aren’t available to other people inside your company or your business partners and clients outside of your company. There they are locked away on individual computers.

This is why we are excited to announce Onehub Sync.

Onehub Sync makes it easy to unleash the files and information stored on individual computers by creating a link to your Onehub workspaces in the cloud. This way you can not only share files and collaborate with people inside your company but also outside your company. It makes information sharing with external partners and vendors or even customers seamless and easy. By 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.

Want to see it in action? Watch this short video.

How it works:
You download the Onehub Sync client to your computer and install. A Onehub folder will be created in your “Documents” folder. You can determine which Onehub Workspaces you would like to sync and turn them on in the Onehub application. When you put files into the Onehub folder on your computer it continuously syncs those files to your client extranets, partner portals, or internal department intranets on Onehub and vice versa. Everyone gets notified via email of new files and changes that are synced so you’re always on the same page. Onehub Sync provides a seamless connection from your computer to the cloud and from your office to others around the world.

We are happy to have Onehub Sync applications available for both Mac and Windows. We will be releasing these to our customers over the next few weeks.We look forward to hearing your feedback about this great new feature. If you are a customer and would like to try Onehub Sync, please contact us at info@onehub.com or 1-877-644-7774.

To continue our blog series “Conversations with Customers”, I had the honor of speaking with David Winters-McDonald; the General Manager of MPC Studios Inc. David explains how using Onehub for both a company intranet and FTP replacement has saved him time and provides a reliable solution for his clients.

Laurel Moudy (Onehub): Can you tell us a little about what MPC Studios does, and what role you play in the company?

David Winters-McDonald General Manager, MPC Studios

David McDonald (MPC Studios): MPC Studios is an Advertising Agency with a dedicated focus on Website Design, Online Marketing, and New Media. We started in 1998 as a small group of young geeks in South Texas, and have grown into a very successful company with over 150 clients across the country. I started working with the company 9 years ago filling in any role that was needed and today I am the General Manager, still filling in any role that is needed.

Laurel Moudy: How did you hear about Onehub?

David McDonald: I found Onehub while searching for an FTP service for one of our clients.

Laurel Moudy: And how is MPC Studios using Onehub today?

David McDonald: We use Onehub in a variety of ways. First we use it internally to transfer large documents between our offices and with our contractors abroad. Second, we use it with a handful of our clients that need an internal FTP tool for distributing files. Third, we have setup small intranets for our clients to use.

Laurel Moudy: Can you give me an example of a client that you work with and how you’re using Onehub with them?

David McDonald: One of our clients is a research group at the University of Texas in Austin that received an EFRC grant from the Department of Energy. Part of the grant stipulates how the progress and activities of the group should be communicated online. They have a public facing website where their activities can be displayed but they also have a private facing section where they distribute materials to the participating researchers. For the private side we have setup Onehub where the researchers can login to upload and download files.

Laurel Moudy: How did you manage the process of sharing files and collaborating before Onehub?

David McDonald: Previously we managed our own FTP server or traded files over email.

Laurel Moudy: Why did you make the switch to Onehub?

David McDonald: We decided to use Onehub rather than a traditional FTP server because of the easy to use interface and because it was very simple to setup. It was not unusual for us to have to train our clients to use FTP whereas with Onehub it was all very intuitive.

Laurel Moudy: How is your company benefiting from using Onehub?

David McDonald: For us, Onehub saves time provisioning accounts and training users. It also enables us to provide this solution to our clients.

Laurel Moudy: What are your clients, partners, and colleagues saying about the Onehub service?

David McDonald: Generally our clients have very little to say about the service. It just works. Previously, with FTP or email, there were occasional problems and that always comes with complaints. The silence speaks volumes to the reliability of the service.

Laurel Moudy: What is your favorite feature in Onehub?

David McDonald: My favorite feature is that the file sharing can be accessed through an easy to use web interface or through a traditional FTP client. This suits both the tech savvy and the tech novices.

In a previous post I talked about the best way to handle putting an application into maintenance mode. In addition to sending the appropriate status code (503) for machines, nginx is configured to serve a helpful page to inform users of the maintenance window. Today, I would like to build on this configuration to make it possible for a few users to test the application while it is in maintenance mode for the rest of the world. There are a few different ways this could be handled, but HTTP cookies are a simple and flexible solution.

Recall these directives which instruct nginx to check for our maintenance page and set the status code to 503:

if (-f $document_root/system/maintenance.html) {
  return 503;
}

Let’s modify this with a variable to track state. Now, we can add an additional check for anything we would like to turn $maint off. $http_cookie holds all the cookies for the request:

set $maint off;

if (-f $document_root/system/maintenance.html) {
  set $maint on;
}

if ($http_cookie ~* "topsekrit" ) {
  set $maint off;
}

if ($maint = on) {
  return 503;
}

You can now set a cookie with a value of “topsekrit” and nginx will let you circumvent the maintenance page to test your new code before you release it to the world.