The Oversing UI Strategy Oversing provides multiple methods of displaying the us

The Oversing UI Strategy

Oversing provides multiple methods of displaying the user’s information. Rather than try to convince customers to use the oversing interface one way, our strategy is to provide ALL of the different UI models over the top of the UI, so that no matter what UI paradigm the user comes from – from the most simplistic (asana) to the document (basecamp) to the column (trello) to the ‘board’ (Jira), that the customer can use the interface that’s familiar to him.

In this way we make a migration path from the very simple task based UI’s all the way up to the most informationally dense UI possible.

Why? Well, if you design your product for a UI, that might seem wise. But the fact is that all human work can be expressed as collection, list, hierarchy, or graph, and oversing uses a graph to represent collections(boards), lists, hierarchies, and graphs. So it is much easier for us to add features that represent more simple UI models, than it is for products designed for simple models to architecturally revise to represent the more complex.

Our goal is to provide a single product with various interface densities so that we serve the entire enterprise no matter how complex (or simple) is their workflow.

Now, in v1 we plan only on having Tree(hierarchy), Gantt(timeline), Board and Table (sortable list). But we have four other UI’s that we plan to add in the future.

Simple list (asana default view for example), This view already exists on the subtasks tab of every page. But we want a workspace view that works the same way.

Column (single column board)

Timeline (non-dependency driven timeline)

PaperSheet (a single page view of all project elements that is more Paper-like in appearance than our default facebook style pages) This provides awesome simplicity for the user