search

fork-dev / TrackerWin

Bug and issue tracker for Fork for Windows
459 stars 10 forks source link

[Discussion]: New sidebar layout #739

Open ghost opened 4 years ago

ghost commented 4 years ago

I don't like the new sidebar design, it inserts extra tabs and clicks, and hides information.

I would like to be able to downgrade to the previous Fork version and prevent Fork from updating itself.

The new changes break my workflow, and makes Fork unusable.

ademlabs commented 4 years ago

I agree, also some labels seem larger (Local Changes, All Commits, Local Branches) in the sidebar and doesn't look proportional. The previous UI was almost perfect. I'd also like a downgrade option or a toggle option to use the previous layout.

SnapJag commented 4 years ago

I actually like the new design. I work with a lot of devs where we have a lot of private branches in origin and this make organizing/finding those much simpler.

If you had it so you could do either had a Layout option, then you could satisfy both, but it would create two choice paths that may not be sustainable.

I will admit that it puts more clicks in, but to pull from origin and then also delete from local makes managing much easier.

fred172 commented 4 years ago

Agreed, it's very frustrating not to be able to see everything you're working with! Please either revert this, or make it optional. As it is, it really doesn't work for me.

DanPristupov commented 4 years ago

I just sent this in an email, but I think it can also be shared there.

Repositories (only) grow. Tens of local branches, hundreds of remote branches and thousands of tags within same scrollview. Also there are stashes (~200 in my case) and submodules. We all have a mess on sidebars.

Now with the new layout it's more logical and structured. It just requires one more click (BTW, same if you had your sidebar collapsed previously).

It takes some time to gain new muscle memory though.

fred172 commented 4 years ago

I respectfully disagree. It’s a big step backwards for my normal workflow and robs me of the overview I normal have of our team projects. I don’t mind an alternative flow, as long as it were optional. Your repositories may grow, but mine do not.

DanPristupov commented 4 years ago

Could we be a bit more calm there? I'd like to hear more feedback and use case descriptions. No need to start the like/dislike war and send us similar messages using all possible channels.

Regarding the problem. On our side, it's difficult question and We'd like to hear more opinions. Currently less than 0.5% of users dislike this feature (but the ones who do, do it a lot 🙂).

Your repositories may grow, but mine do not.

OK. We also receive other feedbacks from users who work with repositories with 25000 new commits monthly.

Each 'alternative flow' complicates source code a lot which slows down development and brings bugs and problem in the future.

fred172 commented 4 years ago

My apologies, I didn’t mean any offense (and I certainly didn’t think I was causing any). Like I said, I can the appeal for the feature. However, it’s not strictly a functionality upgrade, but rather a swap, because you lose the ability to view everything at once.

Our current workflow is that users create feature branches for specific code applications and then merge everything back to the main branch. As such, we really only have 2 main branches (master and development) and whatever feature branches people are currently working on. That’s 5 branches at most, which isn’t something we’d need filters for. In the old situation, I could view at a glance what the current situation was. With the new view, I need to keep switching back and forth between tabs a lot.

I don’t mind the feature at all. It’s great. I won’t stop using Fork if the old view isn’t returned either. But I really, really, really do miss it.

Tenebrous commented 4 years ago

I would actually prefer a mixture - the option to pin a tab which would make it appear inline as before, plus of course the ability to unpin it again.

In the options ("..." menu) for a tab, you'd have a "pin" option - that would then show the contents of that tab in the main list.

odalet commented 4 years ago

@DanPristupov

I must admit, I too miss the all-in-one treeview UI. It may be a matter of taste or my brain muscles not being exercised enough yet, but still. I don't mind - remember, this only applies to my specific use cases - having stashes and submodules separated from the main tree view as I don't use them much. However, in my day to day job I'm regularly watching/correcting over my co-workers use of Git:

Hence, I really like being able to navigate quickly from remote branches to local ones to tags...

I suppose it may be some more work (and bloat the software with functionality you'd rather not maintain) but having a flag in preferences allowing to choose all-in-one vs tabs UI may satisfy everybody.

Anyway, Fork is still my preferred Git UI!

PS: I'd say my workflow is similar to @fred172 above.

ademlabs commented 4 years ago

I would actually prefer a mixture - the option to pin a tab which would make it appear inline as before, plus of course the ability to unpin it again.

In the options ("..." menu) for a tab, you'd have a "pin" option - that would then show the contents of that tab in the main list.

I think this is an excellent alternative. With the current new layout, it would be awesome to just click on the buttons and instead of switching views it just adds it to the current one, with an option in the menu for toggling the behaviour (pinning vs switching).

To be honest, adopting the approach of "we know what's best for the users" isn't really great. You should at least let the users have a choice by either using a previous version or a toggle feature. Currently it's really hard to revert to the 1.47 version.

JulienMaille commented 4 years ago

Reading user comments it seems some would like a dockwindow approach ie. having the option to stack them or tab them.

Gama11 commented 4 years ago

I strongly dislike the new UI so far as well. Compared to before, there's a looot of wasted vertical space for simple repos especially:

https://i.imgur.com/NlmEhjL.png

elendil-software commented 4 years ago

I also dislike the new sidebar. We have similar workflow to @odalet https://github.com/ForkIssues/TrackerWin/issues/739#issuecomment-615886676 and @fred172 https://github.com/ForkIssues/TrackerWin/issues/739#issuecomment-615849901 .

I usually have 2-5 local branches, between 10-20 remote branches. Never more. Branches are deleted when merged to Master.

Reading user comments it seems some would like a dockwindow approach ie. having the option to stack them or tab them.

That would me great.

DanPristupov commented 4 years ago

Alright, this is a great discussion for all of us. We found out that some people prefer the old style sidebar, some people think the new layout is a good start but needs improvements, some people simply like the new one. To be fair, we received much positive feedback by email, but it's not here.

To be honest, adopting the approach of "we know what's best for the users" isn't really great.

We don't. We just didn't expect that change will be a huge problem for some users.

Regarding the behaviour:

Stanzilla commented 4 years ago

Well it should just be an option, imo.

ikrima commented 4 years ago

Meta-feedback: I'd gently request high prioritizing the ability to turn off auto-updates, especially for paying users.

I'd say it's fair if you state you're only providing support for the latest version; but forced updates on dev software, especially core dev software, is imho VeryWrong™

Also, while I prefer the old style and found this update jarring, I'd also like to say some of the rage/entitlement in this thread is ridiculous. Git-fork is still pretty amazing

nox-xou commented 4 years ago

The old sidebar is better. I can filter anything. you may be improve filter box, like chrome DevTools filter.

For example: tag:xxx, branch:yyyy for type filter OR -bugfix to exclude from list.

DanPristupov commented 4 years ago

Summary:

odalet commented 4 years ago

Thanks for the quick reaction! Witnessing here real care for your users base. Keep on the good job!

I just want here to moderate the "Hey I'm a paying user, so I'm entitled to...". For my part, I registered a license more in a spirit of supporting indie dev than in order to have rights on the product. I just payed a few bucks in acknowledgement of the hard work he put into the product. It's been now more than 2 years since I've been using Fork as my exclusive Git UI both at work and home. I find it simply right to retribute him if I can. God, I've spent more money on Microsoft products and didn't complain...

Nothing in the license agreement gives the paying users any right to demand modifications of the software... I'm really pleased @DanPristupov heard us, but that's entirely up to his judgement.

damianh commented 4 years ago

@DanPristupov Just got the update and I took the time to visit the tracker to log an issue but I see it's been discussed and a path mapped forward. Thanks for responding to the feedback with speed!

We will start working on the 'stable' and 'develop' update channels. Usually updates from the 'stable' channel will be released only when we're sure everything is stable and works as expected.

I was going to constructively suggest something like this. In addition to the channels is to do these as a feature toggle, do some A/B testing and get numbers regarding opt in / stay / revert with data as to number of branches/tag/submodules catering for the people above who have few vs many of these items. This will require some tracking which has some privacy implications so perhaps only do this on the Dev channel as a requirement for participating. Also allow us to run stable and dev channels side by side.

Cheers!

fourofspades commented 4 years ago

"Hey I'm a paying user, so I'm entitled to...".

The opposite is however true. If you haven't paid for Fork, you don't really have the right to ask for anything.

It's a shame that Fork isn't really prioritising paying customers. It's not really enterprise ready, not until it supports Enterprise GIT, rather than open-source GIT.

damianh commented 4 years ago

It's not really enterprise ready, not until it supports Enterprise GIT, rather than open-source GIT.

@fourofspades Curious, what exactly is "Enterprise GIT"?

fourofspades commented 4 years ago

Bitbucket Server, Github Enterprise, DevOps Server, anything that's on-premises, and not cloudwashed.

odalet commented 4 years ago

@fourofspades what kind of integration or particular support would you like to see with those? I'm using Fork for 2 years mainly against an on-prem Bitbucket server, and apart from the fact that it does not display a Bitbucket icon, it works perfectly well!

fourofspades commented 4 years ago

Creating pull requests, and some of the other integrations that enterprise git systems have would be a good starting point. Our in house development team are used to these kind of things, and going back to doing things the non joined up way, it seems like a backward step. We have development workflows that integrate much tighter than cloud systems like bitbucket/GitHub.

Don't get me wrong, I really like fork, but it's not enterprise ready until it fully supports enterprise git and can be a drop in replacement for GitHub desktop and sourcetree with all the integrations.

odalet commented 4 years ago

OK, I understand your point. As it happens, these are not use cases of ours, but I get it can be for you.

damianh commented 4 years ago

Ok, strictly speaking these things aren't git but services around version control. I know other git clients have tighter integration with such services for example. As a pure git (gui) client, git-fork works just fine wherever your git repository is hosted, on-prem, cloud or otherwise.

However please consider adding a seperate feature request issue as such is off-topic for this one. (@DanPristupov smells like some addon $$ potential for enterprises 😉).

fred172 commented 4 years ago

I'd also like to say some of the rage/entitlement in this thread is ridiculous.

Feedback is rage/entitlement now? Apparently there's been a misunderstanding, so let me rephrase:

DanPristupov commented 4 years ago

Since Monday we started getting emails asking to return the new tabs. Being on our place is difficult 🙂.

Anyway right now we are working on a solution which will allow the sidebar sections to be configurable. This should make both sides happy and also bring some other improvements in the future. It will take a bit more time than I expected, but that's fine.

It's a shame that Fork isn't really prioritising paying customers.

Well, we prioritise good use case descriptions and discussions.

Regarding making Pull Requests in private BitBucket instance. A corresponding issue on the issue tracker already exists (https://github.com/ForkIssues/TrackerWin/issues/655) and there aren't many 'likes' or proposals. It's the best place to talk about this feature.

SnapJag commented 4 years ago

Dan, thanks for what you do. From my perspective, quality is important. Do take the time you need as I'm sure you have your hands full.

I don't understand why there is a "don't prioritize for paying customers" POV. The whole idea of paying was simply to "thank you for your time" not to dictate your priorities.

I appreciate your methods of implementation, responses to questions, concerns, and bug fixes. All around, appreciate your time and effort.

I'm looking forward to the "side-bar as an option". I could use it both ways at times. I have a lot of branches and the new style will organize my content much more neatly. My perspective.

Glad to collaborate on such a great product that truly makes my work and time much more efficient.

Lonli-Lokli commented 4 years ago

@DanPristupov I propose to add feature to show settings usage per user (in a fashion way, with user acknowledgment about it), so you will know what options (theme/layout/etc) are used by most of users.