We are gathering ideas and feedback about how the users work with layout widgets in complex
It will be very helpful for us if you are so kind to answer the following questions:
1. What kind of problems do you encounter when working with layout widgets? What is
your typical/most common use case scenario?
2. How complex templates do you have - like numbers of placeholders, closeness and do
they overlap? Screenshots and example master pages will help us a lot (we will
use them for usability testing).
3. What is the type of templates you most commonly use:
a. master page with defined placeholders
b. template from scratch with added layout controls
c. a combination of master page with defined placeholders and layout controls
4. How deep is the nesting level you reach when using layout controls (the maximum number of layout controls inside layout controls you had to place to achieve a desired result)?
5. Do you need an ability to name your placeholders and if yes, why?
Looking forward to start a discussion on the topic and see what the issues you encounter
are and how we can address them.
Any comments and feedback are welcome.
You have my feedback on the other post, and the issues list on my site, but let me also just note an important one...being able to choose\set the element names.
Just like we can set the wrapper element (div, section, etc) on the ContentBlock I'd like the same on the layouts if possible please.
How about something basic that have been advocated quite frequently and existed in 3.7. Don't allow widgets to be dragged and dropped in to any area except for a widget placeholder. Dragging and dropping anywhere produces strange bugs and defeats the purpose of "widget placeholders". Also put the names of the placeholders that are coming from the masterpage since this helps content editors and designers make sense of it when the edit mode isn't identical to the public view of the design.
I'd even prefer the names to be subtle overlays than taking up more space on the page, even if they're 20px high it adds up...and layouts need to have names as well (at least on the page template level, not just masterpage placeholders). Also @Basem I'm not sure if you'll agree, but a way to set a better name would be preferred (not just showing the "ID" as you can't have spaces)
Yes! Any name would do really because guessing isn't fun nor accurate.
+1 for Steve and Basem comments
Also please an option on a layout to ignore responsive rules, or a set to pick which it will be allowed use.
Also need I say... optional Twitter Bootstrap support!
Pretty much what has been said already. The ability to have some type of placeholder labeling built into Sitefinity and a more transparent overlay UI for edit/more drag actions.
Complex designs that make use of position offsets very easily break in the backend due to the extra space overhead that is created by setting min-height for the widget toolbars and docking zones. One suggestion I have had in the past was to check the feasibility of having a small overlay icon that would indicate to users where they can edit and when they hover over the widget then push some type of edit overlay where you can handle the drag/edit/more scenarios.
Better custom page layout support would be nice too. There are known bugs sitting in PITS where some weird issues occur and I think Steve has outlined them in his blog and other channels as well.
There is also a bug that I have issued through PITS long ago where using things like iframes in content blocks and/or flash files can prevent users from being able to edit page layout properties. One quick example is that I just put a 6.3 site together and dropped a Google Map onto the page via content block. When going to edit the layout properties you find the dialog does not allow you to view spaces or classes.
Here is another good example of some issues I run into when trying to utilize layout widgets. I want to set margins on them, but I do not want the margins to be rendered as inline styles in the html markup so that I have better/easier control over them via css. This is really key when I am working with responsive designs
So let's say I have a 50/50 widget where I add a class called .custom-margin to both column 1 and column 2. What happens is that both columns get the correct margin, but they break out of the main content area and sometimes become obscured by other widget in the template. Setting the exact same amount of margin on each column via the UI will work fine because Sitefinity re-calculates the width of each column (which can be annoying too).
Basically if there was a better way for Sitefinity to calculate dimensions using box-sizing: border-box; when custom css classes are assigned to widgets.
Attached is an example of what I am talking about.
The first set of layouts in the screenshot is where I add my own css classes. The second set shows what happens when using the Sitefinity UI to set margins.
I understand what I am asking for is probably not something elementary to do, but food for thought.
Responsiveness part has to be improved I guess. There are 3+ sections where you have to manage rules, that's confusing (Settings, Responsive and Mobile Design Section, Template Itself). Responsive styles are attached to the page (frontend) as a separate file, no option to bundle it.
I guess, as Asp.net Web API team decided to use third party json serializer (newtonsoft), you could delegate this task to a third part specialized in it, and include Zurb foundation or Bootstrap.
Clicking edit to add a css class to a layout seems to force it to add inline style attributes with the percentages set.
Let me disable the properties edit dialog on custom layouts (mainly due to the above bug, but we also don't want our client resizing the columns anyway - currently using a css hack to hide the edit button).
Add a tab layout control with nice html.
I've seen a few people try support bootstrap columns but there's been issues
Here are my two cents
I usually create my own .master file in VS. Then I base page templates on that master page giving the clients either
1) different design and/or
2) different layouts
My clients usually then just add layout widget on page levels which mostly would be some 50%/50%
2) On my newes site I have only 3 content placeholders in my .master and the rest will be done in page templates with layouts. I could have .master with one row for example. Then create a page template that would split that into (25/75). 25 % for secondary navigation.
One think I would like is haveing the ability to have fixed colum width: 200px,*
3) see above c)
4) contentplace holder on .maste and tow layoutcontrols usually do it for me
5) It sure would be nice. Sometimes when it gets a bit complex
- Yes it would be nice if you could prevent dropping in outside placeholders
- I had issues where it was hard to acces some content dropped because maybe some of my placeholders where only 30 pixels high.
I agree with pretty much everything that has been said above, but I have a "nice to have" feature that I think would be a huge help.
The ability to export my master page, page templates, widget templates, and themes into a zip file and then import them into another Sitefinity environment. This option would be huge for your marketplace. Imagine if I could visit the Sitefinity Marketplace, inside of the Sitefinity CMS, and pull down a new theme, master page, widget templates, or page templates. Platforms like word press have been able to pull down new themes and even new functionality for years.
In know this a little outside the scope of this forum thread but wanted to see what people thought.
Using responsive design causes the sitefinity grid css to be added after regular css.
No programatic way to create layout controls (dynamic tab control)
Change/add class to layout control and it removes the name and becomes "custom".
Often the problem isn't about complexity, it's about design (fixed height, overflows hidden).
In combination with responsive it would be great as Steve said to be able to 'de-active' rules, and have the rightside sidebar be draggable in order to preview responsive breakpoints.
C. I tend to define 'wrappers' or regions in the masterpages and the individual layouts dynamically inside Sitefinity. The .master gets inserted to Sitefinity, base layout gets defined there, and the inner templates you build with layouts.
4. Usually around 3 or 4, often spread over a masterpage and inherited template.
Say an innerpage with side navigation would be (bootstrap-wise) a container in the .master.
For side navigation on the .master inside Sitefinity you'd drag a 3 + 9 layout. Then the 9 column layout for the inner page might have a certain subdivide, either on page or on template.
5. Yes this would be great.
I'm still for giving us a data-sfplaceholder to fill on edit of the layout or hardcoded in the .master page.
It can help users identify what area is what so they won't drag something in the wrong region.
Simple approach would just be to load the data-sfplaceholder attribute in edit mode (page/template)
Add a checkbox somewhere on page edit toolbar to toggle 'show tooltips' and when checked it turns the data-sfplaceholder into a title
(which will give a tooltip on all browsers).
Thank you very much for your valuable comments and suggestions!
As a next step we will analyze all the feedback and will prepare a list with possible solutions and plan for improvements which will be posted here for further discussions.
We don't use Sf layouts on our site for one reason: using the Sf responsive is too time consuming and cluttering. What we end up doing is creating our own custom grid layouts. The biggest culprit is:
Inline style width. While I understand the need to do this, adding inline width will break grid breakpoints unless you fight it with !important. When you add a layout to the page, it won't add inline width until you adjust the columns. Once you do that, there's no way to back out of inline width. There needs to be a way to reset the layouts back to the default and remove all inline widths.
Use grid classes instead of width. With Bootstrap, Foundation, and all of the other grids out there, please add support for it. It would make everyones day if instead of adjusting percent widths, you just adjust the grid value for each column. This way the css will still be in control of breakpoints and it will allow us to not hack or avoid the layout tool.
And thanks for the detailed replies!
As a first step we will introduce a new Name attribute which can be used with both the content placeholders on master page, and with the layout placeholders inserted with the layout control.
We have the following questions:
• Assuming that master page content placeholders have descriptive IDs, do you expect to be using Names for content placeholders as well? Please, clarify.
• If a content/layout placeholder has ID and no Name, shall we display the ID in Page Edit mode?
• If a content/layout placeholder has both ID and Name, shall we display the Name only, or both Name and ID?
Your feedback will be greatly appreciated.
We are working on the design prototypes, and will show you links shortly.
I would like name to trump ID, but ID if not specified, fail to see the need for both seeing as the ID is lame :)
Like I want to name something "Ad Container 1" not have it be "adContainer1" (like in 3.x). Trying to make something descriptive with no spaces is terrible to look at.
We are ready with a preview of the named placeholder feature.
If a master page content placeholders with IDs: Header, Footer, and this master page is applied to a Sitefinity Page, IDs will show in page edit mode: see here.
User editing dropping layout elements on a page will be able to specify “Label” for each column (layout placeholder), see here. The labels of the layout placeholders will show in In Page edit mode like this.
In Page edit mode, when users are about to drop a widget, they will see the placeholder name in the yellow rectangle. Also, a border will appear around the placeholder where the widget is about to be dropped. See video: http://screencast.com/t/d8vnC1677taS
The questions to you:
We look forward to receiving your feedback.
1) Do you want to have labels (names) in master page content place holders, in addition to IDs?
2) What should happen if a layout placeholder doesn’t have a label? Shall we display:
>> layout placeholder ID
>> layout placeholder class, or
A preview of all versions is here.
1. It would never hurt to have these in there. At my company we use a lot of master page layouts so having the labels show up there would be very helpful.
2. I think the order should be Name -> class -> id -> nothing. As long as Label Name trumps all thats the only thing that matters.
Can we get an idea of what the new Sizes options will be? With all of the frameworks out there that uses the grid system (e.g. Bootstrap and Foundation). Would it be possible to have an option to use grids instead of percents? Or at least a way to turn OFF the ability to add percents to override the layouts? As it stands right now if a client changes the percent of a column it adds "width: 33% !important" to the layout. There's no way to change this as it's inline and !important and it locks it in place, there's no way to remove it even if the client wanted to.
F'ing brilliant :) I love it!
I was (as I'm sure others were) expecting like annotated tabs or something like 3.x...this is much more slick.
(FYI though, don't care for variant2 showing classes...at least don't show the native SF names)
I would prefer nothing to be shown if we have not set anything in the Masterpage or layout placeholder because I think if someone does forget, does not want, or does not know how it would be confusing to endusers to see
Content_C001_Col02 or sf_2cols_1_25.
Also most of the time I (maybe just me) have a master page that will hold stuff from the page templates so most of the times users would not need to drop anything there.
Currently, the page designer allows the user to place content before and after the drop zones as well as within the zones. I understand (from asking about this before) that this is "by design", but the problem is that it is error-prone. Users mistakenly drop content outside the zones that have been setup for their use. The resulting incorrect page layout causes support calls.
I recommend that the before-and-after drop capability be enabled only within the page template designer. When working on templates, it is valuable to place content above and below zones. But in the page designer, this should be disabled.
and thanks for the valuable feedback! We discussed internally and this is the plan for iteration one: for master page contentplaceholder, display ID only. In layout placeholders, display Name only (and no IDs or Classes, since these are not very informative). Later, we might add Names in Master Page ContentPlaceHolders as well.
Gary, as to your request, it is on our list as well, and I'll raise its priority for the next release.
Thank you again for your time,
I am excited to announce here our new Sitefinity project!
You can find out the first bits of information here: http://projectfeather.sitefinity.com/
In short, the main task with this project is to make Sitefinity fun for Front end developers. Basically, you will have full control over the HTML. It will be based on MVC and AngularJS and will also support Bootstrap and more.
It won’t be part of Sitefinity at the beginning but it will be available for download in GitHub.
We are looking forward to feedback and ideas in our Google+ group: https://plus.google.com/u/0/communities/101682685148530961591