I wasn't suite sure where to post this, so will li...
# _general
j
I wasn't suite sure where to post this, so will likely spam a few channels with a link. I was hoping to understand some more up to date information, on why customers still choose to install Office natively rather than consume the web equivalents directly. I know of course that plugins and macros are a challenge in the web apps, but I started to see some shifting, particularly for frontline workers etc. away from the M365 E* pricing down to an F* and putting workers into the Web Apps. Really hoping to understand up to date technical reasons on what would stop the move over, outside of user change impact - appreciate any feedback.
n
You’ve already touched on the main one I see, and that’s COM add-ins. I’ve also seen clinical systems require the desktop version of office installed, to create patient letters. They’ve obviously not figured out how to create documents without office installed. There is also perceived lack of feature parity when compared to the desktop version, which is true in some cases. Offline usage comes up everyone and then, though think the new Outlook supports that from memory
thankyou 1
r
Is there in the Web version of Office possibilities to force configuration to the users. Like with GPO-s? I could imagine also this as part why not shifting.
🤔 1
👍 1
j
The main issue I found was users browsing file shares through Explorer couldn't open files in those file shares with a direct double-click that takes them straight into the desktop app
👆🏼 1
👆🏻 1
j
So the "Microsoft' Answer there would be OneDrive or SPO right>
j
But what if you have stuff in file shares that aren't OneDrive? Network drives, departmental shares, etc
b
I would say application integrations, Navision having an export to excel function. With installed excel that just opens. With online, they would need to save that somewhere, go online, open the file... that just takes too much time
thankyou 1
j
We have custom business apps tightly integrated with Outlook and also feature parity not equal. I tried a few times the web version and I am not a fan.
thankyou 1
j
The feature parity is a lot closer than I thought, when I did a comparison recently
👍🏽 1
j
True also I found when typing it wasn't as smooth as locally, weird feeling.
j
So fair to say it's all integration based stuff as expected. And some usability around local data access not being smooth (the same challenges from my consulting days) I found a lot of the time that plugins and integrations were deployed to the masses to serve a few - wonder how much that is still going on out there - guess it depends on the vertical (legal is demonic when it comes to plugins)
n
For us? Macros. It's insane how many we utilize here.
thankyou 1
If not for those, I'd bet we could switch and have a relatively seamless experience.
a
Exactly as most have mentioned, macros and custom-built add-ins are the no-go taking financial institutions as an example. But I have another customer from the Retail side that we successfully transitioned to WebApps. In this case, we had to add specific registry keys to ensure all Office documents opened in the web browser. As someone mentioned for some AppIntegration we had to add a registry key that would change the mailto function to open OutlookWeb.
😎 1
j
I'd be interested to see that key for opening documents in the browser. Does that include for when browsing through the filesystem in Explorer? Essentially, a file type association?
a
Exactly, let me check here to refresh what exactly we had to set up, as it has been a while now. We give users access to a published explorer, and from there, they open the files... also the big challenge was the email function, as within the in-house POS application, it calls the mail handler to send emails, so we had to set Chrome to be the mail handler.
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeMAILTO\Application] "ApplicationName"="Google Chrome mailto" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ChromeMAILTO\shell\open\command] @="\"C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe\" \"https://outlook.office.com/?path=/mail/action/compose&amp;to=%1" [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\Google Chrome\Capabilities\URLAssociations] "mailto"="ChromeMAILTO" And yes, on the association files, we had to add it as well. <Association Identifier="mailto" ProgId="ChromeMAILTO" ApplicationName="Google Chrome mailto" />
😎 1
its been a while maybe there is less complicated ways nowadays
but it has been 3 years, and it is still working rock solid, I think we had just one issue along the way that Chome changed their default install path
n
lots of workbooks with vba code that run sql select statements back to our ERP via odbc drivers to download data and create reports. while that would not affect task workers like CSR's and such, i don't want one app for this group and one app for the other group. easier to just keep everyone on the local office apps which is office 2021 ltsc at the moment...
j
So with the open piece being solved with registry, the main issues are plugins and macros. Could also give the users a desktop app like feel with install site as app option from the browser. So @James Kindon it’s pretty much inline with our discussion.
💯 1
a
yes, checking here in past email communications, we were able to find a workaround to the compose email piece, the one I shared, but for the office files, the decision was to upload to SharePoint, and once in SharePoint, users could open from there. I think we tried using same approach of setting a new file association but did not work
s
So aside from plugins/macros/integrations with other apps that have been brought up, I think user experience is another piece. The web apps are not a great user experience for people who expect to be in the applications all day. If you're a frontline worker who is using Word or Excel occasionally, it's not bad. But if you're constantly creating/editing/reviewing docs and spreadsheets or doing any amount of work in PowerPoint, the web version is not great for significant usage
thankyou 1
plus its more browser tabs open that you have to manage
j
I find myself using different browsers per customer/tenant. Actually works quite well
😎 1
j
Legal teams also use special plugins for Outlook. Hard stuff to move away from, like our line of business apps tightly integrated. I wish we could move away, less apps to manage but it's doable in our case.
r
the "everything running in the browser" experience varies widely from user to user as well too - diagnosing performance issues is a challenge when you don't know if debbie also has a tab open to some webpage running a crypto mining script or if jim has cat videos playing while trying to deal with a large spreadsheet .. from a compartmentalization standpoint i hate it personally
thankyou 1
p
scrolling through this chat and it has all been touched on. Addins, lack of "click to open" outside onedrive etc. We are moving as much as we can to the web instances, but there is always that one group..
😎 1
j
Really appreciate everyone taking the time, not a lot here that wasn't expected really, summary below • The expected Add-Ins or Plugins or native integrations or Macros are problematic (not suitable for Web) issue is real • Usability is somewhat of a question point for some, but not for others. • Local file access is a concern point, however, there are a few points. ◦ There are options to reduce the strain with FTA changes ◦ User training is key - do they like it, likely not, is that part of a technical challenge, not so much ◦ There are read only options for Office available in a thick client format ◦ In the context of a Microsoft 365 ecosystem, these challenges are addressed by storing data where Microsoft wants you to store data - OneDrive or SPO. Yes, yes, I know its not always the fit, but this is their strategy • A point was made about not wanting to manage different user groups. Good chance multiple user groups are managed for licensing (the context of this thread is M365 Apps only). A valid consideration, but not a technical limitation • Use of browser resources is a concern point - I’ve seen what word and excel are doing too resources in their fat form, particularly with plugins - not sure there is more or less going on there, but a valid point about losing visibility/compartmentalisation • Some verticals would be a simple no based on how the entire business operates, however, some verticals have (as expected) a combination of user types, some would be suited to Web, others not
💯 1
d
Speed (web client is slower, plays up regularly, overall experience is not smooth) Offline access (mainly while flying) Accessing files that are local or on traditional file shares Integrations/plugins Those are my main ones. Also these are related to my personal scenario, agree that for a lot of enterprise orgs web apps should suffice for majority of use cases these days esp if all your data is online.
j
That's a very cool workaround for the mailto @Alex Preczewski.
Working in the industries I work in, the OT platforms that are air gapped from the Internet/Cloud obviously need full installs there. But even in IT (corporate) many mining apps will need Excel, Word and PowerPoint installed along-side to create exports and reports. Excel 64-bit is also used very heavily to process data. It's all high performance, so I wouldn't even consider web versions. I possibly work with different use cases to most so am extremely risk averse when it comes to this stuff due to the perceived heavy costs/loss when things don't perform as expected. There is always more than enough to troubleshoot without this complexity.
Sorry if I come across as negative. It wasn't meant to be! 🙂
j
nope not negative, real. That's fine, this is a seeking to understand exercise more than anything else
⤴️ 1
👍 1
j
Late to the party but some line of business apps are “hardcoded” to work with an installed version of Office and not the web apps. i always run into those lovely apps in healthcare space 🙂