4 ms·

I work with self-hosted Gitlab daily and I’ve never thought the UI was bad or slow. In fact, I think it works pretty well. To the other commenters: Do you have

I work with self-hosted Gitlab daily and I’ve never thought the UI was bad or slow. In fact, I think it works pretty well. To the other commenters: Do you have any examples? Also, I’m excited about auto deployment. The less tools one needs to get software shipped, the better.

foepys 9y ago
To see that the UI design is bad at times, take the design of merge requests and issues for example. On Github you can easily see what happens, comments are surrounded by a black border, the name of the comment author and the date are clearly visible and have a different background color from the comment text. Actions like closing and re-opening are distinctly different from comments and are color coded (green -> re-opened, red -> closed, purple -> merged). Emoticons are part of the comment box and don't visually drift into the next one. Gitlab on the other hand separates comments by a thin (1px) light-grey line that is hardly visible on low contrast monitors like TN displays. Closing and re-opening is also displayed as a light-grey icon on a white background. The author's name has the same color as the comment text, with the date being, again, light-grey. Nothing keeps the contents of a comment together, it's all just text on a white background. The emoticons are just floating around the comments, with the same margin to the next comment as to the comment they are belonging to. So you have to know that emoticons are always below a comment. Github's design is far, far superior to Gitlab's design because it allows skimming instead of concentrating on finding where each comment begins and ends.
- jamedjo 9y ago
  This comment reminded me to create issues for reducing clutter on the MR page [0], and expanding multiple resolved discussions [1] [0] https://gitlab.com/gitlab-org/gitlab-ce/issues/34814 https://gitlab.com/gitlab-org/gitlab-ce/issues/34814 [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/34813 https://gitlab.com/gitlab-org/gitlab-ce/issues/34813
- cmatija 9y ago
  We're working on lots of UX improvements. There's a navigation overhaul planned [1], you can also check out a list of all current UX issues with [2]. As always, community feedback is something we always welcome wholeheartedly [3] [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=UX https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
- svesselov 9y ago
  I appreciate the thoughtful and specific feedback. We are working hard to make merge requests and issues intuitive and easy to work with. Many of your observations regarding merge requests are being worked on as part of this issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/33095 https://gitlab.com/gitlab-org/gitlab-ce/issues/33095
  - foepys 9y ago
    I'm really sorry that I cannot help by posting this on your issue tracker but I don't have the time right now to sift through all relevant issues on Gitlab to find out where to post and what already has been posted. My biggest gripe is just that the issue elements (comments, actions, label changes, description edits) are looking too similar for a quick glance. The light-grey font on a white background makes it pretty hard. My suggestion would be to do it a bit like Gihub and to add a black border around stuff, take another background color for actions, and get rid of the grey font and replace it with black throughout.
tscs37 9y ago
I've used Gitlab for personal projects on a small homelab server. I ran the VM with about 1GB of Memory and 1 vCPU (a Core i3 if I recall correctly). Loading a page could load almost instantly but most of the time it did load after 2 or 3 seconds. Gitlab does not work well when resources are scarce, it does require a bit of a beefy server to get fast and reactive, atleast in my experience. I've found Gitea/Gogs to be a product more focused on running something like Gitlab with much less resources.
- snorremd 9y ago
  I think Gitlab recommends a 4GB of memory and suspect this helps with caching and thus page loads. In an organizational context it should not be too hard to throw hardware at the problem. In my organization we run a Gitlab instance with at least 20 active users (70 users total) and quite a lot of repositories and usually it runs quite fast. This is on 8GB of memory and 2 cores. For personal and home use Gitea/Gogs is probably a better choice indeed. As you point out it runs with much fewer resources and as an added bonus it runs as a single go binary which simplifies hosting it tremendously. You could literally just download the binary and run "$ ./gitea web". Gitlab is another beast in that respect, especially if you do not opt for their Omnibus install.
- Karunamon 9y ago
  Part of this is due to Gitlab's being a Rails app. Large Rails applications are many things, but resource efficient isn't one of them. It's just the nature of the language.
  - hardwaresofton 9y ago
    I wish they would rewrite it to something else. Yes, the app is very likely not CPU bound, but I just can't find myself believing in ruby+rails to ever be "fast". However, I'm also very biased against rails so I generally try to ignore the fact that it's a rails app.
snorremd 9y ago
I agree. I too work with a self-hosted Gitlab instance daily, and the UI is neither horribly bad nor horrendously slow. The interaction design and user experience could absolutely use some work, but I feel Gitlab has been moving in the right direction with this. The navigation is still a bit convoluted, but has gotten better. There are still some issues of nested navigation menus and difficult to find pages. As far as page speed goes it has gotten better and they are actively working on this. As long as the rate of improvement is as good as it is I see no reason to switch to another solution. Especially seeing how the community edition is free and satisfies basic developer needs. Gitlab is also the only code repository service which integrates CI jobs and statuses as well as a front-end for a self-hosted docker registry. Absolutely a killer feature!

foepys 9y ago

To see that the UI design is bad at times, take the design of merge requests and issues for example. On Github you can easily see what happens, comments are surrounded by a black border, the name of the comment author and the date are clearly visible and have a different background color from the comment text. Actions like closing and re-opening are distinctly different from comments and are color coded (green -> re-opened, red -> closed, purple -> merged). Emoticons are part of the comment box and don't visually drift into the next one. Gitlab on the other hand separates comments by a thin (1px) light-grey line that is hardly visible on low contrast monitors like TN displays. Closing and re-opening is also displayed as a light-grey icon on a white background. The author's name has the same color as the comment text, with the date being, again, light-grey. Nothing keeps the contents of a comment together, it's all just text on a white background. The emoticons are just floating around the comments, with the same margin to the next comment as to the comment they are belonging to. So you have to know that emoticons are always below a comment. Github's design is far, far superior to Gitlab's design because it allows skimming instead of concentrating on finding where each comment begins and ends.

jamedjo 9y ago
This comment reminded me to create issues for reducing clutter on the MR page [0], and expanding multiple resolved discussions [1] [0] https://gitlab.com/gitlab-org/gitlab-ce/issues/34814 https://gitlab.com/gitlab-org/gitlab-ce/issues/34814 [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/34813 https://gitlab.com/gitlab-org/gitlab-ce/issues/34813
cmatija 9y ago
We're working on lots of UX improvements. There's a navigation overhaul planned [1], you can also check out a list of all current UX issues with [2]. As always, community feedback is something we always welcome wholeheartedly [3] [1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 [2] - https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=UX https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... [3] - https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues
svesselov 9y ago
I appreciate the thoughtful and specific feedback. We are working hard to make merge requests and issues intuitive and easy to work with. Many of your observations regarding merge requests are being worked on as part of this issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/33095 https://gitlab.com/gitlab-org/gitlab-ce/issues/33095
- foepys 9y ago
  I'm really sorry that I cannot help by posting this on your issue tracker but I don't have the time right now to sift through all relevant issues on Gitlab to find out where to post and what already has been posted. My biggest gripe is just that the issue elements (comments, actions, label changes, description edits) are looking too similar for a quick glance. The light-grey font on a white background makes it pretty hard. My suggestion would be to do it a bit like Gihub and to add a black border around stuff, take another background color for actions, and get rid of the grey font and replace it with black throughout.

tscs37 9y ago

I've used Gitlab for personal projects on a small homelab server. I ran the VM with about 1GB of Memory and 1 vCPU (a Core i3 if I recall correctly). Loading a page could load almost instantly but most of the time it did load after 2 or 3 seconds. Gitlab does not work well when resources are scarce, it does require a bit of a beefy server to get fast and reactive, atleast in my experience. I've found Gitea/Gogs to be a product more focused on running something like Gitlab with much less resources.

snorremd 9y ago
I think Gitlab recommends a 4GB of memory and suspect this helps with caching and thus page loads. In an organizational context it should not be too hard to throw hardware at the problem. In my organization we run a Gitlab instance with at least 20 active users (70 users total) and quite a lot of repositories and usually it runs quite fast. This is on 8GB of memory and 2 cores. For personal and home use Gitea/Gogs is probably a better choice indeed. As you point out it runs with much fewer resources and as an added bonus it runs as a single go binary which simplifies hosting it tremendously. You could literally just download the binary and run "$ ./gitea web". Gitlab is another beast in that respect, especially if you do not opt for their Omnibus install.
Karunamon 9y ago
Part of this is due to Gitlab's being a Rails app. Large Rails applications are many things, but resource efficient isn't one of them. It's just the nature of the language.
- hardwaresofton 9y ago
  I wish they would rewrite it to something else. Yes, the app is very likely not CPU bound, but I just can't find myself believing in ruby+rails to ever be "fast". However, I'm also very biased against rails so I generally try to ignore the fact that it's a rails app.

snorremd 9y ago

I agree. I too work with a self-hosted Gitlab instance daily, and the UI is neither horribly bad nor horrendously slow. The interaction design and user experience could absolutely use some work, but I feel Gitlab has been moving in the right direction with this. The navigation is still a bit convoluted, but has gotten better. There are still some issues of nested navigation menus and difficult to find pages. As far as page speed goes it has gotten better and they are actively working on this. As long as the rate of improvement is as good as it is I see no reason to switch to another solution. Especially seeing how the community edition is free and satisfies basic developer needs. Gitlab is also the only code repository service which integrates CI jobs and statuses as well as a front-end for a self-hosted docker registry. Absolutely a killer feature!