GED

Vale Oil & Gas Document Manager

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

Its 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 more safely and straightforwardly.

Those documents were made of a series of properties and files. So created a way for the user (with such access) to create new document types and new types of attributes when needed. That means users had independence 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 for maintenance.

tred_styles_1

The Challenges

The Requirements

The documents should go for a series of steps before being published, so we divided the applications into 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!

tred-ios-line

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.

tred_scroll

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 the point that only more complex screens or components needed to be designed in photoshop. Simple wireframes by pen and paper or in Keynote were enough.

Design Solutions

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

Drag-n-drop name builder

To create document types, users needed to create the way the file’s directory had to be added in the system and how documents should be named, so we came up with 2 alternatives: to use a drag-n-drop component or a typeahead component like Chosen.
A drag-n-drop component fitted better because it’d be more comfortable for the user re-arrange elements, while with chosen it’d be necessary to erase and write things over and over until they find it’s the right way.

Takeaways

This was my first experience with agile methods of software developments. The speed and precision we achieved in this product were remarkable.

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.