1. 1
Micro-Versioning Tool to Support
Experimentation in Exploratory Programming
Hiroaki Mikami, Daisuke Sakamoto, Takeo Igarashi
2. Target Task
Micro-Versioning
2
Version control operations during exploratory programming
Programming with many experimentations [Johannes et.al., 1992]
1.Implement text field
2.Switch to dropdown list
3.Change background color
4.Revert to the text field
Example
3. Literature Survey
3
We examined previous studies to clarify requirements
Requirements for micro-versioning tools
1. Lightweight user interface [Vakilian et.al, 2012]
2. Provide visual cues [Mealy et.al, 2007]
3. History model generating meaningful candidates
[Yoon et.al, 2014]
4. Version Control Systems (e.g. Ecliipse EGit)
Current Methods (1/2)
4
● Complex user interfaces
● Manual commit operations
Inappropriate for
micro-versioning
5. (Linear) Undo Tools [Yoon et.al, 2014]
Current Methods (2/2)
5
● Cannot undo old edits
● No visual cues
Commenting-out [Yoon et.al, 2014]
● Need to remember separated
commenting out area
Cause mistakes
x=10 x=20 x=30
// var x = 20;
…
elem.innerHTML = x + “”;
Forget to uncomment out
related
change to 20 change to 30
6. Advantages
● No need to manually commit
● Can undo any edits
Related Work：Supporing Selective Undo in a Code Editor[Yoon et.al, 2015]
Purpose
Solve limitations of undo tools
6
Methods
● Selective undo algorithm
● Edit history visualization
7. Related Work：Supporing Selective Undo in a Code Editor[Yoon et.al, 2015]
Problems
● Complex user interfaces
(e.g., separate dialog)
● Might generate meaningless text
7
x = 1.0
Aim to solve these problems
x = 2.0 x = 1.0 x = 3.0 x = 2.03.0
Redo 2.0
11. Previous History Model [Yoon et al, 2015]
Selective undo algorithm
11
Advantage
● Can undo any edits
Disadvantage
● Might generate meaningless text
We extended this model
to solve it
13. History Model：Grouping Separated Edits
13
We use code executions as a delimiter.
x = 1.0
x = 2.0
Insert x = 1.0,
execute
Replace 1.0 with 2.0,
execute
Text Edit GroupsUsers’ Action
Insert x = 1.0
1.0 → 2.0
14. History Model：Exclusive Edits
Example of The Original Model
14
x = 1.0
x = 2.0
Insert x = 1.0,
execute
Replace 1.0 with 2.0,
execute
Undo B
Replace 1.0 with 3.0,
execute
Redo B (undo C)
A. Insert x = 1.0
B. 1.0 → 2.0
C. 2.0 → 1.0 (Undo B)
D. 1.0 → 3.0
E. Insert 2.0
The Original History Model
x = 1.0
Time-series edits
x = 3.0
x = 2.03.0
B and D should not coexist
15. History Model：Exclusive Edits
Example of Our Model
15
x = 1.0
x = 2.0
Insert x = 1.0,
execute
Replace 1.0 with 2.0,
execute
Undo B
Replace 1.0 with 3.0,
execute
Redo B
A. Insert x = 1.0
B. 1.0 → 2.0 C. 1.0 → 3.0
Our History Model
x = 1.0
x = 3.0
x = 2.0
B. 1.0 → 2.0 C. 1.0 → 3.0B. 1.0 → 2.0disable
16. Participants
5 students in our computer science department
Experiment (2 parts)
1. Programming using our tool（about 1 hour）
● To evaluate our tool
● To collect feedbacks
1. Semi-structured interview about edit histories and versioning
operations
● To evaluate our history model
● To compare it with the existing model
Evaluation：Small-Scale User Study
16
17. 1.Evaluation of Our Tool (Procedure)
17
Pre-questionnaires
Programming using
our tool (about 1 hour)
paint program used in the use study
(implement thickness control)
Post-questionnaires
18. Positive
● Agreed that our tool is easy to use.
● UI might be useful for othe applications
○ e.g., composing music
Negative
● Sometimes ignored visual cues
○ undo tools or direct rewrite
● Cluttered visualization.
1.Evaluation of Our Tool (Result)
18
19. 2.Evaluation of Our Model (Procedure)
19
See an edit history See candidates Select appropriate ones
Example of
edit history
Example of candidates
Repeat for 4 histories
20. Candidates selected by participants were all different
E.g., 2 participants：Fixing typo is not a part of an edit history.
3 participants：Fixing typo is a part of an edit history.
Exsiting Model
[Yoon et al.2015]
Generate meaning candidates
Generate also meaningless candidates
Our Model Remove meaningless candidates
Not exactly match the paticipants’
expectations
2.Evaluation of History Model (Result)
20
21. Discussion
Positives
● Satisfied the three requirements
● Got feedback that our tool is easy to use
Negatives
● Need more understandable visualization
● Need to improve the history model
21
Design tradeoff (UI should be simple)
e.g., Use abstract syntax tree information
Out tool is useful for micro-versioning
0:00 - 0:10
Thank you for introduction.
Hello, everyone.
I’m Hiroaki Mikami. Today, I’d talk about our research. It supports programmers’ experimentations. (, Micro-Versioning Tool to Support Experimentation in Exploratory Programming).
0:10 - 1:00
First I’ll describe the target task of our research.
The target task is “micro-versioning”. They are version control operations during exploratory programming.
For example,
please consider (クリック)a programmer implementes a text field.
(クリック) then they switch to a dropdown list,
(クリック) and they changes background color.
If they thinks text field is better than drop down list at this point, (クリック) they reverts to the text field version.
This revert operation is a kind of micro-versioing.
1:00-1:30
We conducted literature survey to clarify requirements for efficient micro-versioning tool.
We examined previous studies, and found that three requirements shown in this slide are needed.
First, tools should have lightweight user interface. Programmers should be able to use tools easily and quickly.
Second, they should visualize micro-versioning operations.
Finally, they should have history models that generate meaningful candidates.
1:30 - 2:00
Now, I’ll describe current micro-versioning methods.
Version control systems, such as Git, can be used for micro-versioning.
They are designed for “large-scale” version control operations.
But they rely on complex user interfaces such as dialogs and menus. They also require users to commit manually.
Because of these problems, version control systems are not suitable for “micro”-versioning.
2:00 - 2:50
Previous studies have shown that linear undo tools, what are called Ctrl-Z, are often used for micro-versioning.
But users cannot undo old edits using these tools. So users sometimes cannot use undo tools.
In addition, these tools don’t provide visual cues. It’s difficult for users to understand undone text before undoing.
Commenting-out is also used for micro-verioning.
But programmers often forget to uncomment-out or comment-out.
So they need to remember content and positions of separated commenting-out.
Because of these problems, undo tools and commenting-out are also not suitable for micro-versioning.
2:50 - 3:30
Some researches have proposed to solve these probolems.
I’ll introduce “Supporting Selective Undo in a Code Editor” which is one of these researches.
This research is for solving limitations of undo tools. It proposed
a new selective undo algoritm, and
a new visualization method of edit histories
This tool doesn’t need manually commit, while Git requires manually commit.
And it can undo any edits. So users can use this tool almost all situations.
3:30 - 4:00
But it remains several problems.
First, it uses complex user interface such as dialogs.
And it might generate meaningless text.
For example, please consider a programmer replaces x from one point zero with two point zero, then revert to one point zero, and finally changes it to three point zero.
If the user redoes two point zero, the tool generates x equals two point zero three point zero. This is inappropriate.
(クリック)Our research aimes to solve these problems, and proposed a novel tool for efficient micro-versioning.
4:00-6:05
Before I explain the proposed tool, I’ll demonstrate our prototype tool.
デモ(マウスは右へ)
This is a user interface of our prototype.
It can be used as a text editor. I’ll edit an HTML in this demonstration.
First, I change the background color of this web page, from green to red (->red),
then click the preview button (click), and our tool updates the web page shown below.
I change the background color again(->blue). and click the preview button (click).
Our tool underlines the text “blue” as an indicator. It means that versioning operations related to “blue” are available.
(click) When I click this marker, our tool shows the list of candidate operations.
In this case, there are two operations, first is to revert the background color to red, and second is to revert it to green.
If I want to revert the background color to green, I click “green”, (click) and our tool conducts the micro-versioning operation.
When the related text has multiple lines, our tool displays vertical lines.
When I click the marker, (click)our tool shows the candidate list.
Our tool also displays changes of the candidate on the scrollbar.
‘id equals age’ in the HTML is referred in the JavaScript.
When I delete the HTML, I should also delete this JavaScript.
But this code is at twelfth line, so it’s not shown in the text editor.
Our tool visualizes changes outside of the current view.
(マウスを左へ)
Next, I’ll describe our tool.
6:05 - 6:25
First, I’d like to talk about how to make the user interface lightweight.
Our tool does not use the separate dialogs and menues.
Users can conduct micro-versioning operations inside the text editor.
6:25 - 7:00
Next, I’ll talk about visual cues of our tool.
Our tool shows the information about micro-versioning operations in the text editor.
For example,
it always shows lines as indicators. These lines represent available versioning operations.
We think this makes it easy for users to notice our tool easily.
Our tool also displays micro-versioning operations on the scrollbar.
Users can see the information outside of the current view. So we think that users can do micro-versioning without mistakes.
7:00 - 7:20
Finally, I’ll talk about the history model used in our tool.
Before describing our model, I’ll introduce the existing selective undo model proposed two thousand fifteen, and I introduced it before.
The model can undo any edits,
but it might generate meaningless text.
(クリック) So, we proposed the extention of this original model to solve this limitation.
I’ll talk about our history model.
7:20-7:50
Our model adds four new features to remove meaningless candidates.
(クリック) In this presentation, I’ll talk about the first, and the second features
7:50-8:25
First, I’ll describe the first feature, grouping separated edits.
Our model uses code executions as delimiters.
For example,
Please consider a user writes x equals one point zero and executes, then changes from one point zero to two point zero and executes.
Our model obtains two edits. First edit is to insert x equals one point zero. And second edit is to replace one point zero with two point zero.
So far, I described grouping separated edits feature.
8:25-9:30
I’ll describe the exclusive edits feature.
First I intorduce an exmpale that the original model generates inappropriate text.
(クリック) A user replaces the value of x from one point zero with two point zero and executes.
(クリック) Then, they undoes the latest edit.
(クリック) The original model saves time-series edits including undo operations.
(クリック) Next, they changes x to three point zero.
(クリック) Finally, they redoes B.
Redoing B is the same as unoding C in the original model.
The original model inserts two point zero, and generates x equals two point zero three point zero. This is inappropriate.
(クリック) This is because B and D coexist. They should not coexist, but the original model can not consider this relation.
9:30-10:30
Next, I’ll describe how our model works in the same situation.
As before, (クリック)a user replaces x from one point zero with two point zero, (クリック) then undoes this edit.
When users undo edits, our model disables the edits instead of adding new edits. Our model does not add new edits when undoing.
(クリック)Next, they changes x to three point zero.
(クリック)If a user redoes B, (クリック)our model first enables B.
(クリック)It also disables C because both B nd C deletes the same text, one point zero.
We call such group of edits as exclusive edits.
Finally, our model generates x equals two point zero.
10:30-11:10
Now, I’ll talk about the small-scale user study we conducted.
We recruited five participants from students of our computer science department.
Our study consists of two parts.
In the first part, participants wrote program by using our tool. This took about one hour.
This part aimed to evaluate our tool and to collect feedbacks.
In the second part, we conducted semi-structured interview about edit histories and versioning operations.
This part aimed to evaluate our history model and to compare it with the existing model.
I’ll describe each part.
11:10-11:45
First, I’ll describe the procedure of first part.
We asked participants about ages and programming experience before programming.
Next, participants wrote program by using our tool.
In this study, we used the paint program shown in this slide.
The participants tried to implement the thickness control feature to this simple paint program.
Finally, they answered questionnaires to evaluate usability of our tool.
11:45-12:20
This slide shows the result of the first part.
There are some positive feedbacks. For example,
Participants agreed that our tool was easy to use.
And they thought that UI of our tool might be useful for other applications, such as composing music.
But there are some negative feedbacks.
Participants sometimes used undo tool or rewrote directly instead of using our tool.
And participants told us that visual information of our tool is sometimes difficult to understand.
When the visualization became complex, participants feld that it was difficult to understand.
12:20-12:50
Next, I’ll describe the procedure of second part.
Participants saw an edit history.
Then they saw candidate versioning operations related to the edit history
This slide shows the examples of edit histories and candidates.
Finally, they selected appropriate versioning operations from candidates. And we asked them about reasons for their selections.
We repeated this procedure for four different histories.
12:50-13:40
This is the summary of the second part result.
First, the existing model could generate meaning candidates. But it also generated meaningless candidates.
Our model could remove such meaningless candidates.
On the other hand, candidates generated by our model and participants’ expectations did not match exactly.
In addition, candidates selected by participants were all different.
For example, two of five participants thought that fixing typo is not a part of an edit history. But other participants thought that it’s a part of an edit history.
As a result, selected candidates were different.
So far, I described the user study we conducted.
13:40-14:25
The result of the user study shows that our tool satisfies three requirements.
And we got feedbacks that our tool was easy to use.
So, we think that our tool is useful for micro-versioing.
However, more understandable visualization is needed.
It might cause design tradeoff because user interface should be simple.
Also, the history model should be improved to match users’ expectations.
We think using abstract syntax trees can improve the history model, for example.
14:25-14:35
I’ll summalize this presentation.
We focused on ‘micro-versioning”. And we proposed the micro-versioning tool shown in this slide.
Thank you for listening.
---
The microphone is not on.
Could you speak more slowly?
We did not deal with it.
The current prototype does not deal with it, but I think it’s important. / but it affects ...
確認したい時
So you’re interested in knowing about …?
場所の特定
Do you mean the first or second slide?
再確認
I’m sorry. I didn’t hear you clearly. Would you repeat the question?
I’m sorry. I didn’t understand your question. Could you rephrase it?
後回しにする
Could we save that until later?
---
We summarized the tool requirements described in previous studies.
Our implementation only supports edit within a single file.
I think it’s difficult to show the multiple files differences within the code editor.
There are cases that AST cannot work well.
For example, the font size of the title and that of the subtitle are related. But there is no relation between two parameters at the AST level. So AST based method fails in this case.
But our approach, grouping by code execution, can deal with this case if the user changes two parameters in sync.
I don't come up with the situation that exclusive edits feature cannot work well, but I think that it cannot work well in a complex situation.
But there are some cases that grouping edit features does not work.
If the reverted program cannot be compiled, some participants did not select as versioning operations. But our model does not consider whether the code can be compiled or not.
So behavior of our model and users’ expectation were different.
![Target Task
Micro-Versioning
2
Version control operations during exploratory programming
Programming with many experimentations [Johannes et.al., 1992]
1.Implement text field
2.Switch to dropdown list
3.Change background color
4.Revert to the text field
Example](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)