I'm trying to figure out why I would use a grid system. I have read some but I just don't get it. I'm used to just putting stuff in html on a page and beind done with it but I have a new project and would like to use a grid because apparently it is a best practice.
I read in one article referenced in another SO question and it said that grid design was in all sorts of development, even application form design. That made me think of things like snap to grid, etc. and I didn't know if the grid in the web design sphere was the same. I was hoping someone could give me a brief but not overly complicated view and not a link to Google which I have used already.
Thank you for any help.
EDIT: I found this website the easiest: http://www.zurb.com/playground/css-grid-builder but again, what do I do with 12 columns? Is everything in a column "smashed" to fit in a column? that doesn't make sense to me.
EDIT: I read the grid 960 tutorial below and was feeling better but at the end it says:
You can just as well use the concepts of Grid 960 in the production code, but it is not recommend sticking with a framework all the way through production. CSS frameworks are just like any tool, they have their uses. With that in mind, go forth and prototype!
I'm not trying to take this out of context but if I don't use it in production, what's the point? I understand the need for prototyping but if I like the prototype why not use the 960 grid? I may not understand the comment. Thanks.
EDIT:
Is the 960 system for production?
I think you're too focused on thinking about grids as applied to web and applications, and need to do a little research about the underlying reasons why grids can be useful for any form of graphic and information design, whether pixels on a screen or hand-drawn ink on paper.
I would recommend you take a step back from the computer, forget about 960, divs, snap-to-grid, and HTML entirely for a bit, and if possible flick through a few graphic design books and magazines and do a bit of doodling. Or even just pick up a newspaper and have a think about what underlying grids they use (how many columns are there, are they the same width, do grids differ across pages or sections, which elements stick to the grid, which diverge from it?).
The Grid System has a good list of resources.
Then you should be in a better position to think about how grids in general might be useful for your projects, and whether a particular model such as the 960 grid might be useful.
When i design any user interface/web design i don't pay attention to a grid layout until i start to have my main elements constructed. once that is done i implement a grid to flow nicely with those main elements for easy visual scanning
Related
I've recently decided to create a web app to host some algorithms - I normally just create them without care for UI. However this time I need to dive deep into UI. I'm familiar with bootstrap, css, asp.net and have made a good start.
I'm finding it very difficult to deal with asp.net controls in the design view and having too much trouble trying to achieve simple tasks such as moving controls to different areas of the webpage. When I have two textboxes the design view forces one on top of the other leaving me so confused. Then when I try to move my bootstrap button it randomly creates paragraphs and refuses to move the button!
I'm looking for some genuine sincere advise on how I would deal with the design view on asp.net when moving controls and what the best techniques are. Also advice on how to make a modern UI, best techniques (perhaps bootstrap mentions) etc...
I am creating a fairly simple data display app in asp.net (visual studio 2015) - (most of the algorithm complexity is going to be behind the scenes and nothing to do with UI). Comprehensive and detailed advice would be really appreciated. Specifically modern good looking UI in relation to data grids, textboxes for user input (as parameters), dropdowns - you know the typical data app.
I'm sure this will be greatly helpful to many others as well!
Yeah, as I web designer who has had to work with asp.net in the past I completely feel your pain. It's not easy to get a modern look mostly because asp.net isn't a modern tool and kind of has a visual vocabulary all its own.
That said, I found I could get decent results by sticking as close to CSS based solutions as I possibly could. You can see some of those results in the following links:
http://www.design-experiments.com/
http://www.troyjnorris.com/shoppingcart/
I found that a minimalist approach tends to come with the best results.
A good process to follow:
- Build what you want to build.
- Add container divs to make selecting elements easier around your controls. This will greatly improve your ability to position elements the way you want.
- Use your browser inspector to figure out the auto generated element names as they appear on the screen. Getting good selectors is half the battle in CSS.
- Rip out the styling you don't like. Standard reset style sheets won't do here. You'll have to build your own to zero everything out on the elements you want to style so you're not fighting the out of the box look of the controls. Again you have to rely heavly on your inspector in a web browser to see what styles everything is inheriting.
- Use google fonts to define visual style of the page.
- Stick to mostly black or white backgrounds.
- Bootstrap is helpful for a responsive grid, but won't do much good attempting to style most of the elements on a page as they're not meant for that.
- As you might have noticed in the examples above the visual interest comes from elements that are unrelated to the asp.net structure and limitations. So have something like that, even a background image or some paralax so it feels like something is going on on the page.
Hope that helps.
I wanted to get opinions on Responsive Design approach, both for designers and developers. My experience has been thus far using a gridless approach, where media queries change DOM elements at the needed breakpoints. This has allowed me to be very nimble for accommodating design specifications. Sometimes I get a "grid" design that just doesn't break down to the right number of columns and that would screw up using a standard grid system like bootstrap (though I realize you can easily customize bootstrap to a certain degree). For example, I once received a design having layouts for 10, 8, 5, and 2 columns.
My concerns are that I'm perhaps:
Making the whole implementation harder than it is.
Ending up with complicated, fragile (and sometimes spaghetti) CSS.
Making future development more difficult.
I'd appreciate any opinions regarding pros and cons on using a Responsive grid or going custom gridless. Do we need to keep the designers on their toes and QA the design as per platform? Is there more flexibility to grids that there seems to be?
I'd prefer to start using either Foundation of Bootstrap, but any recommendations are welcome. Thanks!
Last year we started to use Twitter Bootstrap http://twitter.github.io/bootstrap/ and it became an excelent way to guide the responsive design on our web application.
Take a look and check the benefits that you can get. For us, the most benefits were:
- Cross-browser & Responsive (of course);
- Guide with great documentation to developers (that probably was the greater);
- Ease and simplicity;
If you're all about developing your code more from scratch than utlizing some pre-build foundation then I first suggest a look at XY CSS. XY CSS allows you the versatility of defining however many grid columns you want. You could design with 36 grids in mind for example, which would potentially allow you to contain 36 individual columns across the width of your screen.
Another option would be to use a pre-build but relatively easy framework to modify, which I would suggest Columnal. I like Columnal as the CSS inside is well written and it is not overly complex while also not being too simplistic to be limited in functionality. It's also very easy to modify.
I would suggest against Bootstrap because firstly, I am not a bootstrap fanboy, and secondly, I find it rather "bloated". By bloated I mean it provides you with a lot of crap that you don't necessarily need, or stuff that you want, but you would rather use a different system that is faster, or more well documented, or any numerous other reasons. My primary beef with bootstrap is that it was originally made for Twitter, and then they said hey let's give it to everyone else and they modified the shit out of it and now it's this unkind beast of thing where you almost have to use what they give you because if you don't the system punishes you at every turn for trying to change anything. I prefer to stick to systems that were originally intended for use by the likes of people like you and I. For that same reason, I would suggest foundation or bootstrap.
This is my personal opinion and should not be construed as anything but my opinion.
There are many grids and framework to choose from. A Google search for CSS frameworks will return a dozen articles that themselves list a number of frameworks to choose from.
When it comes to choosing one, it's easy to be lost without having an intimate knowledge of all of them.
What are the main factors that go into choosing a CSS framework, and how will those choices map to certain frameworks?
More generally, how does one choose a CSS framework?
Note 1: I'm using "grid" and "framework" almost interchangeably here, but there is probably one I should use over the other. Corrections on this are welcome.
Note 2: I am well aware that some choices will depend on taste and accordingly, this question can turn into a "best of" contest/subjective topic. I'm trying to keep it as answerable as possible, as I'm pretty sure many have this problem/question of choosing a framework and an answer to that would benefit the community. As such, improvements to this question are welcome rather than just closing it.
When choosing a framework, consider the following questions :
Language : Some frameworks are written in SASS. Others are written in LESS. Yet others are written in pure CSS. Pick a framework written in a language you're most comfortable working with.
Features : Some frameworks offer just a grid. Others add typography. Yet others add a whole bunch of custom UI elements. Pick a framework that corresponds best with the features you want. You don't want a framework with either too few features or one that's bloated and contains many features you never intend to use.
Modularity : You don't want to overwrite 50% of the framework's output with your own custom code. If you do pick a framework that has many more features than the features you need, make sure it's modular enough to easily get rid of much of the code bloat.
Responsiveness : Pick a responsive grid if you want your page to be responsive.
Cross-browser support : If your project needs to support older browsers, make sure you pick a framework that supports all browsers you need to support.
I built my own framework Cascade Framework because none of the frameworks out there answered those questions the way I wanted them to. Feel free to check it out.
The first thing to start with are the requirements and goals of your web project.
1. Do you target only a mobile audience?
If you want a Web-App, you'll need more than a CSS framework, a mobile framework that combines look and feel for specific target devices' UI with functional elements by means of Javascript. The next decision will be if the framework better supports smaller smartphone screens, tablet screens or both.
If you don't need the more functional Web-App approach the way to go are frameworks that are responsive. You will have to concentrate on how you want to arrange and order certain page elements on different screen resolutions and what page elements can be turned off on the smaller resolutions. (This sometimes leads to political debates with the stakeholders debating around what is (more) important and what not).
2. Do you target both mobile and desktop audience?
You want a framework that supports reponsive or fluid layouts for greatest support of your audiences clients. If the graphic design you have to produce is more static the responsive route suits better as it allows easier planning in the different stages within the breakpoints. Most designers currently follow flexible approaches, lightweight, elegant, presentational, not-so-portal-like that also allow fluid implementations (where certain or all page elements are allowed to stretch or grow according to the client/browser viewports).
3. Do you target only traditional audience?
Then simply choose the framework you're confident it allowes the easiest implementation. Did the designer use a grid? Then maybe the CSS framework fits it. Some CSS frameworks come with a nice variety of design templates for Gimp, Photoshop, Illustrator and others, so maybe the design can be based on the template upfront which allows for the best realization.
Two other considerations:
A. There is no graphic design
If you start without explicit design templates I would choose a framework that allows for easy integration of Typography, offers lots examples, use cases, pre-defined page elements or components (buttons, navigation, thumbs...).
B. Time constraints
No time? Some frameworks come with their own or third party customization scripts or wizards. Choose the elements or components you need, turn on or off certain JS libraries, reset stylesheets, things like that and download the final package. That's it.
Some frameworks are pretty mature and well tested so the absence of a vibrant community may not tell you that much. Depending on your skills a lot of support may not be necessary (and even be a bad sign: The grid/framework should be simple and stay out of your way. The questions that may come up should so be the usual CSS questions that are quite common and can be answered even without details of the underlying framework).
Two examples to illustrate two approaches (more grid <-> more responsive):
http://960.gs/
Definitely take a look. Follow the "view the slides" link to read nice background information. A true grid system. It also links to derivatives that support fluid and elastic looks.
http://twitter.github.com/bootstrap/
Modern, nice hype. Lots of components. Customizable. Responsive.
Web-Apps:
http://jquerymobile.com/ and http://www.sencha.com/products/touch
Most grids are 95% the same: they define the width of columns + include a clearfix.
You can even make your own grid if you like. So therefore, if we understand that most grids are essentially the same, which one is the best to use?
1) Customize Twitter Bootstrap by only downloading the grid. It's a great choice because most people are familiar with the "span1, span2, span3" convention. Also, it's available as fixed width and fluid (ie. responsive).
2) 960.gs is probably the most commonly used fixed width grid.
Unsemantic is the responsive sucessor to 960. Both were developed by Nathan Smith.
One question you can ask right off the bat is:
Do I want the framework to be responsive?
The answer to the question will cross many options off your list.
Another main question I ask is what kind of community support is behind the project. From my experience it is a pain to get invested into a particular project and than have it die and get no support. It is nice to have something that has key backers and a large following.
Considering the UI designers from Twitter made Bootstrap I wouldn't just call it hype surrounding that framework. It's excellent code and the most complete framework. 960.gs is a grid system which boostrap has called scaffolding. Bootstrap is also smartphone friendly. So where someone would have to hack together jquerymobile, jquery, 960.gs, plus all the plugins they need. Bootsrap already comes bundled with plenty to get you started with and works on all browsers and phones/tables.
Having recently become a convert to Grid Layouts, I find myself looking at more and more sites' code and seeing that grids are still grossly under-represented.
While I accept that grids might not always be the only right solution for every web design situation, I think that they are a tool that should be seeing higher rates of adoption than they currently enjoy.
I think if I'd known more about the design approach earlier, I would have saved a considerable amount of time and effort. But Grids don't seem to have the sort of exposure that, say, CSS standards do. Why should that be? Is it even a problem that some people might be missing out on a design approach that could potentially be a better solution to a problem they're working on?
The "Grid Layouts" you speak of, are nothing "special". What you are actually talking about, are "CSS frameworks". These "Grid Layouts" should still be using CSS Standard
You also did not mention the most popular CSS Grid Framework - YUI Grids CSS
I think the reason people normally don't use a framework, is that they don't want to be locked into something with limited customization. Also a big reason is that there is no guaranty that the framework will be around forever, and once it is gone, your knowledge with that framework is useless.
There is also some Criticism of CSS Frameworks on Wikipedia:
Lack of flexibility outside the limitations of the framework
Bloated source code
Additional HTTP requests for multiple files
Lack of substantial additional features beyond what is already available with CSS
Also I think that most web developers just like to write there own HTML/CSS.
I'm going to preface this by saying I personally have no strong feelings about grid-based layouts one way or the other. However, the reason other people may not want to dig into them is that it's a major time investment. For example, if you look over the docs and tutorials for Blueprint, it's clear that figuring out how to use it and applying it effectively for one simple project is going to cost you at least an afternoon, and that's assuming everything works exactly the way the docs say it will. If everything doesn't do that, you could be looking at several days of Googling and forum posting. Nothing against Blueprint or grid-based layouts. It's just the nature of these things.
So for all that risk and effort, here's the payoff: every element in your layout lines up on a grid.
The debate over whether that's worth the effort could go on for years. I'm not going to touch that one. Let's just say it's debatable.
I don't like them. The 960 grid sites don't work well on the iPhone/iPod Touch. And they're terrible on my Blackberry. I prefer a fluid layout that works well on smaller screens.
I don't mind if they show up as 960 on computers, but for Pete's sake, serve me something fluid on mobile. If everyone used this, I'd be happy.
I think we don't see grid layout to be so popular because to use any CSS framework you already need to know CSS on decent level, in case anything goes wrong, or because you gonna need to style your elements anyway.
So the question that asked why somebody who already decently know CSS will start using framework.
I think the best way to use framework is to rip some parts of it (like form styling) and use it with your own developed things.
I know that tables are for tabular data, but it's so tempting to use them for layout. I can handle DIV's to get a three column layout, but when you got 4 nested DIV's, it get tricky.
Is there a tutorial/reference out there to persuade me to use DIV's for layout?
I want to use DIV's, but I refuse to spend an hour to position my DIV/SPAN where I want it.
#GaryF: Blueprint CSS has to be the CSS's best kept secret.
Great tool - Blueprint Grid CSS Generator.
There's the Yahoo Grid CSS which can do all sorts of things.
But remember: CSS IS NOT A RELIGION. If you save hours by using tables instead of css, do so.
One of the corner cases I could never make my mind up about is forms. I'd love to do it in css, but it's just so much more complicated than tables.
You could even argue that forms are tables, in that they have headers (labels) and data (input fields).
In the UK and in US there is a legal requirement for favouring CSS layouts over Tables. Both Section 508 (US) and the Disability Discrimination Act (UK) cover accessibility standards for users with limited vision.
In the UK the legislation extends so far as to actually make it illegal to commercially produce a site that impedes the ability of a partially sighted user in the same way that it is now illegal to have a shop with a step to enter it and no way for a wheelchair user to get in - admittedly there have been no prosecutions over website accessibility yet. However I would always go with CSS as it means that your site design is so much easier to maintain in the longer term.
Investing time in learning CSS (I used W3C schools and .Net Magazine http://www.netmag.co.uk) will pay off.
Why tables for layout is stupid: problems defined, solutions offered.
In my opinion, the bias should be in favour of CSS over IE6 - i.e. unless there's an insanely good reason (e.g. your site is only targetted at people using IE6, which would be weird), it's better to 'alienate' people using IE6 rather than people with poor vision and/or automated user agents. Usage of IE6 is decreasing; the latter group is increasing in number. Even if your site doesn't look perfect in IE6, it will probably be easy for those users to read it than a table-based layout will for those who can't see it.
This is a very general question, so it's difficult to answer with specifics. The two books that are excellent resources are:
Bulletproof Web Design, Dan Cederholm
CSS Mastery, Andy Budd
If you only have to spend an hour designing your overall site layout, that's not bad going.
CSS may not be a religion, but it is how browsers interpret HTML for layout. Like it or not, all modern browsers use (some version) of the W3C box model. To continue to rely on tables is continue to rely on a methodology that is just plain wrong in the eyes of the people who design web rendering technology.
I know CSS can seem awfully complicated at times, but I believe it is a necessity in this day and age (trust me, your clients are going to want it).
If you don't feel comfortable taking the time really learn CSS (so it takes you seconds or minutes to position elements...not an hour), then you need to pass the layout work on to someone who knows really knows the front-end.
Yes, there are a lot of problems with the current browser implementations of CSS, but nothing so drastic that you should ever feel the need to return to table based layout. Just sit down and take the time to learn it, like you would any other language or framework.
The best online reference resource I've found is this one:
http://reference.sitepoint.com/css
But it might not hurt to look at a book like Designing With Web Standards which goes a long way in helping you to understand why this stuff is important.
I was also thinking Blueprint was great until I saw YAML (Yet Another Multicolumn Layout). There is an online builder tool which is fantastic. I can get a cool looking multicolumn layout within 5 mins.
After a while you don't even think about it. Using divs with CSS seems like the easier option imo. Plus, you have more freedom when using frameworks such as jQuery. I couldn't imagine doing some of the cool jQuery stuff without using css or divs. If you use tables for style and layout I feel like you miss out on a lot of new technologies and stay stuck in the 90's.
This may be unhelpful but I somehow don't understand all these problems related to CSS. If a newspaper designer would try to embed a movie in the ad page, everybody would agree that he's a bit crazy. But still those same people pine after three-column layouts in HTML. HTML is just not apt to handle this kind of layout well at the moment. Furthermore, multi-column layouts are generally not really well-suited for reading on computer monitors. Aren't there enough viable alternatives?
And by the way, even tables don't offer a good way of implementing a fluent column layout so this is no reason at all to resort to such hacks. Assuming a halfway modern browser (i.e. > MSIE 6), tables don't offer any advantages over clean HTML + CSS that I know of.
I would just use the table.
In my experience, using a table for layout will work the same in all browsers and the CSS will not (especially if you're trying to support IE6). It's just not worth the hours and hours of coding to get a layout to work in CSS when it can be done in 10 minutes using a table.
The other advantage to using tables is that your layout can very easily dynamically size itself to content. Trying to get that done with CSS is a huge nightmare.
I find there are lots of limitations to CSS that just seem to hint the specification designers don't make websites for a living.
Use HTML tables if you can't do it easy in CSS.
Having said that, some of the frameworks do help and it always nicer to do in CSS if you can manage it.
You might be able to find some inspiration here: http://blog.html.it/layoutgala/
A List Apart is a great reference for using semantic HTML, the Holy Grail article is probably one of the best examples. Also, check out CSS Zen Garden for some inspiration on the topic or read Dave Shea's excellent book "The Zen of CSS Design."
You use CSS for layout because not only is it semantically correct but because tables have multiple drawbacks.
Tables are horrible for accessibility because they break almost all screen readers, which in turn gives the visually impaired worthless information because of the way the tables are read.
They also render much slower than their CSS counterparts. Tables have to be drawn twice, once for the layout, and again for the content. This can mean that if you have a remote image or two on a server with a slow connection that your ENTIRE LAYOUT will not render.
Would you use an array to store a dictionary when you have a hashmap? No. And you shouldn't use a table when there's something out there which works better.