Why is seeing your friends comments and code reviews in the text editor any better than seeing them in the browser? Are we becoming this lazy? or this busy?

This is pretty shortsighted. It's not the simple case of "what you can already do with two tools" that we should be thinking about. It's that stuff that you can't even imagine was possible until it integrated, in the same place, and with a good user experience.

You'll have information that's right in front of your eyes where before, the tiniest wall of separation was barrier enough to make it inaccessible or out of mind. Things will become the same, instead of just both being in the same place. This is the essence of good UX, and it has nothing to do with this specific case, but it will emerge from simple cases like this. First two things coexist, then they share, then they become one.

For a while, the iPhone was just a phone and a computer. People even said the same exact thing you just did: "why is having a phone and a palm pilot in one device any better than having them separate?" Then they started sharing features, the internet became pervasively accessible. Then everything started sharing data and features. And now we can't imagine them separate, and we have an entirely new class of thing that came out of it that basically enabled a revolution.

Eventually programming could be the same. Programmers probably have the highest tolerance I know of for compartmentalization of tasks and poor interaction design and data visualization: they are extremely intelligent and have the ability to tie things together in their heads and break down tasks and tools ad hoc. But when you don't have to do that, when programming becomes easier and more fluid, things will start happening that simply couldn't before.

We can only dream of the kinds of advancements in our tools that are yet to come.

i see people saying less context switches. but isn't this the exact opposite? it's way more context switches?

isn't this the same as having our mails popup up notifications every so often or your gmail aggregating twitter and Facebook, because people thought it would make them more productive

You're creating a strawman. I can't see why Github would make the mistake you believe they'd make as they don't have the self-interest that Facebook and Twitter have in killing your focus with an onslaught of notifications.

I think you could expect all forms of notification to be hidden by default.

It would actually likely improve your ability to concentrate. You would be able to switch into another mode of a developers workflow without needing to context-switch onto an often focus-distracting browser.

Anyway, my core point was that there are a combination of features that allow the creation of a new holistic programming experience. I am not arguing its correctness and I am not arguing that it would suit everybody. :)

Exactly - making context switches cheaper isn't very helpful if you're doing so at the expense of making context switches more frequent[0].

[0] and easier to do "by accident"

This is a silly argument. You're all assuming this type of integration will be have the UI quality of your dishwasher.

Of course context switches and irrelevant information will be distracting if done poorly. This is a UX challenge—not a reason to abandon the idea.

Having the focus you need during concentrated tasks such as coding, while also enabling the integration of other tasks—such as high-level team context awareness and collaboration—is the key design challenge. Done well, it would be a killer app.

Done poorly, as with anything, it will fail miserably.

Programmers have a poor reputation for UI design prowess, and programmers tools are sadly usually made by programmers, and thus carry the same reputation. Very few amalgam programmer/designers exist to bridge the gap of motivation and ability to design a better toolset. But they do exist.

Let's be optimistic, shall we?

They're not quite the same. Those are push-notifications. Push/pull is orthogonal to what application you use for which purposes, especially if you have a desktop were you get such push notifications thrown at your peripheral vision no matter what application you're in.

Potentially fewer context switches and interruptions? I know for me the browser is a potential landmine of distraction, it might be handy to be able to limit that.

I think somewhere along the way we lost sight what context switching really is. Just because you put a different activity in the same tool doesn't mean there's not a context switch when you move to that activity.

Do you really think there's not a context switch when you change from writing and thinking about your own code to reviewing pull requests and comments?

There may be benefits to integrating extra functionality, but let's not imagine there's no cost to changing your mode of operation just because it's in the same tool.

Minimising context switching is a big part of improving programmer productivity, as I'm sure you're aware. This may not seem like much, but large increases in productivity can be achieved through small increases building up; every little helps.

Plus, it's cool.

I think you confused context switching with app switching. Yes having Github activity in the text editor means less app switching, but you are still context switching; from writing code to reading comment, which is the real productivity killer. Why not just add gmail to that text editor while we're at it and save ourselves some time?

Same reason there exist plugins to integrate Git status & diff in Sublime: it's useful for some of us.

IDEs, while they have fallen out of favor somewhat in the web development community, offer such a "holistic" development experience already - complete with deep integration into GitHub, in some instances.

I think you miss the point.

Being modularised allows the basic user experience to be kept very simple. It does not need to grow into something like an IDE. Hell, according to Packages [0] even tools like find-and-replace have been modularised so I do not think it follows that Github would carelessly decide to create a big ball of mud!

And additionally this tool has removed barriers that previously existed before.

Since it was created by Github they will be able to expose APIs to create features which are currently not possible.

Likewise the UI being implemented with WebKit means that the user interface can tightly represent what a user is used to seeing at different stages of their development process.

You might have read "The Design of Everyday Things" [1] before. There are certain elements which you need to control to create a good user experience: (1) discoverability, (2) feedback, (3) the conceptual model, (4) affordances, (5) signifiers, and (6) mappings. Without ease in changing the UI, and the possibility that Github will have self-interest in exposing extra APIs, it would be a lot more difficult to control for each of these.

It's just an opportunity to try new ideas. I'm not suggesting that this would be preferable to everybody.

[0] http://atom.io/packages

[1] http://www.amazon.com/Design-Everyday-Things-Donald-Norman/d...

"Being modularised allows the basic user experience to be kept very simple."

The basic user experience does not exist; or rather it is trivially basic in any text editor. What's important is the advanced user experience, and it simply doesn't exist yet. For instance, Python support amounts to syntax highlighting; nothing compared to python-mode and elpy in Emacs, or PyDev in Eclipse.

There's also a large gap between the promise of "Full-featured, right out of the box" and offering fundamental functionality like settings-view and command-palette as extension packages.

What Atom has to offer, currently, is a bloated abuse of web technology with little appeal beyond Javascript hipsters.

This project has years of hard work ahead to begin competing with Emacs and Vim in some niches; hard work that isn't going to happen because it's proprietary software, and contributors will prefer the open source text editors.

> Since it was created by Github they will be able to expose APIs to create features which are currently not possible.

You're probably right, but even if this is not the case, they will at least hopefully have a better understanding of how to use the APIs well, given how often they work on and with their own APIs.

> There's real opportunity here for Github and I hope they take it.

I think the philosophy here is that there is a real opportunity and they hope that you take it (or someone in the community). They're creating a highly-hackable editor and their API allows access to everything you've asked for.

They're going to build a ton of add-ons too, but they want the community to build a lot of this stuff. The most creative product team in the world can't match millions of developers solving their own problems, so rather than try to build the perfect product for everyone, they're building the most flexible product for everyone to mold into what they need.

My hope is that the core of Atom isn't so bloated with GitHub integration and that integration is optionally available through the plugin management system. I'm of the type who prefers to use the text editor just for code and other tools for source control and project management.

>> that integration is optionally available through the plugin management system

Given that even find-and-replace [0] exists as a module I think you have nothing to worry about.

[0] http://atom.io/packages/find-and-replace

> Aspects of Github could be modularised and added to the editor while still keeping the underlying tool simple and this could change our user experience for the better.

This is essentially what we've done with some Rational tools (such as Team Concert) using by defining a set of loose-coupled RESTful capabilities for tool-based integrated, called OSLC http://open-services.net It has the nice quality, if adopted, as being able to link to you own issue tracker hosted elsewhere (bugzilla, jira, etc), CI, end-user need management, etc.

Atom has some limitations, I could see where OSLC and ActivityStreams would be a bit more interesting.

> Why is the basic workflow of the modern-day programmer split over multiple tools and over multiple systems?

I disagree that this is a problem.

Replace "programmer" with any other profession, and you'll see it's universally silly.