A couple of weeks ago, Jacques-Alexandre showed us a prototype for a user interface that would make it a lot easier to create new applications, with a simple multi-step wizard. It came right at the time when I was giving some thoughts to the idea of a wizard-driven user interface for all our objects that could be used as a way to simplify the creation of new records. Some discussions ensued, and we agreed that it would be a good idea to implement it in order to dramatically simplify our overly sophisticated user interface.
The main goal is to simplify the creation of new records for any object, including objects themselves. The idea is to faciliate this creation by canonically generating multi-step wizards that would focus on an object’s required and important fields, with oversized forms. Such wizards would be stateful but non-persistent until the user would click on a Done button, allowing easy navigation through steps. And they would be defined using the exact same schema as the one used for screenflows, so that we could build a single graphical editor for both.
The canonical wizard would have three steps:
- Required Fields, with Next and Done buttons.
- Important Fields, with Previous, Next, and Done buttons.
- Preview, with Previous and Done buttons.
The steps would be shown on a straight-through flowchart setting the user’s expectation about the number of steps involved in the creation of the record. The Important Fields and Preview are optional and would be prominently indicated as such, allowing the user to complete the record creation as soon as all required fields would have been populated. At any time, the user could also switch to the full record view in order ot populate any other fields that are neither required nor important.
Additionally, developers of objects could create custom wizards, much like they can create custom forms and views. This would allow the creation of records for more complex objects such as applications, objects, or purchase orders, for which many parameters must be entered, and for which many fields are relational, including advanced relationships for which multiple relations need to be instantiated.
Right now, we’re not sure whether we will include this in our MVP or not. More on this soon…
Now that we’ve figured out how to create complex views and sophisticated charts, it’s time that we simplify our user interface so that all users could benefit from all this goodness, without having to fiddle through endless menus and cumbersome popups.
In such a context, Florian and I have decided to try something pretty radical: merging our grid perspective and our view editor, into a new grid perspective that would always display charts. The idea is that charts is another way to look at your data, hence our full collection of canonical charts could be considered as a perspective.
And because charts are intrinsically linked to the concept of views, and because views are best created when looking at data, either in raw form or through a pivot table, why not merging all three together? Raw data, view configuration, and charts, all tightly integrated together through the default grid perspective.
This approach would have the benefit of showing gorgeous charts immediately after importing any data (a spreadsheet usually), without having to click on any icon or menu item. And by doing so, we could refactor our grid perspective and get rid of its menus. Instead, we would just show the view’s name (All Records by default), and a set of icons, one for each perspective.
Down the road, we would apply the same principle to all other perspectives, showing different charts for different perspectives, according to the fields that are most relevant for a given perspective. For example, the Calendar perspective would show charts that have a chronological dimension, and the map perspective would show charts that have a locational dimension.
All the pieces are coming back together…
This could not come at a better time…