[grblovrflowerrr]

I think the two natures of Github as a tool for software development and Github as a social coding site are often at odds. Some ways this could be reconciled:

- greater end user customization of the UI layout

- an option to enter a different UI(contributor UI) for repositories you contribute to/own

- make the contributor UI an enhancement on top of the current UI(perhaps a new darker tab bar)

- related to the above, separating out the discovery part into a separate app

In general, I am in favor of greater customizeability in my professional tools, especially something I use as much as Github. I think one reason we as software developers don’t add a lot of end user customizability to our UIs though, is that it adds a ton of complexity to the UI code. This suggests there is opportunity to explore new UI development paradigms and libraries that have end user customizability as a primary concern, instead of a bolted on after thought. I’m curious if anyone is working on such a project.

[reificator]

Especially when it comes to web applications, I'm starting to dread customization.

Just one example: One of the worst platforms/applications I have ever used is built with Sencha/ExtJS, and it causes a ton of bugs and friction. But hey you can move your windows around and resize them, doesn't that make up for features that don't work?

[shaan7]

Most software in the 90s were highly customizable and a joy to use because of that. I don't remember customization adding a lot of complexity to desktop applications (having worked with classic VB6, VB.NET (WPF) and Qt4).

The complexity today comes from the fact that there is much more focus and priority on getting the application to match designers' vision. Its extremely complex to offer the user customization while still ensuring pixel perfect UIs. (Emphasis on complex, its not impossible).

[contradictioned]

In the 90s, how many updates were there, especially introducing new features?

I guess the problem is, if you introduce a new feature in a web app, it can be hidden by the customized design of users. Or it would just appear at a random place in the UI, forcing the user to re customize around that new feature.

[shaan7]

Yes that is indeed a problem, but not unsolvable.

Customization usually doesn't mean radically changing things. Its more about moving UI elements around or changing a List into a Grid etc. A combination of "new" highlight with a "Whats New" popup (extra points for short video intro) usually does the trick.

[jrochkind1]

Yeah, I tend to be not interested in customization, and I believe "general population" UX studies show that most people (not necessarily devs) aren't interested in customization either.

An example of a tool set in a similar space as GH that has prioritized customization are Atlassian Confluence and Jira. How many of us enjoy that software? More than GH?

Customization can't save software that hasn't gotten the UX right in the first place.

[mmiller42]

I agree with that, JIRA is so monstrously difficult. But this kind of limited configuration might not be so bad. If it's kept selective, some configuration is well-loved by technical users, the vast majority of GitHub's visitors.

I think the default order would be used by anyone who doesn't care to configure it.

In some sub-tab of the User Settings panels, there could be a drag-and-drop sort list (like the one for sorting the "featured repositories" on the profile) to arrange the tabs in a different order, and a button to reset them to default.

Maybe one other setting I would add is "dark mode". The CSS is essentially already written in public Chrome browser extensions to "reskin" GitHub's UI. This is because customizing light/dark modes is gaining in popularity. It's a new macOS trend and in my experience surprisingly common in iOS apps too. Since about 70% developers trend towards dark IDEs, it makes sense to have.

Unlike JIRA, I don't think any of these settings should be at the forefront... you should just have sensible defaults and a way to customize it. GitHub Help articles are well-indexed on Google and anyone who wants to know how to change the color mode or tab order is only going to do it about once, so clicking through menus is a familiar and safer-feeling (as opposed to direct links to private UIs) UX, and it's the same as any other process like adding a SSH key, webhook, or app password.

I do think that GitHub's main user base is increasingly loving their customizability. VS Code and Atom gain a lot of traction for their total customizability and extensibility with plugins. I'm not at all suggesting GitHub go in that direction -- but, GitHub is more of a cloud-based software tool than a website. A little bit of customizability goes a long way with user satisfaction, at least to tech-enthusiastic users.

Just little feature flags would be incredibly handy. For example, default to ignoring whitespace in PR diffs (a feature otherwise only available if you know the URL trick, and can't be saved to user settings like your preferred diff layout).

It's the same amount of customizability as "how many emails do you want to display per page" in Gmail. It's enough personalization to be useful and done officially instead of through hacky, dangerous, frequently-breaking Chrome extensions to work around the things that impede productivity.

[jdmichal]

The only thing I've ever seen actually work is a desktop environment. I did a proof of concept for the Coast Guard using Ozone [0]. It basically acts like a desktop, where widgets are individual frames that act like windows with cross-communication ability.

But even then, internal configuration of widgets is the same problem as before, just scope-limited...

[0] https://github.com/ozoneplatform/owf-framework/wiki

[tedunangst]

GitHub should go full MySpace, completely custom css per project.

[tracker1]

Good god no! One of the reasons Facebook won imho is simply because you didn't have to go hunting for core navigation features for every single user's profile page. I do emphatically NOT want that with Github... write a website for your project on ghpages if you want it customized.

[drusepth]

Considering:

1) Most GitHub users are more tech-savvy (and often more CSS-savvy) than your average MySpace users, and 2) Most GitHub users put a lot of value in their repo pages,

this actually seems like it wouldn't _inherently_ be the worst idea, assuming the proper precautions were in place versus bad actors. Allowing each org to fully customize their git repo almost encroaches upon (or replaces?) project websites, which already has some overlap with README files (which aren't currently prioritized). Kill two birds with one stone by giving developers what to prioritize on their repos?

[johannes1234321]

There is lots of value for me in the fact that all those project pages look alike. I can easily go to any project and immediately know where to look and click. This is useful for doing technical evaluation of projects. On Myspace the goal was to show individuality and creativity. GitHub is about the code.

[oblio]

3) Most developers are absolutely awful graphic designers.

[tharax]

> 2) Most GitHub users put a lot of value in their repo pages,

I think you underestimate how many "Single commit, push and forget" test repositories are out there.

[rrix2]

Isn't this github.io ?