7 ms·

The performance improvements are very noticeable : general page load times, pushing code to gitlab is as fast as github now and the commit messages load insanel

The performance improvements are very noticeable : general page load times, pushing code to gitlab is as fast as github now and the commit messages load insanely fast, compared to a few months ago where loading commit messages in the UI used to take at least a couple of seconds. I don't follow gitlab development too closely, but they seem to have focused a lot on improving cache performance. But one change that I did not like was the the removal of the side panel which could be pinned. Navigation required fewer steps, but now an extra click is required to bring up the options.

victorwu 10y ago
Thanks for the feedback regarding the sidebar navigation! Here's the issue that we used to chat extensively about it and came to our current design here in 9.0: https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 There's lots of discussion there. We went with a design that leans on getting out of your way and recovers some screen real-estate. We do recognize the one additional click required though. And we are actively listening to feedback and will continue to iterate. We're working hard to improve usability and navigation in general. In addition to this sidebar change, we've made many nav updates: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348 https://gitlab.com/gitlab-org/gitlab-ce/issues/26348.
- tokenizerrr 10y ago
  Trading usability for screen real-estate? Sounds like your designers have gone off the deep end and fail to realize that Gitlab is a productivity tool, not an art piece.
  - connorshea 10y ago
    I'd argue that extra screen real estate for the content that matters often lends itself toward better UX, but any specific suggestions for improvements would be appreciated. :)
  - thoughtpalette 10y ago
    That's quite a bold statement from an armchair UX designer. They obviously have reasoning and supporting data, maybe you're in the minority of users who've found that useful?
  - victorwu 10y ago
    Thanks for the feedback! In this iteration, we think recovering more space helps users focus on content, and allows them to see more content at once. Definitely we recognize the tradeoff of additional clicks and discoverability as a result. We are definitely focused on usability, and navigation in general. We don't claim to know all the right answers all the time. So we are iterating with each release, and working hard doing user research as well to inform our decisions. You can see some of our recent work regarding nav here: https://gitlab.com/gitlab-org/ux-research/issues/3 https://gitlab.com/gitlab-org/ux-research/issues/3. Thanks.
- tracker1 10y ago
  The application I'm working on, I went with a 3-state navigation... null (default), true (open) or false (closed) ... at large screen sizes null is a soft open, smaller soft closed... toggling goes between the respective hard state and the null/default state. At sm-medium, it's an overlay, at phone/xs it takes over the screen. I find that this is more intuative to use than a hard on/off only.
- wjoe 10y ago
  I agree with the parent about the sidebar. I already disliked the change to make it hidden by default with the pin option since it was a bit inconsistent for me, but it at least gave the option for best of both worlds. Ideally this should be an option. I get that 'modern UX' is all about more screen space and whatnot, but I'm not a fan of that trend personally. It seems that all that's been gained from that change is more empty space at the side of pages. Personally, I'm the type that would rather have more information and convenience on the page than extra space. Would it be that hard to add an option to enable the side bar if people want it? That's what I like about GitLab, that it's very configurable.
sytse 10y ago
Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk/view https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZVZiRXFLOWNVQTA/view?usp=sharing https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTzg3NFN4UXU3Qmc/view?usp=sharing https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTz... Git access will be improved now that we have Gitaly as part of this release. In GitLab 9.1 we want to move git access from the application server to the file server. That should greatly reduce the latency.
- tokenizerrr 10y ago
  Can't access any of those links, just get a login prompt.
  - zegerjan 10y ago
    That is the internal one, Sid meant to link to the public monitoring, located at http://monitor.gitlab.net/ http://monitor.gitlab.net/. It doesn't have the daily overview dashboard, but the fleet overview might be an indicator too (http://monitor.gitlab.net/dashboard/db/fleet-overview http://monitor.gitlab.net/dashboard/db/fleet-overview).
  - sytse 10y ago
    Sorry about that, we've replaced the links with screenshots. The problem is that we can't measure Unicorn timings with Prometheus since it is multi-process. Our Prometheus team is working to fix this for everyone.
- superplussed 10y ago
  I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.
victorwu 10y ago
The ongoing discussion regarding the sidebar/navigation is here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835 https://gitlab.com/gitlab-org/gitlab-ce/issues/29835. Thanks again for the feedback.
- buxtehude 10y ago
  What's sad is that this isn't the first time GitLab UX/UI peeps have tried to remove the sidebar. 9 months ago we went through a very similar version of this: https://gitlab.com/gitlab-org/gitlab-ce/issues/18542 https://gitlab.com/gitlab-org/gitlab-ce/issues/18542 Can we just all agree to keep the damn sidebar available - if UX wants to remove it, fine, as long as users have the ability to easily permanently pin it back open if they wish to do so. By now GitLab UX should realize that enough developers find great utility in that sidebar.
  - allover 10y ago
    Perhaps the 'sad'/'damn sidebar'/'should realize' passive-aggressive entitlement doesn't help?
    - stonogo 10y ago
      Yes, I'm sure Gitlab's engineers make technical decisions based on this guy's tone in Hacker News comments.
      - zachsnow 10y ago
        Maybe they just feel bad when they are going to sleep.
      - allover 10y ago
        His tone almost guarantees his complaint won't be take seriously. Also, just being nice is a generally good principle.
  - buxtehude 10y ago
deleted 10y ago
[deleted]

victorwu 10y ago

Thanks for the feedback regarding the sidebar navigation! Here's the issue that we used to chat extensively about it and came to our current design here in 9.0: https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 There's lots of discussion there. We went with a design that leans on getting out of your way and recovers some screen real-estate. We do recognize the one additional click required though. And we are actively listening to feedback and will continue to iterate. We're working hard to improve usability and navigation in general. In addition to this sidebar change, we've made many nav updates: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348 https://gitlab.com/gitlab-org/gitlab-ce/issues/26348.

tokenizerrr 10y ago
Trading usability for screen real-estate? Sounds like your designers have gone off the deep end and fail to realize that Gitlab is a productivity tool, not an art piece.
- connorshea 10y ago
  I'd argue that extra screen real estate for the content that matters often lends itself toward better UX, but any specific suggestions for improvements would be appreciated. :)
- thoughtpalette 10y ago
  That's quite a bold statement from an armchair UX designer. They obviously have reasoning and supporting data, maybe you're in the minority of users who've found that useful?
- victorwu 10y ago
  Thanks for the feedback! In this iteration, we think recovering more space helps users focus on content, and allows them to see more content at once. Definitely we recognize the tradeoff of additional clicks and discoverability as a result. We are definitely focused on usability, and navigation in general. We don't claim to know all the right answers all the time. So we are iterating with each release, and working hard doing user research as well to inform our decisions. You can see some of our recent work regarding nav here: https://gitlab.com/gitlab-org/ux-research/issues/3 https://gitlab.com/gitlab-org/ux-research/issues/3. Thanks.
tracker1 10y ago
The application I'm working on, I went with a 3-state navigation... null (default), true (open) or false (closed) ... at large screen sizes null is a soft open, smaller soft closed... toggling goes between the respective hard state and the null/default state. At sm-medium, it's an overlay, at phone/xs it takes over the screen. I find that this is more intuative to use than a hard on/off only.
wjoe 10y ago
I agree with the parent about the sidebar. I already disliked the change to make it hidden by default with the pin option since it was a bit inconsistent for me, but it at least gave the option for best of both worlds. Ideally this should be an option. I get that 'modern UX' is all about more screen space and whatnot, but I'm not a fan of that trend personally. It seems that all that's been gained from that change is more empty space at the side of pages. Personally, I'm the type that would rather have more information and convenience on the page than extra space. Would it be that hard to add an option to enable the side bar if people want it? That's what I like about GitLab, that it's very configurable.

sytse 10y ago

Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk/view https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZVZiRXFLOWNVQTA/view?usp=sharing https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTzg3NFN4UXU3Qmc/view?usp=sharing https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTz... Git access will be improved now that we have Gitaly as part of this release. In GitLab 9.1 we want to move git access from the application server to the file server. That should greatly reduce the latency.

tokenizerrr 10y ago
Can't access any of those links, just get a login prompt.
- zegerjan 10y ago
  That is the internal one, Sid meant to link to the public monitoring, located at http://monitor.gitlab.net/ http://monitor.gitlab.net/. It doesn't have the daily overview dashboard, but the fleet overview might be an indicator too (http://monitor.gitlab.net/dashboard/db/fleet-overview http://monitor.gitlab.net/dashboard/db/fleet-overview).
- sytse 10y ago
  Sorry about that, we've replaced the links with screenshots. The problem is that we can't measure Unicorn timings with Prometheus since it is multi-process. Our Prometheus team is working to fix this for everyone.
superplussed 10y ago
I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.

victorwu 10y ago

The ongoing discussion regarding the sidebar/navigation is here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835 https://gitlab.com/gitlab-org/gitlab-ce/issues/29835. Thanks again for the feedback.

buxtehude 10y ago
What's sad is that this isn't the first time GitLab UX/UI peeps have tried to remove the sidebar. 9 months ago we went through a very similar version of this: https://gitlab.com/gitlab-org/gitlab-ce/issues/18542 https://gitlab.com/gitlab-org/gitlab-ce/issues/18542 Can we just all agree to keep the damn sidebar available - if UX wants to remove it, fine, as long as users have the ability to easily permanently pin it back open if they wish to do so. By now GitLab UX should realize that enough developers find great utility in that sidebar.
- allover 10y ago
  Perhaps the 'sad'/'damn sidebar'/'should realize' passive-aggressive entitlement doesn't help?
  - stonogo 10y ago
    Yes, I'm sure Gitlab's engineers make technical decisions based on this guy's tone in Hacker News comments.
    - zachsnow 10y ago
      Maybe they just feel bad when they are going to sleep.
    - allover 10y ago
      His tone almost guarantees his complaint won't be take seriously. Also, just being nice is a generally good principle.
- buxtehude 10y ago

deleted 10y ago

[deleted]