SharePoint Goes (More) Mobile
So, SharePoint 2013’s horizontal menu still has the same touch issues as SP2010; which is extremely disappointing. The Presenter’s company used HTML5 and CSS to address the issue, though Trevor’s solution works just as well.
While SP2010 only has one mobile mode: crappy, SP2013 has THREE modes: crappy, slightly styled crap, and exactly the same as your main site. So, no improvement there.
The presenter also mentioned something called “Device Channels”; basically SP can detect which device (iPad, Windows Phone, etc) is accessing it and assign styles to each device. The presenter indicated that there were reasons that they didn’t use that, however.
Responsive Design seems to be the “way to go”, however. In a nutshell, she described it as different CSS being assigned based on browser width.
She did show off some customization of the SP Horizontal menu based on browser window (www.susqtech.com … check it out on iPhone & iPad … iPad particularly because it uses one menu in landscape and another in portrait).
I talked to Trevor between sessions, pitched a few ideas, got feedback, pitched new ideas, etc, until we’d hashed out a potential plan for responsive designs for OmniPage. Basically, hiding the left nav and horizontal menu if the browser window is phone sized, and adding an accordion, that lets the user switch back and forth between the content and a menu that’s designed for a touch based small browser window interface of the phone). I have sketches, it’s a little difficult to explain. If we implement, I’ll blog it and link to the example.
Given some interesting stats (over 50% of people who surf the web do so, some of the time, on a mobile device … and of those, 1/3 of them ONLY brows the web on a mobile device), I think this could really improve our mobile experience.
SharePoint Business Connectivity Services (BCS)
Good presenter, good info … but I kept finding things stopping me from using BCS!
Presenter recommended a lab, found by Googling “Hands on Lab BCS” … perhaps this one? http://msdn.microsoft.com/en-us/office2010developertrainingcourse_bcsofficelab.aspx
Interestingly, BCS connecting to SQL has the exact same performance hit as using CQWP to query a list, because it does exactly the same thing.
BCS, however, has no cache, whilst CQWP does, so that needs to be taken into consideration.
You DO lose some functionality using BCS … No DataSheet view, no WorkFlows, no item lvl permissioning, no export to excel, no CQWP, etc.
NOTE: Unrelated, apparently you can use SP Designer to hide a field on an input form without using InfoPath using ms-hidden. Must do more research, to address how we’re renaming Title.
Secure Store is the way to go for Authentication.
You can combine BC Filter with BC List (or multiple lists) do do some pretty cool stuff, but you can’t stack Filters, so it’s not as cool as just handing your data to Simile Exhibit. But it’s a start … and it only works with BCS data.
NOTE: We may be able to connect to the ULS Log using BCS, which could be handy.
The chart web part is pretty cool … and it’s deprecated in 2013.
Overall, cool stuff … that I don’t see a use for (for us).
Upgrading to 2013
We’re going from 2010 directly to 2013 which is the easiest thing you can do (since upgrading 2007 is apparently evil).
One thing I missed when testing this before is that there is a feature called ‘Evaluation Upgrade Sites’, where you can have SP make a copy of your site collection and upgrade it to 2013 experience without touching your real site.
NOTE: Even if we can upgrade our 2010 sites to 2013 experience, and make the public facing side look identical, we’ll need to address the fact that the back end that our Content Contributors use does look significantly different.
When we do go to upgrade, you can apparently set entire site collections, or even entire SQL databases to read only to stop your users from making changes whilst you’re doing your migration.
NOTE: Fashion does have one form that submits to a list, so we’ll need to address how that will be ‘down’ during the upgrade.
One user mentioned that they used JS/CSS to obscure the editing elements on the ribbon.
Thinking about it now, I’m realizing that another thing we could do is take the “publish.” sites offline in IIS during the upgrade … that’d stop people from updating their sites really quickly. 🙂
NOTE: Will our customization to remove /sites/ from the URL persist when a site is transferred? What about when it’s updated to 2013 experience?
Lastly, there’s a free product called the “Microsoft Productivity Hub” that we can download that has training materials that we can make available, as well as uploading our own. It’s a site template.
