Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Roadmap doc] - Redesign data storage - removal of Saved requests #80

@jarrodek

Description

@jarrodek

This issue is a request for comment on redesigning data storage model and removal of "saved requests" list.

Background

Saved requests were created to allow freely store any arbitrary request in a main "saved" data store so it can be restored later. That was one of 3 ways of storing the data next to history view and projects.

Over time navigation in the application changed by adding a quick list of history/saved/projects and recently rest APIs menu has been added to the view.
After reviewing the design of the navigation and what we want to achieve in the future we have decided to remove saved section from the application.

Redesign

Right now navigation consist with 2 main sections of the application (HTTP request and Web socket) and 4 quick lists of saved/history/projects/Rest APIs. This navigation is inefficient as introduces to many options that can be confusing for new users.
Google Analytics data shows us that saved requests are used as often as the history. However difference of use of corresponding full screen versions of the lists is significant. This means that most of you use "saved" from the menu panel.
Navigation process can be optimized by reducing number of available panels and moving current saved requests to a "default" project. Change for the user is very little as the same goal can be achieved with other structure that already exists (projects list).

Data redesign

Current data model is focused around history and saved requests. Technically the only difference between two objects is the type (saved or history) and that saved can have a name and description. Projects are just a relation flag between saved requests.
In the future we are planning to focus data structure around projects and not the requests. Projects would become base organizational object for requests.
This would influence every data model in the application and thus export / import models. Naturally the application would support every previous data model and would transform it to a new data model during the import.

End user considerations

Migration to new data structure would be automatic for users who have saved requests not added to a project. The data would be moved to (probably) "Saved requests" default project.
After that there would be no option to save a request without a project name. By default project would be "Saved requests" project unless during the session other project was previously selected.

Navigation will be simplified by removing "saved" tab leaving only 3 options: history, projects, and REST APIs.

Time frame

Public notification of the change will be added to the application in July 2018. The data model won't change for at least next 3 months but it may take longer depending on the discussion and other factors.

We value your voice and we would like to know your opinion about planned changes. Leave a comment bellow and I will respond as soon as I can.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions