Something that would be extremely beneficial is if in the SKUID composer it allowed you to add comments, functionally similar to comments in code, where you can add blocks of text that describe what’s going on with the items you’ve created in the editor, but these “comments” should only show up in the editor, not the published page.
Perhaps even having the ability to add comments to the titles of objects (containers and such) in the SKUID composer, so you know what a particular container is for / contains in the composer, and have added details on how it should be used right there so when scrolling through the interface you have helpful descriptions reminding you / telling other people working on the page what everything is doing.
Page 1 / 1
This would be a huge benefit to the skuid product. Every component ought to have a Comment field to explain why or how the developer is using it.
There should also be a Comment or Documentation component that the developer can drag onto the page wherever it is applicable. Many of my pages do this with the Rich Text component, but I have to set a rendering rule (Display Logic) where logged-in-user-profile = ‘DOCUMENTATION’.
Agreed, this would be hugely helpful. We have done this in some places (Action Sequences have a “Description” property that you can use to leave comments about what a given sequence is used for), but that’s about it, it’s not consistent. This would be very helpful.
Definite +1 for this request. Building in Skuid is very fast…as in faster than Lightning ;)…which as a side effect means technical debt can also build up very quickly. Without comments for models (including specific fields, conditions, and actions within a model), components, and actions (when not packaged into an action sequence), the tendency is to not touch what has already been built so you don’t accidentally break the page…thus technical debt buildup. Over time, a page’s performance can slow, and when it comes time to fork the page into 2…it can be a headache having to perform a fair amount of archeology to determine what components, models, etc. need to be ported to the new page. This one is definitely at the top of my wishlist 
Update:
I’ve found a strategy for assisting in organizing my pages in the editor and having makeshift “comments” keeping the page orderly both for using the editor to make sense of different things on the page, and for different display logic / views.
Basically I’ll organize my pages into different groups of Tab Sets, and then hide the tab headers to people viewing the page, showing only the active tab. Then I’ll name my tab something helpful to see for me on the back-end. This keeps the tab set headers visible in the editor, but hides them from view when the page is actually rendered.
To do this, you add some CSS code that will hide the tab headers for the tab set you assign this class to:
.hide-main-tabs > ul:first-of-type { display: none !important; }```Just add this CSS class (hide-main-tabs) to your Tab Set. Then the tab headers are hidden, and only your main tab is displayed. You can then just call the tab what you want to call it to make sense of the area you’re working with in the editor, and it doesn’t show up to your end-users.
This also lets you have a tab set with multiple tabs, and through display logic only show the tab you want to show, giving you different views for different users and making it easy to organize the different views on the SKUID editor so you can make sense of it from a design standpoint.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.