Element Selection / Deselection

[mircealungu]

A nicer unification of element selection /deselection would still be nice:

• let me single-click select also a folder (this has been discussed before)
  • extra benefit; on a very large system, e.g. Typescript, me clicking on the 'tests' to hide it, does not open it (which is very slow...)
  • use double-click for zoom-in
• also, deselect whatever is currently selected when i click on the canvas outside of any visual element

[joglr]

We should make a test release that implement this and test it with users.

[joglr]

@mircealungu According to the survey, the most loved feature is being able to zoom in. Therefore, I would argue "hiding" it behind a double click would not be productive. What do you guys think?

[mircealungu]

Eheh. Far away from me to take away from the people the most loved feature :)

How does your Operating System work? Does it not select a folder on click and open on double click? Does the double click seem like a hidden feature in that case? To me this is so intuitive and ingrained, that I still have a bit of a surprise with the automatic zoom with GT.

But it's also true that in the case of the OS we've all had to learn the meaning of double click. Do you think that people won't find it in the case of GT? In that case we could add a little note in the Detail panel when something is selected?

One extra benefit for this is that when I want to hide a folder, I don't have to zoom in, filter, and then zoom out again. The select and filter without zoom in and out would be more natural.

What do you think?

[joglr]

Indeed, double click is a thing in the OS.

I found this interesting discussion on double click on the web.

https://ux.stackexchange.com/questions/7400/should-double-click-be-avoided-in-web-applications

In our case, I would argue Git Truck is not your usual web page, and in these types of applications, double click is more common, think Figma, Google Maps, Photoshop etc. I don't really know what kind of applications to compare Git Truck to, but the most important thing would be to implement the behaviour that the user expects of this kind of application.

[mircealungu]

Interesting discussion, but you're not the average web app if I may say :)

As per Jakob Nielsen's Heuristics, the UI should be consistent with itself. In this case, what I would start from is the following:

• When I select a file in your UI it is selected, and I can see the details tab; this is in line with other UIs where you are manipulating objects; the file is an UI object; I select it; I see\ details about the object; I click/select it for seeing details about the selection; I double click it... I executed the primary action on it (e.g. open it in the VSCode... BTW, this would actually be cool!)
• When I select a folder, I zoom in and I also see the details tab; so the folder behaves like a link that "opens a new page" in some sense; and after it was a link, then it is also an object, that is now selected, and I can see the details; but folders are now both links and objects and I think this is not consistent.

I would argue that if both files and folders are objects in the UI, then the UI would be consistent with itself: a UI object, when selected shows me the details that are known about it. And the secondary actions possible, all in the detail tab. You could make it clear that zooming is a possible secondary action by adding it explicitly in the detail panel.

I think the problem is that currently we don't have sufficiently powerful details panels, such that the most interesting thing we can do with the selected folder is to zoom in onto it. And I think the animation is awesome too... But then think about adding new detail views, e.g. one that shows the most relevant history commits. In that case, If I want to see the commit history of a given object without zooming in that would not be possible. This is not that bad for small projects where zoom-in/out is fast, and you could argue that I could quickly zoom out. OTOH, for large projects, these are quite slow operations... so if they can be avoided I think they should.

[mircealungu]

One more observation: In the image below, I have finally succeeded in selecting the artword folder and seeing details about it in the context of overall view. But do you know how I did that? I selected it, zoomed in, then zoomed out, and then I was finally left with the selection of the folder in the bigger context. But this is too convoluted a process.

[mircealungu]

Hmm... and finally what we could discuss is always giving the user an option that's not double click. In this case, we can add a "zoom in" link on the details panel just as we have "open" for a file. In this way the double-click can be avoided, or can be left only for the expert users.

[joglr]

Very interesting observations! In addition to double click, I just thought about the other mouse button: You could experiment with right click showing a context menu

• Hide this kind of file
• Hide this file / folder
• Show details about the file / folder
• Zoom into file / folder
• Open in editor
• ...Other actions?

[mircealungu]

Offering a contextual menu on alternate mouse click is the next level :)

[mircealungu]

@dawidwoz - I was reminded of this as I was testing your Comments detail tab! The fact that I want to select an element to see its comment history and I automatically zoom is frustrating...

[joglr]

@dawidwoz @mircealungu Unrelated to the issue - I was wondering why you are working on a separate repo and npm name - you are welcome to contribute directly to the main branch and publish versions - maybe to a beta tag for starters, but I find it a bit confusing with the separation? What are your thoughts on this?

[dawidwoz]

@joglr We use a new npm name and fork repo due to various reasons:

• I want a one-line code to run to use my version of the product. It is especially important for non-developers who just want to "run and forget".
• One point of source for my code where I am the repo owner. It is important as I need approval from my employer to be able to use it on our work repos.
• Tag system to document my releases.
• Avoid problems if someone else would like to add some code to the main repo.
• Avoid problems while merging temporary fixes to deal with the scalability issues.
• Skip code style-related discussions so I can release/fix quickly.

The npm name is git-truck-beta which suggests the version there is not a production version. I also corrected README to not confuse it with the base product.

I'm going to merge my final changes to the base repo when they are ready.

[joglr]

That kinda makes sense. I understand that you have your reasons.

Here are some of my thoughts on your reasoning:

• I want a one-line code to run to use my version of the product. It is especially important for non-developers who just want to "run and forget".

npx git-truck@beta

• One point of source for my code where I am the repo owner. It is important as I need approval from my employer to be able to use it on our work repos.

Isn't this just a false sense of security for your employer, since you are not the original author of the rest of the code?

• Tag system to document my releases.

You could also "own" the [email protected] (tagged to git-truck@beta release, since you are the only person contributing major changes (I only think it is I who am interested in contributing, and I am only working on non-functional adjustments.

• Avoid problems if someone else would like to add some code to the main repo.
• Skip code style-related discussions so I can release/fix quickly.

Makes sense.

The npm name is git-truck-beta which suggests the version there is not a production version. I also corrected README to not confuse it with the base product.

Solved by using prerelease or beta channels.

I'm going to merge my final changes to the base repo when they are ready.

Alright, then we will just have some issues with versioning, since you are creating versions tags that already exist in the repo, but we will deal with that when the time comes.

[joglr]

@dawidwoz - I was reminded of this as I was testing your Comments detail tab! The fact that I want to select an element to see its comment history and I automatically zoom is frustrating...

Is this something you will be working on @dawidwoz ?

[mircealungu]

@joglr - David just showed me his demo today, and he has the click-to-select implemented for the treemap view. Is your solution something that we should back port to the main trunk Dawid or should a more unified solution for both the views be found?

[joglr]

@joglr - David just showed me his demo today, and he has the click-to-select implemented for the treemap view. Is your solution something that we should back port to the main trunk Dawid or should a more unified solution for both the views be found?

I'm interested in checking this out. Will see how work and consider whether it is possible to use for the circle packing view as well.

[dawidwoz]

When I finish my development, I'll present it to the GitTruck team and gather the last feedback iteration. Then, we can also talk about the technical details.