Uninformative UX / Grammatical Error

[mitchwagner]

When one attempts to delete a graph, they receive the following message:

"The graph will be deleted in sometime."

At a minimum, this should read "The graph will be deleted in some time."

Even this message is vague, however. It might be helpful to add the name of the deleted graph as a sort of confirmation. It would also be very helpful/comforting to a user to provide an upper range of when the graph will be deleted.

[tmmurali]

I agree. The message has to be more precise. @adbharadwaj can you remind me why deletion takes time? Does the graph owner know when the deletion operation completes?

Does our notifications infrastructure handle deletions? I can imagine that both the graph owner and users with who the graph is shared get one notification when the owner "presses the delete button" and another when GraphSpace actually completes the action.

[ghost]

Hello, my name is guruprasad, i am interested in this project. Can I take this up?

I scanned through the code and from my understanding on delete request from the client, deletion done at the server without any fixed delay(it may delay because of network latency or high load).

Fix 1: "Submitted the request to delete the graph with id $id. The graph will be deleted in some time."

or

Fix 2: "Submitted the request to delete the graph with id $id. The graph deletion will be confirmed shortly"

Please give me your feedback.

[jahandaniyal]

@mitchwagner Did you mean something like the UX in the gif below ? we can display the graph name in bold font instead of the graph id as you suggested earlier .

[mitchwagner]

@jahandaniyal Yes, this is very close to what I was envisioning, with the following caveat:

As @guruhegde pointed out, the delete request can take longer than a few moments. For those cases, a different solution for notifying the user (such as email, or the notification framework developed over the last summer) may be more appropriate than a pop-up, since it will be hard to guess when the deletion will actually take place.

@adbharadwaj Thoughts?

[jahandaniyal]

@mitchwagner Perhaps I'm wrong, but I think the notification framework has not been integrated in the current release of Graphspace. Any suggestions on how to use the notification framework would be helpful. If this issue is not yet assigned, then I would like to take it.

[mitchwagner]

The notification framework is currently on this fork, with an open pull request to our development branch: https://github.com/melvin15may/GraphSpace

Information on how this framework is implemented is here: https://gist.github.com/melvin15may/2ae50b6904844a8fa390030321394a3f

It might be best to hold off on this issue until that pull request goes through (unless we want a stop-gap solution), but if someone is interested in exploring this code, it might help with implementation of other issues/projects as well.

Regarding assignment of the issue, I'll leave that to @adbharadwaj and @tmmurali to decide.

[tmmurali]

@jahandaniyal The key question here is figuring out when the graph will be completely deleted from the database. If the deletion code can update the notification infrastructure when the delete operation completes, then we can notify the graph owner and other users with whom the graph is shared

@adbharadwaj Can we write some code to update the notifications list when the delete completes?

[adbharadwaj]

@tmmurali Yes, we can write a code to update the notifications list when delete completes. Because all calls in python are blocking calls, we can simply add the code to notify the user after the deletion.

Infact, if I remember correctly, current notifications framework implemented by @melvin15may does trigger notification when the graph has been deleted successfully. Even the users with whom the graph is shared will get a notification.

[tmmurali]

Thanks for clarifying, @adbharadwaj. In that case, I think the best person to close this big is @heidict as part of her undergraduate research this semester. I will assign it to her, but I am happy to discuss further.