GED
VALE OIL & GAS
DOCUMENTS MANAGER

What's the Application About?

GED — portuguese initials for Electronic Document Manager was my first high complexity Human Computer (HCI) project I’d participated. It has been 4 years already.

It's function was to manage and distribute Vale Oil & Gas’s documents. Before that those documents were manipulated and organized physically and, when necessary, distributed digitally without any control via email. With GED, the employees responsible for that task could manage, classify and distribute them via company’s digital platforms while the users that would consume this data in a more safe and simple fashion.

Those documents were made of a series of properties and files. So created a way for user (with such access) to create new document types and new types of atributes when needed. That way users had independency from the development team and it’d let us free to focus on new features. That was one of the reasons the applications is more than 3 years with no need of maintenance.

ged-mockupsged-mockups

The Challenges

The Requirements

The documents should go for a series of steps before being published, so we divided the applications in 4 main areas: File Repository, Documents, Pre-Published and Published.

To indicate how close the document is to be published, we created a color code the went from red, yellow than green. Every one of those steps (pages) has a color that indicated how close the document was to be published. Green? Published!

Design Framework

We planned the pages in a way that once users visited one page,  they would that get the same pattern in the others and get a pretty good idea of where to find things their needs.

In the header the user could find the name of the page, the call-to-action button and the menu pages.  
#2 is the action bar, where we could find all the main action of that page. #3 is the pages content and #4 is the page navigation — when needed.

In the header the user could find the name of the page, the call-to-action button and the menu pages.  #2 is the action bar, where we could find all the main action of that page. #3 is the pages content and #4 is the page navigation — when needed.

By collecting guidelines, elements and components we formed up our own pattern library. from little atoms to page templates. It was months before Bootstrap came live months later.
We got to a point that only complex screens or components needed to be designed in photoshop. A simple wireframes by pen and paper or in Keynote were enough.

Clever Design Solutions

Solution #1 - Design for Agility

The documents page would be the most used page in the application. For that reason, We designed the page to support navigation, visualization and edition of the documents at the same view. 

In the list on the left you find the document type list, at the center is the list of existing (but not published) documents of that type. Each box is a document and its related files. At right are displayed the fields where documents properties are input.

Solution #2 - drag and drop name builder

To create document types, the users needed to create the way the file’s directory had to be created, like the document’s name  had to be created and we came up with 2 alternatives: to use a drag-n-drop component or a typeahead component like Chosen.

Drag-n-drop fitted better because it’d be easier for the user re-arrange elements, while with chosen it’d be necessary to erase and write things over and over until they finds it’s the right way.

Take aways

  1. This was my first experience with agile methods of software developments. The speed and precision we achieved in this product was remarkable.
  2. Interact with users was super-easy by being close to them, in the same company, in the same building. To test the application and getting feedback right away was great. It’s incredible what you can learn by only watching people using the product.