5 ms·

> Zach Holman made a point, way back in 2012, that they intentionally hide UI features to preserve simplicity and trust in their design. Ehhhhh not quite. The

by holman 8y ago

> Zach Holman made a point, way back in 2012, that they intentionally hide UI features to preserve simplicity and trust in their design. Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. I think that's quite a bit different from what's being discussed in this thread. The last few years in particular GitLab's been adding a lot more features across the whole spectrum of development (CI, packaging, monitoring, and so on), whereas GitHub has been mostly content to refine the existing platform. I don't even think it's really a question of simplicity (or at least not to the extent of what I was trying to mention in my talk from six years ago) — it's more of a matter of expanding into very large holes that the version control industry hasn't really tackled very much before (take a look at Bitbucket, or even some of the open source clones, which all kind of stick in the version-control-only perspective). > I would say it's just a different set of tradeoff balancing. That I'd probably agree with, though. I think GitLab's thoughts on what's helpful to a developer is much broader than GitHub's narrower definition. Each are making their bets with that, so it's more a matter of how you view your own problems and the future of these kinds of problems and all that. :)

rad_gruchalski 8y ago
> Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. Every time I go back to gitlab I’m lost in all those drop downs and buttons it shows me. Just nodding to you statement.
Shank 8y ago
> Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. Oof. Yeah. I understand what you meant -- I guess I wasn't specific enough in what I said. I didn't mention it anywhere in that comment, but I was thinking about their issue page as the prime example. See here: https://gitlab.com/gitlab-com/www-gitlab-com/issues/2231 https://gitlab.com/gitlab-com/www-gitlab-com/issues/2231 I'd say that 1% features shown to anyone on this page are things like confidentiality, time tracking, weight, lock state, and reference. Most of them are in the default position, and reference appears marginally redundant. I didn't execute my example too well, but I think this notion does carry around the rest of the app. I guess I painted too broadly if you had to catch me. Sorry, Zach!
bausshf 8y ago
The simple solution would have been configurations for those 1% who wants them. Either at repository/organization level or user level. That way you can get the best of both worlds. I might be wrong, but that's how I'd see it.

by holman 8y ago

rad_gruchalski 8y ago

Shank 8y ago

> Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. Oof. Yeah. I understand what you meant -- I guess I wasn't specific enough in what I said. I didn't mention it anywhere in that comment, but I was thinking about their issue page as the prime example. See here: https://gitlab.com/gitlab-com/www-gitlab-com/issues/2231 https://gitlab.com/gitlab-com/www-gitlab-com/issues/2231 I'd say that 1% features shown to anyone on this page are things like confidentiality, time tracking, weight, lock state, and reference. Most of them are in the default position, and reference appears marginally redundant. I didn't execute my example too well, but I think this notion does carry around the rest of the app. I guess I painted too broadly if you had to catch me. Sorry, Zach!

bausshf 8y ago

The simple solution would have been configurations for those 1% who wants them. Either at repository/organization level or user level. That way you can get the best of both worlds. I might be wrong, but that's how I'd see it.