I cant wrap my head around properly creating a responsive design using foundation 5 when dealing with grid systems.
Is it imperative that everything be set the column width using the grid system?
To be more clear, does every element on the page require a number of columns for each width (small, medium, large) for the site to be considered truly responsive? Or is it sufficient to set width in % and ems and simple explicit media queries to achieve that goal?
I don't know anything about Foundation 5, but in principle, no, you do not even need a grid system at all to be responsive. As you rightly suspected, media queries used to rearrange the elements you want to move for different size screens will make any page responsive. And yes, set things in em units or %ages - especially the media query breakpoints.
Grids are of use if your page content naturally needs to be displayed in a grid like fashion.
By the way, you would probably have had an answer much earlier if you had tagged it correctly. Responsive design makes it a CSS question, so it needs a CSS tag! I just happened to see this because I was searching for something else.
Related
Summary: I have seemingly hit a limitation in Figma when trying to make the columns behave akin to a CSS grid system. I would like to know if I have misunderstood Figma's built in capabilities, if there is a plug-in that solves the problem, if I have to create one Figma frame per CSS breakpoint (undesirable), or if there are other solutions.
Background: As an interaction/ UX designer, I would like to specify the responsiveness of a web based application, so that the front end developers know how the interface should appear at all browser widths. They implement in a CSS-based grid system similar to Bootstrap
So far, I failed in achieving what I want, and the most knowledgeable UX'ers in the company think I have hit a limitation in Figma's capabilities, but they are not certain.
Basically, what I want is this basic responsiveness, but column based. But as shown in this video, none of my experiments work.
I wonder if it boils down to this: If a Figma child element has:
horisontal constraint set to “Scale” and
vertical constraint set to “Hug contents”
Then the parent element cannot have:
vertical constraint set to “Hug contents”
Is this is a known limitation in Figma? If yes, are there plugins that solve this problem, or is it outside Figma's scope to offer this type of alignment with CSS-based grid systems? Obviously, it would be very beneficial if the solution also supports breakpoints.
P.S. I have asked which SE site that was most suitable for this question, and SO was the suggested site. The question was closed on UX.SE.
No, according to an answer on Figma's own forum, Figma's columns cannot behave akin to a CSS grid system, even though “several threads [have] requested [this] evolution”.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Community!
I know, these questions shouldn't be opinion-based and I'm certainly not asking "What's the best CMS???". I'm just at a point of having tried out so many different CMS that I want to know if there does exist one which meets the following criteria:
Very flexible template system, content elements, content columns
I don't really like the complexity of designing with Fluid in TYPO3. I'm not a complete newbie in this area but it strikes me as being pretty complex, you have to know all these functions and knowledge in TypoScript doesn't have much use outside of TYPO3.
On the other hand, I feel the templating is with Fluid is done pretty well. You have your backend layouts where you define your content columns (name and number), where in your fluid layouts you specify which content column (here, the number is used) is rendered where. Inside the backend you apply your backend layout to your root page (it is inherited which I love because it makes changes easier than having to change the template of every single page!) and you can add your content to the column defined in this backend layout. I love this idea!
The point I like is that content can exist outside this structure - you can create a content element and have it just not being rendered because it has no layout column specified. Also if you ever want to change your layout, you can do so by provoding the same column numbers in a new backend layout. The name of the columns can be changed without problems - that's the problem with Concrete5.
In Concrete5, all content resided inside of the "areas" (quasi content columns) on the individual pages. But because Concrete5 has only inline-editing, you can't just change your area names (and they're visible for your editors so maybe you want to change them to a better name, even though there are some standards like 'main' this doesn't fit for Non-English speaking people who just edit content in their language). If you do, you can't access your content inside these areas anymore because it is coupled with the area names (I wonder why there's no ID-system and just a public visibly area name).
Another point is crappy code - I really don't like the output of some CMS very much, even if you can control it somehow, sometimes there are things like many lines of whitespace - really weird. Concrete5's inline-editing-feature is pretty cool, especially the ability to work with Bootstrap and visually layout your blocks to have two thirds to one third width or something like that. But on the other hand you have to have these header- and footer-includes to use Concrete5, so you HAVE to change the output on your site and have to use the div-wrapper to use inline-editing. I don't really have anything against it as long as it doesn't clutter the final output too much (and I think, Concrete5 is pretty ok in this regard).
I LOVE ModX in this regard because after experimenting just a little bit I actually got ONLY my html and the things I put in the page editor in the final source code. The problem with ModX is: there are no content elements/blocks, there are no content columns/areas - all you have is one big editor field. I know, you can adjust that pretty heavily, but in the end as far as I think it's not really meant to offer you the ability to define multiple areas where you can put different kind of elements inside, is it? Like "Header", "Text & Media" or "Slider" in TYPO3/Concrete5, which you can hide (at least in TYPO3) and move on their own.
(And if there is some good kind of version control, that would be great as well, but that's just a thing I like in TYPO3 and I don't like that much in Concrete5 because you can't really roll back changes to individual elements, just to the whole site - and you can't hide part of your content (hide some blocks like you hide content elements in TYPO3) to "save" an alternative version of, say, a header or a normal text element.)
Long story short, I'm looking for a very flexible template system which let's me design the way I want. It should have individual content elements (elements of different types, which I can create on my own as well) and content areas (/columns), so that I can place my content in different places which I can style individually. It should output only my code if possible (like ModX) and be open to changes (like renaming content columns/areas).
Just to recap my problems I have with the named CMS:
TYPO3: too complex to enjoy layouting with Fluid in my regard
Concrete5: too tightly coupled (content is gone when you rename the
areas in your layout, you can't access it anymore at all)
ModX: Not
really built for multiple content elements which reside in multiple
content columns
To not counteract the purpose of stackoverflow, I want to clarify that I'm not looking for every CMS in which the named things are POSSIBLE. Someone might say "You can totally do that in Drupal, just install these 200 modules and you're good to go!") but are actually intended (like content columns and content elements in TYPO3/Concrete5, especially in Concrete5 it feels very natural to work that way, you don't get a sense of having to hack the system for days just to have a good base for developing your site.
I'm asking if there's a CMS available (it should be open-source/free) that actually supports these developing principles by it's nature. I hope you can help me and everyone looking for a CMS which supports this style of working! Thank you! :)
Coming from the TYPO3 world and not knowing other systems well enough to really compare: if you got complex layouts with multiple grids you will have always some complexity for editing as well.
I don't see a real complexity for fluid using fluid_styled_content as fluid is really simple, nice phpstorm plugins exist which do autoocmplete for you for partials, viewhelper,...
Imo you tried the most used cms in php world and stick to the one which fits best for you. Of course the core team and extension authors are always happy to get feedback. So if some specific thing is too complex for you, please let us know!
Area names in concrete5 are completely up to you (although "Main" is fairly standard). If you won't be switching themes there would be no problem.
You are free to create your own theme/page layouts and name Areas however your want.
The basic content in concrete5 are Blocks not Areas. Sounds like you should look into Stacks, which allow you to put as many blocks/types into each for as many as you want. They do not have to be displayed anywhere.
There are many ways to retrieve Pages, Areas, Blocks and Stacks (including Global) programmatically without a name, such as:
$someBlock = Block::getByID(5); // get your Block by bID #5
Not to mention you can create custom View Templates or override the core files to output however you want (not restricted to HTML).
concrete5 can even be ran at the command line.
Sounds like a little time with the Block documentation would completely change your mind...
jasteele12 # concrete5.org
I'm using Ember JS 2.3.0, Ember Data 2.3.3 and jQuery 2.1.4 and I'm having an issue when trying to transition away from a page with a HTML table component on it. The table component is populated with data from this Ember Data call:
this.store.query('log', {filter: {
created_at_from: moment().subtract(1, 'month').format('DD/MM/YYYY'),
created_at_to: moment().format('DD/MM/YYYY'),
object: 'IsoApplication'
}})
which having looked in the developer tools "Timeline" and "Network" tabs is resolving in good time. It has no special jQuery events etc attached to it and is simply a plain HTML table made dynamic with Ember.
However, when clicking a "link-to" helper that transitions away from the page with the component on it there is a huge 10 second delay before the destination page renders. During this time nothing seems to happen and having used the developer tools "Timeline" and drilled down it seems that the delay occurs when the "removeFromListeners" function is being called (see attached timeline screenshot). No asynchronous stuff is happening at this point and therefore no loader appears but it seems that tearing down the table is the problem because if I remove the table component from the template the issue disappears. Without the table component the page transitions almost instantly.
I have attached the timeline screenshot to see if anyone can help to pinpoint the possible cause of this problem.
Any suggestions would be welcome.
Thanks.
Ok, after significantly reducing the number of rows in my table I discovered that the issue went away. #runspired provided a detailed and very helpful description of why my issue occurred, which I have posted below to inform others who may have similar issues:
there's a number of things going on here
I've given a few talks on this (including two podcasts on Ember Weekend (episodes 38 and 39))
I wish I had my chicago-ember talk on it recorded but I don't
but basically, comes down to three things as to why this is slow
and none of it is actually because "dom is slow", that argument masks the truth of the matter
1.) don't render the universe, render the scene
easiest analogy is take any video game you can think of, especially one in which you can "pivot" the camera view quickly
that pivot is a lot like scroll
you really only want to render what's visible at the moment, and prepare content that's closer to the camera's view
but it makes no sense to prepare content that's far out of view
this is a lesson that every native SDK and game SDK has baked in, but which no JS framework has yet realized
when people say DOM is slow, it's really because they are trying to render far more things than they ought to
2.) is a bug in most browsers
memory allocated for DOM is always retained by the tab that allocated it
this allocation persists beyond the lifecycle of your page
it's a true leak that hopefully Chrome etc. will fix soon
or basically, the allocation heap size made for DOM can only ever grow
you can reuse allocated memory, but you can't shrink it
this means that if you generate a huge amount of DOM nodes, even once you tear them down there's a high memory overhead for that tab
which causes performance issues in other areas because less memory is available for JS allocations etc.
this problem is bigger on mobile, especially android, than on desktop. But it can affect desktop too.
Something going hand in hand with 1 and 2
is there's a definite limit to how many DOM nodes you can render before the browser starts chugging
I've found that limit to be roughly 40k DOM nodes, varies from as low as 20k on older android devices to > 100k on Safari
but 40k seems to be a limit which if held to as a target works well for all platforms
if you have 700-2000 table rows, and each row has maybe 3 TDs, and each TD has just one link or span or other element, and then in that you have some text
6,300 - 18,000 nodes
or basically, you're dealing with half of your max budget with that setup
just as the content of the rows
so 7002 - 20,002 nodes counting the rows
and it's likely that 9 nodes per row is a very low estimate
if we double that
you're exceeding that max
and 18 nodes sounds more likely
3.) GC events stop the world
[9:28]
even though the memory allocated by the tab is retained
the allocation IS cleaned up
(so it can be reused for more DOM later)(edited)
so you're releasing the memory for at LEAST your max DOM size (likely larger) all at once
that's a lot for the browser to clean up on
it's also likely a lot of arrays and array observers are being torn down in this time.
#runspired is also the author of
https://github.com/runspired/smoke-and-mirrors which is a project that:
focuses on improving initial and re-render performance in high-stress situations by providing components and primitives for performant lists and svelte renders to match a core belief: Don't render the universe, render the scene.
I am working with MFC code that I believe was developed in the early 90's. I've been given the great task of bringing the software into the 21st century, getting it to work on the likes of Windows 7/8. The application targets numerous platforms, of which one is Windows XP. The original software had a fixed window size and looks terrible on certain OS. I have managed to overcome this but sizing the dialog leaves a lot of grey space. I need to incorporate anchors and docking, similar to .NET.
As always, time is limited, so I need quick, "dirty" solutions, until I get time to rewrite the UI layer. The application contains a number of "screens", each following a similar format. Banner at the top, content consisting of copyright, help on the LHS and task buttons on the RHS and a kind of footer control containing "hotkeys".
As a quick fix, I am thinking that resizing the dialog should cause the following.
Banner is anchored left and right
LHS/RHS content is split say 60/40
Footer is as per the banner
This is made more difficult as different controls are used for different target operating systems/platforms. Basically, the OnInitDialog, uses conditional compilation to to add controls, dynamically, depending on the platform.
To implement this I am guessing I need something like the following...
Each control "remembers" its bounds
I expect this to be tricky as no WM_CREATE message for dialog child controls.
Possibly use OnParentNotify.
Sizing the dialog "remembers" its last size and calculates differences in width and height.
The dialog sends a parent resize message to its immediate children so they can re-calculate layout.
My question, finally, is what is the best way to approach this?
One idea I have...
Introduce a new Widget class that extends CWnd and returns anchor details via a virtual method.
Create controls such as CBanner, CCopyright, CFooter etc that implement Widget
Create a RowWidget for content that sizes LHS and RHS content appropriately.
Now that was hard to put into words!
Any help appreciated.
Thanks
Karl
Actually a very common question and your reasoning is sound, but rather than reinventing the wheel, it might be better to first look at some freely available implementations along the lines you describe.
For example this CodeProject article does what I think you need.
Lately I have been building a mobile phone application using Sproutcore20 and now Ember.JS.
This works great on my iPhone (3GS) though it stutters on many android devices.
The simplest thing, like switching from main menu item, and thus loading in a different view feels all but native.
Currently it makes use of template views which are appended and removed in a statechart. Each main menu item has a main state in which the corresponding views are appended (and removed on exit).
This method seems optimal to me but it does not function optimal, so I am wondering if an alternative approach like appending all views on load (deferred) and visibility toggling would improve performance (1)? It would make the DOM larger and thus operations on the DOM slower.
What is an optimal Ember.js code structure for building a mobile application, and what considerations need to be taken into account when building for mobile devices(2)?
It really depends on your application. In general, limiting the number of DOM elements and the number of DOM changes helps performance. Deciding whether to leave elements in the DOM and hide/show them, or to create/destroy elements on demand depends on the usage patterns of the app. If you expect the user to move quickly back and forth between views, hide/show can make sense.