[BBLISA] What does SharePoint break for non windows users?

[Paul Beltrani]

Thanks for the in depth replies.

I agree, SharePoint is a whole cluster of tools and protocols and that's
part of the problem.  It's being pitched as a panacea but the fact is it's
way too many things to be able to say that.  Some features will work well
on all platforms others, much less so. That's why I asked, "What breaks?"
I don't have the time to spend verifying what works so I was trying to get
an idea of what may be too painful to deal with.

For example, I respectfully disagree that "... as long as you make mac &
linux support part of the design requirement for this consulting company,
you'll be fine."  Calendaring is a perfect example.   Calendering using
Linux and Exchange is next to useless.  (Yes, I know I said O365/SharePoint,
this is just an example.)  On Linux, I can accept a meeting invite but:
  1) I have to read the email then "accept" i.e. import the invite
  2) If someone changes something, e.g. reschedules, the update doesn't
automatically appear in my calendar
  3) Scheduling an meeting and booking a room doesn't work in a useful way



Several people have been kind enough to reply off list.  I'll post a small
summary in the next day or so.

  -- Paul Beltrani

On Mon, Aug 31, 2015 at 8:13 AM, Edward Ned Harvey (bblisa4) <
bblisa4 at nedharvey.com> wrote:

> > From: bblisa [mailto:bblisa-bounces at bblisa.org] On Behalf Of Edward Ned
> > Harvey (bblisa4)
> >
> > as long as you make mac & linux
> > support part of the design requirement for this consulting company,
> you'll be
> > fine.
>
> By the way, there's a really common pitfall here:
>
> When deploying a solution and supporting cross-platform users, it is very
> common to test some feature list, and determine, that X, Y, and Z don't
> work on linux clients (or whatever). Your design requirements should NOT be
> everything working on every platform. That's simply impossible, and the end
> result would be disabling features that are useful to some group, just
> because they don't work for another group. Your design requirements should
> be instead: Either include everyone in the design & testing of the system,
> or at least appoint some representative from each group. Ensure the testing
> covers expected workflow, and even if the windows users get some extra
> microsoft integration features that are nice but unavailable to non-ms
> users, that's not a problem as long as the non-ms users have something they
> can work with to get their jobs done.
>
> Supporting multi platforms means acknowledging that each platform is
> better than the others, in their own ways. Don't hold everybody back to the
> lowest common denominator - Let each platform do the stuff that it's best
> at, even though the other platforms can't. Give people options and choices,
> and that includes *both* making some attempt at providing every service on
> every platform, *and* having access to the other platforms (in VM's) for
> situations where it's warranted.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bblisa.org/pipermail/bblisa/attachments/20150831/c946f58b/attachment-0001.html>