Enhance the Office JS API to allow apps to read the cell address of selected cells so a better experience can be provided for users who need to see cell references made via their app. Top priority items should include:
1. The ability to read the cell address of cells a user has selected when using addFromPromptAsync pop up. (e.g. Sheet1!$A$1). This is effectively the same address which shows within the addFromPromptAsync textbox currently.
2. Ability to read cell references of any selected cell/cell range.

This enhancement will be useful as currently apps can create a binding to a selection via the addFromPromptAsync pop up form however apps cannot show users where they previously bound to. A common use case of where this employed is where a user needs an app to keep track of certain cells to perform calculations based on their values but the user themselves will forget where those cells are. If apps can access the cell references then they can tell users where their previously bound cells are.

I have this scenario where users are performing reporting and their reporting parameters are inside Excel cells. When a single report can have multiple parameters, my users are finding it difficult to remember where they placed their bound parameters.

Here’s an idea I had a while ago based on a conversation I had with some of the other SharePoint MVPs: expose the REST endpoints and documentation right in the UI for those who have the appropriate permissions. It could be a little icon at the bottom of any page where there are relevant end points. All content is security trimmed anyway, so no one is going to see an endpoint they can’t use (though if they can fathom the docs they can know what endpoints there are available).

Think about it:

You’re on a List Settings page, and you can see the endpoint for that
You’re on a workflow status page…
You’re in Central Admin on the Create Site Collection page…
You’re on a Term Set Administration page…
You’re on a List View page…

All of the APIs are more obtuse than they need to be. In many cases, the docs are either very long-winded without explaining basic operations or just content stubs. By adding these direct connections from the matching UI pages, it would:

Satisfy the developer needs for easy to understand documentation
Educate appropriate [power] users about how to talk to the devs about what they want
Potentially get telemetry to Microsoft about what people want in the APIs and their docs

There’s far too much of the “I can’t look it up in the dictionary until I know how to spell it already” going on with the APIs in SharePoint in general – going back to the SOAP Web Services and beyond. The platform needs to be more open, not less. Adding these direct links to the REST endpoints and their docs would be an incredibly powerful step in that direction.

(Taken from my blog post at http://sympmarc.com/2014/08/01/renegade-idea-expose-rest-endpoints-in-the-sharepoint-ui/)

Scrap the whole program and think through how to set up the functionality of Sharepoint. All I'm trying to do us publish my site and it is unnecessarily complicated. Nothing is intuitive, would take a month to tell you everything. Scrap all the code and rebuild the entire program from scratch...so it makes sense. Remove all of the "Overthinkers" from program engineering staff (have them work on something else). To many redundant, over thought out processes that make simple processes too complicated. I feel like I am forced to look through 10 drawers of beautifully detailed knives and I desperately need a fork... But there is no fork because they were too busy programming knives.... frustrating...AAAAAAHHHH!