Tom Burke
My feedback
-
45 votes
Tom Burke supported this idea ·
-
38 votes
Tom Burke supported this idea ·
An error occurred while saving the comment -
13 votes
Tom Burke supported this idea ·
-
10 votes
Tom 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.
-
321 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 votes
Tom Burke supported this idea ·
-
58 votes
Tom Burke supported this idea ·
-
7 votes
Tom 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 ·
-
12 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 ·
-
15 votes
Tom Burke supported this idea ·
-
4 votes
Tom Burke supported this idea ·
-
7 votes
Tom 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 ·
-
43 votes
Tom Burke supported this idea ·
-
4 votes
Tom Burke supported this idea ·
-
3 votes
Tom Burke supported this idea ·
-
2 votes
Tom Burke supported this idea ·
-
12 votes
Tom 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").