What is the best way to enable editing in a table that only exposes a fraction of the fields? Inlay? Overlay? Separate Page?
download bmml source – Wireframes created with Balsamiq Mockups
The additional hidden fields need to be editable as well, but cannot be exposed initially. ex. RBI, runs, singles ect.
For a scenario like this you'd probably need to do some user testing to actually determine the preferred route. From the placement of your "Add New Player" button I would presume that the user is going to be adding editing a lot of player records at a time.
My initial thoughts from an implementation standpoint are that adding/removing or hiding/showing columns in that grid is not going to look smooth in any way. Thus I would avoid going that route and instead have the edit button open a new modal dialog with the additional fields for you to edit.
An example layout of this dialog:
download bmml source – Wireframes created with Balsamiq Mockups
From this dialog you could also add navigation buttons allowing you to edit the next record or add a new record. Realistically though another idea would be to reconsider why you're not showing all the fields in the first place.
Additionally I would consider placing your Add New Player button on the top left in a toolbar so that it is in a consistent location as the table grows. I would also consider placing the actions on the far left as well.
An example layout of the grid:
Showing content on the same page is also an option. User can minimize the table. You could also display the details of the first team by default and the user can easily view the next record by clicking on the row (mouse, touch, keyboard). The benefit is that the user doesn't lose the table context and doesn't have to click back.
I would say your best approach is to use a separate page for editing inputs found off a summarized data table. By moving a user to a separate page you can reinforce that they are in the "edit" mode instead of the "view" mode. You can also leverage additional technologies that may begin to slow a pages responsiveness down when lumping them together with inlay/overlays. Also if you have multiple inputs that can greatly affect your data, a separate page may enable you to better provide your users with some form of preview window to validate there changes before publishing them.
Based on your example above, most of you users may not have edit access but all users will have "See all" access. This is a good opportunity to use an overlay to expose additional data to users as they request to see it. If you where to provide an overlay to both the "Edit" and "See all" features; you may confuse users, or possible risk users click edit and making changes when all they wanted to do was see the hidden data.
You might want to consider an inspector approach. Have a side panel, or a bottom panel perhaps, which shows all the details for a single player. When you click on a row you can then see all their details, and update as needed in the panel.
The advantage of this is takes a set amount of screen space, and it doesn't perturb the table at all, and because it's not modal, you can use it to scan through players more easily. In fact, you could use the down arrow key to go to the next player, and update the inspector quite easily (and back again with the up arrow obviously).
Basically it would look a bit like the classic email view - a list of emails on top, with the message in a panel below.
