Reproducibility - Operation History

Development & Design
1

Hi @Martin @antonin_d @zoecooper !

Had a great meeting with Zoe Cooper just now. As usual, I talked to darn much. (Sorry Zoe!) But thought I would post here one open question I had and which Zoe was also a bit unclear on, likely until she speaks with Antonin in more depth. But here's my bit of worry or suggestions.

@zoecooper I looked at some of the forum posts again and the blog post which states:

As OpenRefine's lead designer, she will initially focus on improving the platform's Operation History as part of a project funded by the EOSS-5 grant. She will also continue to develop OpenRefine's design practice, following the work initiated by Lozana Rossenova and Lydia Amadi Chinyere through last summer's Outreachy internship.

So​ right, the Operation History covers several things, but user facing it's the Undo/Redo.

1. I'd be very curious what other user facing components that @antonin_d has in mind that addresses the Operation History?

Please post in the forum dev/design category, after you and @antonin_d speak and ideally an initial draft design document would be nice to share and put a link on the forum post as well. I understand it's a work in progress, but I think it's important that we are clear on what parts of the "Operation History" you will be tasked with design/redesigning. If it's only the Undo/Redo (and maybe helping with a DAG design, directed acyclic graph approach, or node approach, then that's fine and could mimic how Git branching is handled somewhat, and how reordering operations could be performed and visualized.)

2. So here's the link to the currently categorized list of undo/redo/history issues...

Issues · OpenRefine/OpenRefine · GitHub

I think it would be great if you and Antonin could somehow add a new label to any of them (even temporary) that lets the community see which of those and any new ones...that you will be addressing as part of the first 6 months hire? or tag with a label of EOSS5? Does that make sense folks?

​Anyways, I realized I talked way to fast during our meeting ! :grin: and I promise to slow down next time. I was just super excited to meet you and more excited to have a new designer on the OpenRefine team!

2 Likes
2

Nice to read your enthusiasm Thad!

Yes the undo/redo tab is at the center of this project, but more broadly it's about improving the representation of operations, which has impact on other areas of the tool (for instance, so far I have also done a lot of work on long-running operations, which you can see in my reports).

You are correct that most of the issues tagged "undo/redo/history" are relevant for this project, the details of which ones we'll prioritize depend on the course of the project and feedback we get.
This document is still relevant to understand the problems that motivate the changes: OpenRefine history improvements - HackMD.
You see for instance that problems such as "facets are recomputed even when the columns they depend on have not been touched" seemly don't make any reference to the undo/redo tab, but to address those we need an improved representation of the columnar dependencies of operations, which is why it's related.

Also there is a GitHub project where I have added issues which I would like to work on in the scope of the project (this view only lists the open ones):

1 Like
3

Great! Thanks @antonin_d , and which ones have scope for @zoecooper to work through on design challenges? Will you be dual assigning Zoe to those?

4

What do you mean by dual assigning?

My plan is to prioritize improvements to the visualization of the history first (and general UI improvements around that area), because it connects nicely to some problems @zoecooper found when learning to use the tool, struggling to relate what is shown in the Undo/Redo tab to the actions done interactively on the grid. It's an area where we should be able to do some quick mock-ups easily too. On the development side, columnar metadata for operations is now available, so it's a good timing to figure out how to show this information to the user.

For the rest of the issues, the prioritization will depend on the feedback we get from testing and discussion here and on GitHub, I would say.

2 Likes
5

Ah, this reply was useful. You shared a bit of your planning thoughts. This is what was good to share. Thanks so much! Understand more fully now, that the Undo/Redo needs a lot of visualization help, but first, documenting and knowing what the operations or (or stand for) is a higher first priority and something you already did mostly and shared before. So got it now. Thanks!

6

thanks for your question @thadguidry
For clarity @antonin_d where are those development taking place? Whould they be available for both the 3.x and 4.x version?

7

I expect most of our changes will depend on the columnar dependencies of operations and lazy evaluation, which are not available in 3.x, so I would do the work in 4.0 by default. If there is interest in backporting some specific changes (such as light UI improvements), it might be doable.