Tom Burke
My feedback
-
45 votesTom Burke
supported this idea
·
-
33 votesTom Burke
supported this idea
·
An error occurred while saving the comment -
11 votesTom Burke
supported this idea
·
-
10 votesTom Burke
supported this idea
·
An error occurred while saving the comment Tom Burke
commented
+10 to the Anonymous comment from July 17, 2018 about locking down certain web parts and effectively creating "page templates" that can have content added, but where web parts and structure can't be messed with. This goes to the governance efforts we've put around our current Classic experience.
-
309 votesnot in our plans right now ·
AdminSharePoint Sites & Collaboration
(Admin, Microsoft SharePoint)
responded
Thank you for the feedback. Creating a Modern Content Editor Web part is not in our plans right now
Tom Burke
supported this idea
·
-
11 votes
An error occurred while saving the comment Tom Burke
commented
Absolutely agree with all of the above. We should have the ability to:
* COMPLETELY ELIMINATE whitespace from between any and all web parts
* Edit the padding, margins, borders, background images, background colors, etc. of any web part (otherwise what is CSS for?)
* Drop images into way more contexts (for instance tables inside of the Text web part)
* Definitely agreed that the giant banners/headers need to be configurable to make them way smaller/shorterThanks for listening!
Tom Burke
supported this idea
·
-
8 votesTom Burke
supported this idea
·
-
56 votesTom Burke
supported this idea
·
-
7 votesTom Burke
shared this idea
·
-
4 votes
An error occurred while saving the comment Tom Burke
commented
More features for intelligently serving up audience-based content would be fantastic. Audience targeting is great but limited. Serving whole pages based on audience would enable a lot more customized content. Make menus where we can dip into FIM/MIM, User Profiles, and SharePoint Directory to grab user attributes (INCLUDING custom AD fields synched to Azure AD) to drive targeting right from SharePoint. Include a Deny feature to deny users meeting certain criteria from accessing pages, sites, or web parts.
Tom Burke
supported this idea
·
-
11 votes
An error occurred while saving the comment Tom Burke
commented
This doesn't necessarily have to be code, in my view...just a new version of the classic Redirect Page.
Another great feature would be if the user has Edit or higher permissions on the Site Pages library, the page gives a delay before redirect, so that it doesn't navigate away before you can open it for editing.
Tom Burke
supported this idea
·
-
13 votesTom Burke
supported this idea
·
-
4 votesTom Burke
supported this idea
·
-
7 votesTom Burke
supported this idea
·
-
13 votes
An error occurred while saving the comment Tom Burke
commented
Just HTML even. I know MS doesn't want to go back to the Script Editor and handle JS parsing, but at least give us some more control over how our content is rendered. The modern web parts are too piecemeal: for instance, why can't I embed a button into a table or link list? Everything is separate, with lots of space in between and no way to create content that other CMSs could handle easily--like tables with embedded images and imagemaps.
Tom Burke
supported this idea
·
-
35 votesTom Burke
supported this idea
·
-
4 votesTom Burke
supported this idea
·
-
3 votesTom Burke
supported this idea
·
-
2 votesTom Burke
supported this idea
·
-
11 votesTom Burke
supported this idea
·
An error occurred while saving the comment Tom Burke
commented
(Modern feedback:)
Just HTML even. I know MS doesn't want to go back to the Script Editor and handle JS parsing, but at least give us some more control over how our content is rendered. The modern web parts are too piecemeal: for instance, why can't I embed a button into a table or link list? Everything is separate, with lots of space in between and no way to create content that other CMSs could handle easily--like tables with embedded images and imagemaps.
Copy Link is just confusing in general, especially with the Doc ID link, which doesn't work in certain contexts/other applications. We had a user delete and recreate a document, which was linked to via a good ol' static HTML link on a page, and the link broke because it was a DocID link. Filename was exactly the same before and after. Very confusing for end users. There needs to be an easier way to get the "/sites/sitename/LibraryName/DocumentName.docx" version of the link, even if DocID is enabled on the site. And an easier way to control whether it opens in browser or client--maybe via a URL parameter (e.g., "?openwith=Client / ?openwith=Browser").