Just had a read of this great tutorial on building AppExchange apps with Skuid: http://help.skuidify.com/m/11217
3 questions spring to mind.
1. The section on end-user customisability is compelling. But the Skuid page composer is so much more powerful than the standard Salesforce page layout editor that end users could easily get themselves into a bit of a mess. I’d love to see the ability to allow end users access to only a cut-down Skuid page composer - one that, for example, removes access to Javascript and CSS resources. Zach mentioned to me once that this can be done with a bit of creativity, just wondered if it was on the near-term roadmap to make officially available.
(An important related point is that with a bit of training, an end-power-user could manage the standard Skuid page composer, particularly given the ease of restoring previous versions. Doesn’t stop me wanting the cut-down composer, though. :) )
2. The section on shipping our app’s core Skuid pages using a static resource is fantastic, and they can also be locked down, which is ideal. So then the path for an end-user to customise one of our core pages then would be to clone it and do as they please. That of course may affect hyperlinks to that page, but we’ve addressed that by housing our Skuid pages within Visualforce pages and having custom setting fields that effectively say “What Skuid page do you want to load for each core Visualforce page?”. The system admin can then set those to the relevant cloned pages if they want, and the hyperlinks remain because they point to the VF container pages. Is that a good practice?
3. End users who clone our Skuid pages to customise then bounce off the upgrade path for our core Skuid pages. Using the custom setting technique above, they can of course switch back to ours at will. Or they can re-clone our new page once we do a release. So it’s not all bad news, but it isn’t entirely seamless. Are there any better ways to manage this?
- Some nice features coming in the Skuid Summer 14 release relevant to this are the ability to set, globally for an org, which Skuid Page Components are available in the Page Composer, via a feature called “Component Packs”. So you could, in effect, do any of the following:
- hide all the standard Skuid components
- just show specific components you’d like (i.e. just Table and Field Editor, or just Calendar and three custom components you’ve made, etc.)
- categorize components into Folders / Groups
This is managed via a new Custom Setting. So you could ship a stripped-down Component Pack with your app. But if you want to add on / improve the feature set, you could reenable the Skuid Core Component Pack (or some other Component Pack that ships with your app), when you are assisting the customer.
2. I don’t see this being a problem, although using Page Assignments would be another alternative.
3.This is another area for potential improvement in the future, we have some ideas about letting you show a Notification in the Page Composer if there’s a “new version” of your managed page available for you to upgrade to — which would proactively encourage your users to get back on board with your standard offering. Just ideas right now…
Zach … thanks for the quick reply. So:
1. This is properly exciting stuff, exactly what we need. Can’t wait to get our hands on it.
1a. We’ve dabbled a little in creating custom Skuid components, but haven’t tried the following. Is it possible/easy to clone standard Skuid components (e.g. table) so that we can offer a cut down version in our Component Pack? For example, we may want end users to be able to change the fields in a table, but not change the table properties.
2. Good to know.
3. Interesting, sounds promising. Will keep an eye out.
1a: No, we’re not providing any guidance at this point on offering stripped-down Builders of standard Skuid components. It’s definitely possible, but we’re not supporting that right now, or in the immediate future. Interesting idea though, the use case makes sense.
Glenn brought up some of the same thoughts we have as we get ready to release a managed package that is Skuidified. Some of the feedback and issues we had with end users (admins) is that if they start changing field editors, etc… it is easy for them to acidentially remove or change a model and then of course that breaks functionality of our released page. I know I discussed with you Zach locking down our pages, which solves this issue, but then they loose the ability to be able to just add a field to a field editor or add a new editor (similar to a section in SF) and add a field to it without doing a full clone. Sounds like Summer 14 will give us some flexibility with this. For now our thought is to lock down the pages and have them clone and use page assignments. Skuid gets better with every release!
Glenn, curious when you packaged your app, since we are doing the same now…did you create a managed extension package in your packaging org.? Meaning it took your existing managed base package and made it an (extension) of Skuid (dependent), or did you create a bridge by uploading your base and Skuid into a separate dev org. with a new namespace? Been talking to Zach about this today pro / cons. We are leaning towards taking our exisitng base managed release package and making it an extension of Skuid. Any feedback would be great.
View our Community Site Map
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.