I guess that's a matter of opinion... they're changing things, and whether that qualifies as improvement is, in most cases, likely to end up being pretty subjective (unless the change is exactly limited to something like "our pages now all render twice as fast!").
And really... do we need to make everything about something Jobs said? The only part I'd agree with here is that "foolish" might apply if they drop the ball by making the UI less usable/intuitive, in which case "stay foolish" is horrible advice and will negatively effect a whole lot of users.
The new design looks stunning next to the older one - which already looked good.
Am I the only one wishing the readme was above the file list? In my case, I often read the readme and rarely look at the files, and as a landing page standpoint it seems logical that the readme would be front facing instead of hidden at the bottom. I'm curious what's the reasoning behind that order, since it's been that way forever and GitHub seems to be fairly dedicated to elegant and thoughtful design while being open to change, I imagine there must be a good explanation.
That would be quite annoying with large READMEs. I could see it being useful the first time I view a project, but any time after that there's a good chance that I'd rather see the file list.
edit: It's for pull requests. When you enable the new design, you get a quick explanation of the green button and where the clone URL has moved to. So far I'm really liking the new design!
>> replaced with a slim, de-emphasized icon-based navigation.
This is the same problem I had with a Gmail redesign a while back. Using icons looks nice and allows for slimmer navigation but it decreases ease of use for me. I can find things much quicker with text labels.
I have the same concern. I find it's even more troublesome with the flat/simplistic design aesthetic: it just takes way longer for my brain to differentiate one light-gray-on-white abstract symbol from another than it does to pattern match word shapes.
I've even turned on whatever Gmail lab puts the words back into the buttons.
My issue is that no-one should really have to 'remember' them.
When I first started using github it was straightforward as I only had to learn what the words meant (i.e 'fork', pull-request, etc). Now a new user is supposed to learn those concepts and their associated symbols. The cognitive overhead just increased.
Aye, I really struggle with the greyscale icon menus everyone seems to think are super great these days. If they're in colour; fine, I can differentiate quickly enough. But both G+ and now GH seem to think very pale grey icons on a white background will be enough for people to distinguish them.
Yep; GMail adopting mystery meat navigation was a real step back, and it's still mildly irritating to use quite a while later. Hopefully this trend, if that's what it is, runs its course before it spreads much farther.
It was pretty common during the 90s when screen resolutions were really low and preserving space was a big deal. We're seeing it again now because of mobile friendly responsive designs dealing with the same issue.
That takes me back. The "Web Pages That Suck" book was what got me into web design and programming.
Unfortunately, while I bet almost all designers would recognize that mystery meat is bad in the classic 90's context of using it on a homepage, its become acceptable with these sorts of interior toolbars.
So while github is not using it on the project homepage - probably because they recognize it would be MM and be awful - they are using it deeper down.
I'm curious how many people browse github from their smartphones. Right now I'm on my desktop and see a pretty column of unlabeled icons, right next to three inches of unused whitespace between the icons and the edge of the frame. It's a somewhat inefficient use of space...
The number of times I've hit GMail's 'Spam' button rather than 'Trash' is ridiculous. Whether due to the icons or the placing of them next door to each other with no visual (apart from icon or text-label) distinction...
Ok, as a dev who doesn't use github much, I'll give my best guess as to what those icons mean. Respectively:
Home
Alerts
Merging
Documentation
Interactive Heartbeat Sensor, presumably using my webcam, to notify authorities when I'm having a heart attack
Graphs
Branching
Settings
How close was I?
By the way, alt text is absolutely essential for screen readers to function. Don't exclude the blind if they have reason to use your site! Blind people definitely use Github.
I'll take a shot too. I don't use most of the fancy features on Github, so I have almost no experience with these things.
<> - code
! - warning / danger
|7 - merge a fork (or accept a pull)
E]E] - I think that might be a dictionary. Look something up?
_|^\_ - Heartbeat to let you know how active a project is.
|+. - Charts to see activity.
4 - Fork
>< - settings. Funny that it's a wrench and screw driver. Although I guess a keyboard and mouse would be a little less telling.
These seem bad because you can't get information about them before you interact. The icons are small, and kind of hard to make out (I had to turn my screen brightness up to see what was going on with that book one). But, once you get a little bit of experience with them (click them once), you'll have that icon (or just the order) ingrained in your brain. It sucks for people who aren't technical, or who are thrown into Github, but it's not bad for experienced users.
That is until next week when they decide they got the ordering wrong, and some of the icons wrong, and randomly swap and replace icons.
This kind of reminds me of the very challenging 'Is this thing I made hard to use for people who don't know what's going on?' It's a very hard problem - you, the creator, are designing and fabricating something that you want other people to use. You think you found a good way there, and you obviously found the best way because that's the way that you're going to build it. The path was obvious, we went from A to B to C back to B then to D, detoured to S for a while, didn't like the color sceheme, went back to D, then decided B was the best one. You have a lot of experience with alternate configurations, and have innate knowledge of how they work on the inside. Someone who comes up and uses D without any primer might be a little confused. Why do the colors matter here? Well, it's obvious, we went from A-B-C-B-D, it's a natural design evolution, ARE YOU TOO STUPID TO SEE IT!?!? You won't be one of my users... It's hard to distance yourself from what you're working on to see the flaws in your own design. It's very hard. It's easy to assume the knowledge you have, or the knowledge you as an organization have, will be present outside your group a priori. You don't know what they don't know, but you know what you know.
Regardless of whether or not you like the changes, Github has probably been following this 'design evolution' for a while, and they like where they're at, and assume you're smart enough to know beforehand what the icons do. Or, at the very least, smart enough to associate an icon with a topic related to git.
I have this problem all the time when using various minimal websites on my tablet. I can't mouse over for a tooltip, so if I don't recognize the icons I just have to start randomly clicking and hoping I don't end up being redirected to my mail app or something.
Finding the right balance between casual consumers of github and developers who live in it all day must be challenging, though.
EDIT: I didn't realize that the front page for a given repo shows text in the sidebar. Good on them, I like that compromise.
> Using icons looks nice and allows for slimmer navigation but it decreases ease of use for me. I can find things much quicker with text labels.
I believe studies have repeatedly shown that users can find things with icons faster than text labels. Icons are less discoverable than text, but once you know what you're looking for, icons are faster.
The 'discovering' part of discoverability isn't something that just happens one time. If I'm not using your software day in day out then I'm likely to forget your silly icons.
Call me a Luddite, when a tool I use every day is completely redesigned, and marketed with phrases like "The content is the interface", I begin to shit my pants.
It's especially scary because there's no rollback. At least I still have gnome desktop, for now...
GitHub issues is another kettle of fish, but does anything force you to use the github interface to use the repositories? Forking, or making buckets?
You can host a copy of your repo on github, another on, say, bitbucket, and another on gitorious, and as long as you take care of syncing between them, you should be alright, right?
Fair point. I actually use Issues a lot, I find it great for small projects where I don't have the time or energy to set up bugzilla or trac etc. I like the way you can browse branches and commits, see your repos, start a new project with a README and so on. I can imagine using the wiki more than I have.
I just get this queasy feeling that this might be one of those over-thought reworkings, where they do everything they thought they would do years ago before the site took off. Sometimes that works, but usually it's a disaster. Incremental changes, with lots of feedback from real users, seems to be the better way for a site with a solid core of happy users to evolve.
I wonder why the heck they include the Mac OS X app chrome. What's the point? You're wasting a lot of space in the screenshot with useless content. Is it just to show off your mac? It's a website for god's sake, it looks essentially the same in any operating system.
The screenshot has to be contained in something to separate it from the page around it, and window chrome makes it feel a lot more real and less like a mockup. A black border or something wouldn't quite have the same effect.
With many screenshot tools there's a 'capture this window' option, which makes it much more easy to grab the output of a window than choosing 'select a box' and dragging a square over the entire window minus the chrome.
That said, it doesn't look like they did that here...
It looks like the code viewing area was narrowed. If the redesign was meant to put more focus on content, this decision is perplexing.
I wish they'd make a responsive design that would make use of my 24" monitor. Right now I've resorted to writing a Chrome plugin to widen the code viewing area via CSS.
> It looks like the code viewing area was narrowed.
Doesn't look like it[1].
I'm not sure that a much wider github would be of use to me. Most projects usually place some kind of limitation on the number of characters per line and even in the file browser I don't find filenames long enough to take that kind of space. Maybe you have some other use cases worth sharing?
My team's inherited code (legacy code) where not all lines are trimmed to 80 or even 120 chars. Long file names or deeply nested directories aren't something I run into currently, but I recall running into them on several J2EE apps in the past.
This might be a nice update, I'll opt-int for some projects and try it out, but it doesn't address my biggest problem with GitHub: the lack of decent code review tools.
I have to use an external review tool like Reitveld to get side-by-side diffs and better comment and patch-set management.
Tixef.com extends the line to fill the full length of the browser window. If the line is still does not fit, then it is wrapped and icon is inserted to indicate the fact. If you have an office then you probably also own a large monitor if not several of. There is really no sense of keeping fixed layouts nowadays in a product targeted towards professionals.
[disclaimer: Tixef is my project so I may be a bit over the top about it]
To provide review tools you need the code as well as its full history. An API is not going to cut it.
However Git being the beautiful distributed system as it is, you don't have to move your hosting. In fact you can push to multiple Git remotes, or use one for backup, or just for reviews.
You can also push to multiple remotes at the same time by adding two urls for the origin. So if you like the idea of your source files residing on a particular provider then you can keep it there as well.
Heroku works in a similar way, you may store your repo elsewhere but deploys happen when you push to their remote.
The true API here is Git itself not some silly and constantly changing REST protocol over something as stable the Git Object Model.
Their fixed layout is a major cause of that in my opinion. Most developers don't code on old VGA terminals anymore and produce more than 80 characters per line, at times much more.
A layout that provides less space than your average text editor or IDE will lead to unnecessary line breaks.
Actually I was referring to something else: the iPhone-style sideways scrolling animation when you click on a source file name or go back to a directory listing.
I'll reserve judgement until I use it but it does look promising.
Now, if they could solve that nasty problem wherein the issues list seems to revert to an earlier revision when you use the browser button I would be a happy camper.
It would be wonderful if you could sort by ctime in the file list view. Bonus points if the the right aligned relative dates could be printed in rfc3339 format. As it is the right aligned relative dates can be disorienting when you scan down the list looking for what has been changed recently.
Yeh, but the convenience of it here is that you may freely browse that repo (and change URL in the address bar), and still have the access to the repo URL.
Agreed. I use Bitbucket every day, and while it's far short of 30 seconds, I do find it takes a second or two of extra scanning to notice where the repo URL is. And it's essentially on the top right, not aggressively out of the way.
Now, Github's pushing it even further out of view than Bitbucket's location.
Honest question: Is Github supposed to be about Git and code?
Statement of opinion: It seems to me that Github is the leader of online code hosting. However, this position could be disrupted because, and I could be wrong, Github focuses on items not directly related to git and/or code.
I dream of a time when the average person making manuals or Stand Operating Procedures in an office environment can see the benefits of source control and has tools that make git easy.
The company that truly focuses on making Git itself dead simple and powerful will win. I pay github every month, but I am starting to lose my patience. I am actively looking to support a company that focuses on abstracting the completely unforgiving nature of git.
In my opinion, you shouldn't need to be a command line virtuoso nor need to grok the entirety of the git code base to use git. Eventually, everyone gets dirty with git and thats when the lack thought in usability exposes itself. Github could focus on this, but it seems like they have other priorities which is fine. I have mine too.
They help, but as a user of Github for Windows, I have too often been told that a "synch" (basically a combination of push and pull) failed and I need to resolve the issue using my command prompt. As an anecdotal measure, I would estimate this happens about 5 to 10% of the time while working alongside my colleagues who are not using Github for Windows, or any similar GUI tool, and using our own private Gitlab origin.
Github for Windows is also disappointingly lacking in functionality that is necessary in my workgroup. For example, it does not support Git submodules or two-origin configurations. When I work in repositories we have configured in that fashion, the command line is my option of choice. And let me be frank: there are scarcely any tools I use that have a worse user interface than the Git command line tool.
I agree with the grandparent that there remains a market under-served: to provide a decent user interface on top of Git. Github for Windows is amazing for a free tool and I give the development team a great deal of respect for what they have provided users like myself (people who want their source control and build tools to just do their job simply and get the heck out of the way). But there is a lot of room for improvement. I for one would pay good money for a Github for Windows "Professional" version.
Try Atlassian's SourceTree.[1] I have only used the Mac app. It's the GUI I settled on after trying three or four others, including Github (again, for Mac). They built the Windows client after everyone who uses Windows at work clamored for it. I'm still on XP though and it requires 7+.
Atlassian also has a good, friendly set of tutorials for using Git.[2] The order in which they introduce the concepts and the commands encourages a clear understanding of the whole system.
SourceTree has been great and Atlassian's support is also excellent. However, I still can't work out how to turn off Git's overly-optimistic automerge, which leaves << HEAD strewn through files at random.
I briefly tried SourceTree when the Windows build was first made available for download. However, it too did not support Git submodules--although from my understanding the Mac version does. I'll keep an eye on it though, since that seemed like something that would be added in time.
I am a firefighter and hobby/part-time developer. We have more manuals and SOP's than you can shake a stick at. They should be in source control so we can see how strategy and tactics evolve over time, who made the changes, diff's and/or allow "pull requests" from the field to change something for the better, as just one example.
Now, try to explain to your Chief or supervisor about how awesome Git is.. that is easy and I've done it. Then comes the part where you explain how to use it; The problem is the interface on both the CLI and GUI require a TON of "other" domain knowledge to use effectively. Abstract all that away at the same price point of Github and you will win a HUGE market.
We don't have IT budget to pay anyone to do this... nor buy the extremely expensive solutions that already exist. So we rely on email and ad hoc training to make sure everyone can stay abreast. Now, how many businesses not related to software development could benefit from Git or a similar DVCS?
That's a pretty interesting use case. I'm always interested in occupations with non-technical emphasis that are moving towards Git, GitHub, and source control in general.
I'd be really interested in hearing more about the problems you face, personally and within the firestation. If you'd like you can email me at my username [at] gmail.
Will do. Think about medical records or 911 call data in a git repo. This is evolutionary stuff that no one in the fire service is thinking about. Hell, our IT guru's can't seem to get clean data from one database to another. Its a sad state in .gov IT at the local level.
Hello Brother! Yes, we've used those... sadly they don't work "at scale." My department has 600 members and a lot of them have good ideas. They have to go through the chain-of-command to get those ideas heard. This method not only suffers from the telephone problem Ie. the idea is lost in translation. It also suffers from a Chief or Capitan not liking the idea(s) and never doing anything with it. Manuals and SOPs in a democratic environment where anyone could clone, make changes and submit pull-requests would be a manna from heaven.
In that case a Github wiki might be a good start. You get the version control, but there's enough abstracted away that it should be easy to get up and running with. Now, you just need everyone in your department to get a Github account...
Yeah but by the time you've used the site a couple times, you'll be able to find the repo url from then on. It really doesn't make any sense being at the top of the page taking up so much prime space.
They added a green button which i assume is "fork on github". It seems they want to encourage people to use github rather to clone to local filesystem.
Nope, that one is for pull requests. But they did disable SSH cloning for read-only and the cloning URL is not showing at all (only after you click on HTTPS), pointing towards preferring of forking.
They've always had a quite prominent "fork on github" button.
Their suggested course of action is to fork on github and then clone to your local filesystem. You then push changes to your fork on github, and open a pull request from within their system.
The default workflow is designed to play nice with their issue tracker/etc.
You can clone with HTTPS, SSH, Subversion, and other methods.
Before I clicked "Enable Repository Next" there was also a "Git Read-Only" option.
The "other methods" text points to https://help.github.com/articles/which-remote-url-should-i-u... which lists HTTPS read-only & read-write and SSH read/write. Last time I looked that page also listed Git read-only (with the description "All git:// URLs are anonymous, public and read-only. Private repositories do not have this URL type. // Use these URLs when cloning someone else's repository (where you don't have write access) and for submodules that point at public repositories.").
There was no explanation in the "Repository Next" blog posting that git:// URLs were being disappeared...
Can't say I like the new look. The pjax improvements are great, of course. But moving all the top menus to a right-hand sidebar just doesn't work well. How glaring is it when the cloning uri, which is wide sequence of letters, is squeezed into a narrow sidebar and thus mostly cutoff. It is is awful. Did they consider drop down menus if it was really necessary to reduce the clutter at the top of the page? Otherwise move the navigation menu to the left and allow the page to fill the screen.
Sorry to be negative. I appreciate work to improve things, some of these changes just aren't. Hope they keep working on it.
Hmm, as someone who spends most of their time on github looking at pull requests and issues, this seems a step backwards.
Not a huge one, but it was nicer to have my most frequent points of interaction at the top. I deal with the code itself in my local repo. I don't need to know how many commits/branches/tags/contributors there are -- that is the redundant info for me, and that should have been shoved to the side.
If I'm using github's UI, it's because I'm managing a project. Might be nice to have a separate "management" interface you can opt into?
tldr: They moved all the "extra" stuff to the side, while keeping the info directly related to the git repo in the center. But the whole point of using github is the value they add, not the core functionality that I can already get through my commandline!
I think their goal is the right; to reduce the vertical space usage at the top of the page before the "content". They did however remove some of the useful tabs and keep the least useful. Programming language stats and project description & project URL seems less important to me than the "code, issues, pull request etc" tabs.
Agreed. I've often presumed that stats (esp. language and commit counts, etc.) were part of the "social" aspect of GitHub, but not otherwise useful to me in any meaningful way most of the time.
I think the sidebars are a step back for me. I preferred some useful content at the top, now having it on a sidebar just moves that content to the right side, away from my focus.
One positive thing about the change is that "network" and "graphs" are now not co-mingled with main workflow items like Issues and Pull Requests.
Does it also work when the syntax is outside of the diff context? I.e. think a html comment that started in an a prior insertion hunk? We had encountered a lot of edge cases whilst building the syntax highlighted diffs for https://www.tixef.com It is a tricky domain, hats of to you for attempting it in JavaScript!
The highlihght is pretty much constrained to diff (on pull requests, commits and compares[1]), but it could work on any page. I've mentioned[2] how I used jquery-syntaxhighlighter to do it, which itself is a fork of Google's Prettify in order to do the heavy lifting of syntax discovery and actual highlight.
+1
Also, how often do contributors look at the source code on github? Contributors will most likely have the repo cloned on their machine. I think if management interface were to exist, it should default to Pull Requests or Issues, or some kind of dashboard that summarizes new activities in both.
I find the source code view is particularly useful as a dashboard because it gives modification times at a glance for each sub-directory, so as a non-maintainer you can tell whether there might be anything of interest to pull down (and possibly reconcile with local changes), without needing to go to that directory on your disk and do the fetch on the command line. So defaulting away from that isn't an obvious solution.
I really wish Github would bring back issues search and would stop making the top search bar default to the current repository. I constantly search something there and always forget to select "Search all Github". That being said, I think it's good that they are reducing the clutter.
search all of github is broken anyway. Half of my projects couldn't run with the language they choose to label it with. Unless you wade into the src, you have no idea what the repo actually is.
Yeah, me too. It happens to me at least daily. I don't think I have ever wanted to search within the repository and it certainly shouldn't be default. In fact, I might write a browser extension to make it global by default again.
I don't mind the navigation being on the right, but the clone url doesn't appear on most repositories which is one of the most important elements of the repo.
I know how it works, I just don't think it should work that way. I bet 95%+ searches on Github are Github-wide, not repository specific. Why not make the most common use case the default? Plus, why would a top navigation bar be context sensitive?
Interesting. I search within a repo (for code or issues) 95% of the time! It'd be interesting to know what their metrics are for usage of the search bar.
Ah, maybe I was just projecting my own usage patterns. A good middle ground would be for Github to display "All repositories" search results beneath repository specific search results.
I wish there was a good way to search code. The input is filtered to be safe, which makes it really difficult to find a specific piece of code (especially when searching all of GH).
I have never understood the reason for putting the commit comments of some random file within it next to the folder name.
It's unnecessary noise and what would be far more useful is how many files and folders that folder actually contained.
To be honest I don't really see the point of putting the comments next to the file name either.
Also, I wish for the love of god that they put the file size there.
Then again my primary use case of github is reading code to learn and having a nosey at how good a coder someone is, so I'm generally looking for the bulk of a program, hence the usefulness of file size and the uselessness of commit comments.
The code browser is in my opinion one of the most useful features of github. Commit history and blame combined with the "unnecessary noise" you describes makes it very easy for me to find out the last time I touched some line or file and what changed.
Why do you really care about the file size and amount of files btw?
A lot of files in C# (and I'd imagine Java) just contain interfaces because it's so 'cheap' to make these in IDEs and that's the programming style.
So often you're looking for the files which contain the majority of the code and you're just having to open random files trying to find it. How big the file is shows roughly how many LOC it contains.
This is actually becoming more common in javascript as well as more people unbundle their code, it'd be useful seeing if the file you're about to open is meat or chaff.
I'm fine with showing the last commit time, that is useful information, the comment itself though is invariably noise to everyone but the committer or team.
It is, of course, not just some random file -- it's the file that has the most recent commit in that directory.
Or rather, it's the commit message from the most recent commit in that directory (it's not so much about files at all).
I find it quite useful, to see if there have been any recent changes in that directory (and specifically when and what) or if it hasn't been changed in years.
I guess the repo's you look at don't write very good commit messages?
If you find the number of days since last change useful... why wouldn't you also find it useful to know what was changed in that last change? That's what the commit message tells you, right?
(and the commit message is also the place you click on in the github ui to see the full commit with diff etc)
161 comments
[ 4.3 ms ] story [ 210 ms ] threadSteve Jobs' "stay hungry. stay foolish" applies perfectly to GitHub's attitude.
Keep up the great work!
And really... do we need to make everything about something Jobs said? The only part I'd agree with here is that "foolish" might apply if they drop the ball by making the UI less usable/intuitive, in which case "stay foolish" is horrible advice and will negatively effect a whole lot of users.
http://wikipedia.org/wiki/Whole_Earth_Catalog
I just think that the alignment of the right vertical icon bar is a bit off, I think it'd be better off-canvas.
The emphasis on speed is great. I hope they'll improve keyboard navigation with this release as well.
- Current/Old https://github.com/etsy/skyline
- New/Redsigned https://f.cloud.github.com/assets/1354/660756/cc8cad9c-d714-...
EDIT: typo
Am I the only one wishing the readme was above the file list? In my case, I often read the readme and rarely look at the files, and as a landing page standpoint it seems logical that the readme would be front facing instead of hidden at the bottom. I'm curious what's the reasoning behind that order, since it's been that way forever and GitHub seems to be fairly dedicated to elegant and thoughtful design while being open to change, I imagine there must be a good explanation.
edit: It's for pull requests. When you enable the new design, you get a quick explanation of the green button and where the clone URL has moved to. So far I'm really liking the new design!
This is the same problem I had with a Gmail redesign a while back. Using icons looks nice and allows for slimmer navigation but it decreases ease of use for me. I can find things much quicker with text labels.
I've even turned on whatever Gmail lab puts the words back into the buttons.
That said, Github looks to be mitigating this issue by having full text on the root screen for the repo. Compare the sidebar here: https://f.cloud.github.com/assets/1354/660756/cc8cad9c-d714-... and here: https://f.cloud.github.com/assets/1354/660769/fe4a1a0e-d714-...
Maybe that will train my brain with positional data a little better than Gmail managed to.
Oh, that's a great point. It pretty much solves my main concerns.
When I first started using github it was straightforward as I only had to learn what the words meant (i.e 'fork', pull-request, etc). Now a new user is supposed to learn those concepts and their associated symbols. The cognitive overhead just increased.
It was pretty common during the 90s when screen resolutions were really low and preserving space was a big deal. We're seeing it again now because of mobile friendly responsive designs dealing with the same issue.
Unfortunately, while I bet almost all designers would recognize that mystery meat is bad in the classic 90's context of using it on a homepage, its become acceptable with these sorts of interior toolbars.
So while github is not using it on the project homepage - probably because they recognize it would be MM and be awful - they are using it deeper down.
What would you recommend they did here?
You shouldn't have to click on icons to find out what they do. There isn't even alt text.
They should have set with devs in a room and asked them - "What do these mean to you?"
UPDATE: hover seems to work now to figure out what the button does. Not sure if this was just my browser or they literally fixed it in the past hour.
Home
Alerts
Merging
Documentation
Interactive Heartbeat Sensor, presumably using my webcam, to notify authorities when I'm having a heart attack
Graphs
Branching
Settings
How close was I?
By the way, alt text is absolutely essential for screen readers to function. Don't exclude the blind if they have reason to use your site! Blind people definitely use Github.
The icons for pull requests and branches are far too similar to each other, in my opinion.
<> - code ! - warning / danger |7 - merge a fork (or accept a pull) E]E] - I think that might be a dictionary. Look something up? _|^\_ - Heartbeat to let you know how active a project is. |+. - Charts to see activity. 4 - Fork >< - settings. Funny that it's a wrench and screw driver. Although I guess a keyboard and mouse would be a little less telling.
These seem bad because you can't get information about them before you interact. The icons are small, and kind of hard to make out (I had to turn my screen brightness up to see what was going on with that book one). But, once you get a little bit of experience with them (click them once), you'll have that icon (or just the order) ingrained in your brain. It sucks for people who aren't technical, or who are thrown into Github, but it's not bad for experienced users.
That is until next week when they decide they got the ordering wrong, and some of the icons wrong, and randomly swap and replace icons.
This kind of reminds me of the very challenging 'Is this thing I made hard to use for people who don't know what's going on?' It's a very hard problem - you, the creator, are designing and fabricating something that you want other people to use. You think you found a good way there, and you obviously found the best way because that's the way that you're going to build it. The path was obvious, we went from A to B to C back to B then to D, detoured to S for a while, didn't like the color sceheme, went back to D, then decided B was the best one. You have a lot of experience with alternate configurations, and have innate knowledge of how they work on the inside. Someone who comes up and uses D without any primer might be a little confused. Why do the colors matter here? Well, it's obvious, we went from A-B-C-B-D, it's a natural design evolution, ARE YOU TOO STUPID TO SEE IT!?!? You won't be one of my users... It's hard to distance yourself from what you're working on to see the flaws in your own design. It's very hard. It's easy to assume the knowledge you have, or the knowledge you as an organization have, will be present outside your group a priori. You don't know what they don't know, but you know what you know.
Regardless of whether or not you like the changes, Github has probably been following this 'design evolution' for a while, and they like where they're at, and assume you're smart enough to know beforehand what the icons do. Or, at the very least, smart enough to associate an icon with a topic related to git.
Finding the right balance between casual consumers of github and developers who live in it all day must be challenging, though.
EDIT: I didn't realize that the front page for a given repo shows text in the sidebar. Good on them, I like that compromise.
I believe studies have repeatedly shown that users can find things with icons faster than text labels. Icons are less discoverable than text, but once you know what you're looking for, icons are faster.
It's especially scary because there's no rollback. At least I still have gnome desktop, for now...
You can host a copy of your repo on github, another on, say, bitbucket, and another on gitorious, and as long as you take care of syncing between them, you should be alright, right?
I just get this queasy feeling that this might be one of those over-thought reworkings, where they do everything they thought they would do years ago before the site took off. Sometimes that works, but usually it's a disaster. Incremental changes, with lots of feedback from real users, seems to be the better way for a site with a solid core of happy users to evolve.
That said, it doesn't look like they did that here...
I wish they'd make a responsive design that would make use of my 24" monitor. Right now I've resorted to writing a Chrome plugin to widen the code viewing area via CSS.
http://github.com/sauravc/github_wideload
Doesn't look like it[1].
I'm not sure that a much wider github would be of use to me. Most projects usually place some kind of limitation on the number of characters per line and even in the file browser I don't find filenames long enough to take that kind of space. Maybe you have some other use cases worth sharing?
[1] https://f.cloud.github.com/assets/1354/660780/2e217312-d715-...
I have to use an external review tool like Reitveld to get side-by-side diffs and better comment and patch-set management.
There is two click quick demo link in the toolbar.
[disclaimer: Tixef is my project so I may be a bit over the top about it]
I'd be more interested in keeping my hosting on GitHub but using more sophisticated code review/workflow tools than they offer.
Have you considered targeting this use case? Their API is robust and includes sufficient access controls. I'm surprised no one is doing this yet.
However Git being the beautiful distributed system as it is, you don't have to move your hosting. In fact you can push to multiple Git remotes, or use one for backup, or just for reviews.
You can also push to multiple remotes at the same time by adding two urls for the origin. So if you like the idea of your source files residing on a particular provider then you can keep it there as well.
Heroku works in a similar way, you may store your repo elsewhere but deploys happen when you push to their remote.
The true API here is Git itself not some silly and constantly changing REST protocol over something as stable the Git Object Model.
so in short: no. :)
(FYI, their API provides access to all the git objects and would also allow you to add additional keys so you could clone it.)
A layout that provides less space than your average text editor or IDE will lead to unnecessary line breaks.
But thank goodness, that is gone!
Now, if they could solve that nasty problem wherein the issues list seems to revert to an earlier revision when you use the browser button I would be a happy camper.
Then I thought how awesome GitHub was and it really understood users. It always had the big repo url on front and top where one can never miss it.
In this new design, GitHub has pushed it on to bottom right and reduced the input size. Bad Decision IMHO.
Github needs to start fixing things rather than constantly making them worse. Whoever is in charge of their UX-design needs to be replaced.
Now, Github's pushing it even further out of view than Bitbucket's location.
Statement of opinion: It seems to me that Github is the leader of online code hosting. However, this position could be disrupted because, and I could be wrong, Github focuses on items not directly related to git and/or code.
I dream of a time when the average person making manuals or Stand Operating Procedures in an office environment can see the benefits of source control and has tools that make git easy.
The company that truly focuses on making Git itself dead simple and powerful will win. I pay github every month, but I am starting to lose my patience. I am actively looking to support a company that focuses on abstracting the completely unforgiving nature of git.
In my opinion, you shouldn't need to be a command line virtuoso nor need to grok the entirety of the git code base to use git. Eventually, everyone gets dirty with git and thats when the lack thought in usability exposes itself. Github could focus on this, but it seems like they have other priorities which is fine. I have mine too.
Github for Windows is also disappointingly lacking in functionality that is necessary in my workgroup. For example, it does not support Git submodules or two-origin configurations. When I work in repositories we have configured in that fashion, the command line is my option of choice. And let me be frank: there are scarcely any tools I use that have a worse user interface than the Git command line tool.
I agree with the grandparent that there remains a market under-served: to provide a decent user interface on top of Git. Github for Windows is amazing for a free tool and I give the development team a great deal of respect for what they have provided users like myself (people who want their source control and build tools to just do their job simply and get the heck out of the way). But there is a lot of room for improvement. I for one would pay good money for a Github for Windows "Professional" version.
Atlassian also has a good, friendly set of tutorials for using Git.[2] The order in which they introduce the concepts and the commands encourages a clear understanding of the whole system.
[1]http://www.sourcetreeapp.com/ [2]http://www.atlassian.com/git/tutorial
Now, try to explain to your Chief or supervisor about how awesome Git is.. that is easy and I've done it. Then comes the part where you explain how to use it; The problem is the interface on both the CLI and GUI require a TON of "other" domain knowledge to use effectively. Abstract all that away at the same price point of Github and you will win a HUGE market.
We don't have IT budget to pay anyone to do this... nor buy the extremely expensive solutions that already exist. So we rely on email and ad hoc training to make sure everyone can stay abreast. Now, how many businesses not related to software development could benefit from Git or a similar DVCS?
I'd be really interested in hearing more about the problems you face, personally and within the firestation. If you'd like you can email me at my username [at] gmail.
Have you all tried using some of the features built in to the editors like revision tracking or history a la google docs?
I know I'm starting to go apples to oranges here- but just tossing that out since those features are sometimes overlooked or forgotten about.
Their suggested course of action is to fork on github and then clone to your local filesystem. You then push changes to your fork on github, and open a pull request from within their system.
The default workflow is designed to play nice with their issue tracker/etc.
Before I clicked "Enable Repository Next" there was also a "Git Read-Only" option.
The "other methods" text points to https://help.github.com/articles/which-remote-url-should-i-u... which lists HTTPS read-only & read-write and SSH read/write. Last time I looked that page also listed Git read-only (with the description "All git:// URLs are anonymous, public and read-only. Private repositories do not have this URL type. // Use these URLs when cloning someone else's repository (where you don't have write access) and for submodules that point at public repositories.").
There was no explanation in the "Repository Next" blog posting that git:// URLs were being disappeared...
Sorry to be negative. I appreciate work to improve things, some of these changes just aren't. Hope they keep working on it.
Not a huge one, but it was nicer to have my most frequent points of interaction at the top. I deal with the code itself in my local repo. I don't need to know how many commits/branches/tags/contributors there are -- that is the redundant info for me, and that should have been shoved to the side.
If I'm using github's UI, it's because I'm managing a project. Might be nice to have a separate "management" interface you can opt into?
tldr: They moved all the "extra" stuff to the side, while keeping the info directly related to the git repo in the center. But the whole point of using github is the value they add, not the core functionality that I can already get through my commandline!
I think the sidebars are a step back for me. I preferred some useful content at the top, now having it on a sidebar just moves that content to the right side, away from my focus.
One positive thing about the change is that "network" and "graphs" are now not co-mingled with main workflow items like Issues and Pull Requests.
Because of that I've been maintaining my personal fix for this: https://github.com/danielribeiro/github-diff-highlight
It would definitely be nice to see it supported natively by GitHub.
The highlihght is pretty much constrained to diff (on pull requests, commits and compares[1]), but it could work on any page. I've mentioned[2] how I used jquery-syntaxhighlighter to do it, which itself is a fork of Google's Prettify in order to do the heavy lifting of syntax discovery and actual highlight.
[1] https://github.com/danielribeiro/github-diff-highlight/blob/...
[2] https://github.com/danielribeiro/github-diff-highlight#hacki...
Instead of trying to highlight the diff directly.
I don't mind the navigation being on the right, but the clone url doesn't appear on most repositories which is one of the most important elements of the repo.
It's unnecessary noise and what would be far more useful is how many files and folders that folder actually contained.
To be honest I don't really see the point of putting the comments next to the file name either.
Also, I wish for the love of god that they put the file size there.
Then again my primary use case of github is reading code to learn and having a nosey at how good a coder someone is, so I'm generally looking for the bulk of a program, hence the usefulness of file size and the uselessness of commit comments.
Why do you really care about the file size and amount of files btw?
So often you're looking for the files which contain the majority of the code and you're just having to open random files trying to find it. How big the file is shows roughly how many LOC it contains.
This is actually becoming more common in javascript as well as more people unbundle their code, it'd be useful seeing if the file you're about to open is meat or chaff.
I'm fine with showing the last commit time, that is useful information, the comment itself though is invariably noise to everyone but the committer or team.
Or rather, it's the commit message from the most recent commit in that directory (it's not so much about files at all).
I find it quite useful, to see if there have been any recent changes in that directory (and specifically when and what) or if it hasn't been changed in years.
If you find the number of days since last change useful... why wouldn't you also find it useful to know what was changed in that last change? That's what the commit message tells you, right?
(and the commit message is also the place you click on in the github ui to see the full commit with diff etc)
I feel like it takes me a minute to figure out what page I'm on now though, due to less navigational context. Perhaps something like this would help:
http://cl.ly/image/252t3J1h0k28
Photoshop: http://i.imgur.com/MR9nzmH.png
Based on the negative comments below, just updating the top navigation (solely) seems like it would have appeased everyone.