UI elements moving across the screen considered harmful

[mvdan]

When I click on "update", the repo item moves to a separate section. This has two inconvenients:

• It is racy. If I click these buttons faster than they can sync (i.e. multiple running at a time), sometimes they don't move properly and stay in the "to update" section.
• It makes reading worse. I can't read commits properly if text is jumping up and down (e.g. if I click "update" on the first and go read the second)

To fix both, I instead suggest that each element is changed somehow, instead of moved around. For example, changing "Update" by "Done" or simply nothing. Colours or other styling could be added to make the difference stand out more.

[dmitshur]

I agree it feels not great. I'll just share some notes.

I tend to try to update packages from bottom, going up. That way things don't move around.

GPS Updates tab is heavily inspired by Apple's App Store on macOS. Its design suffers from the same issue, however, it's less noticeable for a few reasons. There are generally fewer updates for macOS apps than there are for Go packages. They tend to be slower and you can update many packages before the first one completes. And finally, there's an extra delay between an update completing and it moving to the bottom.

I kinda like the general idea of moving completed updates out of the way rather than having them intertwined with the rest of available updates... But yeah. So I'm not sure what to do here.

[dmitshur]

One really interesting idea in this space IMO is how Chrome tackles this problem.

See the following 15 second video:

Basically, they try to avoid moving things unexpectedly as long as your mouse cursor is hoving over the tabs. As soon as you move mouse elsewhere, that's when it tries to shuffle things around.

It would require tracking the mouse on the frontend and doing some experimentation, but if done well, this might be a good idea. There's also a high chance it won't be a good idea. It's definitely going to be complicated to implement.

[dmitshur]

Ok, I can't believe I didn't notice it until now, but the logic for moving a completed update down was wrong (not what I had in mind):

Go-Package-Store/cmd/Go-Package-Store/updater.go

Lines 70 to 79 in 15be84c

	// Move it down the OrderedList towards all other updated.
	{
	var i, j int
	for ; c.pipeline.GoPackageList.OrderedList[i].Repo.Root != updateRequest.root; i++ { // i is the current package about to be updated.
	}
	for j = len(c.pipeline.GoPackageList.OrderedList) - 1; c.pipeline.GoPackageList.OrderedList[j].Updated; j-- { // j is the last not-updated package.
	}
	c.pipeline.GoPackageList.OrderedList[i], c.pipeline.GoPackageList.OrderedList[j] =
	c.pipeline.GoPackageList.OrderedList[j], c.pipeline.GoPackageList.OrderedList[i]
	}

Instead of taking the updated item and moving it down, it swapped that item with the bottom-most available update. So the update you'd expect to be next was preceded by some update from the bottom.

Fixing that is going to help this issue very little, but nonetheless, it's something.

[dmitshur]

I tend to try to update packages from bottom, going up. That way things don't move around.

After doing this enough times, I came up with another idea that I think I'd like to try next. It's not a perfect solution (meaning it's an improvement in some ways, but worse in other ways), but it seems like a net win, and I want to try it.

The idea is to place the "Installed Updates" section on top, above all the available updates:

--- installed package ---
    updated package 1
    updated package 2
    updated package 3

--- available updates + installing updates ---
    available update 4
    available update 5
    available update 6

That way, when you press "update" going from top to bottom, there's a lot less drastic movement, as the package smoothly transitions from the top of second section to the bottom of the first section:

--- installed package ---
    updated package 1
    updated package 2
    updated package 3
    updated package 4

--- available updates + installing updates ---
    available update 5
    available update 6

I've implemented it locally and will do some testing myself the next few days/weeks. If I'm happy with it, I'll proceed forward.

[dmitshur]

I've pushed the code to a recently-updated-on-top branch and opened PR #94, for anyone who wants to try it.

[mvdan]

Thanks! These days I've moved most of my software to modules, so I've stopped using this tool ~weekly for now. I no longer hoard random stuff in my GOPATH, so my workflow has changed a bit.

I presume that a tool to update a module's direct dependencies (seeing what new versions are available and their changelogs/commits) could be interesting, but is less of a problem for me. Generally, updating patch versions is a no-brainer, and updating major/minor versions isn't something that happens often.

I'm already following #92, so I'll probably give the tool another try once that's ready :)