My Feature Modification Request Wish List

Ideas
1

My Feature Modification Request Wish List (in no particular order):

1. Similar to being able to clone models and Skuid pages, it would be a tremendous time-saver to also be able to clone the following items:

  • Table filters
  • Conditions
  • Page Assignments
  • Lookup filters
  • Tabs (in page layouts)
  • Buttons
2. It would also be great if we could save customized components (filters, buttons, icons, layouts, models, etc.) to a library for quick and easy re-use.

3. Some sort of tool to help with cleanup of:
  • models  - unused fields, etc. 
  • pages and page assignments - to determine pages are not assigned, not active, referencing invalid fields, etc.
4. Customizability on the Page and Page Assignment pages.  More specifically:
  • The ability to create folders seem like a logical place to start
  • The ability to customize the “allow ordering”, order by,  # of records to show, as well as some of the fields.
5.  Some sort of wizard or generator to simplify and streamline the deployment process. I’m not thinking full automated here, but something that could generate the correct VisualForce code (taking into consideration the various action types, roles, profiles, etc.) so that we could simply copy and paste the output directly into a VF page and not have to think about it.

The last two aren’t specifically feature modifications - just general wants for my Skuid wish list:

6. More starter page pre-built templates, including the following:
  • Mobile starter page templates
  • “Complete” example -  meaning all of the various Skuid pages, VF page override code,  etc. packaged together that could be imported for use together - but are already working together as a pre-built 
7. Additional updated documentation and downloadable copies of the Skuid pages used for the Deep Dives
  • For the existing documentation it would be great if the screenshots were updated to reflect latest Skuid and Salesforce versions
  • Downloadable copies of the Skuid pages/components shown in the Deep Dive sessions
8. A place for the community to share and publish our own Skuid Pages, components, templates, etc. 
  • Think of the community doing the work in #5 for Skuid

2

That’s a great wish list Brandon.  Some of those things are already on our wish list too. Some are development projects and some are just documentation improvement projects - both of which we are planning.   Thanks for taking the time to send this all along.  We really appreciate the feedback. 

3

I’d like to add a few more to the list…


1. Conditional rendering of table columns

2. All of the following pertain to the field table used when selecting which fields you are adding to a particular model…

 


- check All/None" option when selecting which fields to add to a particular model
looking at the fields you can add to a model including

- sortable columns (sort by field type, field name, etc.)

- the ability to hide/show certain fields to reduce scrolling and clutter for objects lots of fields


3.
Also, a View/Edit XML link that when clicked would open a context-aware pop-up window that would allow you to paste in a snippet of XML specifying whatever conditions,  as an alternative to clicking through the web-gui to configure the conditions.  Rather than having to edit the raw XML file and find where you would need to edit the text, this would paste it in the right place (or open the XML editor page with the cursor pre-inserted in the right place). 



4

I really like this idea Brandon, I’ve been thinking about adding this for a while. Now the feature has a name and a sponsor: “Contextual View/Edit XML”!

5

Hi Brandon, on your  idea for a “Complete” example, we now have a Trialforce you can install that includes a Skuidified Sales Cloud, including a ton of great pages in a complete package. Here are the links to install:

Install in a Production or Developer Edition org: https://login.salesforce.com/packaging/installPackage.apexp?p0=04ti0000000XnLv

Install in a Sandbox org:
https://test.salesforce.com/packaging/installPackage.apexp?p0=04ti0000000XnLv

6

Thanks for pointing that out Ken.  I’m installing it now.

7

A few more…

1. Exportable Page Assignments - similar to how Pages can be exported (and in reference to the exportable Page functionality, a minor modification request I have is to not have to go in and manually delete the unnecessary columns before importing it.)

2. A published list of known issues/bugs (this may exist, but I haven’t been able to find it)

3.Additional documentation and examples - specifically pertaining to:   

 - filters and conditions

 - some of the more “esoteric” fields/options (e.g. “Other Situation”) that we come across but                haven’t the faintest idea what they are supposed to do, no less how to begin configuring                  them

 - more “best practices” and page optimization information that most Skuid users come across (e.g. performance and administrative overheard considerations when it comes to deciding how to go about architecting scalable and responsive pages and apps in Skuid.)  I’m used to barely having one feasible solution that is supported by Salesforce, eliminating most, if not all “major” considerations.  Using Skuid, I now have 25 ways from Sunday to address the same requirement(s). I am wondering “what” I need to or should be thinking about before I begin building the various pages.

I’ve provided a few specific examples below that come to mind:

1. We have three different account types (Customer, Partners, & Distributors).  When building an account list page, when is it better to add 3 separate models (CustomerAccounts, PartnerAccounts, & DistributorAccounts) versus adding just one Account model to show each account type on it’s tab?    

They all have about 5 -6 fields in common (Name, Id, website, billing and shipping address, etc.) and each also has anywhere from 5-15 additional unique fields.  I’ve built the page out with 3 separate account models and with one, but am not entirely sure what ramifications there are (both long and short term) or other things I’m not thinking about or even aware of.

If there are 3 separate models for the same standard sObject, are there additional queries or calls to Salesforce versus having just one model (assuming lazy loading is not enabled)?  Also, I should mention a limit of 15 records per Account type is in place, so we are not talking about 50 or 100 records being returned, and only the required fields are enabled - so basic “cleanup” has been taken care of to some extent.

2. Another option I considered and built that seemingly works just as well the others, included a “skeleton” skuid page with 3 tabs  - one for each account type (customer, partner, and distributor).  Each tab has it’s own page include component pointing to 3 separate pages I built corresponding to each account type.  How is this better/worse (or indifferent) than the options raised in the first example?

 


8

Glad this is in the works! Was about to post as a new idea. Any update to when we might see it? In particular it would be great to have a View/Edit XML link when editing drawers and pop-ups. If the first iteration could do that it would cover probably 90% of my use cases.