-
Notifications
You must be signed in to change notification settings - Fork 6
Dashboard 0.5 Roadmap
Backbone does not fit our development style (i.e. we don't use classes) and has caused a lot of rigidity in the UX. Its opinionated nature is not helpful for a schema-independent user interface.
Pushing dashboard updates to the core can be a pain point; currently it involves manually copying the built files. Architecture updates will be needed for both the dashboard and the core to streamline this.
Ideally, all Deployd open-source projects should be compatible with Windows by 0.5, including build tools written in shelljs. The dashboard is theoretically compatible with Windows but untested so far.
The full-width list items do not work well - they create too much visual separation within the item as some components are right-aligned. The visual metaphor should be entirely rethought. In addition, early tester feedback has suggested that draggable lists may not even add to the experience.
This is currently a placeholder - we need to determine what kind of general configuration an app needs. If none, we should remove this section entirely.
The rename feature of resources is not very discoverable and is inconsistent with the behavior of properties in the Collection editor.
Testing a request directly is useful and is referenced by the tutorial, but is currently a third-party tool. It would be helpful to have one built into the dashboard.
Sometimes it's useful to run a quick script against your app to test something or do a batch operation.
Should be able to export an entire app to a file (preferably a human-readable file), and re-upload to another Deployd instance.
This page should be entirely redesigned.
You should be able to open up a text editor for uploaded files to make quick changes.
The event editor is distracting and not self-explanatory at first glance.
Needs the ability to test a request without actually sending it, needs to watch values, needs to show execution path, and needs to show errors.
On Access (GET/PUT) and On Save (POST/PUT) are a good place to start. Helpers would also be useful.
Each automatic property will expose its own event for calculation and calculate itself only when necessary (i.e. when its dependencies change).
Should be able to query another object in an event, especially in automatic properties.
We need nested collections (i.e. /users/todos) with an automatic parent property and more semantic urls for querying (i.e. /users/12345/todos). We'll also need a Link property type to store a reference to another resource.